1.传统的应用程序相比web Service的优势?
优点一：跨防火墙的通信
如果应用程序有成千上万的用户，而且分布在世界 各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简 单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴 露给最终用户。这样做的结果是开发难度大，程序很难维护。
举个例子， 在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用 来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户 端的编程就简单多了。
如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的 那一步。要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的 SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次 调用中间层组件时，都跳转到相应的“结果页”。
从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用 WebService这种结构，可以节省花在用户界面编程上20%的开发时间。另外，这样一个由WebService组成的中间层，完全可以在应用程序集 成或其它场合下重用。最后，通过WebService把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。
优点二：应用程序集成
企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经 常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要 集成起来。通过WebService，应用程序可以用标准的方法把功能和数据“暴露”出来，供其它应用程序使用。
例如，有一个订单登 录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来 自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService，订单执行程序可 以把“AddOrder”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。
优点三：B2B的集成
用WebService集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。
WebService是B2B集成成功的关键。通过WebService，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系 统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI(电子 文档交换)早就是这样了。但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可 轻易实现，其运行成本就相对较低。不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。WebService只是B2B 集成的一个关键部分，还需要许多其它的部分才能实现集成。
用WebService来实现B2B集成的最大好处在于可以轻易实现互操作 性。只要把商务逻辑“暴露”出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么 开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。
优点四：软件和数据重用
软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。
当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。
WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组 件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接 发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区 域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包 含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。
另一种软件重用的情况是，把好几个应用程序的 功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影 票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所 有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。
将来，许多应用程序都会利用WebService，把当前基 于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程 序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。
从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，WebService根本不能带来任何好处。
2.WCF，Net remoting，Web service概念
一 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 管理进程生命周期，并提供一般的安全性。
3.使用C#创建webservice及三种调用方式
微软.NET战略的一个比较重要的部分就是webservice,利用webservice我们可以创建真正有效的分布式应用程序。
下面，我们对webservice做一些说明。
假设A是客户端，B是webservice服务端，用户通过http协议向服务器发送soap请求，webservice返回客户端XML格式的数据。
现在我们看一看创建一个webservice的大致过程：
服务端的webservice是必须要建的。中间的soap,xml我们不用去关心，在客户端这边，比较重要的是如何从webservice取得对象？答案是用的是proxy对象。客户端由代理对象(proxy)负责与webservice的通信。所以在客户端使用webservice，完全和使用一个本地对象是一样的。
我们现在以一个简单的实例来说明。
打开vs.net,新建工程(asp.net web服务)，在位置中键入http://localhost/webserver,其中webserver就是工程的名字。确定后，出现一个Service1.asmx.cx,双击，出现代码窗口，
using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;
namespace webserver
{
/// <summary>
/// Service1 的摘要说明。
/// </summary>
(1)
public class Service1 : System.Web.Services.WebService
{
public Service1()
{
//CODEGEN：该调用是 ASP.NET Web 服务设计器所必需的
InitializeComponent();
}
#region Component Designer generated code
//Web 服务设计器所必需的
private IContainer components = null;
/// <summary>
/// 设计器支持所需的方法 - 不要使用代码编辑器修改
/// 此方法的内容。
/// </summary>
private void InitializeComponent()
{
}
/// <summary>
/// 清理所有正在使用的资源。
/// </summary>
protected override void Dispose( bool disposing )
{
if(disposing && components != null)
{
components.Dispose();
}
base.Dispose(disposing);
}
#endregion
// WEB 服务示例
// HelloWorld() 示例服务返回字符串 Hello World
// 若要生成，请取消注释下列行，然后保存并生成项目
// 若要测试此 Web 服务，请按 F5 键
// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }
}
}
下面在(1)处加入
[WebService(Namespace="http://localhost/webserver/")]
这是因为soap是基于http协议上的，客户端无法知道webservice位于那个服务器上。在实际应用中，比如http://www.ourfly.com/上放置这个webservice，则Namespace改为http://www.ourfly.com/webserver.
下面我们给这个webservice添加一个方法。
// [WebMethod]
// public string HelloWorld()
// {
// return "Hello World";
// }
微软帮我们写好了一个，接着添加一个方法。方法名称叫show.
[WebMethod]
public string show(string yourname)
{
return “http://www.ourfly.com”+”欢迎”+yourname;
}
现在，就可以运行了，按F5,点击show,输入你的名字，然后点击invote
看到了吧。
<?xml version="1.0" encoding="utf-8" ?>
<string xmlns="http://tempuri.org/%22%3Ehttp://www.ourfly.com欢迎yyg</string>
成功了。打开bin目录，Vs.net已经将proxy做好了.webserver.dll.
现在我们在不同的环境下测试：
1． 打开vs.net,新建”windows应用程序”工程，命名为Client,增加按钮，文本框。
现在要用到代理了，右键单击右边的reference(引用),选择”添加引用”,选择浏览，找到webserver目录下的bin目录下的webserver.dll
再加入一个system.web.webservices的引用，在列表中有。
在form1.cs里，加入
using System.Web.Services;
using webserver;
然后在
private System.Windows.Forms.Button button1;
private System.Windows.Forms.TextBox textBox1;
后面，插入
private webserver.service1 Client
建立一个service1的实例。双击按钮，代码如下：
private void button1_Click(object sender, System.EventArgs e)
{
Client =new Service1();
string name;
name=Client.show("龙卷风.NET");
textBox1.Text=name;
}
按F5，运行工程，点击按钮，文本框中显示
http://www.ourfly.com/欢迎龙卷风.NET
2． Asp.NET web窗口的测试
方法与上面的一模一样，添加引用，建立service1的实例
在此不在细说。
3.在VB中测试
这个就要相对来说复杂一些
首先在vb中建立一个”标准EXE”的工程。添加引用：Microsoft Soap Type library。注意：如果没有安装Microsoft Soap Toolkit,是没有这个类型库的。
可以在http://www.ourfly.com/中下载。
添加一个text
Private Sub Form_Load()
Text1.Text = add()
End Sub
Public Function Add() As String
Dim objSoapClient As New SoapClient
objSoapClient.ClientProperty("ServerHTTPRequest") = True
Call objSoapClient.mssoapinit("http://localhost/webserver/service1.asmx?WSDL", "Service1", "Service1Soap")
这句也可以
objSoapClient.mssoapinit("http://localhost/webserver/service1.asmx?WSDL")
Add = objSoapClient.Show("龙卷风.NET")
End Function
调试成功需要注意的：
运行服务端webservice的程序，出现下面时
支持下列操作。有关正式定义，请查看服务说明。
点击服务说明，会得到完整的wsdl文件
http://localhost/webserver/Service1.asmx?WSDL
我们就要使用这个文件，其中包含了我们定义的方法等等。
Mssoapinit(bstrWSDLFile as string,[bStrServiceName as string ],[bStrport as string ] ,[bstrWSMLDile as string])的用法：
其中第二个，第三个参数在wsdl文件中可以找到。也可以省略。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/cui55/archive/2006/07/06/884520.aspx
4. 什么是remoting和webservice,remoting和webservice的区别
其实现的原理并没有本质的区别，在应用开发层面上有以下区别：
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的一种特例。