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規范就能夠快速掌握這套架構模型，這就是知識凝聚的力量。
查看本欄目
