Remoting、Web Services區別

其實現的原理並沒有本質的區別，在應用開發層面上有以下區別：
1、Remoting可以靈活的定義其所基於的協議，如果定義為HTTP，則與Web Service就沒有什麼區別了，一般都喜歡定義為TCP，這樣比Web Service稍為高效一些
2、Remoting不是標準，而Web Service是標準；
3、Remoting一般需要通過一個WinForm或是Windows服務進行啟動，而Web Service則需要IIS進行啟動。
4、在VS.net開發環境中，專門對Web Service的調用進行了封裝，用起來比Remoting方便

我建議還是採用Web Service好些，對於開發來說更容易控制
Remoting一般用在C/S的系統中，Web Service是用在B/S系統中
後者還是各語言的通用介面
相同之處就是都基於XML

為了能清楚地描述Web Service 和Remoting之間得區別,我打算從他們的體繫結構上來說起:
Web Service大體上分為5個層次:
1. Http傳輸通道
2. XML的資料格式
3. SOAP封裝格式
4. WSDL的描述方式
5. UDDI

總體上來講，.NET 下的 Web Service結構比較簡單，也比較容易理解和應用：
一般來講在.NET結構下的WebService應用都是基於.net framework以及IIS的架構之下，所以部署(Dispose)起來相對比較容易點.
從實現的角度來講，

首先WebService必須把暴露給用戶端的方法所在的類繼承於：System.Web.Services.WebService這個基類
其次所暴露的方法前面必須有[WebMethod]或者[WebMethodAttribute]

WebService的運行機理
首先用戶端從伺服器的到WebService的WSDL，同時在用戶端聲稱一個代理類(Proxy Class)
這個代理類負責與WebService伺服器進行Request 和Response
當一個資料（XML格式的）被封裝成SOAP格式的資料流發送到伺服器端的時候，就會產生一個進程對象並且把接收到這個Request的SOAP包進行解析，然後對事物進行處理，處理結束以後再對這個計算結果進行SOAP封裝，然後把這個包作為一個Response發送給用戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行後續操作。

這就是WebService的一個運行過程。

下面對.net Remoting進行概括的闡述：
.net Remoting 是在DCOM等基礎上發展起來的一種技術，它的主要目的是實現跨平台、跨語言、穿透企業防火牆，這也是他的基本特點，與WebService有所不同的是，它支援HTTP以及TCP通道，而且它不僅能傳輸XML格式的SOAP包，也可以傳輸傳統意義上的二進位流，這使得它變得效率更高也更加靈活。而且它不依賴於IIS，使用者可以自己開發(Development)並部署(Dispose)自己喜歡的宿主伺服器，所以從這些方面上來講WebService其實上是.net Remoting的一種特例。

================
一、Remoting的優缺點？
優點：
1、能讓我們進行分布式開發
2、Tcp通道的Remoting速度非常快
3、雖然是遠端，但是非常接近於本地調用對象
4、可以做到保持對象的狀態
5、沒有應用程式限制，可以是控制台，winform，iis，windows服務承載遠程對象
缺點：
1、非標準的應用因此有平台限制
2、脫離iis的話需要有自己的安全機制

二、Remoting和Web服務的區別？
    ASP.NET Web 服務基礎結構通過將 SOAP 訊息映射到方法調用，為 Web 服務提供了簡單的 API。通過提供一種非常簡單的編程模型（基於將 SOAP 訊息交換映射到方法調用），它實現了此機制。ASP.NET Web 服務的用戶端不需要瞭解用於建立它們的平台、物件模型或程式設計語言。而服務也不需要瞭解向它們發送訊息的用戶端。唯一的要求是：雙方都要認可正在建立和使用的 SOAP 訊息的格式，該格式是由使用 WSDL 和 XML 結構描述 (XSD) 表示的 Web 服務合約定義來定義的。 
    . NET Remoting 為分布式對象提供了一個基礎結構。它使用既靈活又可擴充的管線向遠程進程提供 .NET 的完全對象語義。ASP.NET Web 服務基於訊息傳遞提供非常簡單的編程模型，而 .NET Remoting 提供較為複雜的功能，包括支援通過值或引用傳遞對象、回調，以及多個物件啟用和生命週期管理原則等。要使用 .NET Remoting，用戶端需要瞭解所有這些詳細資料，簡而言之，需要使用 .NET 建立用戶端。.NET Remoting 管線還支援 SOAP 訊息，但必須注意這並沒有改變其對用戶端的要求。如果 Remoting 端點提供 .NET 專用的對象語義，不管是否通過 SOAP，用戶端必須理解它們。

三、最簡單的Remoting的例子
1、遠程對象：
建立類庫項目：RemoteObject

using System;

namespace RemoteObject
{
    public class MyObject:MarshalByRefObject
    {
        public int Add(int a,int b)
        {
            return a+b;
        }
    }
}

 

2、服務端
建立控制台項目：RemoteServer

 

using System;
using System.Runtime.Remoting;

namespace RemoteServer
{
    class MyServer
    {
        [STAThread]
        static void Main(string[] args)
        {
            RemotingConfiguration.Configure("RemoteServer.exe.config");
            Console.ReadLine();
        }
    }
}

建立設定檔：app.config

<configuration>
    <system.runtime.remoting>
        <application name="RemoteServer">
            <service>
                <wellknown type="RemoteObject.MyObject,RemoteObject" objectUri="RemoteObject.MyObject"
                    mode="Singleton" />
            </service>
            <channels>
                <channel ref="tcp" port="9999"/>
            </channels>
        </application>
    </system.runtime.remoting>
</configuration>

3、用戶端：
建立控制台項目：RemoteClient

using System;

namespace RemoteClient
{
    class MyClient
    {
        [STAThread]
        static void Main(string[] args)
        {
            RemoteObject.MyObject app = (RemoteObject.MyObject)Activator.GetObject(typeof(RemoteObject.MyObject),System.Configuration.ConfigurationSettings.AppSettings["ServiceURL"]);
            Console.WriteLine(app.Add(1,2));
            Console.ReadLine();
        }
    }
}

建立設定檔：app.config

<configuration>
 <appSettings>
 <add key="ServiceURL" value="tcp://localhost:9999/RemoteObject.MyObject"/>
 </appSettings>
</configuration>

4、測試
在最後編譯的時候會發現編譯報錯：
1、找不到app.Add()
2、找不到RemoteObject
這是因為用戶端RemoteClient沒有添加RemoteObject的引用，編譯器並不知道遠程對象存在哪些成員所以報錯，添加引用以後vs.net會在用戶端也儲存一個dll，可能大家會問這樣如果對遠程對象的修改是不是會很麻煩？其實不麻煩，對項目編譯一次vs.net會重新複製dll。
然後直接運行用戶端會出現“目標主機拒絕”的異常，也說明了通道沒有開啟
運行服務端再運行用戶端出現“找不到程式集RemoteObject”！回頭想想可以發現我們並在服務端對RemoteObject添加引用，編譯的時候通過是因為這個時候並沒有用到遠程對象，大家可能不理解運行服務端的時候也通過？這是因為沒有這個時候還沒有啟用遠程對象。理所當然，對服務端要添加引用遠程對象，畢竟我們的對象是要靠遠程承載的。
現在再先後運行服務端程式和用戶端程式，用戶端程式顯示3，測試成功。

四、結束語
我們通過一個簡單的例子實現了最簡單的remoting，對其實質沒有做任何介紹，我想通過例子入門才是最簡單的。

==============
MSMQ,Enterprise Service, DotNet Remoting,Web Service 的優缺點

對於送耦合的引用，有一下四種選項。

1.MSMQ

從windows nt 開始微軟就開始提供msmq 的支援，一直到現在的3.0，主要提供一下幾個特性的支援。
可靠的訊息傳遞，類似mail 系統，有離線支援
可設定訊息的優先順序，Label的各種額外的標示
事務支援
通過DC,IC的靈活應用，有好的縮放性

對於用戶端，要求必須是windows 系統，從windowsce 到windows .net 2003 都作支援。可以通過連接器跟其他的非微軟技術整合.NET 有一個專門的封裝 System.Messaing Namespace.

2.Enterprise Service

.NET 中其實通過託管的Enterprise Service 跟 COM+ 應用架構互動。

從windows 2000 開始有這個組件，目前到windows 2003 版本是1.1

我認為有幾個特性值得一用
對象池，對於物件建構特別慢，而又沒有狀態的應用特別適合。很類似我們 ADO.NET 中的串連吃。可以跟JIT去結合。
分散式交易協調，加上事務補償。這是一大優點
另外一點就是送耦合事件，這一點對於plug and play 的訂閱式應用很有協助。

當然直接的用戶端也必須是 windows 2000 以及以上的OS

3.DotNet Remoting
這個我用的最多，感覺也最深；）

dotnet remoing 的中文翻譯時遠端，其實是一種.NET 平台下面很好的一種遠端調用，提供了開發的架構。靈活的通訊傳輸協議，當然也可以自己去擴充。遠程對象的調用提供了多種方式，可以使有狀態的，也可以使無狀態。對於開發人員，感覺根本地調用一樣方便。這一點主要卻別於Web Service。

其實這種應用類似一個相對耦合的應用。用戶端和服務端豐富的通訊模型是基於.NET 平台。也就是說如果用戶端不一定是.NET 平台的話，remoting 就顯得不是很適合。一個簡單的例子就是對象的傳遞

從remoting 服務端傳遞一個對象給用戶端，可以是對象的遠端一個遠端參照，也可以使一個對象的copy，就是我們通常說的mbr 或者mbv

當然，web 服務是無法實現對象的引用傳遞，web 服務只能是一個mbv，而web 服務這裡的mbv 作的就不夠徹底了。我在http://dotnet.mblogger.cn/montaque/posts/2094.aspx 提到他們走的不同的序列化方式。對於web 服務，只是一個很淺的copy。也就是說對象在傳遞到服務端的時候，並沒有把 100% 的狀態傳遞過去。

而remoting 傳遞的對象就比較地道。或許這就是一個.NET Remoting 相對於web 服務比較更貼近本地調用的一個體現

缺點前面提到了，就是豐富的特性是基於。NET 這個平台。.NET 中通過 System.Runtime.Remoting.Dll

4. web 服務。
這是個標準的東西，我的意見是標準的東西不見的都是最好的。在保證標準的同時，丟失了很多特性。