webservices(什么是WebServices)

1、我找的一些资料，可能会有点文不对题。

2、定义WebServices是自包含的、模块化的应用程序，它可以在网络(通常为Web)中被描述、发布、查找以及调用。

3、定义WebServices是基于网络的、分布式的模块化组件，它执行特定的任务，遵守具体的技术规范，这些规范使得WebService能与其他兼容的组件进行互操作。

4、定义所谓Web服务，它是指由企业发布的完成其特别商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项应用服务。

5、(UDDI规范0)商业需求XMLWebservices是分布式计算的重要标准，也是未来软件开发的技术趋势，通过XMLWebservices标准，应用软件之间可以实现跨平台，跨编程语言的联接和互操作。

6、作为微软平台的一个基本功能，.基于XMLWebservices标准的.NET开发平台可以实现个人之间，个人与企业之间，和企业之间的信息互连，这样就实现人们可以随时随地存取和使用信息的梦想。

7、在微软构造和实现这种.NET-connected平台的同时，众多的合作伙伴和厂商也在开发基于XMLWebservices标准的可以互相联接和整合软件产品和解决方案。

8、这些软件产品和解决方案正在给他们的客户带来巨大的好处、企业的信息系统可以更方便地为其用户提供更好的服务，企业的信息系统可以与合作伙伴的系统更好地相连，可以为企业的雇员提供及时正确的信息。

9、产业商机微软公司的.NETConnectedLogo计划，是一个全球认证计划，主要是用来标识那些基于XMLWebservices而开发的软件和解决方案。

10、经微软认证的软件公司，可以将.NETConnected标志图案置于其被认证软件产品的包装，文档，宣传材料和广告中。

11、.NETConnected标识，标志着您的应用软件基于.NETFramework开发，能够基于XMLWebservices标准和其他的软件共享数据和功能。

12、.NETConnectedLogo计划可以帮助客户识别应用软件、系统和服务是否为了适应下一代Internet计算的要求而进行了优化。

13、参加Microsoft.NETConnectedLogo计划的好处Microsoft.NETConnectedLogo会、标识领先的软件开发技术和实力。

14、区别您的应用软件于其他的软件产品。

15、充分利用微软在.NET上所做的广泛的市场宣传和投入。

16、通过.NETConnected目录在全球推广和宣传您的软件产品和解决方案。

17、使用.NETConnected产品和服务的用户会受益、经认证的软件产品和服务，可以基于XMLWebservices与其他的软件互联，并被无缝地整合进企业未来的信息系统中。

18、经认证的产品，基于.NETFramework开发，有良好的性能，稳定性和安全性，意味着这个产品或服务可以信赖。

19、可以帮助最终用户迅速地识别那些能够帮助他们随时随地信息互连的技术。

20、Microsoft.NETConnected白金应用要求、应用软件或服务应基于Microsoft.NETFramework开发，主要的应用功能提供有基于XMLWebservice的接口,这个Webservice调用的过程要符合业界标准、XMLSchema0,SOAP1XMLSchema0,SOAP1以及WSDL1。

21、应用应该用到至少一种微软的应用服务器，如SQLServer,ExchangeServer,BiztalkServer等。

22、The.NETConnectedDirectory微软.NETConnectedDirectory提供了一个中心的位置，用户可以在这里查找信息，合作伙伴可以在这个位置展示满足.NETConnectedlogo要求的软件和服务。

23、即使微软推广这些应用软件和XMLWebservices时，合作伙伴仍然可以继续维护与宿主这些服务或应用软件，维护任何支付方式，处理所有与这些产品相关的问题。

24、通常，如果你的产品得到了.NETConnected资质认证，他就会自动的在目录产品列表中显示出来。

25、一个合作伙伴可以选择是否要在.NETConnectedDirectory中显示自己的产品。

26、合作伙伴的信息在加入目录之前要经过评审得到允许才可加入。

27、合作者详细网址(需要URL)为了能够使合作者对它们提交的东西做出改动时(支付结构，下载网址，描述等)不用重新提交入口，我们需要连接到合作者的网址，这个网址包括后面列出的一些信息。

28、这些信息不仅会帮助开发者得到计划的版本，下载信息等，它也包含应用软件自身的基本商业信息。

29、合作者的网页包含的信息为、使用XMLWebservice的XMLWeb服务或应用软件的名字描述产品的功能执行它的步骤连接到XMLSchema的网址，浏览XMLSchema(可选)WSDLSchemaVersion(ie、v1)SOAPVersion(ie、v1)XMLWebservice或软件花费和支付方法系统要求(可选)和哪些产品一起工作效果好或要求(可选)建立联系得到用户支持建立连接下载软件(可选)直接回到.NETConnecteddirectory的链接http、//www.microsoft.com/net/directory产品有效期(如果有的话)可选信息--常见问题回答，其他信息，联系电话网页必须显示适当的.NETConnectedLogo合作者的信息在加入目录之前要经过评审得到允许才可加入未来的需求将来.NETConnectedLogo计划会产生更高级的标准。

30、这个文档只是作为参考，MICROSOFT并没有授权，或隐含什么。

31、使用.NET就其核心问题而言，Microsoft®.NET是关于使技术为人们所用，而不是强制个人适应其计算机的限制。

32、利用.NET，无论何时何地您总能连接到您首选设备上的信息。

33、利用.NET，您可以保护您的个人信息和企业数据，同时允许有您的授权的他人连接到这些信息。

34、.NET的价值对于个人(包括您自己、您的客户、雇员、供应商和合作伙伴)来说，使用Microsoft.NET进行生成的成果将是无缝的、吸引人的体验。

35、使用.NET进行开发借助MicrosoftVisualStudio®.NET和Microsoft.NET框架，Microsoft®.NET提供了生成和部署最先进的应用程序和XMLWebservices的最快捷方法。

36、.NET对开发人员意味着什么通过使用Microsoft?VisualStudio®.NET和.NET框架，Microsoft为开发人员提供了一整套开发工具，使用这些工具可以快速而轻松地创建最先进的应用程序和XMLWebservices。

37、借助VisualStudio.NET和.NET框架，Microsoft.NET允许更快地开发软件应用程序和服务。

38、.NET框架和VisualStudio.NET将为应用程序和XMLWebservices提供更高的可靠性。

39、XMLWebservices的使用将允许在.NET平台上创建的应用程序和服务更容易、更有效地集成在一起。

40、XMLWebservices对于Microsoft.NET，在处理一组有限任务的离散单元(XMLWebservices)中生成代码。

41、由于基于XML的标准接口简化了软件之间的通讯，因此可以将XMLWebservices一起集成到高度专门化的应用程序和体验。

42、您可以使用来自世界各地的最好的XMLWebservices，快速而轻松地创建所需的解决方案。

43、Microsoft将提供一组以用户为中心的核心XMLWebservices(即Microsoft.NET我的服务)以提供诸如用户标识和日历访问之类的功能。

1、当前，WebService是一个热门话题。

2、但是，WebService究竟是什么？什么情况下应该用WebService？什么情况下不应该用WebService？是需要我们正确认识的。

3、WebServices是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务,它是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。

4、WebService是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式(Http，XML，Soap)来访问WebService,通过WebService内部执行得到所需结果.WebService可以执行从简单的请求到复杂商务处理的任何功能。

5、一旦部署以后，其他WebService应用程序可以发现并调用它部署的服务。

6、在构建和使用WebService时,主要用到以下几个关键的技术和规则、XML、描述数据的标准方法.SOAP、表示信息交换的协议.WSDL、Web服务描述语言.UDDI、找到服务驱动器的的方法实际上，WebService的主要目标是跨平台的可互操作性。

7、为了达到这一目标，WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。

8、由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。

9、长项跨防火墙的通信如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。

10、因为客户端和服务器之间通常会有防火墙或者代理服务器。

11、在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。

12、传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。

13、这样做的结果是开发难度大，程序很难维护。

14、举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把"结果页"送回浏览器。

15、要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。

16、如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。

17、要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。

18、不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。

19、同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"。

20、从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上20%的开发时间。

21、另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。

22、最后，通过WebService把应用程序的逻辑和数据"暴露"出来，还可以让其它平台上的客户重用这些应用程序。

23、长项应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。

24、应用程序经常需要从运行在IBM主机上的程序中获取数据。

25、或者把数据发送到主机或UNIX应用程序中去。

26、即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。

27、通过WebService，应用程序可以用标准的方法把功能和数据"暴露"出来，供其它应用程序使用。

28、例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容。

29、还有一个订单执行程序，用于实际货物发送的管理。

30、这两个程序来自不同软件厂商。

31、一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。

32、通过在订单执行程序上面增加一层WebService，订单执行程序可以把"AddOrder"函数"暴露"出来。

33、这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。

34、长项B2B的集成用WebService集成应用程序，可以使公司内部的商务处理更加自动化。

35、但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。

36、WebService是B2B集成成功的关键。

37、通过WebService，公司可以把关键的商务应用"暴露"给指定的供应商和客户。

38、例如，把电子下单系统和电子发票系统"暴露"出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。

39、当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。

40、但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。

41、不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。

42、WebService只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。

43、用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。

44、只要把商务逻辑"暴露"出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。

45、这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。

46、长项软件和数据重用软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。

47、最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。

48、当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。

49、但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。

50、原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。

51、WebService在允许重用代码的同时，可以重用代码背后的数据。

52、使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件。

53、只需要直接调用远端的WebService就可以了。

54、举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。

55、WebService的提供商可以按时间或使用次数来对这项服务进行收费。

56、这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

57、另一种软件重用的情况是，把好几个应用程序的功能集成起来。

58、例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。

59、现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。

60、一旦他们把这些功能都通过WebService"暴露"出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

61、将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。

62、两种情况下，都可以重用代码和代码背后的数据。

63、从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。

64、不过，也有一些情况，WebService根本不能带来任何好处。

65、短处单机应用程序目前，企业和个人还使用着很多桌面应用程序。

66、其中一些只需要与本机上的其它程序通信。

67、在这种情况下，最好就不要用WebService，只要用本地的API就可以了。

68、COM非常适合于在这种情况下工作，因为它既小又快。

69、运行在同一台服务器上的服务器软件也是这样。

70、最好直接用COM或其它本地的API来进行应用程序间的调用。

71、当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

72、短处局域网的同构应用程序在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。

73、例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。

74、在这些程序里，使用DCOM会比SOAP/HTTP有效得多。

75、与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。

76、有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行WebService调用。

77、不过最好还是直接通过TCP进行RPC调用，那样会有效得多。

78、总之，只要从应用程序结构的角度看，有别的方法比WebService更有效、更可行，那就不要用WebService。

1、当前，WebService是一个热门话题。

1、WebService技术是原来的组件技术思想在Internet时代中的进一步发展，更准确地说，WebService是封装成单个实体发布到网络上，并提供API以提供其他程序使用的功能集合，是在Internet上进行分布式计算的基本构造块，是可用URL定位服务资源。

2、简言之，WebService是可远程调用的应用程序组件。

3、WebService的本质目的是提供一个与操作系统、程序设计语言、机器类型、运行环境均无关的平台，实现Internet中应用程序的共享。

4、WebService基于一系列的标准协议，其协议构架如图4示。

5、图4WebService协议架构统一描述、发现与集成协议UDDI(UniversalDescription，DiscoveryandIntegration)用于构建WebService的服务注册中心，实现服务发现功能。

6、Web服务描述语言WSDL(WebServiceDescriptionLanguage)驻留在服务容器中，定义了一种提供Web服务描述的标准化方式。

7、简单对象访问协议SOAP(SimpleObjectAccessProtocol)提供传输数据的标准方式，充当在服务提供方和服务请求方之间激活服务的消息交换服务。

8、可扩展标记语言XML(ExtensibleMarkupLanguage)是Internet上数据交换的标准，在WebService中实现信息表达，用于SOAP，WSDL和UDDI。

9、超文本传输协议HTTP(HyperTextTransferProtol)是WebService最流行的传输协议。

10、WebService体系结构是一种面向服务的结构，典型的WebService组件架构如图5示。

11、WebService体系结构主要由服务请求者、服务注册中心和服务提供者三部分组成。

12、其实现过程包括服务发布与注册、服务查询与发现、服务绑定与调用三个过程。

13、服务请求者指查询、调用服务的客户端程序服务提供者即服务的所有者和部署服务的平台服务注册中心指用来存储服务信息的信息库，服务提供者在这里发布、注册服务、而服务请求者在这里查询、绑定服务，最终实现调用服务提供者的服务。

14、图5WebService组件架构WebService有两大核心优势，即分布性和互操作性。

15、在WebService架构下，服务提供者和服务请求者都可以是分布式的，一个服务请求者可以远程调用多个服务提供者的服务，服务提供者也可以同时为多个服务请求者提供服务，这为服务共享提供了一个最佳的方式。

16、互操作性也是服务共享的关键问题。

17、WebService的信息表达基于标准通用的XML语言，在XML语言的基础上，使用WSDL和UDDI实现服务注册与发现，使用SOAP实现服务调用。

18、基于这些标准的协议，WebService实现了服务的跨平台、跨语言的共享。

19、XML、SOAP、WSDL和UDDI是用于构建和使用WebService的核心标准和技术。

20、以下将分别介绍这四种标准和技术。

21、1XMLXML是一种数据描述语言，为Internet上数据交换的标准。

22、XML定义了应用系统间传递数据的结构，而且这种结构的描述不是基于二进制的、只能由程序去判读的代码，而是一种简单的、能够用通用编辑器读取的文本。

23、XML的基本概念包括元素、属性、DTD，Schema和命名空间等。

24、元素是XML文档内容的基本单元。

25、语法上而言，一个元素包括一个起始标记、结束标记以及标记之间的数据内容。

26、形式上为、数据内容。

27、元素内容可以为其他的元素或未处理文本或两者的混合，还可以是空的。

28、元素的嵌套使得文档的层次结构很容易表示。

29、一个元素可以有多个属性。

30、属性是一个名称数据对，表示为字符串。

31、用户可以根据需要自己定义。

32、一个元素不能有同名的两个属性。

33、XML的精髓是允许文档编写者制定基于信息描述、体现数据间逻辑关系的自定义标记。

34、如果不对文档标记作明确定义，而是任意地使用它们，则生成的文档是无法识别的。

35、DTD是对文档结构的一个清晰描述，定义了特定文档中允许出现的元素类型、属性和实体，给出了文档的整体结构和语法。

36、XMLSchema是定义XML的数据定义文件。

37、XMLSchema也规定了一套特定文档的结构，这是与DTD的相同之处。

38、与DTD相比，最大的不同在于它本身也是XML文档。

39、此外还有以下的不同、XMLSchema可以用XML解析器来解析允许使用全局性元素(在整个XML文档中用相同的方式使用元素)和局部元素(特定的上下文中元素有不同的含义)提供丰富的数据类型(整型、布尔型、日期类型等)，且元素的数据类型可以自定义。

40、XML命名空间是一组可以用作XML文档的元素或属性名称的名称集，就是将元素或属性的名称归类。

41、因为XML的开放性，允许任何人创建属于他们自己的元素或属性名称，这样就不可避免地出现不同的人或组织定义的元素名称或属性名称重复，使得相同的名称表达不同的语义。

42、为了避免元素之间出现相同名称的冲突，命名空间限定这些元素或属性名称在命名空间内是唯一的。

43、一般命名空间由这些统一资源标识符URI(UniversalResourceIdentifier)来识别。

44、URI在Internet上是全球唯一的，用URI来限定XML元素名称或属性名称也就确保是全球唯一的。

45、XML主要具有四大优势、(1)XML用文本格式表示数据，方便在Internet上的传输。

46、这一点使XML数据可以方便地利用现有的Internet上基于文本的各种传输协议(如HTTP)进行传输，可以安全的穿越防火墙。

47、(2)XML是可扩展的。

48、XML是一个元语言(MetaLanguage)，它使用了标准化的方法定义其他语言。

49、它只是为结构文档提供了一个数据格式，而没有深入该数据本身，定义它的词汇列表。

50、这使自定义标记语言成为可能，每个行业，每个部门，甚至每个人都可以定义自己的标记语言。

51、(3)XML可以对信息进行很好的层次描述。

52、它基于信息内容的描述，对信息的表达清晰。

53、(4)XML可以进行数据完整性的自动检验。

54、XMLDTD和Schema机制使得XML解析器可以检验XML文档是否与DTD或Schema相配。

55、2SOAPSOAP通过定义一个关于远程组件如何请求信息和如何递交信息的标准，实现Internet中不同应用之间的集成和交互。

56、SOAP是一个基于HTTP和XML的请求、响应RPC协议。

57、SOAP把XML使用代码化为请求和响应参数编码模式，并用HTTP传输。

58、SOAP本身没有定义任何应用程序语义，如编程模型或特定语义的实现，实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。

59、这使得SOAP能够被用于从消息系统到RPC(远程进程调用)的各种应用中。

60、SOAP规范主要由信封(Envelop)、编码规则(EncodingRules)和RPC表示(RPCRepresentation)三部分组成。

61、①SOAP信封构造定义了一个整体的SOAP消息表示框架，可以用于表示消息中的内容是什么，是谁发送的，谁接受并处理它，以及这些处理操作是可选的还是必需的等。

62、②SOAP编码规则定义了一个数据的编码机制，通过这样一个编码机制来定义应用程序中需要使用的数据类型，并可用于交换由这些应用程序定义的数据类型所衍生的实例。

63、③SOAPRPC表示定义了一个用于表示远程过程调用和响应的约定，例如，如何使用HTTP或SMTP协议于SOAP绑定，如何传输过程调用，在具体传输协议的哪个部分传输过程响应，如可以在HTTP的响应的时候传递过程响应。

64、这三部分在功能上是彼此独立的。

65、特别的，信封和编码规则是被定义在不同的XML命名空间中，这样有利于通过模块化获得定义和实现的简明性。

66、SOAP消息是SOAP应用中的主体要素。

67、SOAP为在一个松散的、分布的环境中使用XML对等地交换结构化地和类型化的消息提供了一个简单的轻量级机制。

68、SOAP消息的描述框架格式是以SOAP信封为根元素，内含SOAPHeader和SOAPBody子元素的一个XML文档。

69、所有的SOAP消息都是使用XML格式来编码的。

70、SOAP消息必须不包含DTD与PI(ProcessingInstructions)。

71、除SOAPmustunderstandattribute和SOAPactorattribute外，一般允许属性及属性值自由地选择是在XML实例中描述还是在XMLSchema中描述。

72、SOAP是一种基于XML的轻量级消息交换协议，它是建立在现有行业标准之上的，所以在支持这些标准的平台上运行的应用程序可以通过SOAP消息与其他平台上运行的应用程序有效地进行通信，而且能够穿越防火墙，因而得到了业界的广泛支持。

73、3WSDLWeb服务描述语言WSDL(WebServicesDescriptionLanguage)是基于XML模式的规范，用于将Web服务描述为操作集，并将数据输入/输出参数描述为消息。

74、WSDL还定义使用绑定机制将任何传输协议、数据格式或结构附加到抽象消息、操作或终端的通信模型。

75、WSDL将Web服务描述为一组服务访问点，或称为一组“端口”，客户端可以通过这些端口对包含面向文档信息或面向过程调用的服务进行访问。

76、一个端口定义了一个“服务”项目的提供地点。

77、一个服务可以有多个提供地点，但只能对一组事先定义好的“信息”做出响应。

78、“信息”是对通信数据的描述，每条信息由一组数据组成，这些数据必须定义为收、发双方都能识别的“类型”。

79、端口和信息结合在一起代表了一组“操作”，并定义了这个服务访问点的“端口类型”。

80、把一种协议和一种数据格式关联在一起就定义出了一种可重复使用的“绑定”。

81、把一个网址和一个绑定关联在一起就定义了一个端口，相关的具体部署的端点通过组合就成为抽象的Web服务。

82、综上所述，WSDL文档的根元素是definitions元素，该元素又包含6个子元素、(1)Types、包含可由服务器收发的消息的架构定义。

83、最常见的表示架构的方法是使用XML架构(2)Message、充当一个将架构中的消息与消息的定义关联起来的交叉引用。

84、简单地说，就是定义通信中的数据，包括数据输入和输出。

85、(3)PortType、定义一组Web服务可公开的接口。

86、一个接口与一个或多个消息关联。

87、(4)Operation、它是对服务端所实现功能的抽象定义。

88、(5)Binding、将PortType定义与某个特定的协议关联。

89、(6)Service、定义Web服务公开的相关端点(端口)的集合。

90、4UDDI统一描述、发现和集成协议UDDI(UniversalDescription，DiscoveryandIntegration)是一套基于Web的、分布式的、为Web服务提供信息注册中心的实现标准规范，同时也包含一组使不同的人或组织能将自身提供的Web服务注册以使得他人或其组织能够发现的访问协议的实现标准。

91、UDDI注册的工作流程如图6。

92、UDDI注册中心是Web服务注册、用户集中管理的地方，通过它可以发布、查询、调用WebService，也可以查询特定服务的描述信息，并动态绑定到该服务上。

93、UDDI注册中心同时还提供服务结点管理、用户管理、权限管理、计费管理等功能。

94、服务提供者提供服务需要到UDDI注册中心进行服务的注册、登记，这样用户就可以通过UDDI注册中心获取所需要服务的基本信息与技术细节信息，再通过对服务的绑定得到服务和产品。

95、图6UDDI注册工作流程。

1、WebService技术是原来的组件技术思想在Internet时代中的进一步发展，更准确地说，WebService是封装成单个实体发布到网络上，并提供API以提供其他程序使用的功能集合，是在Internet上进行分布式计算的基本构造块，是可用URL定位服务资源。

1、WebService技术是原来的组件技术思想在Internet时代中的进一步发展，更准确地说，WebService是封装成单个实体发布到网络上，并提供API以提供其他程序使用的功能集合，是在Internet上进行分布式计算的基本构造块，是可用URL定位服务资源。

1、Web service到底是什么。

2、在什么情况下你应该使用Web service。

3、分布式应用程序和浏览器研究一下当前的应用程序开发，你会发现一个绝对的倾向、人们开始偏爱基于浏览器的瘦客户应用程序。

4、这当然不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。

5、发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。

6、传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。

7、配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。

8、事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。

9、在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。

10、极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。

11、不信？问问你的会计师对新的基于浏览器的会计软件有什么想法、绝大多数商用程序用户希望使用更加友好的Windows用户界面。

12、关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。

13、这是因为任何运行Web浏览器的机器都在使用HTTP协议。

14、同时，当前许多防火墙也配置为只允许HTTP连接。

15、许多商用程序还面临另一个问题，那就是与其他程序的互操作性。

16、如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。

17、然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。

18、而且，目前还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。

19、现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。

20、这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。

21、在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。

22、只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

23、。

24、什么是Web Service对这个问题，我们至少有两种答案。

25、从表面上看，Web service 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。

26、这就是说，你能够用编程的方法通过Web来调用这个应用程序。

27、我们把调用这个 Web service 的应用程序叫做客户。

28、例如，你想创建一个Web service ，它的作用是返回当前的天气情况。

29、那么你可已建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。

30、要调用这个ASP页面，客户端需要发送下面的这个HTTP GET请求、http、//host.company.com/weather.asp?zipcode=20171返回的数据就应该是这样、21,晴这个ASP页面就应该可以算作是Web service 了。

31、因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。

32、当然，Web service 还有更多的东西。

33、下面是对Web service 更精确的解释、 Web services是建立可互操作的分布式应用程序的新平台。

34、作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。

35、COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

36、Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。

37、你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service ，只要我们可以通过Web service标准对这些服务进行查询和访问。

38、。

39、新平台Web service平台需要一套协议来实现分布式应用程序的创建。

40、任何平台都有它的数据表示方法和类型系统。

41、要实现互操作性，Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。

42、在传统的分布式系统中，基于界面 (interface)的平台提供了一些方法来描述界面、方法和参数(译注、如COM和COBAR中的IDL语言)。

43、同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。

44、最后，我们还必须有一种方法来对这个Web service进行远程调用。

45、这种方法实际是一种远程过程调用协议(RPC)。

46、为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。

47、下面几个小节就简要介绍了组成Web service平台的这三个技术。

48、。

49、XML和XSD可扩展的标记语言(XML)是Web service平台中表示数据的基本格式。

50、除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。

51、无关性是比技术优越性更重要的、软件厂商是不会选择一个由竞争对手所发明的技术的。

52、XML 解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。

53、例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。

54、W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。

55、它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

56、Web service平台就是用XSD来作为其数据类型系统的。

57、当你用某种语言(如VB.NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。

58、你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。

59、在第二章中，我们将深入XSD，学习怎样转换自定义的数据类型(例如类)到XSD的类型。

60、。

61、SOAPWeb service建好以后，你或者其他人就会去调用它。

62、简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。

63、实际上，SOAP在这里有点用词不当、它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此、你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。

64、SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。

65、 SOAP也是基于XML和XSD的，XML是SOAP的数据编码方式。

66、第三章我们会讨论SOAP，并结识SOAP消息的各种元素。

67、WSDL你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。

68、这些非正式的方法至少都有一个严重的问题、当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Webservice。

69、解决方法是、用机器能阅读的方式提供一个正式的描述文档。

70、Web service描述语言(WSDL)就是这样一个基于XML的语言，用于描述Web service及其函数、参数和返回值。

71、因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。

72、一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

73、。

74、UDDI　　UDDI 的目的是为电子商务建立标准。

75、UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

76、远程过程调用RPC与消息传递　　Web Service本身其实是在实现应用程序间的通信。

77、我们现在有两种应用程序通信的方法、RPC远程过程调用?和消息传递。

78、使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。

79、RPC系统试图达到一种位置上的透明性、服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。

80、　Web Service软件的支持　　操作系统离不开丰富的应用软件的支持。

81、同样，Web Service这项技术只有通过日益广泛的应用才能体现出其价值，目前比较流行的实现方法是使用.NET 和 Java两种技术，并且两种实现方法可以互相操作。

82、如今我们已经可以看到使用微软、IBM、SUN、Borland等不同厂商的Web Service构建工具建立的Web Service应用。

83、微软.NET　　微软的.NET技术应该算是时下最为流行的Web Service 开发技术。

84、首先因为其公司在以前相应的产品就占有相当大的市场份额，以至使新推出的.NET得以有比较稳定的用户群。

85、其次也是更重要的是 .NET平台不仅延续了微软一贯的编程风格，而且还增加了许多支持Web 服务的关键性技术，使得.NET在操作的简单性和执行的稳定性，高效性上达到了一个非常好的结合。

86、微软的Visual Studio.NET便是一个便于 Web 服务的开发工具。

87、微软的目标是，将其新编程语言——C#作为Web Service的首选语言。

88、虽然C#看起来与Java类似，但是还有一些Java中没有的独特的功能。

89、.NET技术中用于Web Service 开发的主要工具是ASP.NET?从技术上说，ASPasp.net? 提供了一些超出ASP以前版本的优点(例如、代码和HTML的分离，与脚本语言相比较，对“真正”的编程语言如 C# 的支持)。

90、IBM的WebSphere　　IBM公司是业界第一家能够提供全面支持Web服务的电子商务基础设施中间件的公司。

91、通过多年来与W3C(The World Wide Web Consortium)的共同努力，包括DBLotus、Tivoli 和WebSphere在内的所有IBM软件都实现了对SOAP、WSDL、UDDI、Linux、XML、J2EE等开放技术和标准的全面支持。

92、 IBM公司的WebSphere也是比较好的基础架构软件开发平台。

93、WebSphere软件平台及开发工具包括WebSphere Studio Application Developer WSAD? 基于J2EE、XML 和Web服务等开放标准，并具备 IBM 在可靠性、扩展性和安全性上的主要优势。

94、WebSphere 是 IBM 在 Web Services策略中的核心平台，它支持所有开发、发布、部署 Web Services应用所必需的开放标准和技术，包括 UDDI，SOAP，J2EE，WSDL，和对 XML 技术集成的增强，这特使得它在全球有很多用户。

95、Borland的JBuilder　　Borland公司在 JBuilder7中，用户可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3进行更快捷地开发Web Service和无线应用。

96、这样将使开发者能够在同一个开发环境中轻松地创建和集成Web Service。

97、今年新推出的JBuidler8更是针对Web Service开发更提供了方便和高效的方法。

98、总之，在Web Service开发上，.NET 和Java都是很好的选择，尽管两者现在都有一些需要完善的地方，但是就目前来说，它们还是最好的开发手段和技术。

99、具体选择哪种开发工具，也是仁者见仁，智者见智的问题。

100、从根本上说，这两种方法没有孰优孰劣的问题，只是根据使用者对这两种方法的掌握程度和对具体语言的偏爱程度来决定。

101、。

102、什么是 XML Web Service？XML Web Service 是在 Internet 上进行分布式计算的基本构造块。

103、开放的标准以及对用户和应用程序之间的通信和协作的关注产生了这样一种环境，在这种环境下，XML Web Service 成为应用程序集成的平台。

104、应用程序是通过使用多个不同来源的 XML Web Service 构造而成的，这些服务相互协同工作，而不管它们位于何处或者如何实现。

105、有多少个构建 XML Web Service 的公司，就可能有多少种 XML Web Service 定义。

106、不过几乎所有定义都具有以下共同点、 * XML Web Service 通过标准的 Web 协议向 Web 用户提供有用的功能。

107、多数情况下使用 SOAP 协议。

108、 * XML Web Service 可以非常详细地说明其接口，这使用户能够创建客户端应用程序与它们进行通信。

109、这种说明通常包含在称为 Web 服务说明语言 (WSDL) 文档的 XML 文档中。

110、 * XML Web Service 已经过注册，以便潜在用户能够轻易地找到这些服务，这是通过通用发现、说明和集成 (UDDI) 来完成的。

111、 本文将介绍这三种技术，但首先需要解释一下为什么要关注 XML Web Service。

112、XML Web Service 体系结构的主要优点之一是、允许在不同平台上、以不同语言编写的各种程序以基于标准的方式相互通信。

113、对这一行业有所了解的用户可能马上会说、“等一等， CORBA 和之前的 DCE 不是都做过相同的承诺吗？这和它们有什么区别？”最重要的区别在于、SOAP 比以前的方法要简单得多，因此要实现与标准兼容的 SOAP，障碍也要少得多。

114、Paul Kulchenko 在 http、//www.soapware.org/directory/4/implementations(英文)上提供了一个 SOAP 实现方案的列表。

115、上次统计时，该列表已经包含了 79 项。

116、正如您所预料，多数大的软件公司都提供 SOAP 实现方案，但也有许多实现方案是由个别开发人员创建和维护的。

117、相对以前的方案而言，XML Web Service 的另一大优点是使用标准的 Web 协议 - XML、HTTP 和 TCP/IP。

118、许多公司都已经建立了 Web 基础结构，同时它们的员工在维护方面也都具备相应的知识和经验。

119、因此，引入 XML Web Service 与引入以前的技术相比，其成本要低得多。

120、我们将 XML Web Service 定义为、通过 SOAP 在 Web 上提供的软件服务，使用 WSDL 文件进行说明，并通过 UDDI 进行注册。

121、那么，您也许要问、“使用 XML Web Service 能够做什么？”最初的 XML Web Service 通常是可以方便地并入应用程序的信息来源，如股票价格、天气预报、体育成绩等等。

122、我们很容易想到，可以构建一整类应用程序以分析和汇总所关心的信息，并以各种方式提供这些信息。

123、例如，您可以使用 Microsoft® Excel 电子表格来汇总所有的财务信息 - 股票、401K、银行存款、贷款等等。

124、如果能够通过 XML Web Service 获得这些信息，Excel 就可以不断对其进行更新。

125、这些信息中有些是免费的，有些则可能需要订阅才能获得相应服务。

126、大部分这种信息现在已经可以在 Web 上找到了，但是 XML Web Service 可以使编程访问更简单，也更可靠。

127、以 XML Web Service 方式提供现有应用程序，可以构建新的、更强大的应用程序，并利用 XML Web Service 作为构造块。

128、例如，用户可以开发一个采购应用程序，以自动获取来自不同供应商的价格信息，从而使用户可以选择供应商，提交订单，然后跟踪货物的运输，直至收到货物。

129、而供应商的应用程序除了在 Web 上提供服务外，还可以使用 XML Web Service 检查客户的信用、收取货款，并与货运公司办理货运手续。

130、将来，某些最有趣的 XML Web Service 所支持的应用程序还可以利用 Web 完成目前无法完成的任务。

131、例如，日历服务就是 Microsoft .NET My Services(英文)项目即将支持的服务之一。

132、如果您的牙医和机械师通过这一 XML Web Service 提供其日程安排，您就可以通过网络与他们安排约会。

133、如果您愿意，他们也可以直接在您的日历上约定清洁和日常保养的日期。

134、不难想象，只要能够对 Web 进行编程，您就可以创建数以百计的应用程序。

135、有关 XML Web Service 及其可以构建的应用程序的详细信息，请参阅 MSDN Web 服务(英文)主页。

136、。

137、WSDLWSDL (Web Services Description Language) 表示 Web 服务说明语言。

138、在本文中，我们可以认为 WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。

139、换句话说，WSDL 对于 SOAP 的作用就象 IDL 对于 CORBA 或 COM 的作用。

140、由于 WSDL 是 XML 文档，因此很容易进行阅读和编辑。

141、但大多数情况下，它由软件生成和使用。

142、要查看 WSDL 的值，可以假设您要调用由您的一位业务伙伴提供的 SOAP 方法。

143、您可以要求对方提供一些 SOAP 消息示例，然后编写您的应用程序以生成并使用与示例类似的消息，但这样很容易出错。

144、例如，您可能看到一个 2837 的客户 ID，并假设它为整数，而实际上它是一个字符串。

145、WSDL 通过明确的表示法指定请求消息必须包含的内容以及响应消息的样式。

146、WSDL 文件用于说明消息格式的表示法以 XML 架构标准为基础，这意味着它与编程语言无关，而且以标准为基础，因此适用于说明可从不同平台、以不同编程语言访问的 XML Web Service 接口。

147、除说明消息内容外，WSDL 还定义了服务的位置，以及使用什么通信协议与服务进行通信。

148、也就是说，WSDL 文件定义了编写使用 XML Web Service 的程序所需的全部内容。

149、有几种工具可以读取 WSDL 文件，并生成与 XML Web Service 通信所需的代码。

150、其中一些最强大的工具可在 Microsoft Visual Studio® .NET 中找到。

151、当前，许多 SOAP 工具包都包括从现有程序接口生成 WSDL 文件的工具，但却几乎没有直接用于编写 WSDL 的工具，而且 WSDL 的工具支持也很不完整。

152、但不久就会出现编写 WSDL 文件的工具，接着还会有生成代理和存根的工具(与 COM IDL 工具很相似)，这些工具将成为多数 SOAP 实现方案的一部分。

153、到那时，WSDL 将成为创建 XML Web Service 的 SOAP 接口的首选方法。

154、这里有一个非常好的 WSDL 说明(英文)，您还可以在 http、//www.worg/TR/wsdl(英文)找到 WSDL 规范。

155、。

1、定义WebServices是自包含的、模块化的应用程序，它可以在族蚂网络(通常为Web)中被描述、发布、查找以及调用。

1、当前，WebService是一个热门话题。

2、但是，WebService究竟是什么？什么情况下应该用WebService？什么情况下不应该用WebService？是需要我们正确认识的。

3、WebServices是由企业发布的完成其特定商务需求的在线应用服务,其他公司或应用软件能够通过Internet来访问并使用这项在线服务,它是一种构建应用程序的普遍模型,可以在任何支持网络通信的操作系统中实施运行它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。

4、WebService是一个应用组件,它逻辑性的为其他应用程序提供数据与服务.各应用程序通过网络协议和规定的一些标准数据格式(Http，XML，Soap)来访问WebService,通过WebService内部执行得到所需结果.WebService可以执行从简单的请求到复杂商务处理的任何功能。

5、一旦部署以后，其他WebService应用程序可以发现并调用它部署的服务。

6、在构建和使用WebService时,主要用到以下几个关键的技术和规则、XML、描述数据的标准方法.SOAP、表示信息交换的协议.WSDL、Web服务描述语言.UDDI、找到服务驱动器的的方法实际上，WebService的主要目标是跨平台的可互操作性。

7、为了达到这一目标，WebService完全基于XML(可扩展标记语言)、XSD(XMLSchema)等独立于平台、独立于软件供应商的标准，是创建可互操作的、分布式应用程序的新平台。

8、由此可以看出，在以下三种情况下，使用WebService会带来极大的好处。

9、长项跨防火墙的通信如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。

10、因为客户端和服务器之间通常会有防火墙或者代理服务器。

11、在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。

12、传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。

13、这样做的结果是开发难度大，程序很难维护。

14、举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把"结果页"送回浏览器。

15、要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。

16、如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。

17、要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。

18、不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。

19、同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的"结果页"。

20、从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可以节省花在用户界面编程上20%的开发时间。

21、另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。

22、最后，通过WebService把应用程序的逻辑和数据"暴露"出来，还可以让其它平台上的客户重用这些应用程序。

23、长项应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。

24、应用程序经常需要从运行在IBM主机上的程序中获取数据。

25、或者把数据发送到主机或UNIX应用程序中去。

26、即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。

27、通过WebService，应用程序可以用标准的方法把功能和数据"暴露"出来，供其它应用程序使用。

28、例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容。

29、还有一个订单执行程序，用于实际货物发送的管理。

30、这两个程序来自不同软件厂商。

31、一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。

32、通过在订单执行程序上面增加一层WebService，订单执行程序可以把"AddOrder"函数"暴露"出来。

33、这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。

34、长项B2B的集成用WebService集成应用程序，可以使公司内部的商务处理更加自动化。

35、但当交易跨越供应商和客户、突破公司的界限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。

36、WebService是B2B集成成功的关键。

37、通过WebService，公司可以把关键的商务应用"暴露"给指定的供应商和客户。

38、例如，把电子下单系统和电子发票系统"暴露"出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。

39、当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。

40、但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。

41、不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。

42、WebService只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。

43、用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。

44、只要把商务逻辑"暴露"出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。

45、这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。

46、长项软件和数据重用软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。

47、最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。

48、当前，像表格控件或用户界面控件这样的可重用软件组件，在市场上都占有很大的份额。

49、但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。

50、原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。

51、WebService在允许重用代码的同时，可以重用代码背后的数据。

52、使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件。

53、只需要直接调用远端的WebService就可以了。

54、举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息，确认这个地址是否在相应的邮政编码区域。

55、WebService的提供商可以按时间或使用次数来对这项服务进行收费。

56、这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。

57、另一种软件重用的情况是，把好几个应用程序的功能集成起来。

58、例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。

59、现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。

60、一旦他们把这些功能都通过WebService"暴露"出来，就可以非常容易地把所有这些功能都集成到你的门户站点中，为用户提供一个统一的、友好的界面。

61、将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。

62、两种情况下，都可以重用代码和代码背后的数据。

63、从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。

64、不过，也有一些情况，WebService根本不能带来任何好处。

65、短处单机应用程序目前，企业和个人还使用着很多桌面应用程序。

66、其中一些只需要与本机上的其它程序通信。

67、在这种情况下，最好就不要用WebService，只要用本地的API就可以了。

68、COM非常适合于在这种情况下工作，因为它既小又快。

69、运行在同一台服务器上的服务器软件也是这样。

70、最好直接用COM或其它本地的API来进行应用程序间的调用。

71、当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。

72、短处局域网的同构应用程序在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。

73、例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。

74、在这些程序里，使用DCOM会比SOAP/HTTP有效得多。

75、与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。

76、有趣的是，在.NETremoting中，也可以指定使用SOAP/HTTP来进行WebService调用。

77、不过最好还是直接通过TCP进行RPC调用，那样会有效得多。

78、总之，只要从应用程序结构的角度看，有别的方法比WebService更有效、更可行，那就不要用WebService。

版权声明：本文由用户上传，如有侵权请联系删除！