.NET與J2EE只能是敵人嗎？
台灣微軟產品行銷經理 許建志 2004/05/10
上期文章談及目前多數企業內系統多是多層式的架構，可分為展示層、中介層與資料層。因此，整合便會在這幾層之間產生多種連接點的組合。其中，中間層技術整合最為複雜，包括展示層到中介層（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溝通；另一方面，昇陽也將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先建立一個連接點對點的實驗性專案是比較好的選擇，一方面因為不同平台對應的技術已經非常成熟而開發容易，另一方面也是最節省成本而能清楚檢視效益的方式。
當然，如果不滿足於互通的效率，或是希望更進一步的進行更緊密的整合，包括繼承、雙向溝通、資料型別的對應等，使用協力廠商所提供的低階整合技術也是可以考慮的選擇。
一旦整合端點進行到超過一定數量以上，便該開始考慮訊息佇列或是集線器概念伺服器等的軟體，將可以大幅增進異質平台整合的速度。上圖是進行異質平台的選項指引：
在熟悉了這些整合技術之後，下ㄧ期開始將開始說明不同企業透過Web services進行整合的應用案例與分析。
fr.: http://taiwan.cnet.com/enterprise/topic/0,2000062938,20089372,00.htm
0 Comments:
Post a Comment
<< Home