選擇正確的.net技術[翻譯]

原文出自：
《Microsoft .NET Distributed Applications: Integrating XML Web Services and .NET Remoting》
Part II Chapter 10 Choosing the Right .NET Technology

    在這本書中，我一直強調一個原則，那就是每一個.NET技術都有一個理想的應用環境。為了構建一個成功的分布式應用程式，你不但要理解如何使用這些技術，而且要知道何時使用這些技術。

內部和外部系統
    內部系統是一個相對私人的軟體，它管理著每日任務的某些部分，這些任務是商業運營中所必需完成的。它可以包括Bug跟蹤功能、開發部門使用的專案管理軟體，或者是客戶銷售跟蹤和投資管理應用程式。在其中任何一個案例中，我們有兩個選擇：
    基於.NET Remoting技術的解決方案可以提供最快的通訊速度。當然，內部系統通常並不會停留在這種方式上。如果該系統是成功的，你通常需要一種橋，用以向其他系統提供功能（介面）。由於這個原因，如果你需要開放一些功能給第三方軟體，基於XML Web服務的解決方案提供一種簡單的整合途徑。XML Web服務還提供一些ASP.NET服務，例如緩衝一個驗證，這樣可以提高運行效率或者簡化編碼。無論基於兩種技術中的哪一種，用戶端通常使用 Windows Form建立，它提供了一個十分靈活的使用者介面，允許你建立不同的應用類型，例如一個長期啟動並執行系統托盤程式。

    提供給外部系統（例如電子商務商店）的功能可以依賴於ASP.NET或XML Web Service作為支撐。最關鍵的考慮是你是否需要使用離線架構，這種架構通過訊息佇列或者相似技術來實現客戶請求的分配。如果你期望在高峰時間，有一個相對集中的大輸送量，並且客戶不需要即時的回應的話，這種離線架構使伺服器的處理能力達到最大。

混合的內部/外部系統
    一些系統把XML Web服務和.NET Remoting結合起來，它們把.NET Remoting用於內部客戶，而把XML Web服務作為與第三方軟體或平台通訊的介面。這個方式是否成功，取決於能否保證XML Web服務和遠程組件使用相同的服務提供者(Service Provider)組件來完成一個類似於體重物的過程，例如訪問資料庫。儘管XML Web服務和遠程組件相互獨立運行，它們仍然共用相同版本的服務提供者組件，10-6所示。

                                         圖10-6

註：技術上講，建立一個具有XML Web服務和遠程對象共同性質的組建對象是可能的。你只要從MarshalByRefObject 派生一個類，從而允許提供.NET Remoting支援，並且添加<WebMethod>特性，建立一個.asmx檔案來暴露Web方法。然而，這種方法是絕對不建議使用的。你仍然應該把組件獨立開來。XML Web服務和.Net Remoting在處理問題上的微小差異，例如序列化，會為未來的開發增加麻煩。因此，我們應該把共用的功能放入獨立的組件中。

通用的後端(The Common Back-End)
    混合系統的弱點在於，對於大資料量載入效率很低。例如，XML Web服務和Remoting對象之間串連無法被池化；另外，由於我們處理的是兩個重複的對象實現，Server Load Balancer會變得十分複雜。
    解決這個問題的一個方案是通過.NET Remoting 建立一個通用的後端處理組件，10-7所示。這個附加的層將導致附加的跨進程通訊，因此它會降低一小部分效能。然而，從長遠來看這種結構更具有延展性。

                                        圖10-7

部分離線系統(Partially Disconnected System)
    部分離線系統包含一些無法保持長期串連的用戶端，因此無法總是與伺服器端組件互動。例如，你可以建立一個用於記錄經常出差的員工的開銷的程式，當電腦重新串連到網路時，這些費用報表會被輸入中央資料庫。另一個離線系統的例子是一種分配給第三方的工具。比如說，你可以能會為一些已授權的商人提供銷售訂單工具。然而，你不能夠假設這些商人在使用程式時能夠一直串連在Internet上，你也不能假設他們能夠串連到他們的內部網上。
    在離線系統中，有不止一種方法可以用於通訊。一種方法是使用訊息佇列（10-8所示），在這個例子中，當串連恢複時，系統會自動發送訊息，這種方法是有用的，它允許你使用與即時串連系統(Connected System)的用戶端相同的設計來完成離線系統的用戶端。無論在即時串連系統還是在離線系統中，一旦操作完成訊息就會發出，唯一的差別在於Windows分發訊息的方式。
    圖10-8

在其他一些案例中，你可能會因為特殊的需求需要開發一個定製的解決方案。你可以建立一個應用程式，該程式不斷查詢串連是否可用或者等待使用者手動告訴程式是否有一個串連可用。這種方法同email程式的工作方式一樣。如果你在離線狀態下發送一個email資訊，然後退出程式，重新串連，在你重新載入程式之前資訊是不會被發出的。
    一個最終的方法是建立一個專門的Windows服務，負責發送資訊到中央服務的任務。這個服務將一直在電腦上允許，檢查串連是否可用，如果可用，它會把儲存在用戶端的資訊發送出去。這個方法概念上與訊息佇列類似。然而，你無法保證所有的用戶端上安裝了訊息佇列軟體，並且被正確配置，這是非常常見的。

從COM升級
    在當今世界，分布式系統通常都需要從一個已存在的COM架構演化而來，.NET使這個工作變得相對簡單。從COM到.NET的遷移是主要的工作，但是必須遵循一條準則，那就是採用分階段的方式以保證系統能夠正常工作。對於大多數機構來說，這意味著在一個COM和.NET組件混合的系統上花費大量的時間。
    當你升級一個傳統的多層應用程式時，最好是從追蹤記錄用戶端應用程式開始，因為用.NET用戶端與一個COM組件通訊要比用一個基於COM的用戶端與. NET組件通訊簡單得多。整合的第一階段應該是使用ASP.NET或Windows Form重寫展示層，10-9，你可以用.NET內建的COM互動支援來訪問中介層的COM對象。
    圖10-9
   
    由於用戶端直接與COM層通訊，升級業務組件變得十分困難。另外，如果組件位於另外一台電腦上，你必須使用分布式COM(DCOM)來作遠程通訊。下一個階段則要把COM互動層放到伺服器上，10-10所示。你可以通過使用XML服務或通過.NET Remoting開放出來的組件建立另一個.NET層，用戶端直接和該層的.NET元件連線，該組件負責獲得請求並從下層的COM組件中獲得結果。
    圖10-10
   
    最後一個階段是使用.NET組件重建業務層，10-11所示。在最好的情況下，你應該可以一個一個部署你的這些組件，在用戶端的代碼不需要任何改動的情況下，你只需要更新.NET的XML Web服務層或者遠程組件。
圖10-11