com+.webservice.remoting 的介绍

最新推荐文章于 2025-05-07 11:31:06 发布

chenzhifeng

最新推荐文章于 2025-05-07 11:31:06 发布

阅读量1k

点赞数 1

文章标签： service object asp.net components .net windows

本文链接：https://blog.youkuaiyun.com/chenzhifeng/article/details/1700361

版权

本文探讨了.NET平台上的商业组件设计及其应用，包括.NET Remoting、COM+与ASP.NET Web Service技术的特点，并介绍对应的实现模型。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如果你已經以商業元件為設計應用程式的核心，則在 .NET 平台上開發程式，你會有左右逢源的感覺，我們在.NET平台可以組合各種元件，並快速實作提供適當的服務。我以表-1 的 OrderBusinessLogic 處理訂單當做商業元件的例子，依序說明 .NET Remoting、COM+、及 ASP.NET Web Service 技術的特性，並介紹其對應的設計模型。我對這些設計模型的變化做個比喻，商業元件就像牛肉，加上不同的配料與烹飪方式，我們做出牛肉麵、沙茶牛肉、牛肉火鍋、或是牛排大餐，這是在不同場合或條件限制下提供的服務變化，而 .NET 平台與 VS.NET 則是厨師的最佳助手與工作環境。

public class OrderBusinessLogic
{
	public bool AddNewOrder(…)
	{ . . . }
	public bool UpdateOrder(…)
	{ . . . }
	public DataSet QueryOrder(string queryCriteria)
	{ . . . }
}

表 1

Remoting 是一個完整的分散式物件運算架構，可以看成是 DCOM 的演進版本，它支援二種通訊協定（適用於 Intranet 的 TCP/Binary data，效率較高，及適用於 Internet 的 HTTP/SOAP），允許 Client 控制 remote object 的生命週期，並且支持 Client 與 remote object 雙向傳送訊息。運用 Remoting 設計元件有二種模型，圖-1 設計模型先建立一個 Remotable object 做為可以在網路兩端自由行動的物件，再建立一個 Windows Service object 做為 Hosting 機制，Service Object 使用 TCP 或 HTTP 通訊協定註冊服務端點的 URL，用戶端用 URL (例如 tcp://remoteServer:port/OrderService) 取得 remote object，然後與 Remote Object 互動就像在本機一樣了。

圖-2 是第二種 Remoting 設計模型，省去 Service object，用 IIS 當做 hosting process，建立 Virtual root 當做 Order Service，用戶端使用 http://webhost/OrderService/OrderServiceMethod.soap 取得 remote object，後續的使用方式則如圖-1 設計模式。此種方法雖然會犠牲一點效能，但只需要使用 ASP.NET 技術，所以實作上非常容易。

COM+ 是 .NET 支援大型應用系統的分散式運算服務，在 Windows .NET Server 2003 上的 COM+ 是 1.5 版，COM+ 是Enterprise Service components 的執行環境。COM+ 支援交易管理，跨資料庫的 2-Phase Commit、Just-In-Time Activation、Object pooling & Recycling、負載平衡…等功能，大量降低程式開發人員的 coding 負擔。COM+ 使用 DCOM協定，所以不適合防火牆外的 client 存取。圖-3 是運用 COM+ 功能的簡易版設計模型，我們設計 ServicedComponent 將 Business Logic 的物件包裝起來，將之安裝至 COM+，並設定交易管理或 Object pooling 等等 runtime 屬性。Client 端必須具備 DCOM，可以是 Windows Client 或 IIS，在 Client 註冊 ServicedComponent 的 proxy 後就可以把當做 remote object 來使用了。

Web Service 最適合網際網路的分散式運算環境，它採用公開的標準，以 HTTP 為通訊協定，可以跨異質平台，穿越網路管制，加上提供公佈與查詢 Web Service 的 UDDI 機制，免除用戶端必須事先註冊 COM+/Remote Components 的困擾，雖然犠牲一點效能，但可以得到最大的彈性。圖-4 採用 Web Service 最簡易的設計模式，運用 Visual Studio.NET 可以很方便地建立 Web Service 專案，在 Web Service 的 ASP.NET 程式中撰寫 Business Logic 與存取資料庫的程式，並在 UDDI Server上註冊就可以提供服務了。

圖-4 的設計模型雖然簡易，但是沒有可再用的商業元件，所以較理想的方案是圖-5 的設計模型，以獨立的 Order Business Logic 元件當基礎，再由 ASP.NET 的 Web Service 程式當做 Client 的介面去呼叫商業元功能，並執行必要的資料轉換與安全控管，此種設計模型兼顧元件設計的優點及實作的簡易性。

如果企業建置大型的應用系統，需要較高的延展性，保持多樣化的系統整合彈性，並能同時滿足 Internet/Intranet 的存取方式，則應採用圖-6 的架構，以商業元件為基層，Intranet 的用戶端運用 Remoting 技術與 remote object 緊密結合以達到最高效能。運用 COM+ 功能以滿足高容量/高延展性的需求。建置 Service components 或 COM+ 的基層架構後，我們可以很方便地實作 ASP.NET Web Services，快速建立各種 Clients 所需要的整合運算、資料展現的功能。遵照此種設計架構亦可有效地套用 .NET 安全機制、或 Operation Management 管理方案的功能。即將推出的 Windows .NET Server 2003 內建最新版的 .NET Framework，包含建構圖-6設計模型所需的所有功能；Visual Studio .NET 2003則提供前後端程式的整合開發環境，大幅降低技術門檻，讓開發人員將重點放 Business Logic 與整合工作，快速建立企業級的應用系統。