Socket,webservices,remoting,WCF

Socket,webservices,remoting,WCF

Socket是老牌的传输，基于tcp/ip的传输，主要是Listen,Send,Receive

从webservices，,remoting开始，我们可以自定义方法来传输数据了，webservices可以生成代理类，而remoting则更方便，直接服务器和客户端可以用一个对象来解决，其实感觉就是动态生成的代理类（不过其核心，一个是远程对象副本，一个是远程对象）

WCF更是集这些通信的大成，自定义方法和代理类当然没有丢掉

核心是(下面转一段文章)

WCF服务需要依存一个运行着的进程（宿主），服务寄宿就是为服务指定一个宿主的过程。WCF是一个基于消息的通信框架，采用基于终结点（Endpoint）的通信手段。终结点由地址（Address）、绑定（Binding）和契约（Contract）三要素组成，如图3所示。由于三要素应为首字母分别为ABC，所以就有了易于记忆的公式：Endpoint = ABC。一个终结包含了实现通信所必需的所有信息，我们可以这样认识终结点的ABC：

• 地址（Address）：地址决定了服务的位置，解决了服务寻址的问题，《WCF技术剖析(卷1)》第2章提供了对地址和寻址机制的详细介绍；
• 绑定（Binding）：绑定实现了通信的所有细节，包括网络传输、消息编码，以及其他为实现某种功能（比如安全、可靠传输、事务等）对消息进行的相应处理。WCF中具有一系列的系统定义绑定，比如BasicHttpBinding、WsHttpBinding、NetTcpBinding等，《WCF技术剖析(卷1)》第3章提供对绑定的详细介绍；
• 契约（Contract）：契约是对服务操作的抽象，也是对消息交换模式以及消息结构的定义。《WCF技术剖析(卷1)》第4章提供对服务契约的详细介绍。

 ------------------------------------------------------------------------------------------------------------------------------

 WS VS WCF

1. webservice是一个标准。就相当于一个图纸，不提供实际的实现方案。
而wcf是微软.net平台下实现webservice的解决方案，其实就像java平台下webservice的实现方案是axis。
因此，一个是标准，一个是实现。也就不存在比较了。
2. webservice是数据通信协议的接口，比如客户端通过远程访问服务器端的数据或者其他可访问的任何站点的数据，WS都可以实现数据get和post数据，ws不受平台和语言的限制，
也就是跨平台/跨语言的一种通用的数据通信技术。
wcf是微软.net平台出来的技术，其实就是把webservices进行二次封装，也把原来的remoting技术整合进来，大家可以想象下我们把通用的东西进行二次封装，那么我们在特定的环境下是不是会更好用啊，
呵呵，理论上的确是这样，其实当我们这两种远程通信协议都会用的时候，我们会发现他们都差不多，用法的复杂程度也差不多，其实都很简单，我们在10分钟内就可以会用了，真正的数据通信实现和难点
人家技术本身都给实现了，我们只是知道如何用即可了，不必知道所以然。在后面的章节里我会把webservices和WCF的用法总结出来，请大家注意更新blogs。
3. 至于我们在一个项目里是选择webservices还是WCF，就好比到山顶有两条差不多的路，就看项目需要和个人爱好了。我个人觉得你的项目环境都是.NET平台下的 就用WCF好了，如果你的项目设计JAVA
平台的通信或者此项目就是写服务供给其他第三方使用的话，那么就要用webservices了，
4. 最后一句白话，webservices是通用的，WCF是专用的。条件允许的情况下用哪个都一样。


---------------------------------------------------------------------------------------------------------------------------------------

ASP.NET Web Services 和NET Remoting的对比

    现在我们已经理解了.NET remoting和Web Services的基本概念。现在让我们来看看这两种技术有什么具体的不同。为了这个目的，我将它们的不同分为性能、状态管理等方面进行阐述。

1.  性能

从性能方面，.NET remoting在使用TCP通道和二进制格式时拥有更快的通讯速度。而关于Web Services的主要焦点就集中在性能上。由于XML的冗长而使得用SOAP协议序列化出来的传输数据要比二进制数据流更慢。另外，处理字符串要比直接处理二进制更慢。然而，如果我们的Web service要进行的工作主要是计算操作，可以在服务端使用缓冲技术来增加web service的性能。
    如果我们使用一个SOAP格式的.NET remoting，我们会发现ASP.Net Web Service的性能会比使用SOAP协议的.NET remoting（可以使用http或tcp同道）更好。因此，.NET remoting技术只有在使用TCP通道和二进制格式时才比Web service的性能更高。

2. 状态管理

    Web services是一种无状态的编程模型，这就意味着需要单独处理每一个请求。另外，客户端每一次调用web services，服务端会为这个请求建立一个新的对象。这个对象在所有的方法调用完后销毁。为了在请求之间维护状态，我们可以使用和ASP.NET页同样的技术。如Session和Application对象，或是为我们的解决方案定制一个解决方案。但我们要清楚的是，在Web Service中维护状态的成本是非常高的。

    .NET remoting支持多种方式的状态管理。我们可以从中选择适当的解决方案。在前面提到过，SingleCall对象是无状态的，Singleton对象可以共享所有客户端的状态，并且客户对象在每一个客户端维护状态。如果我们不需要维护状态，可以使用singlecall对象，如果我们需要维护状态，可以一起使用singlecall和singleleton对象。

3.  安全

    .NET remoting并不支持跨平台的安全调用。但由于.NET remoting对象运行在IIS中，因此可以使用IIS的所有的安全特性。如果我们在其它的非IIS容器中使用TCP或HTTP通道，那么我们必须自已实现验证，授权等机制。

    web service和.NET remoting一样，也运行在IIS中，同样也可以使用IIS所提供的安全机制，如SSL、授权等。

4. 可靠性

    .NET remoting可以将任何程序作为远程对象，如Windows Form、服务程序、控制台或ASP.NET工作进程等。如果我们将Windows服务或控制台程序作为远程对象，那么我们需要确认所提供的服务特性是否符合远程对象的要求。然而如果我们在IIS中提供远程对象，那么我们可以利用ASP.NET工作进程的两个特性：自动开始和线程安全。对于ASP.NET Web service来说，可靠性并不是经常需要考虑的因素，因此它可以利用IIS在这方面的能力。

5. 可扩展性

    ASP.NET Web services和.NET remoting框架都是可扩展的。我们可以过滤内部和外部的信息，控制各种类型的组件和元数据的产生。.NET remoting可以扩展到下一层，以允许我们实现自己的格式化程序和通道。
     ASP.NET Web services依赖于System.Xml.Serialization.XmlSerializer类通过SOAP协议来发送和接收信息。我们可以非常容易地通过加入定制的属性来控制这一切。