全面的、可伸縮的SOA vs.簡單可行的SOA建設模式

申請免費試用、咨詢電話：400-8352-114

        每個企業(yè)都必須在全面的、可伸縮的SOA與簡單可行的SOA建設模式之間找到適合自己的平衡點。
        幾年前，由Web服務引發(fā)的到今天以SOA（面向服務的架構）形式繼續(xù)著的狂潮下面出現了一條斷層。是的，幾乎所有人都認為基于XML的消息技術是實現平臺中立的、可以整合到支持企業(yè)業(yè)務功能的高層服務的正確途徑。但是，人們還感到技術規(guī)范的標準化過程失去了控制。
        IBM、Microsoft以及其他廠商提出了那么多的Web服務標準，以致不得不發(fā)明一個新的集合名詞：WS-*。星號是通配符，可以表示“地址”、“事件”、“路由”、“可靠性”、“ReliableMessaging（可靠消息傳遞通信協議）”、“安全會話”、“安全性”、“交易”、“信任”以及其他多得嚇人的術語。經過一番調查，XML的共同發(fā)明人Tim Bray斷言，“WS-*臃腫、不透明并且非常復雜”。

爭議背后的兩大陣營
        有人說WS-*是套在馬前面的車子—本末倒置了。這種理論認為，重量級廠商與關鍵客戶和合作伙伴密切合作，將一些Web服務規(guī)范的復雜性提升到了只有他們才能維持的程度。由于這些規(guī)范大大超前于大多數用戶目前的需要，因此，它們的發(fā)展一直沒有得到有效地推動。
        OASIS是目前負責協調眾多WS-*規(guī)范的標準組織。該組織主席兼CEO Patrick Gannon不情愿地承認說，從一開始就應當讓用戶參與。他說：“由于沒有提出正式的用戶需求，我沒有參與這些規(guī)范的開發(fā)工作。不過，我是個實用主義者，規(guī)范已經制定了?！?BR>        然而，情況并不總是如此。簡單形式的XML消息早在這些標準問世之前很久就取得了成功。Metratech CTO Jim Culbert講述了其公司的面向服務的計費系統(tǒng)在90年代末是如何運行的。合作伙伴之間交換的消息采用XML格式，并利用具有SSL加密功能的HTTP傳輸——目前，這種方法仍用于大多數安全的Web服務通信中。
        Seybold分析師Brenda Michelson當年是L.L. Bean首席設計師。他講述了有關這家公司使用Web服務的早期體驗，其經驗與Metratech公司類似。當時有兩個因素非常突出。首先，Web服務提供一種簡單的、無處不在的集成框架，這種框架以后被提升到架構的高度并被打上了REST（表現性狀態(tài)傳輸）的標記。其次，XML提供了一種定義服務的通用方式，從它們產生或消費的數據的角度，而非從產生或消費數據的編程的角度來定義服務。這兩個因素的結合曾是——現在仍然是強大的推動力。
        對于WS-*的另一種觀點認為，那些已經在安全性、事務處理和可靠通信方面付出成本的業(yè)界重量級廠商，的確有資格將他們在這些問題上的經驗轉化為XML語言。RouteOne公司技術總監(jiān)TN Subramaniam曾經有過痛苦的經歷。當時，他準備擬定他自己的單一登錄規(guī)范，結果在他發(fā)現SAML（安全斷言標記語言）時放棄自己的規(guī)范。他的投資方合作伙伴狂熱地采用了SAML，因為所有身份管理廠商（包括Netegrity和Oblix）都支持SAML。
        Subramaniam問道：“讓5位每隔一天開一次會的設計師來解決各種分歧，還是建立一個所有廠商都參加的委員會來詳盡地考慮所有問題，兩種方法誰優(yōu)誰劣呢？”
        人們不禁會將這兩種觀點之間的緊張關系解釋為WS-Heavy與WS-Lite的不同，在這兩個陣營中，WS-Heavy意味著WS-*聲稱提供的安全性、可靠性和可伸縮性，比較而言，WS-Heavy像一個莊重的大教堂，而WS-Lite意味著吸引著REST、AJAX和RSS等標志的速度、簡單性和靈活性，WS-Lite更像是一個集貿市場。但是，本文所采訪過的企業(yè)設計師中沒有一位承諾效忠于某個陣營。下面是五個企業(yè)根據自己的需要來實現SOA的例子，他們都是實用主義者，會去做完成工作所需要的任何事情，因此了解他們如何使用（以及不使用）Web服務標準是具有指導意義的。

RouteOne：有效的信用檢查
        雖然端到端的SSL常常足以滿足需要了，而且這樣做足夠輕巧，但RouteOne公司的Subramaniam出于兩個理由更喜歡WS-Security提供的更細粒度的方法。
        RouteOne是一家通過網絡為汽車經銷商提供汽車信貸申請服務的公司，RouteOne公司一方面吸引了眾多的汽車經銷商，另一端則與幾家金融公司聯網（見圖1）。



        在汽車信貸的申請過程中，首先，需要對信用申請書進行數字簽名，并且需要根據服務合作伙伴理解的規(guī)則去做這件事。WS-Security定義了這類規(guī)則，盡管無可否認的是這樣做會導致規(guī)則太多。一種方法是將簽了名的申請放到SOAP消息中，另一種辦法是利用帶有附件的SOAP。但是，RouteOne的不同合作伙伴之間沒有達成一致，因此RouteOne同時使用上述兩種方法。這讓人感到沮喪，但是Subramamian寧愿有兩種規(guī)則，也不愿意沒有規(guī)則。 
        第二個理由涉及一項激勵設計WS-*的深層次原則：無處不在的仲裁（intermediation）。RouteOne被要求保存詳細的審計日志，但是希望不必加密所有的日志。因此，它使用DataPower的XML加速器，有選擇地只加密像工資總額和社會保險號等敏感條目。由于這是基于標準的仲裁系統(tǒng)，DataPower設備可以直接以這種方式修改RouteOne的XML消息傳輸流。
        當服務直接通信時，沒有必要定義實現服務仲裁的約定規(guī)則。目前，最引人注目使用WS-Lite的典范——Amazon和eBay——以點對點的方式使用Web服務。在這種模式下，SOAP/WSDL應用程序接口與REST 應用程序接口之間沒有太大的差別，因此使用這些平臺的絕大多數的開發(fā)人員喜歡REST風格也就并不奇怪了。不過，當你的確需要讓你的XML傳輸流經過仲裁系統(tǒng)時，SOAP和WSDL突然成為了更合理的選擇。
        不過，Subramaniam是一位實用主義者。普通的XML over HTTP（沒有WSDL）也在RouteOne的內部和外部事務中發(fā)揮著作用。由于在內部的遺留系統(tǒng)上安裝一個小服務程序接口并通過它提取XML數據是一件誰都不會反對的事，因此，這種戰(zhàn)略被應用于各種合適的地方。一些RouteOne公司的外部合作伙伴使用同樣的方法，并且由于“他們這樣做可以毫不費力地賺錢”，所以Subramaniam不可能要求使用其他方法。相反，RouteOne將輸入傳輸流變?yōu)镾OAP和WSDL格式，以支持未來將BPEL（業(yè)務流程執(zhí)行語言）用于業(yè)務創(chuàng)新時的流程編排。目前，沒有提供SOAP和WSDL接口的合作伙伴在競爭上并沒有處于劣勢。不過，競爭的天秤可能不久就會傾斜。
        RouteOne依靠SAML和WS-Security。而Subramaniam希望他也可以使用標準格式的可靠的消息技術。他說：“如果我不發(fā)送消息，我們就會損失金錢?！笔躤bXML（電子商務XML）和JMS（Java消息服務）的啟發(fā)，他現在與合作伙伴一起使用一種能夠保證有序的、可靠地提交消息的方案。不過，他希望OASIS在整合它現在管理的兩項規(guī)范，WS-Reliability和WS-ReliableMessaging時取得成功。Subramaniam說：“這種重復非常非常糟。我希望有一個通用規(guī)范，這樣我可以拋棄我自己的東西，使用這個通用規(guī)范。”

Corillian：點對點的簡單性
        據Corillian公司首席設計師Scott Hanselman說，很多面向服務的系統(tǒng)不要求可靠的消息技術，而他的公司的銀行業(yè)中間件就屬于這類服務系統(tǒng)。
        Hanselman 說，Corillian的產品，即所謂的Voyager，處理由25％的在線銀行用戶間接使用的服務?！暗牵麄兾┮魂P心的交易是主機上的交易?！币虼?，他并不操心WS-Reliability與WS-ReliableMessaging的合并。盡管他沒有使用WS-Security，但他認為SSL在大多數情況下同樣有效。他承認，這種方法將路由器和仲裁系統(tǒng)排除在外，“但是我很少使用它們，因為10次中有9次我們進行點對點消息通信?！?BR>        他也瞧不上UDDI。UDDI是一種倍受指責的標準，用于發(fā)布Web服務目錄。至于那種認為黃頁中找不到的服務就不能被重用的論點，Hanselman并不買賬。他說，找到服務實際上并不是開發(fā)人員的問題。方便有效地使用它們才是開發(fā)人員的問題。
        當然，WSDL也受到了它所應當受到的批評。RouteOne的Subramaniam認為，WSDL 1.1的“愚蠢的”復雜性，使它成為限制SOA的鐐銬，他希望“更加干凈的”WSDL 2.0能減輕這種負擔。Hanselman說，也許是這樣，但是“你不可能不使用WSDL 1.1?！睌蛋偃fWeb服務是利用WSDL 1.1進行的，而且這種情況將持續(xù)很長一段時間。利用WSDL 1.1，Corillian通過在Voyager的核心說明對象、消息和服務，并將這些說明與不使用XML的內部機制綁在一起。當需要增長時，公司創(chuàng)建了替代的捆綁，使客戶可以通過一個Web服務鏡頭看到引擎。Hanselman認為，如果WSDL 1.1是一種80％的解決方案的話，那么WSDL 2.0可能是90％的解決方案，但是它們誰都不能提供至關重要的方法。

醫(yī)學中心：數據實時傳送
        得到最廣泛采用的高級Web服務標準顯然是WS-Security。除此之外，很難找到與WS動物園中更奇異的野獸相處過的實踐者了，不過，Furrukh Khan講述了有關他從基本Web服務向高級Web服務遷移過程中引人入勝的故事。Khan在俄亥俄州立大學醫(yī)學中心工程與醫(yī)藥學院任職，全面負責醫(yī)學中心的IT工作。
        在這個環(huán)境中，來自監(jiān)測儀器的病人狀態(tài)數據被記錄到數據庫中，并且同時傳送給智能客戶端?？蛻舳顺绦蛴^察、分析并注釋數據流。數據流必須安全可靠近實時地提供給很多的客戶端。
        早期部署基于Microsoft的WSE（Web服務擴展），采用了WS-Policy。WS-Policy還沒有在標準組織中找到安身之處，但可能不久會找到的。WS-Policy被用于說明登錄后端數據庫的認證方法（例如，要求規(guī)定密鑰簽署的X.509證書）以及解釋所要求的有效載荷簽名和加密算法。

 現在，醫(yī)學中心的系統(tǒng)部署基于Beta版的Microsoft Indigo（一種高級Web服務協議群的Windows實現），使用WS-ReliableMessaging來保證有序、可靠地提供信息。它還使用WS-SecureConversation來優(yōu)化傳送高容量數據流的安全可靠的通道（見圖2）。



        Khan解釋說，光靠在WS-Policy協助下的WS-Security不能維持近實時的傳輸流。這個需要頻繁與身份管理系統(tǒng)交換證書的協議太愛講話。實現證書緩存的WS-SecureConversation優(yōu)化了這項協議。此外，依靠Indigo對WS-ReliableMessaging的支持，能夠實現一種特性使路由器可以幫助建立兩個終端之間的連接，然后從中抽身不再參與。所有這些帶來了巨大的擴展性。
        Khan說：“以前在使用WSE時，每臺路由器都將我們限制在300個客戶端上。” 他補充說，Indigo可以支持每路由器638個客戶端，并且經過優(yōu)化，運行在路由器后面的每個服務都支持那么多的客戶端。他說：“因此如果你不斷增加服務，它可以線性的擴展。”該系統(tǒng)目前支持1000多個客戶端，所有的客戶端每隔30秒就能同時觀察病人狀態(tài)數據。
        在回憶從WSE向Indigo遷移的經歷時，Khan符和Scott Hanselman關于將開發(fā)人員與XML隔離的觀點。
        他說，WSE處理基本的場景，但是除此之外，“我們不得不編寫WSE程序?！庇捎贗ndigo的更高的抽象水平，這個問題消失了。
        從更大的范圍看，Indigo使一個更困難的問題（即在平臺原有的服務和傳輸技術配合下恰當地使用Web服務）迎刃而解。Khan說：“在Microsoft領域中，企業(yè)服務與Web服務完全不同，MSMQ生活在自己的世界中，而XML有它自己的工具包?！辈煌膱F隊成員必須是不同學科的專家，沒人能掌握所有的東西。

Providence：復用而非復制
        Providence的醫(yī)療系統(tǒng)部署成為典型的兩層SOA來支持其臨床業(yè)務與辦公應用，以及醫(yī)生與患者的門戶。一組對應于業(yè)務流程的粗粒度的服務是由另一組更基本的服務組織而成的。雖然使用了一些高級標準，如WS-Security，但是Providence沒有直接與它們打交道。Providence負責開發(fā)的副總裁Reagin說：“我們依靠廠商的安全技術實現?！北景钢械膹S商是Infravio公司。該公司的Web服務管理系統(tǒng)為Providence部署和管理服務提供了框架。
        Infravio實現了UDDI，但Reagin說，由于使用的服務比較少，目錄查找并不那么重要。但是，宣布和執(zhí)行控制這些服務的使用政策非常重要，監(jiān)測服務活動也很重要。
        在Infravio的模型中，服務被配置成以每一對生產者和消費為單位，每一對生產者和消費者都由合同來管理。例如，主患者索引是醫(yī)生和患者門戶都使用的通用服務，但使用方法略有不同。出現在患者門戶中的患者的健康計劃成員號必須從醫(yī)生門戶中刪除。通過為不同的消費者創(chuàng)建不同的WSDL接口，Infravio使通用服務可以被重復使用，而不是復制。這種變化是通過一種說明方式實現的，而不是通過編寫程序實現的。
        目前，Providence的SOA部署基本上是內部的。服務支持對外的門戶，但還沒有直接暴露給合作伙伴。不過，這一天將會到來，Reagin對此十分肯定。當這一天到來時，他預期使用的核心標準SOAP和WSDL將實現更多的高級功能：編排、可靠的消息、策略管理的安全性以及審計。WS-*的哪些部分將實現這些功能？Reagin沒有為這個問題去傷腦筋。到時候，他將購買—而不是開發(fā)所需要的基礎設施。

PGP：安全與協作并重
        安全性和可靠的消息技術是Pfizer Global Pharmaceuticals (PGP)集團的關鍵要求。在Blue Titan的Network Director的幫助下，這家制藥巨頭的SOA部署滿足了這些要求。Network Director管理PGP企業(yè)中的Web服務傳輸流。
        在安全性方面，Blue Titan的“結構”（fabric）執(zhí)行一項策略。根據這項策略，請求被傳送到DataPower仲裁系統(tǒng)進行遵從性審計，然后再傳送到Oblix系統(tǒng)進行認證。PGP應用架構主管Martin Brodbeck將WS-Security視為完成這些活動的集成框架。雖然他沒有直接接觸相關標準（如WS-Policy或WS-Trust），但Blue Titan事實上的確支持它們（見圖3）。



        除了安全性外，可靠的消息技術也是PGP關心的關鍵問題。在市場上有各種各樣的面向消息的中間件，并且其中一些還有多種版本（如JMS）的情況下，公司看上了Network Director RM的隱藏差別的能力。雖然該產品對WS-ReliableMessaging的支持不夠合適，但PGP正在評估Indigo。Brodbeck說：“Blue Titan在Indigo的配合下，將使RM可靠消息傳遞的功能非常易于使用?！?BR>        Brodbeck向重要標準（如WS-Security和WS-ReliableMessaging）的小名單添加了RSS。RSS是非常流行的網志聯合發(fā)布（Weblog syndication）格式。PGP將這種WS-Lite變種視為戰(zhàn)略性技術可能讓你感到驚訝，可是，如果你想一想協作和知識管理將如何推動一家像PGP這樣的企業(yè)的總收入的增加，也就不奇怪了。不過，PGP設想的不是那種普通的網志軟件。PGP全球應用與架構副總裁Richard Lynn說：“我們必須對RSS重新語境化（recontextualize），使它適用于我們的企業(yè)?！?BR>        PGP的要求包括虛擬化RSS輸入，使它們獨立于硬編碼地址，從而聚合它們提供特殊的業(yè)務功能，并利用控制已有Web服務的同樣類型的說明性策略來保護它們。據Blue Titan創(chuàng)建人、CEO Frank Martinez說，Network Director即將推出的新版本將滿足這些要求，擴展該產品的在WS-Lite協議周圍包裹上一層WS-Heavy基礎設施的能力。

Heavy、Lite還是其他？
        當你把WS-*群當做一個整體時，你必然得出這樣的結論——批評者是對的 : 它的確是一只怪物。馴服這只怪物需要一種統(tǒng)一的概念框架。這正是Gannon、Khan和Subramaniam以不同方式表達的觀點。Gannon提到由OASIS制定一系列藍圖和參考模型。這些文件旨在幫助設計師了解不同的WS-*規(guī)范（這些規(guī)范被設計為模塊化構件）如何組合在一起，來解決具體的問題。對于醫(yī)學中心的Khan來說，這不只是藍圖問題。他需要一種能夠克服復雜性的工具包，并認為Indigo將成為這種工具包。
        RouteOne的Subramaniam希望最近一個叫做JBI (Java業(yè)務集成)的項目能成為Java世界中實現統(tǒng)一的力量。他們Web服務的困難之處“是你必須看到整個圖畫——WSDL、SOAP以及WS-Security的相關部分和BPEL?！彼瓮鸖eeBeyond（最近被Sun Microsystems收購）和WebMethods等廠商支持JBI。他說：“當你能夠看到所有這些東西如何拼在一起構成一幅JBI的大畫面時，一個非常美好的基礎設施就誕生了?！?BR>        當然，工具包和框架也是雙刃劍。甚至在網絡協議成為標準并且開放時，你仍會將注意力過多地放在細節(jié)上。這正是為什么實用主義的設計者和還不需要高級WS-*特性的開發(fā)人員通常關注基本的規(guī)范（SOAP和WSDL）的原因。Subramaniam問道：“如果你需要某種外殼的話，為什么不使用SOAP？如果你必須準確地描述你的接口的話，為何不使用WSDL？”
        對于Grossman和其他人來說，重要的是利用SOAP和WSDL在正式的契約與靈活的互操作性之間取得平衡，同時為未來使用更高級的SOA特性打下基礎。PGP的Brodbeck認為WSDL是實現可重用事務處理和流程的關鍵因素。不過，他還把RSS加入到體系中來。其實，惟一真正重要的規(guī)范是適合你的規(guī)范。

編看編想：SOA的互動
        SOA的實施與一般的項目不同的地方之一，就是SOA所涉及的規(guī)范很多，但規(guī)范本身又很寬泛，給參與項目的實施者提供了很大的空間。
        當然，現在已經不用從零開始，因為已經有許多廠商在基于SOA的理念和Web服務的基本框架下制定了相關的規(guī)范。值得慶幸的是，有規(guī)范總比沒有好，因為沒有規(guī)范其實可以理解為有無窮多的規(guī)范，讓你無所適從。在正文中提到的RouteOne公司的原則非常有效，寧愿有兩種規(guī)則，也不愿意沒有規(guī)則。
        廠商在提出自己所倡導的規(guī)范時也會提供相應的產品，并影響相關的廠商支持該規(guī)范，那么這種規(guī)范和產品就是有相當生命力的，應該可以成為用戶的備選方案。
        如果把眾多的規(guī)范劃分為WS-Heavy與WS-Lite兩大陣營的話，那么用戶在選擇SOA的方案時就有了一個大致的原則，如果傾向于靈活、簡捷的風格，就從WS-Lite中入手，如果強調安全可靠，WS-Heavy則是不可少的著眼點。但WS-Heavy與WS-Lite這種劃分法只是一個粗略的框圖，可以為企業(yè)用戶構建SOA提供一個迅速入門的分類，但如果只以規(guī)范為核心來實施SOA，那么必然會受制于規(guī)范的不完善和產品的限制。
        不管規(guī)范如何龐雜，產品如何繁多，但最終目的只有一個——實現業(yè)務目標。因此，應用才是SOA的核心，圍繞應用來選擇相關的規(guī)范和確定物理實現的產品才能保證不偏離大方向。正文中PGP集團的作法就是一個不錯的例子，既強調安全認證，同時又構建了RSS這種WS-Lite技術，因為PGP集團的業(yè)務發(fā)展中離不開安全與協作兩大因素，是應用的需要融合了規(guī)范上的區(qū)別。所以說，SOA的實施是一個應用與技術規(guī)范、產品三位一體的互動過程。(CCW)