WCF、Net remoting、Web service概念及区别

http://hi.baidu.com/%BE%B2%CA%D8%BB%D8%D2%E4/blog/item/c00cc117ecb890def6039ef7.html

 

Windows通信基础（Windows Communication Foundation，WCF）是基于Windows平台下开发和部署服务的软件开发包（Software Development Kit，SDK）。

　　WCF就是微软对于分布式处理的 编程技术的集大成者，它将DCOM、Remoting、Web Service、WSE、MSMQ集成在一起，从而降低了分布式系统开发者的学习曲线，并统一了开发标准。

　　WCF是建立在.Net Framework 2.0基础之上的，包含在.NET
3.0/3.5当中。2005中并没有包含WCF，但是当安装好了WinFX Runtime Components后，我们就可以在Visual
Studio 2005环境下开发和创建WCF的程序了。

　　尊重资料来源。以下来自网页http://www.cppblog.com/mzty/archive/2007/10/24/35068.html

　　一 WCF

　　概括地说，WCF具有如下的优势：

　　1、统一性

　　前面已经叙述，WCF是对于ASMX，.Net Remoting，Enterprise
Service，WSE，MSMQ等技术的整合。由于WCF完全是由托管代码编写，因此开发WCF的应用程序与开发其它的.Net应用程序没有太大的区
别，我们仍然可以像创建面向对象的应用程序那样，利用WCF来创建面向服务的应用程序。

　　2、互操作性

　　由于WCF最基本的通信机制是SOAP，这就保证了系统之间的互操作性，即使是运行不同的上下文中。这种通信可以是基于.Net到.Net间的通信。

　　可以跨进程、跨机器甚至于跨平台的通信，只要支持标准的Web
Service，例如J2EE应用服务器（如WebSphere，WebLogic）。应用程序可以运行在Windows操作系统下，也可以运行在其他的
操作系统，如Sun Solaris，HP Unix，Linux等等。

　　3、安全与可信赖

　　WS-Security，WS-Trust和WS-SecureConversation均被添加到SOAP消息中，以用于用户认证，数据完整性验证，数据隐私等多种安全因素。

　　在SOAP的header中增加了WS-ReliableMessaging允许可信赖的端对端通信。而建立在WS-Coordination
和WS-AtomicTransaction之上的基于SOAP格式交换的信息，则支持两阶段的事务提交（two-phase commit
transactions）。

　　上述的多种WS-Policy在WCF中都给与了支持。对于Messaging而言，SOAP是Web
Service的基本协议，它包含了消息头（header）和消息体(body)。在消息头中，定义了WS-Addressing用于定位SOAP消息的
地址信息，同时还包含了MTOM（消息传输优化机制，Message Transmission Optimization Mechanism）。

　　4、兼容性

　　WCF充分的考虑到了与旧有系统的兼容性。安装WCF并不会影响原有的技术如ASMX和.Net Remoting。即使对于WCF和ASMX而言，虽然两者都使用了SOAP，但基于WCF开发的应用程序，仍然可以直接与ASMX进行交互。

　　二 WebService的运行机理

　　首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class)，
这个代理类负责与WebService服务器进行Request 和Response，
当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解
析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy
Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作。

　　三 .net Remoting

　　是在DCOM等基础上发展起来的一种技术，它的主要目的是实现跨平台、跨语言、穿透企业防火墙，这也是他的基本特点，与WebService有
所不同的是，它支持HTTP以及TCP信道，而且它不仅能传输XML格式的SOAP包，也可以传输传统意义上的二进制流，这使得它变得效率更高也更加灵
活。而且它不依赖于IIS，用户可以自己开发(Development)并部署(Dispose)自己喜欢的宿主服务器，所以从这些方面上来讲
WebService其实上是.netemoting的一种特例。

　　区别：

　　1、Remoting可以灵活的定义其所基于的协议，比如http，tcp等，如果定义为HTTP，则与Web
Service相同，但是webservice是无状态的，使用remoting一般都喜欢定义为TCP，这样比Web
Service稍为高效一些，而且是有状态的。

　　2、Remoting不是标准，而Web Service是标准。

　　3、Remoting一般需要通过一个WinForm或是Windows服务进行启动，也可以使用iis部署，而Web Service则必须在IIS进行启动。

　　4、在VS.net开发环境中，专门对Web Service的调用进行了封装，用起来比Remoting方便。

　　5 net remoting只能应用于MS 的.net framework之下，需要客户端必须安装framework，但是WebService是平台独立的，跨语言（只要能支持XML的语言都可以） 以及穿透企业防火墙。

　　分布式应用程序设计：ASP.NET Web 服务和 .NET Remoting

　　ASP.NET Web 服务偏向于 XML Schema 类型系统，提供具有广泛使用范围的跨平台支持的简单编程模型。.NET
Remoting
偏向于运行时类型系统，提供较为复杂而且使用范围小得多的编程模型。这种本质上的差别是决定使用哪种技术的主要因素。但是，还要考虑很多其他设计因素，包
括传输协议、主机进程、安全性、性能、状态管理以及对事务的支持等。

　　传输协议和主机进程

　　尽管 SOAP 规范并不要求用 HTTP 作为传输协议，但是客户端只能通过 HTTP 访问使用 ASP.NET Web 服务实现的
Web 服务，因为它是 ASP.NET 支持的唯一一种传输协议。服务是通过 IIS 调用的，并在 ASP.NET 的辅助进程
aspnet_wp.exe 中执行。

　　.NET Remoting 使您能够在任何类型的应用程序（包括 Windows 窗体、托管的 Windows 服务、控制台应用程序或
ASP.NET 辅助进程）中灵活地托管远程对象。正如前面所述，.NET Remoting 提供两个传输信道——TCP 和
HTTP。这两个信道都能使用套接字提供任意发送和接收进程之间的通信。

　　它还能将 HTTP 信道与 IIS 和 ASP.NET
辅助进程集成。这一点很重要，原因有以下几点。首先，它是当客户端请求到达时自动启动 .NET Remoting 端点的唯一方法。.NET
Remoting 管线不包括启动远程服务器所需的 DCOM 类型的服务控制管理器
(SCM)。如果从任意进程中提供远程对象，则需要确保那些进程正在运行。还必须确保它们是线程安全的，例如，线程 A 不能在线程 B
开始关闭进程之后激活对象。如果从 ASP.NET 提供远程对象，则可以利用 Aspnet_wp.exe
辅助进程，这样既可自动启动又具有线程安全的优势。第二，与 IIS 集成是确保跨进程 .NET Remoting 调用的唯一途径，如下一节所述。

　　ASP.NET Web 服务和 .NET Remoting 基础结构都是可扩展的。您可以过滤入站和出站消息，从多方面控制类型封送和元数据的生成。使用 .NET Remoting，还能实现您自己的格式化程序和信道。

　　安全性

　　由于 ASP.NET Web 服务依赖于 HTTP，因此它们与标准的 Internet 安全性基础结构相集成。ASP.NET 利用
IIS 的安全性功能，为标准 HTTP 验证方案（包括基本、简要、数字证书，甚至 Microsoft? .NET
Passport）提供了强有力的支持。（还可以使用 Windows 集成验证，但只能用于信任域中的客户端。）使用可用的 HTTP
验证方案的一个优势在于，无需在 Web 服务中更改代码，IIS 是在 ASP.NET Web 服务被调用之前执行验证的。ASP.NET
还支持基于 .NET Passport 的验证和其他自定义的验证方案。ASP.NET 支持基于目标 URL 的访问控制，并通过与 .NET
代码访问安全性 (CAS) 基础结构的集成支持访问控制。SSL 可用于确保通信的安全。

　　尽管这些标准传输技术对于确保 Web 服务相当有效，但它们只能做到这种程度。在涉及到不同信任域中多个 Web
服务的复杂情况下，还得建立自定义的特殊解决方案。Microsoft 和其他公司正致力于创建一套安全性规范，该规范将基于 SOAP
消息的可扩展性提供消息级别的安全性功能。这些规范之一是 XML Web
服务安全性语言（WS-Security），它为消息级别的凭据传输、消息完整性和消息保密定义了框架。

　　正如上一节所述，一般情况下，.NET Remoting 管线不能确保跨进程调用的安全。使用 ASP.NET 托管于 IIS 中的
.NET Remoting 端点可以利用 ASP.NET Web 服务可用的所有安全性功能，包括对使用 SSL
确保有线通信的安全性的支持。如果您正在使用托管在进程中的 TCP 信道或 HTTP 信道（而不是
aspnet_wp.exe），则必须自己执行身份验证、授权和保密机制。

　　另一个要关注的安全性问题是，在不必更改默认安全性策略的情况下，从不完全信任的环境中执行代码的能力。ASP.NET Web
服务客户端代理可以在这些环境中工作，但 .NET Remoting 代理则不能。要从不完全信任的环境中使用 .NET Remoting
代理，需要特殊的序列化权限。默认情况下，该权限不会授予从 Intranet 或 Internet 上下载的代码。如果要在不完全信任的环境中使用
.NET Remoting 客户端，则需要更改从那些区域中加载的代码的默认安全性策略。当您从运行于沙箱（如下载的 Windows
窗体应用程序）中的客户端连接到系统时，ASP.NET Web 服务是较简单的选择，因为不需要更改安全性策略。

　　状态管理

　　默认情况下，ASP.NET Web 服务模型采用无状态的服务结构；它并不是本能地与来自同一个用户的多个调用相关。另外，客户端每次调用
ASP.NET Web 服务时，都创建一个新的对象以服务于该请求。方法调用完成后，该对象即被破坏。要维护请求之间的状态，可以使用 ASP.NET
页面使用的相同技术（例如，Session 和 Application 属性包），也可以自己实现自定义的解决方案。

　　.NET Remoting
支持许多状态管理选项，并且可能与来自同一个用户的多个调用相关或不相关，这取决于您选择的对象生命周期架构。SingleCall
对象是无状态的（如用于调用 ASP.NET Web 服务的对象），Singleton
对象共享所有客户端的状态，客户端激活的对象在每个客户端的基础上保持状态（带有其产生的所有相关的可升级性和可靠性问题）。

　　性能

　　从原始性能方面来讲，使用 TCP 信道和二进制格式化程序时，.NET Remoting 管线能够提供最快的通信。在我们进行的比较
ASP.NET Web 服务和 .NET Remoting 的相对性能的几乎所有的测试中，ASP.NET Web 服务在性能上都超出了使用
HTTP 或 TCP 信道的 SOAP 格式化程序的 .NET Remoting 端点。更有意思的是，使用二进制格式化程序和 HTTP 信道的
ASP.NET 和 .NET Remoting 端点在性能上非常相近。（更多信息，请参见 Performance Comparison:NET
Remoting vs. ASP.NET Web Services。）

　　企业服务

　　ASP.NET Web 服务或通过 .NET Remoting
提供的对象可以使用本地事务根据单个数据库协调工作。如果需要根据多个资源协调工作，可以使用 .NET 企业服务（又称 COM+）公布的事务（由
COM+ 管线管理的 DTC 分布式事务）。但要注意的是，ASP.NET Web 服务和 .NET Remoting
管线都不能传播公布的事务，因此两种端点都不可能通过跨进程的调用继承公布的事务。

　　这不一定是件坏事。一般来讲，公布的事务比本地事务代价要高，而要跨进程传播公布的事务，则代价会更高。如果确实需要这一功能，简单的解决方案
是在 .NET 企业服务的服务器应用程序中部署一个从 System.EnterpriseServices.ServicedComponent
派生的类（更多信息，请参见 COM+ Integration:How .NET Enterprise Services Can Help You
Build Distributed Applications）。对该类对象的跨进程调用将使用 DCOM
进行处理，以确保正确传播事务环境。较难的解决方案是使用底层的 API，手动传播分布的事务。

　　值得注意的是，传统的分布式事务模型一般不适用于松散耦合的 Web
服务。基于补偿事务的模型（即，撤消其他事务所提交工作的事务）更有意义，因为其隔离约束条件并不是很严格。在包括 Microsoft 的 Web
服务供应商中有一种普遍的说法，即 Web 服务空间需要的事务模型越灵活，该空间中进行的工作越多。等到定义出 Web
服务事务的标准方法时，您就可以根据情况使用本地或公布的事务实现自己的补偿架构了。

　　小结

　　虽然 .NET Remoting 基础结构和 ASP.NET Web
服务都可以进行跨进程通信，但每种设计适用于不同的用户。ASP.NET Web 服务提供了简单的编程模型，并具有广泛的使用范围。.NET
Remoting
提供了较为复杂的编程模型，而且使用范围窄得多。请务必了解这两种技术的工作原理，并选择适合您应用程序的技术。在任意一种情况下，都要使用 IIS 和
ASP.NET 管理进程生命周期，并提供一般的安全性。

　　我采用Remoting技术也是项目的需要：

　　1、Remoteing主要用于C/S结构项目。

　　2、将Remoting采用TCP通讯，比Web Service不是稍微高效一些，而是高几倍，甚至几十倍，不愧为是在DCOM等基础上发展起来的技术。对于跨地区，乃至跨省（广域网）的分布式应用，效率的高低意味着软件系统的生死存亡。

　　我在博客上说的这个三层结构，本意也只是在.net环境下，利用反射技术、对象关系映射等技术，写一个底层点的程序集，方便编写数据库访问程
序。该程序集要能封装常用的数据库操作。这个程序集不管是在Remoting、Web
Service还是WCF，应该都能用的。就象我们在大学课本里学数据结构，学的是一种思想。如果只是单纯局限一种技术，在日新月异的发展中，终将淘汰。
我们都是凡人，不可能掌握所有技术。适合自己项目需要的，就是最好的！

 

微软论坛的斑竹回答如下：

    1.WebService：严格来说是行业标准，不是技术，使用XML扩展标记语言来表示数据（这个是夸语言和平台的关键）。微

软的Web服务实现称为ASP.NET Web Service.它使用Soap简单对象访问协议来实现分布式环境里应用程序之间的数据交互。

WSDL来实现服务接口相关的描述。此外Web services 可以注册到UDDI中心.供其客户查找使用。

    后来微软做了ASP.NET Web Service的安全，性能，数据加密、解密，托管宿主等多方面的扩展，称为WSE系列，这个是过

度产品，最高到WSE3.0.后来就是WCF时代。

    2.WCF：其实一定程度上就是ASP.NET Web Service,因为它支持Web Service的行业标准和核心协议，因此ASP.NET Web Service

和WSE能做的事情，它几乎都能胜任，跨平台和语言更不是问题（数据也支持XML格式化，而且提供了自己的格式化器）。

    但是WCF作为微软主推一个通讯组件或者平台，它的目标不仅仅是在支持和集成Web Service,因为它还兼容和具备了微软

早期很多技术的特性。

    根据微软官方的解释，WCF（之前的版本名为“Indigo”）是使用托管代码建立和运行面向服务（Service Oriented）应用程

序的统一框架。它使得开发者能够建立一个跨平台的安全、可信赖、事务性的解决方案，且能与已有系统兼容协作。WCF

是微软分布式应用程序开发的集大成者，它整合了.Net平台下所有的和分布式系统有关的技术，如Enterprise Sevices

(COM+).Net Remoting、Web Service(ASMX)、WSE3.0和MSMQ消息队列。以通信(Communiation)范围而论，它可以跨进程、跨机器

、跨子网、企业网乃至于 Internet；以宿主程序而论，可以以ASP.NET，EXE，WPF，Windows Forms，NT Service，COM+作为宿

主(Host)。WCF可以支持的协议包括TCP，HTTP，跨进程以及自定义，安全模式则包括SAML， Kerberos，X509，用户/密码，

自定义等多种标准与模式。也就是说，在WCF框架下，开发基于SOA的分布式系统变得容易了，微软将所有与此相关的技术

要素都包含在内，掌握了WCF，就相当于掌握了叩开SOA大门的钥匙。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/avi9111/archive/2010/06/08/5655563.aspx

=========================================================================

web service 要求是以 http 为传输协议,以 soap 为应用协议的 API 接口.

WCF 作为一种开发 Web Service 的框架(当然,并不仅仅用于开发Web
Service应用),默认采用Soap应用协议,通过配置basicHttpBinding,wsHttpBinding(支持WS.*)以提供对无安
全和有安全保证的Web Servcie调用的支持.

为了与非 Wcf 平台开发的服务端或客户端程序交互,必须注意以下几点:

1,了解序列化后的 soap 消息格式,可以使用 Fillder 抓取 http 包,以查看 soap 消息内容,这在调试阶段非常利于你通过定制序列化行为以满足非 Wcf 平台开发的服务端或客户端程序所要求的 xml 结构;

2,当要确保通讯安全时,始终使用传输层安全而非消息安全,传输安全将非常容易实现,而消息安全则非常复杂,wsHttpBinding的消息安全并不能保证和所有平台正常交互.

3,了解你的服务宿主平台(IIS,Tomcat之类),诸如 expect100Continue 等与平台相关的 http
标头设置,将使你调用他人服务或提供服务给他人调用时产生"意想不到"的错误;这里错误无法从异常中获取到正确的提示,你必须分析正确的 http
数据包和错误的 http
数据包之间的差别以发现这些不同之处.所有,我额外的推荐你一个sopa工具:soapui,这个工具在生成客户端代理方面,有着比
wcftestclient 更好的兼容性.

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

概述　　Windows Communication Foundation
(WCF)
是由微软发展的一组数据通信的应用程序开发接口，它是.NET框架

的
一部分，由 .NET Framework 3.0 开始引入，与 Windows Presentation Foundation 及
Windows Workflow Foundation 并行为新一代 Windows 操作系统以及 WinFX 的三个重大应用程序开发类库。在
.NET Framework 2.0 以及前版本中，微软发展了 Web Service (SOAP with HTTP
communication)，.NET Remoting (TCP/HTTP/Pipeline communication) 以及基础的
Winsock 等通信支持，由于各个通信方法的设计方法不同，而且彼此之间也有相互的重叠性（例如 .NET Remoting 可以开发 SOAP,
HTTP 通信），对于开发人员来说，不同的选择会有不同的程序设计模型，而且必须要重新学习，让开发人员在用户有许多不便。同时，服务导向架构
(Service-Oriented Architecture)
也开始盛行于软件工业中，因此微软重新查看了这些通信方法，并设计了一个统一的程序开发模型，对于数据通信提供了最基本最有弹性的支持，这就是
Windows Communication Foundation。

概念

　　WCF 由于集合了几乎由 .NET Framework 所提供的通信方法，因此学习曲线比较陡峭，开发人员必须要针对各个部份的内涵做深入的了解，才能够操控 WCF 来开发应用程序。

　　通信双方的沟通方式，由合约来订定。通信双方所遵循的通信方法，由协议绑定来订定。通信期间的安全性，由双方约定的安全性层次来订定。

合约（Contract）

　　WCF 的基本概念是以合约

(Contract) 来定义双方沟通的协议，合约必须要以接口

的方式来体现，而实际的服务代码必须要由这些合约接口派生并实现。合约分成了四种：

　　数据合约 (Data Contract)，订定双方沟通时的数据格式。服务合约 (Service
Contract)，订定服务的定义。营运合约 (Operation Contract)，订定服务提供的方法。消息合约 (Message
Contract)，订定在通信期间改写消息内容的规范。一个 WCF 中的合约，就如同下列代码所示：

　　using System;using System.ServiceModel;namespace
Microsoft.ServiceModel.Samples{ [ServiceContract(Namespace =
"http://Microsoft.ServiceModel.Samples")] // 服务合约 public interface
ICalculator { [OperationContract] // 营运合约 double Add(double n1, double
n2); [OperationContract] // 营运合约 double Subtract(double n1, double n2);
[OperationContract] // 营运合约 double Multiply(double n1, double n2);
[OperationContract] // 营运合约 double Divide(double n1, double n2); }}

协议绑定 (Binding)

　　由于 WCF 支持了 HTTP

，TCP

，Named Pipe，MSMQ

，Peer-To-Peer
TCP 等协议，而 HTTP 又分为基本 HTTP 支持 (BasicHttpBinding) 以及 WS-HTTP 支持
(WsHttpBinding)，而 TCP 亦支持 NetTcpBinding，NetPeerTcpBinding
等通信方式，因此，双方必须要统一通信的协议，并且也要在编码以及格式上要有所一致。

　　一个设置通信协议绑定的示例如下：

　　<?xml version="1.0" encoding="utf-8" ?><configuration>
<system.serviceModel> <!-- 设定服务系结的资讯 --> <services>
<service name=" CalculatorService" > <endpoint address=""
binding="wsHttpBinding" bindingConfiguration="Binding1"
contract="ICalculator" /> </service> </services> <!--
设定通讯协定系结的资讯 --> <bindings> <wsHttpBinding> <binding
name="Binding1"> </binding> </wsHttpBinding>
</bindings> </system.serviceModel></configuration>

　　虽然 WCF 也可以使用 SOAP

做通信格式，但它和以往的 ASP.NET

XML Web Services

不同，因此有部分技术文章中，会将 ASP.NET 的 XML Web Services 称为 ASMX Service
。

　　WCF 的服务可以挂载于 Console Application，Windows Application，IIS (ASP.NET)
Application，Windows Service 以及 Windows Activation Services 中，但大多都会挂在
Windows Service。

安全性层次

　　WCF 实现上已经支持了传输层次安全性 (Transport-level security) 以及消息层次安全性 (Message-level security) 两种。

　　传输层次安全性：在数据传输时期加密，例如 SSL。消息层次安全性：在数据处理时就加密，例如使用数字签章，散列 或是使用金钥加密法等。

客户端

　　对于 WCF 的客户端来说，WCF 服务就像是一个 Web Service 一样，在 Visual Studio 2008 中，所有 WCF 服务的连接都是由客户端的 WCF Service Proxy
来运行，开发人员不用花费太多心思在通信上，而 WCF Service Proxy 在 Visual Studio 中被称为服务参考
(Service Reference)。

　　在 Visual Studio 中加入 WCF 的服务参考时，Visual Studio
会自动帮开发人员做掉一些必要工作（例如组态创建以及产生 Service Proxy 等），开发人员只需要在代码中取用 WCF Service
Proxy 对象即可。