1.  關於SOA

1.1  技術背景

        為了幫助企業和組織實現隨需應變的業務需要關注兩個要素：業務設計（業務模型和業務流程）以及底層技術基礎設施。企業可能必須修改業務模式和業務流程，以專注於企業的核心競爭力，並克服業務模型本身效率低下的缺點。如果沒有能夠以簡單的方式展現複雜業務流程的工具，就不能簡單地確定瓶頸和重複部分。其中優化業務模型是實現隨需應變業務的一個重要步驟，但是隻有這一步是遠遠不夠的，IT基礎設施必須能夠生成新的業務流程以能夠迅速適應未來業務流程變化，這說明動態業務模型需要靈活的IT體系結構。
        SOA恰恰能夠提供這種靈活性，它與Web服務緊密結合正迅速成為整合應用的新標準。1996年，Gartner最早提出SOA思想，2002年12月Gartner提出SOA是“現代應用開發領域最重要”的課題。預計到2008年，SOA將成為佔有絕對優勢的軟體工程實踐方法。Gartner為SOA描述的遠景目標是：讓IT變得更有彈性，以更快地響應業務單位的需求，實現實時企業(Real-Time Enterprise)。構建技術、軟體工程、軟體平臺、資訊保安、可信賴計算、軟體產業這六個領域既是SOA核心理念，也是其發展與應用的基礎。
        在SOA架構中，流動的應該是構件，而不是已經整合在一起的整個系統軟體。一個使用者選擇了一款軟體，一般都有定製的要求，尤其是系統管理軟體，如ERP、CRM等。構件化技術為不同使用者的定製要求提供了可能，把常用功能做成可供選擇的構件，使用者因此有了更為靈活的選擇。沒有構件化時，軟體系統的各個部分是緊密結合在一起的，因而會“牽一髮而動全身”，採用了構件化技術後，軟體的各個功能模組可以獨立地實現、升級，而不會影響系統整體。
        顯然，SOA不但在開發和維護成本方面有一定優勢，而且實現了較大的靈活性。它與其他面向物件技術不同之處在於能將介面技術與實施技術隔離，以此來展現各種服務。在部署方面，這些服務通常比物件更具獨立性，可構成企業內部和企業間應用的功能元件。
        隨著越來越多的企業架構師用新的方法來構建應用，負責基礎工作（應用伺服器）的廠商們現在也開始著手對自己的產品進行改造，以適應SOA的要求。META預測，到2005年，一組SOA架構原則將在整個IT領域內擴散開來，它的表現形式有面向服務的業務架構、面向服務的安全架構、面向服務的管理架構等。到2006年，SOA將成為一種被廣泛接受的元資料互操作架構，因為它強調互操作表示符、格式（資訊模型）和協議（流程模型）。到2007年，應用將以SOA的動態、可擴充套件、聯合互操作性原則為基礎，通過基於XML的技術（Web service）實現。目前，像IBM、Oracle、SAP和微軟等軟體與系統廠商對SOA的興起和部署給予密切關注，並爭先推出相應的產品。

1.2  國內外現狀

        SOA這個引起業內轟動的理念在20年前就已提出，但當時由於技術的原因，而可望不可及，現在SOA已從概念變為業界追捧的技術、客戶未來的投資重點，這不僅僅歸功於Web服務標準及相關軟體技術的成熟，更重要的是眾多業內廠商對SOA的傾力支援。目前的面向SOA中介軟體市場可以用“群雄逐鹿”四個字來形容。
據Gartner統計，2005年國際應用整合和中介軟體（AIM）市場上的軟體總收入達到85億美元，同比2004年增長7.1%，下表（表1）就列出了總份額中69%的分佈情況。

        IBM的Websphere是基於網際網路的電子商務應用的理想整合和開發環境，可以使企業的電子商務應用程式根據需求輕鬆地與企業內部或外部的貿易伙伴之間的應用自動連線。IBM正致力於制定新的標準並將新技術整合到Websphere的軟體平臺上，以使電子商務可以利用這些新的功能。所有IBM的中介軟體都支援網際網路開放標準，以實現Web服務應用的發展。據Gartner資料顯示，IBM在所有的中介軟體關鍵領域全面勝出，包括交易處理監視器、整合套件、門戶以及面向訊息中介軟體等，市場份額超過37%，成為全球最大的應用整合中介軟體廠商。

        位居第二的是BEA，它也是最早進軍SOA應用的廠商，其基於SOA架構開發的WebLogic平臺8.1版本可以將以往相互分離的應用整合和應用開發匯聚在一起，通過將整合和開發融合為一個IT流程，該平臺能夠提高軟體基礎架構的複用性、業務靈活性和技能協作水平，並最終為使用者帶來長遠的成本節約。

2.  關於應用整合中介軟體

2.1 中介軟體的概念

        中介軟體（middleware）是基礎軟體的一大類，屬於可複用軟體的範疇。顧名思義，中介軟體處於作業系統軟體與使用者的應用軟體的中間。中介軟體在作業系統、網路和資料庫之上，應用軟體的下層，總的作用是為處於自己上層的應用軟體提供執行與開發的環境，幫助使用者靈活、高效地開發和整合複雜的應用軟體。

        在眾多關於中介軟體的定義中，比較普遍被接受的是IDC表述的：中介軟體是一種獨立的系統軟體或服務程式，分散式應用軟體藉助這種軟體在不同的技術之間共享資源，中介軟體位於客戶機伺服器的作業系統之上，管理計算資源和網路通訊。

        IDC對中介軟體的定義表明，中介軟體是一類軟體，而非一種軟體；中介軟體不僅僅實現互連，還要實現應用之間的互操作；中介軟體是基於分散式處理的軟體，最突出的特點是其網路通訊功能。

2.2 應用整合中介軟體

        應用整合(EAI)中介軟體屬於應用中介軟體的一種，包括基於訊息代理的企業應用整合框架和技術介面卡與應用介面卡。由於企業的業務流程會同時涉及到多個應用系統，因此要求這些系統能夠協同，但介面、架構的不統一往往使得這些本應該整合的應用系統稱為一個個“資訊孤島”，在此背景下EAI技術應運而生。它可以通過中介軟體作為粘合劑來連線企業內外各種業務相關的異構系統、應用以及資料來源，從而滿足E-Commerce、ERP、CRM、SCM、OA、資料庫、資料倉庫等重要系統之間無縫共享和交換資料的需要，如圖1所示。

                                                                                      圖1 EAI實現模型

目前越來越多的廠商青睞於將面向服務的架構（SOA）應用到應用整合中介軟體中，從而使得該中介軟體的功能更強也更符合企業的需求。

3.  基於SOA的應用整合中介軟體架構

3.1 典型場景

        SOA本身是一個比較抽象的概念，不同廠商、不同組織對SOA的解釋也不盡相同。基於SOA的應用整合中介軟體較之普通的中介軟體又有哪些優勢，以及能夠解決目前許多企業面臨的哪些問題，這些都是設計該整合中介軟體時所要考慮的情況。

         首先讓我們設想如圖2所示的場景，有這樣一家業務不斷拓展的跨國服裝公司，它的總部在北京，負責根據各地子公司或下屬部門反饋的資訊進行戰略性的決策。由於職能的需要，該公司總部使用了一家國內公司開發的線上辦公自動化系統（OA）和另一家國內公司開發的人事管理系統（HR），前者的服務端執行在Linux系統上，後者則部屬在Windows作業系統上，兩套系統投入使用的時間較長，其間分別由各自的提供商負責升級維護。另外，由於

                                                        圖2 基於SOA應用整合中介軟體的典型應用場景

發展的需要，該公司將自己的生產基地設在長三角地區的杭州，並使用面向製造業的ERP產品，該產品由國內一家大型的ERP廠商提供並作售後支援，執行在Unix系統上。該公司還在日本、歐盟等世界各大城市設立了自己的辦事處或者分支機構，因為歷史、政治和經濟等各方面原因選擇了當地IT公司所提供的OA、HR以及CRM產品，這些軟體分別執行在Windows、Linux、Unix等諸多作業系統平臺上。此時，多軟體系統的資訊互動和整合問題就日益顯著的暴露出來：外國分支機構彙總的資料無法直接提交到國內總部的系統中，需要人工處理以報表的形式傳送到國內；一項很簡單的業務流程無法在涉及到的各個系統中自動進行處理，需要人為的進行溝通、聯絡並進行操作，其中存在許多協調不暢的情況，甚至因此貽誤了商機。公司的高層決策者們收到各方面的反饋意見和抱怨，發現公司的資訊化系統處於難以管理，難以協調，資訊滯後，決策滯後，整體維護困難，升級代價高昂的境地。無奈之下，決策者們只好向IT顧問求助以尋求有效的解決方案。IT顧問根據該公司的實際情況，提出了使用基於SOA應用整合中介軟體的建議，因為這種中介軟體恰好可以解決此服裝公司面臨的問題。經過一段時間的投入，該服裝公司終於具有了一個協調、管理、業務操作整合和資料整合的控制中心，隨時隨地瞭解各個部門的資料和執行狀況，系統還能夠根據資料倉庫中的資料智慧化地、及時地向決策者們推薦根據市場變化情況調整業務流程的方案。沒錯，這就是基於SOA的應用整合中介軟體的魅力所在。

3.2 架構設計

                                              圖3 一種基於SOA的應用整合中介軟體架構圖

• 基礎應用Framework（核心執行時）

        該層是整個應用整合中介軟體系統的最底層也是核心層，正如其名字所反映的那樣，該層包含了支撐中介軟體正常執行的基礎框架、基本類庫等，同時還需要從底層上實現一個ESB(企業級服務匯流排Enterprise Service Bus)從而能夠保證將外部的各類軟體插接到上面實現應用整合。因此，該層涵蓋的內容非常廣泛，也是該中介軟體產品成功的關鍵。ESB能夠實現到何種程度也就意味著最終能夠實現多大程度的應用整合。SAP的NETWeaver最下層也是這樣一個Framework，但是目前只提供對.NET和JAVA兩個平臺的支援，也就是說還僅能夠將.NET和JAVA應用整合進去。而傳統的Win32應用甚至基於指令碼的應用及其他更為原始的應用如C程式系統將會被拒之門外。

• 業務支援元件

        應用整合中介軟體本身也是一套完整的系統，也應具備普通應用系統具備的公共模組，比如中介軟體本身需要負責的事務管理模組，資料訪問控制模組，基本業務配置模組，日誌管理模組，異常處理模組，郵件及訊息管理模組甚至還有商業系統之間互動管理的模組。這些支援元件雖然不是直接用於應用整合，但是對於中介軟體這個軟體系統本身的執行而言卻是不可缺少的。

• 可擴充套件的服務庫

        該中介軟體的用途在於對外部應用進行整合並轉化為相應的服務。然而，系統本身預置的服務畢竟有限，若想滿足業務不斷變化的需求，必須將外部系統匯入，將其應用註冊為預置的服務。這樣一來，中介軟體具有的服務庫就會不斷得到擴充從而使得功能更為強大。

• 整合開發環境IDE

        作為一箇中間件產品而言，擴充套件性也是非常重要的，如果能夠提供一個附加的圖形化開發工具使業務人員根據自己的需要調整、增加中介軟體具有的功能，無疑是產品的一大亮點。同時，作為整個系統的一個套件，也能夠使產品體系得以完善。

•  企業級Portal 

        基於SOA的應用整合中介軟體首先是一箇中間件系統，因此必須提供一個外部可以訪問並進行配置甚至直接操作的介面，比較主流的當屬portal。通過一個企業級的門戶，操作人員可以直接通過瀏覽器登入、瀏覽或者使用上面的各種服務對應的功能。這個門戶具有動態配置與釋出的能力，一站式登入的能力，當然也應該有較強的互動能力。SAP的NETWeaver就具有一個非常強的Portal，當屬典範。     

3.3 總結與展望

        現有的基於訊息中介軟體等解決方案，較好地滿足了應用系統在效能、服務質量和安全性等幾個方面的需求，畢竟這些技術已經日趨成熟。但在SOA環境中，其應用元件之間是一種鬆耦合的關係，要讓一個應用軟體的元件，很容易去跟屬於不同應用的軟體元件進行對話，並如何確保這些迥然不同但又互相連線的系統的效率、可靠性、可控性和安全性，就複雜得多了。追求純粹的SOA顯然不能有效解決這些問題，因為它太抽象又太多的不確定因素。然而如果能夠將SOA的思想融入到應用整合中介軟體中去則可以集各方優勢，倒不失為一套穩妥的解決方案。

        2006年是國內外軟體廠商拉開有關SOA產品之戰序幕的一年，這其中既有廠商們的大力吹捧又有媒體不遺餘力地宣揚，但是有一點卻是事實：對國內企業而言，中介軟體是一個機會，而基於SOA的中介軟體一定是那些有實力大企業的機會。正因為如此，國家資訊產業部資訊產品管理司將基於SOA的應用整合中介軟體列為投資的重點產業並公開向國內企業招標。在答辯會上，有十幾家企業拿出自己的方案書激烈角逐，最後中標的就可以一次性獲得國家幾百萬元的資金支援。國家對SOA對中介軟體的重視程度由此可見一斑。

        正如上面所言，基於SOA的應用整合中介軟體屬於有實力的軟體企業，誰給與重視並敢於投入，誰取得了先機，誰就很可能成為未來國內軟體市場的主導者。