| 時間：2003-03-07 作者：Tyler Jewell 瀏覽次數： 3846 本文關鍵字：JCA, Web, Services, EAI |
|
前不久我去了趟東海岸，在那裏我拜會了很多開發者、客戶以及合作伙伴，跟各種各樣的人交談過，並聽到了很多圈內的趣事。
最近，我主要忙於一項大的Web服務。因此花了大量的時間來學習、找人談話並寫了一些關於這項技術的東西。在與該領域內不同的客戶羣交流時，我吃驚地發現一個問題一而再再而三地反覆出現。
人們總是問我J2EE連接器體系結構(J2EE Connector Architecture，JCA)和Web服務的區別是什麼。他們很想知道選擇其中一個而不是另外一個的標準是什麼。最初，我感到很詫異，因爲答案看上去那麼顯而易見。但是，稍加思索，我就明白了人們爲什麼會混淆。供應商們將Web服務定位爲標準的集成服務，他們的市場銷售做的如此之好，以至於公司和個人用戶已經開始感到憂慮，因爲JCA也在做同樣的宣傳。人們很自然地得出結論，這兩種技術在互相競爭，是互相排斥的。真的嗎？有一點，但不全是。
瞭解定位
Web服務和JCA都是解決集成問題方面的標準，但它們卻並不互相競爭。開發者和用戶們需要知道這兩者是不同的，並且需要知道這兩種技術的差別所在，這一點很重要。
Web服務和JCA都是解決集成問題方面的標準，但它們卻並不互相競爭。開發者和用戶們需要知道這兩者是不同的，並且需要知道這兩種技術的差別所在，這一點很重要。
Web被定位於用來標準化集成的技術，而JCA規範則用來標準化企業應用集成（EAI）。其中EAI是廣義上集成問題的一個子集。因此，問"如果我有一個EAI問題，該使用Web服務、JCA，還是兩者兼而有之？"這樣的一個問題，完全是合乎情理的。
最大的區別在於侵入
侵入（Intrusion）是指爲了支持集成技術而需要對遺留系統做的改動。
l JCA：該技術需要很少或者不需要對遺留系統的侵入。JCA適配器可以利用本地API、套接字、數據訪問以及其他不需要更改現有代碼基礎的技術來訪問遺留系統。於是公司就可以利用在已部署系統中的投入，而不必再投入額外的資源來更新系統以支持集成。
l Web服務：爲了讓遺留系統能本地支持將Web服務用作EAI方案，必須需要很高程度的侵入。遺留系統必須被更新並且修改，以包含一個Web服務棧。這個棧將處理所有的SOAP消息分析和遺留系統調用，這是一項很龐大的任務。大多數企業都不會貿然修改現有的COBOL或者舊的大型機應用以引進一種還不成熟的Web服務棧。
l Web服務：爲了讓遺留系統能本地支持將Web服務用作EAI方案，必須需要很高程度的侵入。遺留系統必須被更新並且修改，以包含一個Web服務棧。這個棧將處理所有的SOAP消息分析和遺留系統調用，這是一項很龐大的任務。大多數企業都不會貿然修改現有的COBOL或者舊的大型機應用以引進一種還不成熟的Web服務棧。
因此，如果一個公司想爲EAI使用Web服務，最有可能的做法是購買一個Web服務網關，該網關將截取Web服務消息，對遺留系統進行本地調用，得到響應，然後將其轉換成一個響應Web服務消息。JCA很容易就能被用作進行本地遺留系統調用的技術，但很多公司可能反對使用這麼多的消息層來啓用EAI。
順便說一下，我個人認爲EAI問題最終會成爲Microsoft的.NET策略中的一個障礙。由於大多數遺留系統都不是運行在Microsoft Windows上，所以.NET不可能直接進行遺留系統集成。Microsoft已經公開宣稱Web服務爲他們未來的EAI戰略。這意味着Microsoft在依賴公司將Web服務棧內置於遺留系統中以獲得對它們的訪問。我想說的是企業肯定不會接受這種做法，來做這麼一筆投資。因爲那些使用.NET的企業將被迫購買EAI服務器（WebLogic Server是不錯的選擇）來截取Web服務請求並使用像JCA這樣的EAI類技術來進行集成。
上下文傳播
需要考慮的一個嚴重的基礎結構問題是從使用遺留系統的客戶到遺留系統本身的事務和安全上下文傳播（Context Propagation）。
l JCA：JCA支持從JCA服務器到遺留系統的安全和事務傳播。這是JCA設計中最主要的基礎結構概念之一，也是被很多集成環境採用的一個強有力的原因。這意味着如果一個標識用戶的XA事務上下文或者安全上下文是在應用服務器中創建的，那麼當應用服務器調用遺留系統上的服務時，遺留系統就會感染上事務和安全上下文。就XA事務來說，這意味着如果遺留系統是XA-compliant的資源管理器，它就能參與XA事務。這樣設計師們就能設計出EAI系統，這種系統能保證具有遺留系統以及使用該系統的客戶的ACID事務。至於安全來說，這意味着用於個人的單點登陸（single sign-on）可用於客戶和遺留系統之間。在設計和遺留系統的交互時，這些是需要考慮的關鍵特性。
l Web服務：Web服務消息可以傳播一個事務或者安全上下文來作爲一個SOAP頭部擴展，這是可能的，但現在標準的做法已經不這麼做了。另外，即使存在這樣一個標準，也不會用來傳播XA事務和內部的安全用戶標識符。Web服務可以將客戶從服務器上分離出來，就和MOM系統將生產商和消費者分離一樣。是的，跨過Web服務消息傳播XA事務上下文是有可能的，但Web服務的本性意味着誰也不能預測響應消息究竟何時發送或抵達目的地。XA事務是一個壽命很短的事務，通常每30秒自動進行一次transaction rollback。Web服務的這種不可預測和不連貫的本性使它成爲XA事務上下文不太現實的傳輸手段。系統級的安全標識符同樣有這個問題。這意味着利用Web服務來訪問遠程系統的客戶不能使用XA事務來實現同樣的目的。
l Web服務：Web服務消息可以傳播一個事務或者安全上下文來作爲一個SOAP頭部擴展，這是可能的，但現在標準的做法已經不這麼做了。另外，即使存在這樣一個標準，也不會用來傳播XA事務和內部的安全用戶標識符。Web服務可以將客戶從服務器上分離出來，就和MOM系統將生產商和消費者分離一樣。是的，跨過Web服務消息傳播XA事務上下文是有可能的，但Web服務的本性意味着誰也不能預測響應消息究竟何時發送或抵達目的地。XA事務是一個壽命很短的事務，通常每30秒自動進行一次transaction rollback。Web服務的這種不可預測和不連貫的本性使它成爲XA事務上下文不太現實的傳輸手段。系統級的安全標識符同樣有這個問題。這意味着利用Web服務來訪問遠程系統的客戶不能使用XA事務來實現同樣的目的。
但是也不要對Web服務失望。Web服務爲業務邏輯（business logic）層提供了一個商業級的接口，而不是一個細粒度（fine-grained）的方法。如果這樣的話，Web服務就需要事務，安全以及很多其他的基礎結構技術，但是它們必須應用於Web服務所運行的環境中（不可預測的響應，不可預測的載荷，應用的來去，XML格式的變化等）。例如，OASIS工作於商業事務協議（BTP），爲該環境中的系統提供了壽命很長的事務。另外，它還創建了很多安全Web服務規範。Web服務最終會改變開發者對商業服務的看法以及他們用來創建商業服務的體系結構，但是這些新的方案是否適用於EAI，這得你自己判斷。
代碼綁定
代碼綁定是EAI簡單但重要的一面。我們可以將Web服務和JCA做一個比較。
代碼綁定是EAI簡單但重要的一面。我們可以將Web服務和JCA做一個比較。
l JCA：JCA是基於Java的技術，這並不意味着遺留系統必須是用Java編寫的，但是使用JCA的遺留應用必須用Java編寫。這給設計師們某些暗示。首先，任何使用JCA的應用和它對JCA的使用綁定在一起。這意味着如果應用對遺留系統的使用需要作出變化，那麼開發者必須動手重新編寫JCA訪問代碼以作出改動。這對於一些公司來說可能是問題也可能不是。其次，應用可以利用對訪問遺留系統的客戶所作的強制聲明（strong typing）和編譯時間檢查。由於用來訪問遺留系統的數據類型和方法是以Java類型出現的，使用JCA的Java應用可以對遺留系統的語義用法進行編譯時間檢查（它並不確認該系統的正確用法，只是說明使用該系統的語法是正確的）。
l Web服務：Web服務EAI方案允許用任何語言編寫的客戶端都能訪問遺留系統，這些客戶端可能是用Java，C#，Fortran，或者COBOL編寫的。同樣，由於Web服務使用XML消息來和其他系統通信，與Web服務動態連接並獲取WSDL文檔來理解消息結構的客戶端不能從編譯時間檢查中獲得任何好處。但是，Web服務的格式可能是實時的，應用也可以動態地和它一起變化，也就是說Web服務的改變並不一定意味着使用Web服務的客戶端需要重新編寫。
l Web服務：Web服務EAI方案允許用任何語言編寫的客戶端都能訪問遺留系統，這些客戶端可能是用Java，C#，Fortran，或者COBOL編寫的。同樣，由於Web服務使用XML消息來和其他系統通信，與Web服務動態連接並獲取WSDL文檔來理解消息結構的客戶端不能從編譯時間檢查中獲得任何好處。但是，Web服務的格式可能是實時的，應用也可以動態地和它一起變化，也就是說Web服務的改變並不一定意味着使用Web服務的客戶端需要重新編寫。
數據綁定
數據綁定用來將遺留系統數據的格式變成客戶端應用可用的一種格式。
l JCA：JCA需要對一個Java數據類型（Java類）的數據綁定。這對於在本地類型和Java類型之間有一個清晰映像的簡單數據類型來說。但如果遺留系統有複雜的相關或者二進制數據必須被處理，那麼很快就會有麻煩。JCA 1.0沒有一個表示遺留系統中數據格式的標準作法，並且動態客戶端也不能連接到JCA適配器上以"發現"遺留系統的數據格式是什麼。JCA 2.0包含了一個元數據功能（metadata facility），它能允許JCA客戶端查詢JCA適配器，以便動態地發現遺留系統中的數據形狀和類型。
l Web服務：Web服務給遺留系統帶來了一個有趣的問題，因爲遺留系統中的數據必須首先被轉換成XML來傳輸，然後再轉換成使用Web服務的客戶端的編程語言格式。如果EAI系統使用客戶端->Web服務->服務器中間件->本地集成適配器->遺留系統這種途徑，那麼遺留系統中的數據將沿着一種醜陋的格式傳輸，即本地格式->本地集成適配器轉換的語言格式->XML轉換->使用Web服務的客戶端的語言格式。除非數據綁定技術取得突破性進展，否則原始數據的很多含義在這些轉換過程中很有可能丟失（更不用說系統變慢這樣顯著的性能了）。
數據綁定用來將遺留系統數據的格式變成客戶端應用可用的一種格式。
l JCA：JCA需要對一個Java數據類型（Java類）的數據綁定。這對於在本地類型和Java類型之間有一個清晰映像的簡單數據類型來說。但如果遺留系統有複雜的相關或者二進制數據必須被處理，那麼很快就會有麻煩。JCA 1.0沒有一個表示遺留系統中數據格式的標準作法，並且動態客戶端也不能連接到JCA適配器上以"發現"遺留系統的數據格式是什麼。JCA 2.0包含了一個元數據功能（metadata facility），它能允許JCA客戶端查詢JCA適配器，以便動態地發現遺留系統中的數據形狀和類型。
l Web服務：Web服務給遺留系統帶來了一個有趣的問題，因爲遺留系統中的數據必須首先被轉換成XML來傳輸，然後再轉換成使用Web服務的客戶端的編程語言格式。如果EAI系統使用客戶端->Web服務->服務器中間件->本地集成適配器->遺留系統這種途徑，那麼遺留系統中的數據將沿着一種醜陋的格式傳輸，即本地格式->本地集成適配器轉換的語言格式->XML轉換->使用Web服務的客戶端的語言格式。除非數據綁定技術取得突破性進展，否則原始數據的很多含義在這些轉換過程中很有可能丟失（更不用說系統變慢這樣顯著的性能了）。
另一方面，很多公司用XML格式來表示遺留數據自有他們的道理。XML在商業上很有意義，有很多種方法來跨越不同的應用和系統使用這些商業意義。但是，如果遺留系統在本地將它的數據用XML展現出來，那麼Web服務可能會提供一個無縫方案，該方案使得對JCA的使用也變得很麻煩。在過去的三年裏人們創建了很多使用XML作爲數據格式的系統，這些系統現在都已成爲遺留系統，所以這種方案可能是可行的。
結論
我希望通過本文大家能比較瞭解JCA和Web服務的體系結構在用於EAI時的主要區別。我們對於這兩者定位的爭論以及進一步的比較很感興趣，如果您有什麼新的想法，請告訴我們。可以發送電子郵件，讓我們共同討論。
我希望通過本文大家能比較瞭解JCA和Web服務的體系結構在用於EAI時的主要區別。我們對於這兩者定位的爭論以及進一步的比較很感興趣，如果您有什麼新的想法，請告訴我們。可以發送電子郵件，讓我們共同討論。
原文URL： http://dev2dev.bea.com/articles/552.jsp
| 作者簡介 | |
| Tyler Jewell是BEA的技術傳播先驅。他還是《Java Web Services》一書的作者，《Mastering Enterprise JavaBeans 2.0》和《Professional Java Server Programming (J2EE 1.3)》的作者之一。J2EE和Web服務這兩方面的Web題材的書他都寫過。 | |