EAI是“死神之吻” ？

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

既然說SOA是拯救EAI的“天使”，那么就讓我們來看看SOA這個“天使”究竟是什么樣子？ 也許是失敗的案例太多了，EAI(企業(yè)應用集成)作為一類典型的IT項目，常常被人們稱為“死神之吻”。在集成軟件的發(fā)展歷史上，IBM公司的SAA和SQL關系數(shù)據(jù)庫曾經(jīng)給人們留下深刻印象。

CORBA技術在這個領域很風光。而在中間件成為一種流行的集成方法的今天，許多集成工具采用專用而非開放標準的技術，以Hub(交換中心)的架構為基礎把應用、消息系統(tǒng)和數(shù)據(jù)源連通起來。不管怎樣，上述所有這些技術和產(chǎn)品都在向著一個目標——實現(xiàn)EAI的標準化而努力。

SOA能夠改變這一切！

在過去的40年間，軟件架構師總是在與同一個“魔鬼”交戰(zhàn)，這就是軟件的復雜度，而交戰(zhàn)的結果總是不斷印證著那句不變的咒語：道高一尺，魔高一丈。特別是隨著硬件系統(tǒng)、操作系統(tǒng)平臺的不斷增加以及企業(yè)網(wǎng)絡的飛速蔓延，如何把這些不同的信息系統(tǒng)集成起來，也就是實現(xiàn)EAI(企業(yè)應用集成)，更是令許多企業(yè)的IT人員不堪重負。

到目前為止，傳統(tǒng)的編程技術所形成的軟件系統(tǒng)都是剛性的。也就是說，一旦開發(fā)完成并投入運行，就是固定不變的，不能在使用過程中進行調(diào)整和改變。在業(yè)務流程中，軟件系統(tǒng)嚴格按照預先設定的目標，各功能模塊按照確定的順序執(zhí)行。如果數(shù)據(jù)結構或者業(yè)務邏輯發(fā)生改變，就必須對所有相關的軟件模塊、數(shù)據(jù)源和消息逐個進行修改。就算是有了EAI中間件，這種情況也并沒有得到根本性的改變。

今天，SOA改變了這種現(xiàn)狀。SOA采用服務請求（Service Request）的方式，使軟件系統(tǒng)向“柔性化”邁進了一大步。與傳統(tǒng)的軟件系統(tǒng)不同，SOA只限定服務所需的信息并提出服務請求，但是不限定提供服務的模塊。

由于不限定提供服務的模塊，這樣就完全可以在服務請求模塊不知不覺的情況下，由新的數(shù)據(jù)源來滿足這個服務請求。另一方面，新的數(shù)據(jù)源也可以去響應其他服務請求者提出的類似請求。在這樣的系統(tǒng)中，只需要根據(jù)新的情況修改服務的執(zhí)行者，而不需要修改服務的請求者。所以，基于SOA的企業(yè)應用系統(tǒng)可以隨著企業(yè)業(yè)務的變化而逐漸演變。

Web服務催生SOA

既然說SOA是拯救EAI的“天使”，那么就讓我們來看看SOA這個“天使”究竟是什么樣子？

SOA支持服務型軟件的設計。也就是說，在這樣的環(huán)境中可以設計出為其他應用提供服務的軟件模塊。另一方面，所有有服務需求的應用模塊都會把自己接受服務的接口公布出來。這樣一來，網(wǎng)絡環(huán)境就可以變成這些服務的交易場所和交易機制。這與當今盛行的Web服務的思路可謂異曲同工。實際上，Web服務將會催生SOA的實現(xiàn)。

當我們利用Web服務來實現(xiàn)SOA的時候，就等于獲得了一種建立各種應用并實現(xiàn)EAI的編程工具和方法，應用系統(tǒng)的開發(fā)、集成和維護的成本和風險都會大大降低。實際上，SOA既是一種架構模式，又是一種編程模式，它同時也是一種關于軟件的全新思維方式。

SOA不僅可以得益于Web服務的成熟與發(fā)展，而且可以從其他許多技術領域獲得幫助，其中，網(wǎng)格計算將會是第一個對它有幫助。網(wǎng)格計算　　不僅僅可以把許多CPU的計算能力整合起來，而且可以提供一種框架，用來完成軟件服務模塊的動態(tài)定位、分配、均衡與管理工作，從而保證不管發(fā)出服務請求還是提供服務的模塊處在任何地方，都可以保證系統(tǒng)可以安全有效地運行。

值得注意的是，SOA并不能等同于Web服務。Web服務是一套技術體系，包括XML、SOAP、 WSDL和UDDI，可以用來建立應用解決方案，解決特定的消息通信和應用集成問題。隨著時間的推移，我們發(fā)現(xiàn)這些技術在不斷發(fā)展、不斷成熟，也會更好地幫助你實現(xiàn)SOA。但是，Web服務不是SOA。SOA是一種軟件架構，而不局限于某個技術的組合(例如Web服務)。它超越了技術范疇。在一個商業(yè)環(huán)境中，純粹的SOA是一種應用軟件架構，其中所有的功能都是相互獨立的服務模塊，通過完備定義的接口相互聯(lián)系起來。只要按照一定的順序來請求這些功能模塊所提供的服務，就可以形成完整的業(yè)務流程。

Web服務的出現(xiàn)，為SOA的應用提供了一種標準。到目前為止，業(yè)界已經(jīng)形成了一些基本的標準模塊。SOAP用于服務請求的建立；WSDL用于服務請求的發(fā)布；UDDI用于服務請求的目錄列表；另外還有一些關于安全和數(shù)字簽名的標準。但是，在業(yè)務邏輯的層面上，比如業(yè)務流程的開發(fā)與管理方面，各家軟件廠商總是存在著分歧與爭議。

如果SOA理想得以實現(xiàn)，也許會使集成變得更加容易。但要讓SOA盡善盡美地走到這一步本身并非易事。首先，必須實現(xiàn)原有系統(tǒng)的標準化，即便如此，仍然需要根據(jù)特定的業(yè)務流程進行適量的開發(fā)工作。在實施SAP項目方面有經(jīng)驗的人都有體會，任何業(yè)務都有其獨特的流程和數(shù)據(jù)結構，其中許多內(nèi)容無論如何都無法用標準的軟件模塊來實現(xiàn)。在企業(yè)應用集成方面，情況同樣如此。盡管已經(jīng)有了許多進行虛擬數(shù)據(jù)映射和遺留業(yè)務邏輯自動分析的工具，但是其中總有一些特殊的程序和數(shù)據(jù)結構無法自動處理。

可以預見，SOA并不會完全取代傳統(tǒng)的剛性應用軟件，但是將會給他們套上標準化的“外殼”，讓他們更加易于與別的應用系統(tǒng)實現(xiàn)集成。另外，我們不能把SOA與Web服務以及XML混為一談。Web服務可以用來實現(xiàn)SOA，但是如果沒有Web服務，你也可以很好地實現(xiàn)SOA。反之，即便是利用Web服務技術，也不一定能保證SOA的效果就更好。

從長遠觀點來看，基于XML的Web服務將會成為實現(xiàn)SOA的主要工具。但要達到那一步，也許還需要3～5年的時間。目前，我們對SOA還需要有更加深入的認識，也許還會走很多彎路。例如，采用傳統(tǒng)的方法，即便是利用SOAP消息來實現(xiàn)現(xiàn)有軟件的集成，其結果仍然是一個剛性的點對點通信系統(tǒng)。只不過由于很多廠商都支持SOAP，因此實現(xiàn)過程會比較容易而已。由此形成的集成系統(tǒng)，維護復雜程度并不會降低多少。

來源：AMT