JCA——一個名不見經傳卻重要的JavaEE規範

JCA（Java EE Connector Architecture）規範能夠說是JavaEE規範集合裏最「默默無聞」的，在JavaEE1.3規範發佈時就加入了，比如今重要成員JPA, CDI等都早了不少。從應用開發角度來看，開發一個很普通的Web應用程序，只有幾個頁面，使用Servlet就能夠完成，用JDBC API保存信息到數據庫中，部署這個應用到JavaEE應用服務器中時，就會用到JCA技術。這個很簡單的應用程序只用了龐大的JavaEE規範集30多項中的Servlet和JCA兩項規範而已。那麼，如此重要的規範，爲什麼不多人知曉呢，本文就解釋一些其中的原委。

JCA原意是Java企業版本鏈接器體系結構，這樣一個生澀的詞語不能很好的描述它的功能。簡單來講，這個規範的做用就是定義如何鏈接JavaEE應用服務器和外部的信息系統，這類系統包括但不侷限於數據庫，消息中間件，分佈式緩存系統，ERP/CRM爲表明的企業軟件系統，Tuxedo等事務/消息中間件等。咱們知道JavaEE中的Enterprise是企業的含義，這套規範集的設計目標一開始就定義了是爲企業應用軟件而設計的。在一個企業領域的範疇內，能夠運行着不少應用軟件，若是一套軟件是用JavaEE規範技術開發並部署運行在應用服務器中，而且它須要和其餘應用系統進行信息交互， JCA就能夠發揮強大的功能。

JCA產生於J2EE最爲繁榮輝煌的1.3版本時代，JCA 1.0版本由JSR16提出，當時J2EE整個技術棧已經比較完備，一個需求產生了：如何把JDBC/JMS等鏈接管理統一塊兒來？與此同時，BEA公司的Tuxedo產品也面臨和J2EE進行集成的問題。JCA1.0版本定義了鏈接管理，以及在鏈接之上如何管理事務和安全，但只考慮了Outbound(出站)單向請求的需求。

接下來J2EE出現了羣雄混戰的局面，更多的產商對JCA規範產生了興趣，包括衆多的EAI集成軟件廠商和ERP巨頭如SAP等等，JCA1.5規範在2003年完成，這個版本就很完備了，加入了Inbound(入站)消息流向，定義了WorkManager等重要內容。直到今日，不少Resource Adapter也只支持1.5規範。

在版本5時J2EE從新命名爲JavaEE，這個大版本主要聚焦在JPA和EJB3，JCA沒有變更。JavaEE6版本發佈時JCA升級到1.6，JSR編號是322，除了功能完善之外，主要是加入對Annotation的支持，今後能夠選用XML或者Annotation描述JCA的相關實現類。

去年發佈了JavaEE7，JCA做了微小的修改，升級到1.7，但仍是沿用JSR322規範編號。因此咱們如今看到的最新支持JavaEE7的應用服務器中的JCA規範是1.7版本。在最新的Wildfly（原JBossAS）應用服務器中，數據庫鏈接池，JMS鏈接，接受消息MDB信息等配置信息，都是IronJacamar(JBoss開源組織JCA實現)能夠識別並處理的配置選項。

讓咱們看一下標準的JCA體系結構圖。

四個部分是應用服務器(Application Server)，應用組件(Application Component), 資源適配器(Resource Adapter)和企業信息系統(Enterprise Information System)。

咱們通常開發的應用是將War部署在WebServer中，分別對應於應用組件和應用服務器。企業信息系統是能夠獨立運行的應用系統，好比數據庫，ERP等，資源適配器是爲了和企業信息系統進行鏈接而設計的鏈接適配器軟件，能夠把JavaEE應用服務器和外部應用系統鏈接起來，並提供資源服務給應用組件來使用。

這裏你們可能會產生疑問，通常應用能夠經過JDBC或者JMS接口得到鏈接，爲何還要定義JCA規範接口呢。答案簡單說就是爲了統一接入層的API和被容器管理。應用服務器中的資源池容器（能夠稱爲JCA容器）須要管理全部的外部信息系統鏈接，統一調度給應用程序使用。對於應用開發人員來講，使用這些資源就很簡單，只須要經過JNDI就能夠獲取到可用資源，獲得引用並進行調用，使用完畢後關閉，容器會進行回收，放回可用資源池中供後續使用。全部這樣的資源都會被資源容器識別並管理，JCA的規範就定義了這樣的接口。咱們看到在JCA Javadoc中定義的很清楚，spi包裏面的就是讓資源適配器實現的接口集合。

讓咱們稍微深刻代碼看重要接口：

入口點是ResourceAdapter，這個接口表明了資源管理器的實例，方法定義了實例的生命期回調方法，其中start方法的參數實現了BootstrapContext接口，能夠把應用服務器的服務能力做爲上下文傳入。

經過配置信息，能夠得到Outbound信息入口接口ManagedConnectionFactory，經過這個接口的方法，能夠得到被管理的鏈接ManagedConnection。咱們要理解在JavaEE的世界裏，幾乎任何資源都是被管理的，或者能夠當作是邏輯意義上的資源。經過JNDI獲取到的接口實現類，在不一樣應用場景中，後臺程序已經作了不少工做：有可能加入了豐富功能，也有多是隻是一個空的代理引用，等須要時再去訪問真正的對象，達到節約佔用資源的目的。經過ManagedConnection接口，應用能夠進一步得到實現業務接口的對象，從而和外部信息系統進行交互。

對於Inbound來講，開發人員經過描述文件或者Activation註解定義，編寫MDB來接受外部系統傳入的消息。這裏就引出一個頗有趣的話題，咱們學習JavaEE技術，特別是用到EJB時，規範有一個要求是不能建立線程，由於這樣會讓線程資源很難被容器全面管理。但一個常見的需求就是打開一個端口來接收外部的消息或者調用請求。通常實現方式會建立線程來完成端口偵聽和接收消息，這樣就違反了JavaEE規範要求。那麼面對這樣的需求該怎麼作？這時WorkManager就發揮了它的做用。

WorkManager調度Work，而Work擴展了Runnable接口，這樣能夠把須要執行獨立線程的代碼邏輯封裝到Work的實現類中，提交給WorkManager去調度執行。通常來講應用服務器會維護線程池來合理分配可用的線程資源，進行高效調度管理。這樣相似於打開一個端口去接收消息的需求就能夠被知足，絕大多數JMS實現的資源適配器就是這樣作的。

說了這麼多，可能你們以爲也不過如此，以上的需求不用JCA彷佛也能實現，爲何要搞得很複雜來使用JCA呢？這樣就引出JavaEE核心思想--事務性。

給企業開發應用，事務是一個極其重要的商業因素。咱們知道財務會計核心準則之一就是有借必有貸，借貸必相等，這句話就充分體現了事務思想。企業的業務，流程，事件處理，都是有必定的管理規定的，每一個涉及商業邏輯的業務系統，都會充分考慮知足業務事務一致性的需求。除了剛纔說的財務系統之外，其餘的企業軟件系統也須要對事務有良好的支持，好比請假被批准了，同時可用年假記錄數額也須要減小。整個系統內完成這個業務事務以後，仍是處於一個「平衡」的狀態，能夠說企業應用的絕大多數軟件都須要事務支持。

基於JavaEE開發的應用，通常來講也須要支持事務，同時和外部系統配合來支持完成一項事務過程。咱們知道數據庫，JMS服務器等都是支持事務的，和它們的鏈接中會帶有事務上下文信息，這樣就能夠經過必定的契約（接口），來進行事務信息的傳遞。在JavaEE的設計思路中，能夠經過聲明式編程和對象功能增強來屏蔽必定程度的事務處理複雜性，這部分知識在講述EJB核心思想的書籍裏都有論述。簡單來講是對象經過容器內部傳遞上下文(Context)信息來屏蔽一部分業務開發人員處理事務細節的繁雜編程工做。

這個上下文同時還能夠傳遞安全相關信息，也就是JavaEE的安全相關的內容。JCA一樣對鏈接管理的安全性進行了規範定義，從而能夠方便的對應用服務器和外部系統的安全身份，受權信息進行管理和映射。在JCA1.6之後，對Inbound的事務和安全的定義也完善了。

既然這麼好，那咱們把JCA徹底用在Java業務軟件中如何？等等，JCA也有一些在技術選型上須要考量的地方。

首先是事務支持，咱們知道事務能夠說和系統可擴展性是冤家對頭。事務過程當中必然帶有狀態，而遠程調用服務/可擴展的設計原則之一就是無狀態的，這個矛盾沒法避免。那麼在不須要事務支持或者要求不高的業務範疇，好比論壇，博客等，咱們能夠選擇取消事務支持來提升系統效率。其實這一點也是JavaEE技術在互聯網領域面臨尷尬的緣由之一。

其次，JCA的關注點主要在鏈接管理上，規範並無定義拿到鏈接後如何獲取業務對象引用，以及業務對象接口的寬泛程度等內容。因此對於複雜的業務系統來講，資源適配器中絕大多數配置項都是私有的，沒法所有規範化， 引入JCA對實際應用幫助有限。

第三，鏈接池是高性能業務系統的核心組件之一，數據庫鏈接池的管理是運維工做的主要內容。但鏈接池功能衆多，配置繁雜，每一個應用服務器實現都不一致，而這部份內容並無在規範中定義。因此應用在不一樣服務器間遷移變得很困難，光鏈接池配置就須要作不少工做。

那麼什麼場景適合使用呢？若是使用兼容JavaEE的應用服務器來開發，好比JBossAS(WildFly,Redhat JBoss EAP)，Weblogic，Glassfish，Webshpere等，那麼已經用上JCA。此外對須要支持分佈式事務的軟件系統，進行二次開發，JCA都是良好的技術選擇。典型例子有各類MQ/JMS具有事務能力的系統，和Tuxedo鏈接的WTC資源適配器等。

還有一個更重要因素，就是JCA規範是系統間集成技術經驗的一種體現，任何開發者基於JavaEE開發，須要和外部系統交互，在設計/編碼/上線運營/系統成熟後會發現和目前JCA定義的體系架構會很是類似。學習JCA規範就可以快速掌握這套架構模型，這就是知識凝聚的力量。