JCA: Java步入應用集成時代

2019-11-18 13:26:44

字體：大中小

來源：轉載

供稿：網友

　　java 2企業版(J2EE)連接器架構(JCA)是對J2EE標準集的重要的補充. 它注重的是用于將Java程序連接到非Java程序和軟件包的中間件的開發.JCA是由Sun公司領導的Java標準化組織開發的.JCA 目前還是在最后的草案階段, 它定于2001年年底發布并且將成為J2EE 1.3 的一部分.JCA 提供了許多值得注重的好處, 但是直接的JCA編程并不是每個人都能學會.
　　
　　JCA包括三個要害的元素:
　　JCA 資源適配器
　　系統介面
　　通用客戶介面(CCI Common Client Interface,目前還是可選內容)
　　
　　JCA 是軟件工業界在應用程序集成領域建立標準進行的第一步工作,而以前要做到這一點基本上是通過專有的中間件完成的.這是邁向正確方向的第一步, 因為應用程序的集成已經不僅成為了業界領袖面臨的首要問題而且也讓大多數主流軟件商無法回避.
　　
　　JCA 資源適配器是定制的Java程序用來實現對特定的外部程序的連接(無論它是一個以前遺留下來的程序,還是購買的程序).一個遵循JCA標準的資源適配器都必須支持JCA系統界面,以便通過連接緩沖進行性能優化并支持自動的安全簽名.JCA還提供一組界面支持事務治理(雖然實際上在資源適配器中對分布式事務的支持是可選的).
　　
　　一個全功能的資源適配器答應連接到外部(目標)程序來完成以下功能:
　　
　　使得目標程序能夠參與與其它應用程序和數據庫之間分布式的基于XA的事務過程.
　　
　　能夠在不犧牲應用程序的安全級別的前提下掩蓋外部平臺的安全細節.
　　
　　能夠增加應用程序的可伸縮性.
　　 JCA: Java步入應用集成時代

　　要支持JCA的事務和安全功能需要目標程序通過資源適配器為程序的訪問暴露足夠的事務和安全界面.過時的應用程序或者是應用程序平臺假如不經過加強則有可能只能部分的符合JCA標準. 許多的適配軟件很可能只能支持最小的"無事務"選項而且可能只能擁有一個部分支持目標環境的安全結構的安全界面.
　　
　　最小化的資源適配器也許只能改進那些在JCA出現以前由不同的銷售商開發的非標準適配器.在目前的開發階段,JCA與更現代的和更開放的目標應用程序或環境結合的時候最能體會它的威力.到2004年,在軟件集成項目中少于百分之三十的軟件包和遺留下來的適配軟件將使用JCA, 而且擁有完全功能的將少于百分之十--包括對事務的支持,完全的安全性,以及CCI(0.7 的可能性).
　　
　　
　　
　　資源適配器用系統界面來與底層的J2EE應用服務器交互.資源適配器通過JCA系統界面將繁雜的細節處理過程交給底層的應用服務器,從而滿足可伸縮性,集成性,和安全性方面的要求,上層的應用程序假設底層的應用服務器知道如何處理對JCA系統界面調用.因此,應用服務器銷售商聲明支持JCA,其本身并不保證能夠提供對應用程序集成的支持除非銷售商還提供(通過合作或是獨立開發)預先開發的JCA資源適配器.
　　
　　JCA 通用客戶界面是調用程序(用戶程序或是集成中間件)使用的一套應用編程界面(API).JCA CCI被用做對資源適配器的標準訪問過程,不管實際的目標程序或是環境是如何工作的.因為所有的資源適配器支持相同的一套Aip,所有的調用程序和外界程序間的交互過程就形成了標準.但是對CCI支持在JCA 1.0中是可遷的.許多的資源適配器會暴露非標準的但是滿足特定目標或平臺訪問方式的客戶界面.
　　
　　CCI與企業版JavaBeans(EJB)的調用界面是不同的,而且JCA 資源適配器的封裝方式也不盡相同;JCA的Java編譯文件(JAR)與EJB JAR文件有不同的設計方式.所以CCI代表了J2EE范圍內一個新的專門的編程模型;它是復雜的而且需要專門的技術知識.但是實際使用CCI的開發者的大部分很可能將是工具軟件銷售商(例如WebGain和IBM Visual Age)以及集成中間件生產商(例如WebMethods和TIBCO Software),而不是企業應用開發者.
　　
　　要支持JCA, 集成中間件銷售商一般不得不采用一整套J2EE平臺,就象JCA設計需要的那樣(也就是"managed"選項).但它們中的大多數還沒有這樣的能力,所以可能只是實現JCA標準的功能弱一些的"unmanaged"選項.這種情況很可能拖延集成中間件銷售商對JCA全部標準的采用,因而也就會拖延對整個JCA的采用.到2004年,所有主導的集成中間件銷售商都將通過獨立開發或是合作在它們的產品里捆綁進一個J2EE應用服務器(0.7的可能性).
　　
　　JCA 對 Web服務(Web services)
　　資源適配器的代碼是復雜的,需要對目標平臺內部結構的深刻了解和程序設計方面高級的知識.因此,外部應用程序(而不是調用程序的開發者)銷售商將開發大部分的資源適配器.所以,套裝軟件銷售商和運行環境銷售商對它的采用程度將決定整個工業對JCA的接受程序.目前,很少有銷售商已經開始(并己決定了發布時間)致力于為它們的程序提供JCA資源適配器.雖然我們可以預見在未來的六個月內還會有類似的宣稱出現,但是銷售商必須決定是否支持JCA或者Web服務描述語言(WSDL)作為它們標準的外部訪問界面.
　　
　　JCA在功能上比Web服務要豐富,但是它發布起來更難而且限制了銷售商只能從Java環境訪問它們.Web服務界面能夠自動的包括對Java,微軟,和其它結構的支持.一個可能的折衷是銷售商同時提供對JCA和Web服務界面的支持,也許使用Web服務來打包JCA CCI.在未來的版本里,JCA很可能擴展它對xml和松偶合訪問的支持.未來的JCA版本還可能提供對CCI和Web服務的標準化的支持.因此,JCA將為對JCA資源適配器的緊耦合(JCA)和松耦合提供協議.
　　
　　未來對適配器的改進要求
　　JCA要求資源適配器運行在J2EE容器里;非Java目標程序的本地適配器是不被支持的.通常,將適配器和目標應用程序放在一起能夠提高集成度和事務交換的能力.要達到這個目的,用戶將不得不走到標準的前面去.開發一個外部的非JCA適配器然后為它開發一個JCA包容器是可能的.但是這種分布的適配器將不那么好治理而且不太可能實現JCA標準的完整功能.
　　
　　JCA標準沒有解決一個資源適配器是應該總是代表整個目標環境(3270 CICS)還是代表一個或多個外部程序的功能(例如這樣的功能,"從一個3270 CICS 應用程序獲取客戶信息").復合資源適配器--那些為幾個外部環境(例如AS/400和R/3)--則連提都沒有提到.當前的應用集成的實際顯示一個適配器的功能范圍可以是"瘦"或者含有很多的技術而在商業邏輯方面變得"胖"而粗笨.對大多數集成項目來說要害性的異步集成方式也沒有出現在JCA 1.0里. 當實際采用JCA的時候這些問題就會出現而且有可能需要在JCA未來的版本里做進一步的擴展和明確.制定JCA 2.0的工作已經開始.
　　
　　應用集成更大的一幅畫面
　　JCA的范圍被限制在適配器技術里,這相對于整個應用集成平臺來說是一個小部分.許多應用集成的需求和方案還沒有包括在J2EE里.它不支持語義數據傳輸,業務進程治理,異步集成(JCA 的目標只有請求/應答式的適配器風格),消息倉庫和集成系統治理.JCA完全面向對同步復合應用的支持,支異步應用程序集成視而不見.要滿足這些要求,到2004年附加的與集成有關的標準將被添加進J2EE(0.8的可能性).
　　
　　總結
　　JCA是對J2EE顯著的擴展,但它沒有能夠適應所有應用集成項目的需求. 不管JCA如何,J2EE的用戶在建立它們的集成內構的時候將繼續部分的依靠專有解決方案.

上一篇：Jive筆記--Database Package下面的暗黑世界

下一篇：在運行時刻更新功能模塊