TechEd 2003特別報導-.NET的分散式物件應用

.NET對分散式物件及Web Services技術多所著墨
從物件導向走向分散式物件

在物件導向風行多年之後，多數企業的應用程式均朝物件導向發展，微軟在TechEd 2003中特別說明分散式物件的觀念，繼DCOM及COM+之後，.NET提供Remoting技術，在.NET平臺上提供較Web Services效能佳的分散式物件應用。

在Visual Basic盛行的世代，由於物件導向的架構不是很明確，因此主從架構的物件導向應用程式，大多只做到功能導向（Function-Oriented）的資料服務，而沒有完整物件的概念。資料服務由用戶端執行邏輯判斷及權限審核，再將合法的要求傳送至伺服器存取資料，因此網路上傳輸單純的資料，不包含商業邏輯。功能導向的應用程式先依商業邏輯撰寫功能函式，再將物件以參數方式傳給函式處理。這種作法導致一旦商業邏輯改變，便需大費周章地修改函式，與功能相關的所有物件參數也需作大幅的修正，因此耗費許多維護成本。

物件導向在傳輸的過程中，物件除了資料外，還包含商業邏輯的程式判斷，具有局部的決策權，可減低用戶端程式碼的撰寫。撰寫應用程式前要先規畫物件類別，確立之後再定義類別的功能與運算，而商業邏輯實作的細節則加以隱藏，只留下呼叫它們的介面供外界調用。

分散式物件則應用於多層式（N-Tier）架構，允許系統的各個部分，分布在不同地方的電腦上；所謂分散式運算是應用程式不只是擷取遠端資料庫伺服器的資料，而且可以分散在不同的系統平臺上，並一起運作及共用資料。我們可以使用遠端的商業邏輯，並分享遠端的資料；無論用戶端在何處，都可以存取分散式計算的企業應用系統。分散式物件可重複使用的商業邏輯元件，可簡化應用程式的管理，且更具穩定性與安全性，加速企業應用程式開發，提升應用程式的可攜性與執行速度，讓用戶端的開發與資料的處理更具生產力，強化企業競爭力。各家分散式物件的技術
SOA結合物件導向才理想

Java家族的RMI、CORBA的IIOP、Microsoft的DCOM、COM+及Web Services等都是目前當紅的分散式物件技術；透過它們讓不同電腦上的用戶端程式，都可以使用到分散式系統中的物件。不過目前各家分散式物件的技術皆不相同，無法彈性互通，用戶端必須綁死在特定技術上。

Web Services是目前網際網路上跨平臺通用的最佳方案；而企業內部網路中，使用專屬的技術執行效能較佳，CORBA是可跨平臺及程式語言的技術；RMI針對Java設計的跨平臺分散式運算技術；而微軟推出.NET Remoting（.NET遠端服務），則是.NET平臺實現分散式物件的技術。

.NET分散式物件關鍵技術包括Serialization及Remoting，Web Services即Serialization的機制，可設定屬性將物件傳送到用戶端，即傳統以值呼叫（Call By Value）的方法；.NET Remoting則是以址呼叫（Call By Reference），開發人員可自訂傳輸通道及檔案格式，較Web Services適合企業內部網路使用。

在分散的多層式架構（N-Tier）中，COM+及IIS搭配Web Services，資料傳輸的過程中，若未包含商業邏輯也僅達到資料交易的功能。最近相當熱門的話題SOA（Service Oriented Application Architecture；以服務為導向的應用程式架構），將個別程式或系統視為許多的服務，再利用共通的服務介面溝通的一種應用程式架構設計方法。每一個服務具有完整的資料結構與程式邏輯，並透過定義好的訊息格式進行溝通。

服務與物件的差別在於，物件封裝資料與商業邏輯；服務僅封裝邏輯卻不封裝資料，因此存在安全性及效能的問題。以資料為中心的服務架構，回傳處理過的資料；而結合物件導向的服務架構，以物件傳遞資訊，內含商業邏輯可判斷使用者是否具有存取的權限，將能提高安全性。設計模式及UML的推廣

設計模式（Design Pattern）及UML雖然已推廣多年，但在以中小企業主的臺灣，並沒有受到廣大的重視。今年TechEd 2003微軟在課程中安排了這兩項主題，而且參加人數非常踴躍。

模式（Pattern）是一種「千錘百鍊」的智慧結晶。根據經年累月的經驗，得知在適當的時機，套用公式或法則以解決特定的問題。設計模式是軟體界前輩的智慧結晶，以解決過去經常發生的問題。運用良好的設計模式，可使系統架構更優良也更快完成，對於後續的程式撰寫、測試及維護，有很大的幫助。在「Microsoft .NET企業應用系統架構與設計模式」課程中，講解了MVC及Facade等設計模式，從會後發問的人數及內容來看，開發人員對設計模式雖不盡了解，但已開始感到興趣。

在「快速開發.NET應用程式」的課程中，概略地講解UML的概念，塑模可使事物的本質簡易化，透過UML共通的表現方式，讓設計、開發人員及使用者達成良性的溝通。不過，從學員表示難以說服企業採購塑模工具，及對學習塑模語言感到負擔的反應，可了解UML在臺灣無法快速普及。在會場微軟以自家產品Visio展示塑模功能，事實上，IBM Rational及Borland的Together等著名的塑模產品，均有推出.NET的版本。EJB與.NET Enterprise Services的演進與比較
從多層式架構比較J2EE與.NET的差別
從COM到.NET Enterprise Services
物件導向的分散式運算技術

回顧應用程式架構的發展史，從兩層式（2-Tier）架構、三層式（3-Tier）到多層式架構（N-Tier）。傳統兩層式主從架構，包括使用者介面層的用戶端及資料服務層的伺服器端，缺點是用戶端的應用程式龐大且複雜，維護成本頗高。

三層式架構分為用戶端使用者介面層、商業邏輯層及資料服務層，將商業邏輯獨立出來，可減輕用戶端及伺服器的負擔。隨著物件導向的流行，中間商業邏輯層被包裝成許多物件。多層式架構又稱為四層式架構，與三層式架構的差別在於，將中間的商業邏輯層分為網站伺服器及應用程式伺服器。

從多層式架構比較J2EE與.NET，用戶端同樣使用HTTP通訊協定，並透過瀏覽器作為使用者介面，差別在於後端的應用。第二層網站伺服器，J2EE執行JSP、Servlet、Struts及JSF等開發的程式，.NET則是透過IIS執行ASP.NET開發的程式。

第三層J2EE可選擇二十多家廠商提供的應用程式伺服器產品，包括IBM WebSphere、BEA WebLogic、Sun iPlanet、Oracle 9i AS、Borland Enterprise Server甚至免費的JBoss或Apache Tomcat參考實作等，執行EJB元件；.NET則使用IIS執行.NET Enterprise Services及COM+等元件。第二層與第三層的溝通，J2EE是透過RMI over IIOP通訊協定；.NET則使用.NET Remoting。最後一層資料庫伺服器，J2EE與.NET均開放支援所有資料庫產品。只是J2EE藉由JDBC及JDO存取；.NET則以ADO.NET串連資料庫。

COM加上分散式運算即衍生出DCOM的技術，不過當時的MTS並沒有與整合Windows NT，必須額外安裝。COM+則是企業級的物件導向分散式運算，COM+ 1.0已內建於Windows 2000，COM+ 1.5則內建於Windows XP及Windows Server 2003。

當Windows升級到.NET平臺，COM的技術被.NET Component取代，DCOM則由.NET Remoting取而代之，而.NET Enterprise Services是架構在COM+之上，雖然COM+目前並未完全被取代，不過，相信未來將逐漸淡出。

在Windows NT的年代，RPC（Remote Procedure Call；遠端程序呼叫）是主從架構下用戶端可呼叫伺服器執行程式，並傳回結果的一種通訊協定。RPC的出現對開發人員而言是一大福音，只要撰寫用戶端及伺服器端的程式，傳輸通訊的複雜處理過程，交由RPC處理即可。

RPC並沒有物件導向的概念，DCOM即是RPC加上物件導向的應用，.NET Remoting則簡化了DCOM的複雜度，不過DCOM與.NET Remoting均為Windows平臺的應用。CORBA則是跨平臺及程式語言（Common Object Request Broker Architecture）技術，不過由於技術複雜且昂貴，因此難以普及。在Web Services出現之後，CORBA的應用逐漸減少，未來將僅存在於少數對效能要求嚴苛的企業內部網路中。

Java的RMI（Remote Method Invocation；遠端方法調用）可說是具物件導向概念的RPC，在Java 1.1即推出。不過RMI只限於Java的溝通，並沒有跨平臺的應用，後來RMI將底層通訊協定分為JRMP（Java Remote Method Protocol；Java遠端方法協定）及IIOP（Internet Inter-ORB Protocol），最初底層是以JRMP作為通訊協定，後來被CORBA取代，成為J2EE的RMI over IIOP。

與J2EE的EJB相較，開發.NET Enterprise Services較為簡單，EJB較為複雜，不過具有較高的彈性，且企業可擁有高度的自主權。J2EE與.NET使用的技術及架構大同小異，只是J2EE由JCP組織共同制定公開的標準，各家廠商再依標準實作產品，而.NET由微軟單一廠商主導。.NET只能選擇Windows平臺及微軟的解決方案；而J2EE具跨平臺的特性，且可從多家廠商中選擇適合的產品。兩大陣營的良性競爭，對企業而言，可說提供了更多元的選擇。.NET對Web Services提供的支援
動態搜尋Web Services的機制
強化Web Services的WSE 2.0工具包
ASP.NET Starter Kit

企業內部網路的應用系統整合，可選擇CORBA、.NET Remoting及DCOM等技術，以提供較佳的執行效能。網際網路的異質平臺整合方面，Web Services佔有舉足輕重的地位，透過業界標準的XML格式，Web Services可滿足跨平臺，適合穿越防火牆B2B的應用，且具重複使用性，可提升生產力。

.NET提供動態的Web Services架構，將保有更大的彈性。不過Web Services畢竟是相當年輕的技術，在企業最關注的資料傳輸安全性方面，尚未制定完整的規格。因此.NET推出WSE 2.0工具包，以強化Web Services的安全性及執行效能。

過去.NET使用Web Services，只能靜態的在設計階段利用wsdl.exe或「Add Web Reference」搜尋Web Services，再讀取WSDL檔轉換成.NET程式可解讀的代理程式，無法在執行階段動態呼叫Web Services。當Web Services的位址、功能或參數有所更動時，就必須修改程式，較不具彈性。

動態呼叫Web Services的方式，在設計階段並不需要知道WSDL，而是在執行階段才開始搜尋Web Services，動態解析WSDL文件產生代理程式，再根據定義初始化並啟用Web Services。開發人員可選擇將設定固定在程式中，或設計使用者介面讓使用者自行輸入Web Services名稱，選擇呼叫執行的方法，並輸入相關參數，使呼叫Web Services的架構更具彈性。

WSE（Web Services Enhancement）是微軟針對Web Services推出的工具包，包括WS-Security、WS-Attachment及WS-Routing等機制，讓開發人員可開發具安全性、支援路由傳送並夾帶檔案的Web Services。1.0版已於去年12月上市，WSE 2.0目前已進入預覽階段。

WS-Security可套用現有的認證、加密及簽章技術，以確保訊息的身分鑑別、完整性、機密性及不可否認性，讓開發人員專注於商業流程，降低撰寫安全性需求的程式碼。由於WSDL無法描述安全性需求，Web Services原則可透過XML架構的組態檔，定義SOAP訊息的有效期限、安全性需求及通訊協定的版本等內容。

目前Web Services以二進位元檔傳遞文件，接收後再還原檔案內容。WS-Attachment提供夾檔的功能，可減少訊息來回拆解運算的過程。WS-Routing以Facade設計模式為架構，提供Web Services的轉送服務，可跨數個網站伺服器傳遞Web Services。開發人員可在.NET的Web.config檔以類似建立轉送對照表（Routing Table）的作法，定義服務的提供者。未來Web Services的伺服器更名或改變IP位址，只要修改組態檔的路由設定即可。

WSE目前並未正式成為業界標準，由於微軟是參與制定標準的主要成員之一，所以.NET預先實作未成為標準的規格。雖然影響Web Services跨平臺的相容性，不過由於WSE工具包並不內建於Visual Studio .NET，企業可視需求決定是否下載使用。WSE工具包目前是英文版，開發人員透過工具即可設定WSE的各項功能，不需自行撰寫程式。目前WSE工具包的功能仍不算完整，與未來正式的業界標準也可能稍有不同，因此比較適合應用於.NET平臺本身。

在TechEd 2003「與微軟對談」針對Microsoft .NET的場次，有不少學員詢問ASP.NET相關的開發問題，甚至抱怨ASP.NET資料呈現的功能太過陽春。事實上微軟為了推廣ASP.NET，已推出ASP.NET Starter Kit，包括入口網站、社群、報表產生、專案追蹤及電子商務等五種.NET Web應用解決方案。ASP.NET Starter Kit是由美國微軟開發的英文版免費開放原始程式碼，企業可至微軟網站下載，並可任意修改程式碼。

ASP.NET Starter Kit針對各種需求提供的入門套件，可讓資訊人員學習到ASP.NET的三層式架構、支援行動裝置的功能、開發Web Services、建立圖形及報表、驗證及存取資料庫等的開發技巧。不但可節省開發的時程，資訊人員不必再逐行苦寫程式，更可降低學習的成本。文⊙李延華