撰文／李國平
EAI 技術背景EAI（Enterprise Application Integration）企業應用內建近來伴随着企業資訊系統的成長正在迅速升溫。在早期單一部門級小型C/S應用階段，企業和開發商并沒有內建系統的需求與必要；而時至今日，企業應用從OA到MIS，從Call Center到Enterprise Portal，ERP/CRM/SCM等橫跨Intranet /Internet的分布式系統Step by Step地部署建立起來，而這些各司其職的資訊系統卻缺乏互聯互通資料共享事務協作的能力，形成了網絡時代的資訊孤島。抽象歸納一下，如果期望的資訊體系有以下一個或多個需求：
１．體系内有一個以上的資訊系統。
２．各個系統可以建立在不同時期或不同平台。
３．資訊系統都能相對獨立地工作。
４．系統間需要資料共享或業務協作以及跨平台事務處理。
５．統計分析查詢資訊資料可以覆寫整個體系或來自特定系統。
６．有時需要增加或替換一些系統并平滑地與其它舊有系統繼續協作。
７．具備體系與體系的互動能力，就像體系内所能做到的一樣。
８．延長體系和系統的生命周期，提高可用性并降低耦合複雜度與維護成本。
那麼，不可避免地企業将面對資訊系統整合這一技術課題。
EAI就在這樣的需求驅使下走上了IT技術舞台。EAI的主導性原則是：降低企業應用整合的成本、風險與複雜度，建立一個有序的協作性強的多系統企業架構。在EAI概念提出之前，企業已經有一些傳統的資訊交換與系統整合方式來滿足上述需求解決互動問題，如自定義格式、EDI和XML格式的資料檔案交換、共享資料庫、調用特定廠商提供的API或元件接口等，EAI其實并不是取代前者的技術，而是綜合現有應用內建技術與手段，為企業應用整合提供分析設計思考方法與架構模型的理論支援。本文将從EAI的分析導向、架構模式、實作技術、安全政策、産品淺析等幾個方面漸進式地為大家介紹EAI技術。
EAI 分析導向EAI的分析導向不是要為決策者或架構師們提供一種EAI實施的向導，而是傳遞一種EAI系統分析的思考方式。确切地講是在規劃和指導EAI體系需要把握和平衡的不同層次多個側面， EAI分析導向應當是在整個EAI項目的體系規劃架構設計開始之前，就應當訓練的思考方式和确立的審視标準，并且貫穿于整個EAI項目的始終。
要建立完善可靠的EAI技術體系模型，應該權衡分析并滿足以下幾個方面的需求：
a. 應用整合導向（Application Integration-Oriented）
應用整合導向的思考出發點為如何整合現有的和未來的應用系統，以實作資源共享與資訊互聯。首先需要明确每一個系統在企業資訊化的時間和空間中所承擔的業務。在一個或多個系統間建立可用性強的企業應用，把分散的、孤立的應用按企業業務需求和資訊體系規劃按實際應用進行內建。應用整合可根據企業需求與系統特點靈活選擇從資料層、業務邏輯層、使用者界面層等多個層面開展。如醫療業的IHE（Integrating the Healthcare Enterprise）目标就是為了整合醫療機構體系中的HIS、RIS/PACS、LIS、CIS、ICU/CCU等應用系統。
b. 流程自動化導向（Process Automation-Oriented）
流程自動化導向是以實作企業流程的自動化，縮短流程時間，提高工作效率并降低工作成本與人為出錯幾率為目标的思考方式。在兩個以上系統與應用間完成文檔、資訊或任務的業務流轉，減少非必要的人為幹預和工作量，建立協作性強的流程自動化體系。現在流行的BMP(Business Process Management)業務流程管理與BPA（Business Process Automation）業務流程自動化都是這種概念的延伸。如WfMC（Workflow Management Coalition）工作流管理聯盟規範，其核心的價值展現就是互操作性（Interoperability）。
c. 事務處理導向（Transaction-Oriented）
事務處理導向的着眼點是事務的處理，首先明确事務進行中的分布在不同應用不同系統中的各種元素，并對事務處理的參與者進行角色劃分，對事務類型進行抽象歸納，建立業務處理政策的制定與調整機制以具備業務調整自适應的能力，實作事務的協作者所必須的功能與接口，提供可用的事務協作元素并保障事務的建立、配置設定、稽核、執行、回溯可以順利地在分布體系下完成。
d. 分布對象導向（Distributed Object-Oriented）
分布對象導向是采用面向對象的思考方式描述與建構分布式資訊系統，從資訊系統的基本元素——元件（Component）上提供分布式計算的能力，将分布式系統中的業務邏輯與功能集合抽象成特定的對象，并通過定義對象間的通信規則和關聯關系以組成分布式系統的整體架構。如RPC、CORBA、EJB、DCOM、．NET等對象模型都是基于分布式對象的應用體系技術。
各實施導向之間并不是互斥和孤立的，而是一個從宏觀到微觀的漸進分析過程。每個應用整合項目中都需要設計多項業務流程、每個業務流又有可能由一到多個的事務組合而成，而可抽象的每種事務類型則是由大量的分布式對象來描述與協作。在實際的EAI系統架構設計時，應當綜合考慮多種導向的思想，兼顧應用、流程與事務、業務對象等多個層面的分布化應用協作問題，才能從千頭萬緒複雜多變的企業應用體系中抓住EAI體系架構的關鍵環節，剝絲抽繭地明确企業的分布應用體系需求及特點，為體系的設計規劃提供前提保障。最終達到減小應用系統的互相關聯性，縮減系統互動和內建的複雜度，優化和改進現有業務流程，提高自動化程度，減少人為幹預與出錯幾率，建立獨立性強，延展性好的分布應用的目的。
EAI 架構模式架構模式（Architecture Pattern）是差別于設計模式（Design Pattern）的概念，設計模式是為了提高軟體的靈活性和重用性，在不斷發展變化的項目與設計中針對某一類特定問題的解決方法抽象與實作思想歸納，故也被稱為微架構模式（Ｍicro Architecture Pattern）,而架構模式雖然與設計模式有許多共通之處，但着眼點則是更為宏觀的High-Level Design，是設計模式的思想放大與概念深化，是面向整個系統架構的全局方案模型。
EAI架構模式的目标是為EAI的成功實施提供一組基礎技術理論支援，是得以解決EAI架構設計中的若幹問題的具體的模式化的結構模型，正确地靈活地應用EAI架構模式，是EAI項目成功實施的重要保障，正如牢固的完美的建築物都植根于科學理論和精确計算的建築架構一樣：
a. 內建擴充卡(Integration Adapter)模式
意圖：轉換已有的應用接口到期望接口
參與者：一個或多個的用戶端應用、內建擴充卡和一個服務服務端應用
圖１：內建擴充卡模式
內建擴充卡模式提供一種導出可重用應用服務的靈活方法，此架構模式與設計模式中的擴充卡模式的意圖相同，另外內建擴充卡模式的另一個意圖則是為多個用戶端應該提供可重用的接口。用戶端應用通過內建擴充卡來調用服務端應用，內建擴充卡轉換被導出的公用API為伺服器端API。擴充卡不知道用戶端應用的存在。在非侵入式（nonintrusive）的擴充卡設計中，擴充卡對伺服器端是透明的，而在侵入式（intrusive）擴充卡設計中，服務端應用在一些情況下需要做一定修改。
正如文章開始所描繪的那樣，企業資訊化是呈階段性發展的，在此過程中後進系統大量的基礎資料往往需要從舊有系統中擷取。內建擴充卡模式，比較适合解決新老系統的協作整合問題。Sun在J2EE1.3中推出的JCA（Java Connector Architecture）Java連接配接器架構就符合內建擴充卡模式，JCA的目标就是在Java新世界與舊有的EIS（Enterprise Information System）企業資訊系統間通過CCI（Common Client Interface）建立通用的內建适配規範。
b. 內建消息器(Integration Messenger)模式
意圖：描述減少應用間通訊關聯性的方法
參與者：被內建的應用、內建消息器
圖２：內建消息器模式
內建消息器是一個實體層上的分布式邏輯實體。內建消息器模式描述減少應用互動邏輯的應用內建架構，顯著的益處就是可以降低應用間的通訊依存性，建立起更為靈活的內建機制，在應用間傳遞消息并提供位置透明的服務。內建消息器模式可支援的通信方式有：
１．一對一同步（請求/應答） 由一個用戶端應用和一個服務端應用構成，用戶端在阻塞模式下等待服務端對請求進行處理。
２．一對一異步（消息隊列）。由一個用戶端應用和一個服務端應用構成，用戶端在非阻塞模式下等待服務端對請求進行處理。
３．一對多異步（釋出和預定）。由一個用戶端和一個或多個服務端組成，可由多個預定者訂閱同一個釋出事件。
在此涉及到在應用間進行互動，與EAI密切相關的概念——應用互動模型（Application Interaction Model），包括以下三種模式：
１．消息代理器（Message Broker）
２．消息隊列（Message Queuing）
３．釋出和訂閱（Publish＼Subscribe）
在本模式中，應用負責實作應用互動邏輯，應用互動的語義對內建消息器完全透明。通訊模型是多樣化的，但其目的是一緻的——最小化應用間的通訊依賴性。異步模式對比同步模式的優點在于，異步模式可以確定資料被安全可靠地發送和接收，而不必擔心因為網絡或其它異常而導緻的資料丢失；缺點則是異步模式會導緻将同步消息處理事務拆分成了消息發送/入隊，消息接收/出隊兩個分段事務，實時性與互動體驗比同步模式差。由于內建消息器是基于消息傳遞的松耦合技術，消息在發送方和接收方的平台、應用上保持中立，易于實作跨平台系統的內建。另外，通過消息代理機制還可以完成諸如資料轉換、消息分發、路由、緩沖、存儲等特定功能。JMS（Java Message Service）Java消息服務中展現了內建消息器模式的架構思想。
c. 內建外觀(Integration Facade)模式
意圖：減小用戶端與服務端應用的關聯性，提供一個連接配接到背景應用的簡化接口
參與者：一個或多個的用戶端應用、內建外觀和一個或多個的服務端應用
圖３：內建外觀模式
內建外觀架構模式與外觀設計模式的意圖一緻，但內建外觀架構模式為減小用戶端應用與服務端應用的依賴關系提供更高層的簡化接口，提供靈活的可重用的應用和應用內建服務。內建外觀能為一個或多個用戶端提供一個簡化接口。用戶端應用調用內建外觀的簡化服務，內建外觀抽象伺服器端的功能并把內建外觀的接口轉換成服務端應用接口，使服務端應用更易于使用。用戶端應用程式完成實際工作，而內建外觀将自身的接口轉換成服務端應用接口。其互動模型是用戶端或服務端之一的單向性互動。內建外觀不知道客戶的存在，服務端應用也不知道內建外觀的存在。通過從多個服務端應用系統中抽象出統一外觀接口，就可以簡化用戶端的內建難度，達到對多個服務應用的方法一緻性調用，屏蔽了其原有的複雜性。
d. 內建中介器(Integration Mediator)模式
意圖：封裝應用互動邏輯，最小化應用關聯性
參與者：內建中介器、參與的應用（Participating Applications）
圖４：內建中介器模式
內建中介器模式是封裝應用互動邏輯與降低應用間耦合的應用內建架構方法。其重要優點有：
１．最小化了應用間的依賴性和舊有系統的影響。
２．通過集中式的應用互動邏輯簡化了分布式互動的複雜度與維護工作量。
３．在封裝的應用互動邏輯的基礎上易于建立可重用的服務。
這些優勢為實施者提供了更為靈活的內建方法，并改善了商務的靈活性。與內建消息器相比，內建中介器知道有哪些應用存在。內建中介器包含了應用互動邏輯，負責控制和協調應用間的互動，應用程式直接與內建中介器互動，而不需要面對不同的應用程式。各應用間通過與內建中介器的直接互動，降低了應用間互相調用所存在的複雜度，達到了最小化應用關聯的目的。而與內建外觀相比，內建中介器為應用提供的是不分客戶與服務的雙向存取功能。并且內建中介器通常也由實體上的伺服器實作，而不僅僅是統一的抽象接口邏輯。
e. 流程自動化器(Process Automator)模式
意圖：減小流程自動化邏輯與應用的關聯性的架構方法描述
參與者：活動服務（Activity Service）、流程控制器和應用
圖５：流程自動化器模式
流程自動化器模式描述最小化流程自動化控制邏輯與資訊系統依存關系的架構方法，借此所有的系統互動（及人的互動）都由活動抽象從流程控制器中得以隐藏。
主要優點有：
１．可以經濟地實作強大的流程自動化解決方案。
２．可獲得空前的業務流程分析能力（如流程瓶頸、統計資訊、錯誤資訊和資源利用等）。
３．此種架構可獲得空前的重定義和快速部署流程自動化應用的靈活性。
４．與內建外觀模式和內建中介器模式類似，應用內建邏輯是封裝并且可共享的。
５．流程自動化應用工具貼近管理者角度，減少了商業角度與IT世界的語義分歧，最小化從商業需要到IT解決方案的轉換發生錯誤的可能。
流程自動化器模式可以通過靈活的系統內建架構改善交易的靈活性，交易需要高品質的業務流程、降低縮短業務周期、降低處理成本。相同的流程每天都被重複地執行無數次，流程自動化器可以自動地為這些流程建立活動的排序機制，流程自動器的核心是活動的排序和控制（自動或手動）。以流程自動化器模式為基礎，在企業分布式體系下實作業務流程管理和業務流程自動化的難度将大大降低。
EAI架構模式中的這五種模式有一個共同目标：減小應用間的耦合度。不同的模式，總在不同的層次上進行解耦的工作。內建擴充卡是在接口層，內建消息器是在通訊層，內建外觀和內建中介器是在應用層。流程自動化器則是在業務邏輯層。在架構層面适當地解耦，是堅固而靈活的EAI解決方案的本質。通過在複雜的企業體系環境下靈活地應用EAI架構模式，可以将繁雜而紛亂的分散應用系統整合為龐大但有序的分布應用系統，為整個EAI項目的成功實施和項目切割奠定了堅實穩健的基礎。在合理的成功的建築架構中添磚加瓦，勢必會比在沙漠中建造海市蜃樓般的空中樓閣更為可靠。
EAI 實施技術EAI技術的層次劃分目前可謂仁者見仁，智者見智，如有将EAI分為三層，從低到高分别是基礎設施層（Infrastructure layer）、應用互操作層（Interoperability Service layer）和檔案層（Content Layer）；而不少應用開發商将EAI按內建的資源分為從低到高的資料（Date）層、應用（Application）層和商業邏輯（Business Process）層，而另外的觀點認為在這三層的基礎之上，還有使用者界面（User Interface）層的內建。在此之外，至少還可以找到不下三種的層次劃分提法，百花齊放百家争鳴向來是學術界與産業界的盛世，不同的出發點和分析角度自然會得出截然不同的結論，筆者毫無妄論之意，隻根據自身工作經驗抽象出EAI技術實作手段的三個層次：最底層協定層由支援同/異步消息交換的各種通訊協定組成，由異步的基于資料交換的資料層和由具有同步實時性的分布式元件技術構成的應用層（包括界面層和業務層，都是被這些應用所實作的），越是采用底層的技術，其耦合度就越低，內建的靈活性也就越強，但可操作性/互動能力就越弱；反之，采用上層的技術可獲得較好的互動能力和操作體驗，但耦合關聯度就會加大，內建的靈活性會受到較多的限制。而事實上每一種較上層的技術都是對比其低層的一種或幾種技術的封裝特例和綜合應用。
圖６：資訊系統互動／內建途徑及EAI實施技術分層
a. 協定（Protocol）層
協定主要是由實作OSI（Open System Interconnection）開放系統互聯參考模型的通訊協定組成，資訊交換的兩端隻需要按協定約定完成請求/響應，對兩者的作業系統、應用軟體沒有任何限制。協定層主要包括被Internet廣泛采用的TCP/IP及其基礎之上的FTP/HTTP/POP3/SMTP（其中某些上層的協定可通過收/發的事務分段實作異步處理，如FTP、POP3、SMTP等）等基于Socket連接配接的技術（Socket甚至還是某些特殊的本地程序間的通訊方式，如在Service和Application之間），也包括在小型以太網時期流行的IPX/SPX、NetBIOS等協定，另外管道（Pipe）技術也是一種系統間通訊的方式（如SQL Server等資料庫提供的Named Pipe資料連接配接；作業系統還可以提供Anonymous Pipe等）。使用協定層的實作手段，可為資訊內建的開發與應用提供較多的靈活性，但為滿足應用互操作的上層需求将必須付出較大的工作量與成本代價。
b. 資料（Data）層
資料層主要是通過異步方式進行資料的傳遞，資料的發送/接收雙方通過先後對資料的寫入/讀出完成資訊的交換。包括資料庫（如通過ODBC、JDBC、OLE DB等通用資料庫連接配接方式）、消息隊列（作業系統的消息隊列機制其實也算是消息隊列的一個特例，隻不過它是在應用與應用間完成消息傳遞）和直接檔案交換（如Flat File、EDI及XML等格式的檔案交換）三種途徑，這三種方式多數情況下對交換雙方的作業系統和應用軟體沒有限制，并且異步模式也能對批量處理和離線作業提供良好的支援，具有開發工作量小，技術難度低等特點，很多早期原始的資訊交換都是采用資料層的實作技術。
c. 應用（Application）層
應用層主要由各種流行的分布式對象組成，具有對象化的開發和應用模型，調用簡單實時性好，可操作性/互動能力強，但平台無關性差等特點，早期的分布對象技術，多數是從RPC技術衍生進化而來，其中又一度以CORBA（Common Object Request Broker Architecture）平台中立、語言中立、定義完善而廣受支援；RMI、EJB和DCOM、．NET等元件在其各自的分布式平台下也被廣泛應用；而近兩年興起的Web Service/SOAP更是由于既具備對象化的操作能力與較大的內建靈活性（僅受限于SOAP協定本身）而大受業界的青睐，原因也正在于它很好地平衡與把握了互動與內建這柄雙刃劍。近年來大量湧現的中間件廠商一方面靈活地封裝商業邏輯為企業建立起可重定義可重定向的分布式商業資訊體系，一方面也為企業應用層面的內建起到了積極的推動意義。
2002年2月，旨在保證跨平台、跨應用、跨程式設計語言的來自不同廠商的Web Service間的互操作性的WS-I（Web Services Interoperability Organization）Web服務互操作性組織成立，目前已獲得Microsoft、IBM、Sun、SAP、BEA、Oracle、Sybase、Intel、Borland、HP等絕大多數廠商的支援；而同年8月釋出的旨在統一Web Service業務流程協作與整合方面的标準BPEL4WS（Business Process Execution Language for Web Services）Web Service的業務流程執行語言規範也受到廣泛支援，從最初的由IBM、Microsoft、BEA三家廠商發起，目前會員已包括Oracle、PeopleSoft、SAP、Sun、Tibco、Business Process Management Initiative (BPMI.org)、Workflow Management Coalition (WfMC)等公司和機構；以及UDDI、WSDL、WS-Coordination、WS-Transaction、WS-Security、WS-Attachment、WS-License等技術的成熟完善。這些為兌現當初Web Service向世界所作的平台應用無關低耦合度互操作性等承諾鋪平了道路，Web Service已經真正進入了成熟的商用化階段，将要在企業應用與系統內建方面大展拳腳了。
EAI 安全政策資訊系統是現代化企業的命脈，資訊系統的資料丢失、資訊洩露、内容篡改、越權通路等都将是企業不可承受之重。企業應用內建由于涉及Intranet/Internet等錯綜複雜的網絡環節，安全因素更不容忽視。在自始至終從EAI項目的需求分析、設計開發、測試部署及應用運作的整個EAI應用體系的生命周期内，安全都應當是最為重要的一個環節。構築安全的電子交易模式，應滿足以下五個方面，這也是OSI規定的五種标準的安全服務：
１．資料保密：防止資訊被截獲或非法存取而洩密。
２．對象認證：通信雙方對各自通信對象的合法性、真實性進行确認，以防第三者假冒。
３．資料完整性：阻止非法實體對交換資料的修改、插入、删除及防止資料丢失。
４．防抗抵賴：用于證明已發生過的操作，防止交易雙方對發生的行為抵賴。
５．通路控制：防止非授權使用者非法使用系統資源。
建立安全的企業資訊平台，應從以下幾個方面着手：
a. 從管理高度重視安全體系
人是社會活動和生産活動中最活躍的因素，要建立安全的企業資訊體系，首先應從管理高度重視企業的資訊安全，企業中上到上司層下到操作員，都應認識到安全對企業的重要意義，才有可能有意識、有針對地加大在安全方面的重視和投資。對内則可以通過建立管理制度、員工操作教育訓練、使用者政策制定、通路權限劃分等機制降低來自企業内部的安全隐患；對外則可以通過建立保密制度和技術投資來規避資訊安全風險，保證企業資訊系統的安全。
b. 用技術手段建立安全體系
通過技術手段規避安全隐患的幾個方面：
網絡安全：安全的應用體系隻能建立在安全的基礎平台之上，企業資訊化規劃與架構設計中就應當充分考慮到資訊安全問題，建立内置的系統級的安全政策，如采用内外網隔離、子網劃分、防火牆、域權限等等技術提供基礎網絡安全。
應用安全：安全的應用應滿足資訊交換的完整性、一緻性、保密性和有效性等多個方面的需求。如在資訊系統的分析、設計、開發、測試、驗收、部署、應用等多個環節把握安全準繩，發現并彌補可能被惡意利用的漏洞；使用SSL（Secure Socket Layer）、SET（Secure Electronic Transaction）、PKI（Public Key Infrastructure）等技術保障電子交易的安全等。
操作安全：系統操作權限的設定應遵循最小化原則，即為操作使用者提供能滿足其工作需要的最小使用權限，避免誤操作和越權通路；另外，還需要建立系統日志機制記錄應用運作與使用者操作的情況。
c. 有法律制度保障安全體系
在管理與技術體系之外，法律支援也頗為重要，有健全完善的法律制度才能為電子商務、電子政務等行業建設提供可靠保障。如，我國政府最近正在審議的《中華人民共和國電子簽名法》草案，相信将對督導中國電子交易的發展壯大起到意義深遠的影響；另外，盡快建立健全我國在計算機及網絡犯罪方面的立法工作也勢在必行，有了國家法律做後盾才能對網絡黑手起到震懾和懲戒的力度。
EAI 産品淺析J2EE/Unix/Linux和．NET/Windows是目前企業應用平台的兩大陣營，兩個體系在成熟度與易用性、高性能與低成本、開放性與相容性、占有率與增長率等多個層面上競争角力，而EAI的衆多技術産品與解決方案提供商也主要是圍繞這兩大企業應用平台分庭抗禮。
a. IBM WebSphere Business Integration
WebSphere是IBM龐大的基于J2EE的電子商業平台的核心，整個軟體家族提供了開發、部署、應用、管理等一整套解決方案，WebSphere Business Integration正是其中專注于企業應用內建與流程自動化領域的一組軟體産品，主要包括被更名為WebSphere MQ 的商業通訊中間件服務MQSeries，和在2002年被IBM重金收購的EAI/BPM軟體供應商CrossWorlds和Holosofx的軟體産品，整合後的WebSphere Business Integration覆寫模型、內建、連接配接、監控和管理五個方面近二十個軟體子產品，并提供大量成熟的行業與跨行業解決方案參考。其目标是連接配接應用和實作流程自動化，建立單一化統一化和現代化的企業基礎架構。所有的應用都可以跨越不同的環境、開發語言、傳輸方式和資料格式來共享資料。可以設計和規劃獨立運作或與人互動的商業流程。企業資訊體系可獲得按照商業需求靈活智能地路由和傳遞資訊的能力。可幫助企業模拟行業特有的業務流程在企業内部與合作夥伴、客戶間的業務活動的流轉，在定制和套裝的應用程式間整合這些流程。将企業流程與供應商和客戶通過連接配接起來，并提供業務流程監控和業務性能管理的功能。在最新V 4.2.2 版的Business Integration中，同步連接配接能力、監控和調試跟蹤等功能都得到了大大的加強。Business Integration正如其所在的龐大的WebSphere體系一樣，具有産品線完善、功能細分明确、組合協作能力強、解決方案靈活、平台一體化等特點，藍色巨人博大精深的軟體模型與解決方案體系由此也可見一斑。
b. BEA WebLogic Integration
WebLogic 原本是一家獨立的公司，1998年被慧眼識珠的BEA看中，收購後成為BEA WebLogic Platform。在2002年前WebLogic曾是J2EE應用伺服器領域的龍頭老大，無奈後來被IBM “随需應變”的WebSphere，奪取了桂冠，隻得屈居第二。BEA WebLogic Platform與IBM WebSphere具有很多共通點，如都是基于J2EE平台，都是套裝化軟體體系，商業應用服務軟體的相同市場定位等。雖然較之IBM WebSphere産品線，BEA WebLogic Platform多少顯得有些薄弱，從系統架構、功能子產品、解決方案、技術支援力量等多方面落後于前者，但能在這個“隻有第一第二，沒有第三”的殘酷競争環境中生存發展，也确有其過人之處。在最新版式的BEA WebLogic Integration 8.1中，BEA WebLogic Integration是其重要産品之一，提供了較為完善的企業業務系統內建方案，包括應用伺服器、業務流程管理、應用內建和B2B內建等功能。為開發、內建和管理業務流程提供了直覺且強大的實施方法，它能使IT技術以單一的解決方案教育訓練适用于所有應用，在跨不同項目部署資源時具有更大的靈活性和可伸縮性，并且提供的開發和運作時架構，将所有業務內建元件統一到一個單一、靈活的環境之下。這些元件涵蓋業務流程管理、資料轉換、業務夥伴內建、連通性、消息代理、應用監控和使用者互動等。BEA 較之IBM當然是“小巫見大巫”，但靈活性卻比較強，比如對EJB等标準支援的産品化響應速度，而IBM之是以能有近百年的發展曆史，風雨飄搖，巋然不動，步步為營穩中求勝才是其生存發展的法寶。
c. Microsoft Biztalk Server
Microsoft長久以來一直是桌面應用領域的霸主，而從．NET Enterprise Servers概念的提出開始，其試圖一改以往自己樹立的桌面應用提供商的形象，正式進軍市場潛力巨大的企業應用領域。盡管從微軟的财務年報來看目前微軟的Business Solutions部門尚處于虧損狀态，但改頭換面統稱為Windows Server System的微軟商用服務軟體體系卻在不斷成長完善中。而其中的Biztalk Server就是面向企業EAI/BPA領域的伺服器産品。最近剛剛問世的Biztalk Server的第三個版本Biztalk Server 2004客觀來講已相對成熟，雖然相較于IBM WebSphere還隻能算是“輕量級選手”，不過對中國大多數的中小規模企業來說，卻是比較有競争力的産品。一方面是因為這些企業的應用平台多數部署于Windows環境，系統底層支援會比較平滑，一方面微軟所謂“Do More With Less”的市場政策也的确符合中國企業資訊化要求少投入多産出的客觀現狀。不過Biztalk Server的價格（Enterprise Edition為2萬5000美元、Standard Edition為7000美元、Partner Edition為1000美元）看似不高，但“水份”不小：首先，Biztalk Server隻能依賴于SQL Server/Windows運作，新出的Biztalk Server 2004更是把開發、配置、部署、管理的環境嵌入到了Visual Studio．NET當中，這些價格不菲的平台軟體Bill當然也是會一文不少地寄帳單給你的。從功能來看，正式基于．NET和支援Web Service、具備企業内部與貿易夥伴間的整合能力、流程管理與自動化、業務規則制定與監控等功能有所增強、遵循了BPEL4WS并提供靈活的行業加速器和擴充卡等等，的确也當刮目相看了。附贈的一條來自微軟内部人士的消息是Longhorn中Avalon、Indigo、WinFS三大特性中WinFS是基于Yukon資料庫引擎（原理類似于在NTFS檔案系統之上加一層類MSDE〈Microsoft SQL Desktop Engine〉無管理界面的資料引擎），并且Yukon引擎完全内建于系統底層之中。以上這點是衆所周知的，真正讓人吃驚的是Biztalk Server的EAI/BPM/BPA商業流程、業務規則和活動監控引擎也将會成為潛在Longhorn底處的一枚重鎊炸彈，也就是說Longhorn系統将把Biztalk Server引擎作為其Indigo 網絡架構中Web Service的一部分，整合到系統底層當中去。希望IBM等其它EAI/BPM廠商不會就此事又與微軟打起曠日持久的壟斷官司來，也不要又被歐盟寄罰單了。
目前EAI領域尚處于春秋戰國的紛争時期，參與的技術廠家較為衆多，無論是領袖群倫的行業巨無霸，還是企業應用軟體領域的後起之秀，資料庫或作業系統發家緻富的淘金者，都觊觎着企業應用領域的這塊大蛋糕，争先恐後地想要分一杯羹。相信經過兩三年的市場競争考驗與優生劣汰，EAI技術能夠更加成熟與完善起來，将企業資訊化推向更深更廣的應用高度。
總結企業資訊化是一個長期的發展漸近過程，而EAI技術是其發展上升的過程中所不能避免的問題。建立強壯而靈活企業資訊體系的關鍵，就是通過EAI技術，将孤立的分散于企業内與企業夥伴間的應用系統聯系起來，形成資源共享、業務協作的分布式商業應用體系。
無論是EAI的導向思想，還是架構模式，都是為成功解決企業資訊系統內建中的種種難題，提供科學的方法與理論依據。EAI概念的引進與實踐，必将為企業降低資訊投資的成本與風險，提高業務競争力與企業應變能力，在資訊孤島間建立起溝通共融的橋梁，為分布式跨應用、跨企業的商業協作體系的建立提供強大的技術基礎和理論參考。
注：本文涉及技術與産品較廣，作者在寫作中參考了國内外的衆多技術資料，在此表示感謝。另外，本文部分觀點源于筆者自身的工作經驗，僅供參考。