摘要：隨著企業的需求日增與技術演進，現在我們已擁有多種選擇可輕易地整合。NET與J2EE兩大平臺。在目前的技術中，兩者的整合機制可分成三種類型

      目前多數企業內系統多是多層式的架構，可分為展示層、中介層與資料層。因此，整合便會在這幾層之間產生多種連接點的組合。其中，中間層技術整合最為復雜，包括展示層到中介層(P to D)、中介層到中介層(D to D)等。過去幾年間，許多廠商所建構的組件技術與標準即是用來協助于企業內部建立各種分布式系統，包括有：

　　Distributed Component Object Model(DCOM)：微軟讓那些使用COM規格所撰寫的組件可以進行分布式應用，并讓組件在遠程機器被呼叫。
　　Common Object Request Broker Architecture(CORBA)：這是OMG(Object Management Group)所提出可跨越不同廠商進而統一分布式系統技術的規格。
　　java Remote Method Invocation(RMI)：Java v1.1.x的核心規格，允許用Java所撰寫的組件可以被分散至其它機器或是行程中。
　　雖然如此，這些技術基本上還是受限于企業內部，甚至是某些固定的平臺之上。雖然微軟提出COM Internet Services(CIS)技術，可讓DCOM透過port 80溝通;另一方面，SUN也將RMI over Internet Inter-Orb PRotocol(IIOP)納入Java規格，但對于那些需要跨越企業內外網絡，甚至是進行不同平臺間的整合工程而言仍然不足。

　　幸運的是，隨著企業的需求日增與技術演進，現在我們已擁有多種選擇可輕易地整合.NET與J2EE兩大平臺。在目前的技術中，兩者的整合機制可分成三種類型：

　　底層協定(Wire Level)

　　這是走低階協議以進行整合的第一種方式。當然，除了「苦工式」整合，也就是自己建立socket或經HTTP通訊協議進行之外，技術人員也可考慮選用協力廠商的產品，例如：Intrinsyc Software的Ja.NET，或是JNBridge旗下的整合軟件等。(前者當然是Java與.NET名稱的整合，后者為Java與.NET橋梁的意思)。

　　其中，「Ja.NET」可視為Java之上的.NET Remoting(編者按：Microsoft .NET Framework內的主要組件)的堆棧實作，而在Java平臺上提供Ja.NET的執行時期模塊(Run time)，可支持TCP/ip、HTTP等溝通管道，也可同時支持SOAP或是二進制互通協議以提升溝通效率。透過此執行時期模塊，.NET與Java/J2EE的數據類型不僅可以對應，還能進行雙向的溝通。

　　JNBridge也是類似架構，透過對應的執行時期模塊與代理程序(proxy)，.NET程序可以在不需要Java原始程序的狀況下與這些組件進行互通、繼承，并將其視為同一個程序內的.NET組件。以下為JNBridgePro的架構圖：



這類整合方式有諸多優點，包括更佳的互通效率、對象參考與生命周期的控制、支持回呼程序(call back)與事件(event)，而能有更緊密的整合效益。但相反的，因為是較緊密型的整合，彈性也會變低。另外，這類整合也通常缺少動態尋找并新增服務的機制。一般來說，對于企業內部不同平臺的整合仍是非常不錯的選擇。

　　訊息隊列或集線器(Message Queues或Hub)

　　點對點的整合只適合初期項目，也許利用上述的底層協議方式，或是下文將會提及的Web services進行互通。但是當.NET有N個模塊，J2EE有M個模塊，要互通就需要建立「N*M」的點對點聯機，復雜性與困難度將之提升。因此，當整合進行到一定規模，可以開始考慮采用類似訊息隊列或是集線器等方式進行。

　　目前可見軟件，如MSMQ、IBM WebSphere MQ、Microsoft HIS、BizTalk Server，或者是Mind Electric公司的GAIA等，都能有效的將整合數量如同集線器一樣減至N+M的狀態。

　　這類技術概念如同集線器，可以整合不同的接口或透過外掛的Adaptor增加對于不同接口的支持。以Microsoft BizTalk為例，微軟與協力廠商所開發的Adaptor便超過一百個，其中包括SAP、Siebel、Java/J2EE、Web services、SQL Server、IBM WebSphere MQ等相對應的Adaptor。

　　換句話說，只要把先前.NET的N個模塊與J2EE的M個模塊各自透過Adaptor「安插」至類似BizTalk Server等具備「集線器概念」的服務器，即能整合與應用不同組件。

　　由于不同平臺之間的組件是非常松散結合的(loosely couple)，相依性較低而適合N對M的整合以達到「服務導向架構」(SOA)的目標，這也是此類整合的諸多優點之一。例如，將一個.NET組件經Adaptor串接至某集線器概念服務器之后，將可用不同的方式存取此組件，也許是經由J2EE、或者是利用Web services，甚至是IBM的MQ Series。如此一來，對.NET組件開發者而言，完全不必擔心未來使用這個組件的對象與技術平臺為何。

　　為滿足進階的需求，這類型服務器部分也內建安全性、交易、路由器等功能，導入成本當然很高，甚至個別的Adaptor也要分開購買，因而適合有大量整合需求的企業采用。


　　網絡服務(Web services)

　　前述兩種方式之外，以SOAP為基礎的Web services進行異質平臺整合，可說是最具彈性與成本優勢的選擇。雖然Web services的規格在WS-I等國際組織推動之下，仍是「現在進行式」，但對于.NET與J2EE兩大平臺進行基本整合與互通而言已是游刃有余。目前.NET與J2EE兩大平臺都有對應的Web services實作，包括：

　　.NET：除了提供舊版本Web services支持能力的Web services Toolkit與Microsoft Visual Studio .NET開發工具之外，幾乎所有微軟的產品都加入了Web services的支持，包括Microsoft Office System、Windows Server System…等，其它還有如Borland的Delphi 8 for .NET、C# Builder…等。
　　J2EE：包括有Apache的Axis、IBM的WSTK和WSAD，以及Mind Electric的Glue…等。
　　其中，Mind Electric將Glue稱為Java Web services的「Turbo Pascal」，意思為用Java撰寫Web services最簡單、最容易入門的工具。除簡單易用之外，Glue可單獨運作或是外掛至不同的應用程序服務器，包括WebLogic、WebSphere、JBoss等，而其執行效率也比很多其它品牌的應用服務器所實作的Web services效率更佳。

　　若從技術細節剖析，透過Glue可以將EJB對外包裝成Web services，并可以和JASS進行安全性整合、透過JMS提供可依賴的訊息機制…等。因此如果只是想單純的加入Web services支持，使用Glue會比升級應用服務器更劃算。

　　進行整合的階段

　　雖然上面介紹了眾多不同整合的技術，但是一旦企業產生異質平臺整合的需求，透過Web services先建立一個連接點對點的實驗性項目是比較好的選擇，一方面因為不同平臺對應的技術已經非常成熟而開發容易，另一方面也是最節省成本而能清楚檢視效益的方式。

　　當然，如果不滿足于互通的效率，或是希望更進一步的進行更緊密的整合，包括繼承、雙向溝通、數據型別的對應等，使用協力廠商所提供的低階整合技術也是可以考慮的選擇。

（出處：http://www.companysz.com）