WebService/Wcf基础知识

XML Web services 基础结构：

若要在 Web 的多样性世界里取得成功，在涉及到操作系统、对象模型和编程语言的选择时，XML Web services 不能有任何倾向性。同样，若要使 XML Web services像其他基于 Web 的技术一样被广泛采用，则它们必须是： 

松耦合的：如果对两个系统的唯一要求是要理解前面提到的自我描述的基于文本的消息，那么这两个系统就被认为是松耦合的。另一方面，紧耦合系统要求大量自定义系统开销来进行通信，并要求系统之间有更多的了解。 

常见的通信：大概不会有人会在现在或不远的将来生成一个无法连接到 Internet 的操作系统，因此，需要提供常见的通信信道。同样，能够将几乎所有系统或设备连接到 Internet 的能力将确保这样的系统和设备能够为连接到 Internet 的所有其他系统或设备所使用。 

通用数据格式：通过用现有的开放式标准而不是专用的封闭通信方法，任何支持同样的开放式标准的系统都能够理解 XML Web services。在采用自我描述的基于文本的消息时，XML Web services 及其客户端无须知道每个基础系统的构成即可共享该消息，这使得自治系统和完全不同的系统之间能够进行通信。XML Web services 使用 XML 实现此功能。 

XML Web services 采用一种基础结构，该基础结构提供下列内容：定位 XML Web services 的发现机制、定义如何使用这些服务的服务说明以及通信时使用的标准连网形式。下图显示了此基础结构的一个示例。

XML Web services 基础结构
XML Web services 目录 XML Web services 目录提供一个用以定位其他单位提供的 XML Web services 的中心位置。XML Web services 目录（如 UDDI 注册表）充当此角色。XML Web services 客户端可能或可能不需要引用 XML Web services 的目录。 

XML Web services 发现 XML Web services 发现是定位（或发现）使用 Web 服务描述语言 (WSDL) 对特定 XML Web services 进行描述的一个或多个相关文档的过程。DISCO 规范定义定位服务说明的算法。如果 XML Web services 客户端知道服务说明的位置，它们可以跳过发现过程。
 
XML Web services 说明 若要了解如何与特定的 XML Web services 进行交互，需要提供定义该 XML Web services 支持何种交互操作的服务说明。XML Web services 客户端必须知道如何与 XML Web services 进行交互才可以使用该服务。 

XML Web services 连网形式 为实现通用的通信，XML Web services 使用开放式连网形式进行通信，该格式是任何能够支持最通用的 Web 标准的系统都可以理解的协议。SOAP 是 XML Web services 通信的主要协议。

1、SOAP
         SOAP是Web Service的基本通信协议。因为SOAP与DCOM和CORBA在概念上有相同之处，所以很多人在问：“SOAP是怎样激活对象的？”或“SOAP在使用什么命名服务（Naming Service）？”。或许在执行SOAP的过程当中会用到这些，但这些并不在SOAP规范要考虑的范畴之内。SOAP只是定义SOAP消息的XML格式（XML Format），如果你用一对SOAP标记（SOAP Elements）把XML文档括起来，那么这个就是一个SOAP消息，这不是很简单吗？
         SOAP规范还定义了怎样用XML来描述程序数据（Program Data）,怎样执行RPC（Remote Procedure Call）。这些可选的规范是为了构建RPC-style的应用程序（客户端SOAP消息包含函数名和在函数中用到的参数，而服务器端SOAP消息包含执行函数之后的结果）。大多数SOAP解决方案都支持RPC-style应用程序，因为很多程序员已对DCOM或CORBA熟悉。SOAP还支持Document-style应用程序（SOAP消息只包含XML文本信息）。Document-style应用程序有很好的灵活性，所以很多用RPC很难构建的Web Service用这种方式构建。
        最后SOAP规范还定义了HTTP消息是怎样传输SOAP消息的。这并不代表SOAP只能用HTTP来作为传输协议，MSMQ、SMTP、TCP/IP都可以做SOAP的传输协议。 
        很多大公司根据SOAP规范，都开发出了自己的SOAP解决方案。这些解决方案都是相对于某种语言。比如说Microsoft SOAP toolkit2.0把COM函数转换成SOAP消息，而Apache toolkit把JAVA函数转换成SOAP消息。这样难免带来一些兼容性问题。 
        现在SOAP的很多另人瞩目的特性已成为现实（SOAP已经运行于不同的硬件和软件平台），而且有70多个解决方案。之所以SOAP被人们所爱戴，是因为SOAP比其他同类技术（CORBA、DCE）简单易用。
        安全性对于应用程序来说是很重要的。那么SOAP的安全性如何呢？对于把HTTP作为传输协议的SOAP来说是没有问题的，因为HTTP协议已经有很好的安全构架。那么用其他传输协议会出现安全问题吗？不是的，你不必担心，因为已经有这方面的规范了（http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-security.asp）。


2、  WSDL
        WSDL是一种XML文档，它定义SOAP消息和这些消息是怎样交换的。IDL（Interface Description Language）是用于COM和CORBA的，WSDL是用于SOAP的。WSDL是一种XML文档，所以我们可以阅读和编辑，但很多时候是用工具来创建、由程序来阅读。
        举个例子，你要使用供应商的Web Service构建应用程序。你可以向供应商索取使用Web Service的范例，然后按照范例来构建应用程序。这样可能出现意料不到的错误，比如说，你在程序中使用的客户代码的数据类型是integer，而供应商使用的数据类型是string.。WSDL详细定义客户端消息的格式，需要什么样的参数，这样可以避免不必要的错误。


3、 UDDI
        UDDI可以比喻成电话本，电话本里记录的是电话信息，而UDDI记录的是Web Service信息。你可以不把Web Service注册到UDDI。但如果要让全球的人知道你的Web Service，最好还是注册到UDDI。
        UDDI目录说明文件也是一个XML文档，它包括三个部分。“白页（White Paper）”说明提供Web Service的公司（人）信息，比如说名称、地址和联系方式等等。“黄页（Yellow Paper）”说明UDDI目录的分类，比如说金融、服务和印刷等等。“绿页（green Paper）”说明接口（Web Service 提供的）的详细信息。UDDI提供多种查询方式，来帮助你找到需要的Web Service。如果你查询与财务有关的Web Service，那么UDDI会提供详细的信息。

什么情况下应该使用Web Service?


跨越防火墙的通信

　　如果你的应用程序有成千上万的用户，而且他们都分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。那是因为客户端和服务器之间通常都会有防火墙或者代理服务器。在这种情况下，你想使用DCOM就不是那么简单了，而且，通常你也不愿意把你的客户端程序发布到如此庞大数量的每一个用户手中。于是，你最终选择了用浏览器作为客户端，写下一堆ASP页面，把应用程序的中间层暴露给最终用户。结果呢?运气好的话，只是开发难度大了一些，运气不好的话，就会得到一个根本无法维护的应用程序。

　　想象一下你应该怎么在你的应用程序里面加入一个新的页面：你必须先建立好用户界面(Web页面)，以及在这个页面后面，包含相应商业逻辑的中间层组件。这还不够，你还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把"结果页"送回浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程不就简单多了吗?还有，建立ASP页面的那一步可以省略掉吗?

　　当然。如果你的中间层组件是Web service的话，你完全可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用Web service，你可以直接使用Microsoft SOAP Toolkit或。NET这样的SOAP客户端，也可以使用你自己开发的SOAP客户端，然后把它和你的应用程序连接起来。这样做，不仅可以缩短开发周期，还可以减少代码的复杂度，并增强整个应用程序的可维护性。同时，你的应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"了。

　　以我的经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用Web service这种结构，可以轻松的节省花在用户界面编程上的20%的开发时间。这样做还有另一个好处，就是你将得到一个由Web service组成的中间层，这一层是完全可以在应用程序集成或其他场合下被重用的。最后，通过Web service把你的应用程序的逻辑和数据暴露出来，还可以让其它平台上的客户重用你的应用程序。

应用程序集成

　　企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发的力量。你的应用程序经常都需要从运行在古老的IBM主机上的程序中获取数据; 或者再把数据发送到主机或UNIX应用程序中去。即使是在同一个平台上，不同的软件厂商生产的各种软件也常常需要集成起来。通过Web service，应用程序可以用标准的方法把功能和数据暴露出来，供其它的应用程序使用。

　　例如，你有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等信息。同时，你还有一个订单执行程序，用于实际货物发送的管理。这两个程序是来自不同软件厂商的。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层Web service，订单执行程序可以把"AddOrder"函数暴露出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。进而通过Web service集成应用程序

B2B的集成

　　用Web service集成应用程序，可以使你公司内部的商务处理更加自动化。但当交易跨越了你的供应商和客户，突破了公司的界线时又会怎么样呢?跨公司的商务交易集成通常叫做B2B集成。

　　Web service是B2B集成成功的关键。通过Web service，你的公司可以把关键的商务应用暴露给指定的供应商和客户。例如，把你的电子下单系统和电子发票系统暴露出来，你的客户就可以以电子的方式向你发送购货订单，而你的供应商则可以以电子的方式把原料采购的发票发送给你。当然，这并不是一个新的概念：电子文档交换(EDI)早就是这样了。Web service和EDI之间的主要区别在于，Web service的实现要比EDI简单得多，而且Web service是运行在Internet上的，在世界任何地方都可轻易实现，这样其运行成本就相对较低。不过，Web service并不像EDI那样，是文档交换或B2B集成的一套完整的解决方案。Web service只是B2B集成的一个关键部分，还需要许多其它的部分才能完成这个集成。

　　用Web service来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把你的商务逻辑暴露出来，成为Web service，你就可以让任何指定的合作伙伴轻松的调用你的商务逻辑，而不管他们的系统在什么平台上运行，使用的是什么开发语言。这样就大大减少了花在B2B集成的上的时间和成本。这样的低成本让许多原本无法承受EDI的投资成本的中小企业也能实现B2B集成。

软件重用

　　软件重用是一个很大的主题，它有很多的形式和程度。最基本的形式是源代码模块或者类一级的重用。另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这样的可重用软件组件在市场上都占有很大的份额。但这类软件的重用都有一个很严重的限制：重用仅限于代码，而数据不能被重用。原因在于你可以很轻易的发布组件甚至源代码，但要发布数据就没那么容易了，除非那些数据都是不会经常变化的静态数据。

　　而Web service允许你在重用代码的同时，重用代码后面的数据。使用Web service，你不再像以前那样，要先从第三方购买、安装软件组件，再从你的应用程序中调用这些组件。你只需要直接调用远端的Web service就可以了。举个例子，你想在你的应用程序中确认用户输入的邮件地址，那么，你只需把这个地址直接发送给相应的Web service，这个Web service 就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址的确在相应的邮政编码区域。Web service 的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不现实的，因为那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

　　另一种软件重用的情况是把好几个应用程序的功能集成起来。例如，你想要建立一个局域网上的门户站点应用，让用户既可以查询他们的联邦快递包裹，察看股市行情，又可以管理他们的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了上面的这些功能。一旦他们把这些功能都通过Web service 暴露出来，你就可以非常轻易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

　　用Web service来集成各种应用中的功能，为用户提供一个统一的界面许多应用程序都会利用Web service，把当前基于组件的应用程序结构扩展为组件和Web service 的混合结构。你也可以在应用程序中使用第三方的Web service 提供的功能。你还可以把你自己的应用程序的功能通过Web service 提供给别人。所有这些情况下，你都可以重用代码和代码后面的数据。总之，Web service 将是软件重用的一种非常有力的形式。

什么时候不应该使用Web Service？

一个对Web service的完整介绍还应该包括什么时候不该用Web service.经过前面的介绍，我们知道了Web service 在通过Web进行互操作或远程调用的时候是最有用的。不过，还有许多情况，Web service根本不能给你带来任何好处。

　　单机应用程序

　　目前，我们还有很多桌面应用程序是供商用和个人使用的。其中一些只需要与运行在本机上的其他程序通信。在这种情况下，我们最好就不要再用Web service ，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在一台服务器上的服务器软件也是这样：最好直接用COM或其他本地的API来进行应用程序间的调用。当然Web service 也能用在这些情况下，但那样不仅消耗太大，而且不会给你带来任何好处。

　　局域网上的同构应用程序

　　在许多应用中，你所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，你有两个服务器应用程序需要相互通信，或者你有一个Win32或WinForm的客户程序要连接到局域网上的另一个服务器程序。在这些程序里使用DCOM会比SOAP/HTTP有效的多。类似的，如果你的一个。NET程序要连接到LAN上的另一个。NET程序，那么你应该使用。NET remoting.有趣的是，在。NET remoting中，你也可以指定使用SOAP/HTTP来进行Web service 调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，只要你从应用程序结构的角度看来，有别的方法比Web service 更有效，更可行，那就不要再用Web service.

　　总结

　　Web service是创建可互操作的分布式应用程序的新平台。Web service 的主要目标是跨平台的可互操作性。为了达到这一目标，Web service 是完全基于XML、XSD等独立于平台、独立于软件供应商的标准的。

　　Web service在应用程序跨平台和跨网络进行通信的时候是非常有用的。Web service适用于应用程序集成、B2B集成、代码和数据重用，以及通过Web进行客户端和服务器的通信的场合。

　　当然，Web service也不是万能的，你不能到处滥用Web service.在有些情况下，Web service 会降低应用程序的性能，而不会带来任何好处。例如，一台机器或一个局域网里面运行的同构应用程序就不应该用Web service 进行通信。

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 服务。
这是个标准的东西，我的意见是标准的东西不见的都是最好的。在保证标准的同时，丢失了很多特性。

利用wsdl.exe将服务描述文件生成webservice代理类


1、开始->程序->Visual Studio 2005 命令提示
2、输入如下红色标记部分
 
D:/Program Files/Microsoft Visual Studio 8/VC>wsdl /language:c# /n:TestDemo /out:d:/Temp/TestService.cs D:/Temp/TestService.wsdl
 
在d:/Temp下就会产生一个TestService.cs 文件
 
注意：D:/Temp/TestService.wsdl 是wsdl路径，可以是url路径：http://localhost/Temp/Test.asmx?wsdl
 

+++++++++++++++指令解释++++++++++++++++++++++++++++++++++++
 
wsdl.exe <选项> <URL 或路径> <URL 或路径> ...
     - 选项 -
<URL 或路径> -
    指向 WSDL 协定、XSD 架构或 .discomap 文档的 URL 或路径。
/nologo
    取消显示版权标志。
/language:<language>
    用于生成的代理类的语言。请从“CS”、“VB”、“JS”、“VJS”、
    “CPP”中选择，或者为实现 System.CodeDom.Compiler.CodeDomProvider
    的类提供一个完全限定的名称。默认语言为“CS”(CSharp)。
    缩写形式为“/l:”。
/sharetypes
    打开类型共享功能。此功能针对不同服务之间共享
    的相同类型(命名空间、名称和网络签名必须相同)
    创建一个具有单一类型定义的代码文件。
    请使用 http:// URLs 作为命令行参数来引用
    服务，或为本地文件创建一个 discomap 文档。
/verbose
    指定 /sharetypes 开关时显示额外信息。
    缩写形式为“/v”。
/fields
    生成字段而非属性。缩写形式为“/f”。
/order
    为粒子成员生成显式顺序标识符。
/enableDataBinding
    在所有生成的类型上实现 INotifyPropertyChanged 接口，
    以启用数据绑定。缩写形式为“/edb”。
/namespace:<namespace>
    生成的代理或模板的命名空间。默认命名空间
    为全局命名空间。缩写形式为“/n:”。
/out:<fileName|directoryPath>
    生成的代理代码的文件名或目录路径。默认文件名是从
    服务名派生的。缩写形式为“/o:”。
/protocol:<protocol>
    重写要实现的默认协议。请从“SOAP”、“SOAP12”、
    “HttpGet”、“HttpPost”中选择。
/username:<username>
/password:<password>
/domain:<domain>
    连接到要求身份验证的服务器时使用的凭据。
    缩写形式为“/u:”、“/p:”和“/d:”。
/proxy:<url>
    用来处理 HTTP 请求的代理服务器的 URL。
    默认为使用系统代理服务器设置。
/proxyusername:<username>
/proxypassword:<password>
/proxydomain:<domain>
    连接到要求身份验证的代理服务器时使用的凭据。
    缩写形式为“/pu:”、“/pp:”和“/pd:”。
/appsettingurlkey:<key>
    在代码生成中用来读取 URL 属性的
    默认值的配置项。默认为不从配置
    文件中读取。缩写形式为“/urlkey:”。
/appsettingbaseurl:<baseurl>
    计算 URL 段时使用的基 URL。
    还必须指定 appsettingurlkey 选项。URL 段是
    从 appsettingbaseurl 计算
     WSDL 文档中的 URL 的相对 URL 的结果。缩写形式为“/baseurl:”。
/parsableerrors
    输出错误，其格式与编译器报告的格式类似。
     - 高级 -
/server
    服务器开关已被否决。请改用 /serverInterface。
    使用基于协定的 ASP.NET，为 Xml Web Services 实现
    生成抽象类。默认情况下，生成客户端代理
    类。
/serverInterface
    为 ASP.Net Web 服务的服务器端实现生成
    接口。将为 wsdl 文档中的每个绑定生成
    一个接口。wsdl 单独实现 wsdl 协定(实现
    接口的类在类方法上不应包括下列任意一项:
    更改 wsdl 协定的 Web 服务属性或序列化
    属性)。缩写形式为“/si”。
/parameters:<file>
    从指定的 xml 文件读取命令行选项。这样可以
    指定命令行中无法使用的选项，例如选择
    生成的异步编程模型类型。有关详细信息，
    请参阅工具文档。缩写形式为“/par:”。

利用svcutil.exe工具来通过服务地址生成代理类和配置文件


SVCUtil.exe 目录：C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin 下

生成代码命令：

SvcUtil /language:c# /out:HellowWCFServiceClient.cs /config:App.conifg http://localhost:8371/HelloWCFService

上面命令指定了要生成代码的语言、代码文件和配置文件名、WCF服务端地址（注意：运行命令式必须确定WCF服务端正在运行中），运行后将生成一个配置文件和一个包含客户端类的代码文件。请将这两个文件添加到客户端应用程序，并使用生成的客户端类来调用服务。


+++++++++++++++指令解释++++++++++++++++++++++++++++++++++++

/directory:<目录>
要在其中创建文件的目录。默认设置：当前目录。缩写形式：/d

/help
显示此工具的命令语法和选项。缩写形式：/?

/noLogo
取消版权和标题消息。

/svcutilConfig:<配置文件>
指定要取代 App.config 文件使用的自定义配置文件。 可以使用该自定义配置文件来注册 system.serviceModel 扩展，而无需更改工具的配置文件。

/target:<输出类型>
指定要由工具生成的输出。有效的值为代码、元数据或 xmlSerializer。缩写形式：/t


示例
以下命令将依据运行的服务或联机元数据文档生成客户端代码。

svcutil http://service/metadataEndpoint


以下命令将依据本地元数据文档生成客户端代码。

svcutil *.wsdl *.xsd /language:C#

以下命令将依据本地架构文档用 Visual Basic 生成数据协定类型。

svcutil /dconly *.xsd /language:VB


以下命令从运行的服务中下载元数据文档。

svcutil /t:metadata http://service/metadataEndpoint


以下命令为程序集中的服务协定和关联的类型生成元数据文档。

svcutil myAssembly.dll


以下命令为程序集中的服务以及所有关联的服务协定和数据类型生成元数据文档。

svcutil myServiceHost.exe /serviceName:myServiceName


以下命令为程序集中的数据类型生成元数据文档。

svcutil myServiceHost.exe /dconly


以下命令验证服务宿主。

svcutil /validate /serviceName:myServiceName myServiceHost.exe


以下命令为程序集中任何服务协定使用的 XmlSerializer 类型生成序列化类型。

svcutil /t:xmlserializer myContractLibrary.exe

利用disco.exe工具通过服务地址生成服务的描述文件（wsdl）


(1) 打开 Visual Studio 命令提示符

(2)输入disco.exe http://localhost:3721/StudentService.svc?wsdl

即可生成StudentService.wsdl及其他框架文件