WebService技术及其应用技术.doc

《WebService技术及其应用技术.doc》由会员分享，可在线阅读，更多相关《WebService技术及其应用技术.doc（45页珍藏版）》请在三一办公上搜索。

1、WebService技术浅析及其实际应用The Technical Analysis and practical application of Web Service 摘 要随着电子商务技术的快速发展，原来那种基于特定系统和特定环境的开发方式逐渐无法适应新的需求变化。WebService技术的出现，给异构系统间的商务应用集成带来了前所未有的希望。本文主要介绍了WebService技术和WebService技术在实际应用中的一个例子。WebService技术是通过构筑一个通用的、与平台和语言无关的技术层，使得各种不同平台上的应用系统间，实施彼此的连接和集成。本文首先对WebService技术进行

2、了简介，在了解它的使用情况和优缺点后，对它和目前现有分布式CORBA技术进行了分析和对比，进而对它的体系结构有深入的了解。其次介绍了WebService技术中的关键技术，其中包括可扩展性标记语言（XML）、简单对象访问协议（SOAP）、Web服务描述语言（WSDL）和统一描述、发现与集成（UDDI）注册中心。最后本文依据WebServices的技术原理、体系架构及关键技术，提出了一个WebServices技术在旅游系统中的应用。关键词：WebService技术；CORBA技术；XML；SOAP；WSDL；UDDI协议AbstractWith the rapid development of e

3、-commerce technology, those original developing methods which are based on specific system and environment are unable to adapt to the newly changing requirements. The Web service technology brings the unprecedented prospect to the business application integration of the heterogeneous system.This art

4、icle introduces the concept of Web service, and brings out an example in a particle application. Web Service technology implements a mutual connection and integration between the application systems in variety platforms through building an all-purpose technology layer which is unrelated to any platf

5、orms and languages. We firstly briefs the Web service technology , then makes an comparison and analysis between the Web Service and the distributed CORBA after knowing its usage condition and its advantages and disadvantages ,and then form a deeper understanding to its architecture. Secondly, the k

6、ey technologies in Web service are introduced, including Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), WebServices Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI) registry. Finally, a tourism system application based on the technical

7、principles, systematic architecture and key technologies of Web service is brought forward in this article.Keywords: WebService technology。 CORBAtechnology。 XML。 SOAP。 WSDL。 UDDI protocol目 录第一章引言11.1 选题的背景和意义11.2 选题的研究现状11.3 选题要研究的主要内容1第二章 WebService技术的简介22.1 WebService技术的出现22.2 WebService技术概述32.3 W

8、ebService技术的体系结构32.4 WebService技术的工作流程52.5 WebService技术的优缺点52.5.1 WebService技术的优点52.5.2 WebService技术的缺点8第三章 WebService技术与CORBA技术93.1 CORBA技术的简介93.2 WebService技术和CORBA技术10第四章 WebService技术中的关键技术124.1 XML124.1.1 简介124.1.2 XML和HTML的差异124.2 SOAP134.3 WSDL和UDDI规范144.3.1 WSDL144.3.2 UDDI15第五章 WebService技术在

9、旅游信息系统中的应用185.1 方案论证185.1.1 旅游信息系统的结构185.1.2 系统功能方案185.2 系统功能方案215.2.1 系统的体系结构215.2.2 电子地图功能与实现225.2.3 地图查询功能与实现255.2.4 信息发布功能与实现305.2.5 电子商务功能315.3 系统总结32第六章结束语33致谢34参考文献35附件36第一章引 言1.1 选题的背景和意义不断发展的计算机技术使得传媒业发生了巨大的变化，并得以普及。World Wide Web、Java技术以及XML似乎无处不在，这些技术均得以快速应用，而且已成为企业级计算机的主要技术。Web服务最早出现在199

10、9年，也是不断发展的技术。Web服务是随着传媒业的巨大扩张而出现的，这项技术已经得到商务活动的认可，并且开始被大量的开发人员采纳。随着时间的推移，WebService技术也越来越完善，并且渗透于人们生活的方方面面。1.2 选题的研究现状关于WebService技术已经有不少文献进行了讨论，在有些文献中主要描述了WebService技术的前瞻性，其他一些则把重点描述了WebService技术在生活、军事、气象、医疗等实际应用前景。对于初涉WebService技术的人们来说这些都比较抽象且不易理解，本文在以上基础上对WebServices技术的研究现状、WebServices应用的关键技术和Web

11、Services技术与CORBA技术的比较这三个方面做出了详细的介绍，可以加深人们对WebServices技术的理解。1.3 选题要研究的主要内容本文对WebServices所涉及的相关技术进行了剖析，并在此基础上给出了一个WebServices技术的应用实例，主要对以下方面进行了论述：1. WebServices技术的出现。2. WebServices技术的基本概念。3. WebServices技术与CORBA技术的比较。4. WebServices技术中的关键技术。5. WebService技术在旅游信息系统中的应用。第二章 WebService技术的简介2.1 WebService技术的

12、出现1999年，惠普公司成为第一个引入Web服务概念的软件厂家。惠普公司的eSpeak平台使开发人员可以建立与实现电子Web服务，这是与Web服务相似的程序单元。但是，eSpeak的基础技术具有专业性质，从而使这个平台没有得到广泛的行业支持。2000年6月，微软公司正式提出了Web服务的概念，把Web服务作为.NET工程的关键组件，这个工程用的是全新的方法在开发、构建与使用软件，能够牢牢掌握Internet。微软公司声称将整个公司的命运都压在Web服务上，使Web服务几乎立即成为“下一件大事”。现在几乎每个主要软件厂家都在推出Web服务工具和应用程序。随着Web服务的发布，许多人认识到这个技术

13、可能对分布式计算机带来革命。过去，CORBA与DCOM都已经提交到标准组织，让公司可以选择其中一个标准作为通用分布式计算的标准。但这种情况并没有发生，因为公司已经在Windows或Java平台上投入大量资金，使用了相应的分布式技术，移植到平台会需要大量业务时间，经费和员工生产率。行业对相互操作性问题的经验导致了WebService技术开放标准的开发，努力实现跨平台通信。Web服务使用的主要标准是XML，这是个数据标记语言，使用程序和平台之间可以交换信息。微软与DevelopMentor公司建立简单对象访问协议（SOAP Simple Object Access Protocol）作为Web服务

14、之间传输信息与指令的消息协议，用XML作为基础协议。另外两个Web服务规范是Web服务描述语言（WSDL WebServices Description Language）和统一描述、发现与集成（UDDI UniversalDescription Discovery and Integration），也用XML作为基础协议。WSDL提供了描述Web服务及其特定功能的标准方法，UDDI定义建立目录XML规则，公司可以用这个目录对本身及其Web服务进行公告。尽管Web服务还没有充分发挥所有潜力，但已经对业务通信带来了变革。在教案、制造、财务服务与旅游等等行业中得以广泛的使用11。2.2WebSer

15、vice技术概述WebService它不是一种框架，而是一种技术。WebServices是由企业发布的完成其特定商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项在线服务，它是一种构建应用程序的普遍模型，可以在任何支持网络通信的操作系统中实施运行；它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。WebService是一个应用组件，它逻辑性的为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式（HTTP，XML，SOAP)来访问WebService，通过WebService内部执行得到所需结果

16、。WebService可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他WebService应用程序可以发现并调用它部署的服务。官方的解释就是：WebService主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。WebServices技术可以理解为：各个站点之间互相调用方法实现功能，不受操作系统，编程语言等等的限制，比如：工行的网上银行系统是使用java编写的，中行的网上银行系统是使用.net编写的，可是他们各自提供转账的对外接口，实现跨语言、平台的信息交互。在工行的提款机上可以使用中行的卡取钱，它其实是调用了人家中行的系统的方法和中行的数据库交互，中行

17、的数据库是不允许工行的程序去访问的。2.3 WebService技术的体系结构Web服务的一个主要思想，就是未来的应用将由一组应用了网络的服务组合而成。只要两个等同的服务使用统一标准和中性的方法在网络上宣传自己，那么从理论上说，一个应用程序就可以根据价格或者性能的标准，从两个彼此竞争的服务之中选出一个。除此之外，一些服务允许在机器之间复制，因而可以通过把有用的服务复制到本地储存库，来提高允许运行在特定的计算机（群）上的应用程序的性能。WebServices体系结构是面向对象分析与设计（OOAD）的一种合理发展（logical evolution），同时也是电子商务解决方案中，面向体系结构、设计

18、、实现与部署而采用的组件化的合理发展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。这两种方式在复杂的大型系统中经受住了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也是WebServices中的基本概念，而且，WebServices另外一个基本概念就是：所有东西都是服务，这些服务发布一个API供网络中的其他服务使用，并且封装了实现细节。下面就来看一下WebServ

19、ices的体系结构-面向服务的体系结构（SOA）。图 2-1面向服务的体系结构（SOA）从图2-1可以看出，SOA结构中共有三种角色：Service provider：发布自己的服务，并且对使用自身服务的请求进行响应。Service broker：注册已经发布的Service provider，对其进行分类，并提供搜索服务。Service requester：利用Service broker查找所需的服务，然后使用该服务。SOA体系结构中的组件必须具有上述一种或多种角色。在这些角色之间使用了三种操作：publish操作：使Service provider可以向Service broker注册自

20、己的功能及访问接口。find操作：使Service requester可以通过Service broker查找特定种类的服务。bind操作：使Service requester能够真正使用Service provider。为支持结构中的三种操作（publish、find和bind），SOA需要对服务进行一定的描述，这种服务描述（Service Description）应具有下面几个重要特点：首先，它要声明Service provider的语义特征。Service broker使用语义特征将Service provider进行分类，以帮助具体服务的查找。Service requester根据语义

21、特征来匹配那些满足要求的Service provider。（因此，语义特征中重要的一点就是对Service provider的分类）其次，服务描述应该声明接口特征，以访问特定的服务。最后，服务描述还应声明各种非功能特征，如安全要求，事务要求，使用Service provider的费用等等。接口特征和非功能特征也可以用来帮助Service requester对Service provider的查找。注意，服务描述和服务实现是分离的，这使得Service requester可以在Service provider的一个具体实现（implementation）正处于开发阶段、部署阶段或完成（execu

22、tion）阶段时，对其（具体实现）进行绑定。另外，SOA中的组件相互之间必须能够进行交互，才能进行上述三种操作。所以WebServices体系结构的另一个基本原则就是使用标准的技术，包括服务描述、通讯协议以及数据格式等。这样一来，开发者就可以开发出平台独立、编程语言独立的WebServices，从而能够充分利用现有的软硬件资源和人力资源。最后，SOA体系结构没有对WebService的粒度进行限制，因此一个WebService即可以是一个组件（小粒度），该组件必须和其他组件结合才能进行完整的业务处理；WebService也可以是一个应用程序（大粒度）5。2.4 WebService技术的工作流

23、程在使用WebService时，包括三个阶段的通信。第一阶段的通信被称为发现阶段(Discover)，其主要作用是确定在服务器上有哪些服务。经过发现阶段我们一般可以确定服务器一共提供了哪些服务，在使用这些服务之前我们还必须知道这些服务支持什么样的界面。第二阶段的通信就是发送请求获得WebService描述语言WSDL。 第三阶段的通信主要是向WebService服务器发送信息服务请求，并等待服务器的应答。2.5 WebService技术的优缺点2.5.1WebService技术的优点在以下四种情况下，使用WebService会带来极大的好处。长项一：跨防火墙的通信如果应用程序有成千上万的用户，

24、而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用DCOM就不是那么简单，通常也不便于把客户端程序发布到数量如此庞大的每一个用户手中。传统的做法是，选择用浏览器作为客户端，写下一大堆ASP页面，把应用程序的中间层暴露给最终用户。这样做的结果是开发难度大，程序很难维护。举个例子，在应用程序里加入一个新页面，必须先建立好用户界面(Web页面)，并在这个页面后面，包含相应商业逻辑的中间层组件，还要再建立至少一个ASP页面，用来接受用户输入的信息，调用中间层组件，把结果格式化为HTML形式，最后还要把“结果页”送回

25、浏览器。要是客户端代码不再如此依赖于HTML表单，客户端的编程就简单多了。如果中间层组件换成WebService的话，就可以从用户界面直接调用中间层组件，从而省掉建立ASP页面的那一步。要调用WebService，可以直接使用MicrosoftSOAPToolkit或.NET这样的SOAP客户端，也可以使用自己开发的SOAP客户端，然后把它和应用程序连接起来。不仅缩短了开发周期，还减少了代码复杂度，并能够增强应用程序的可维护性。同时，应用程序也不再需要在每次调用中间层组件时，都跳转到相应的“结果页”。从经验来看，在一个用户界面和中间层有较多交互的应用程序中，使用WebService这种结构，可

26、以节省花在用户界面编程上20%的开发时间。另外，这样一个由WebService组成的中间层，完全可以在应用程序集成或其它场合下重用。最后，通过WebService把应用程序的逻辑和数据“暴露”出来，还可以让其它平台上的客户重用这些应用程序。长项二：应用程序集成企业级的应用程序开发者都知道，企业里经常都要把用不同语言写成的、在不同平台上运行的各种程序集成起来，而这种集成将花费很大的开发力量。应用程序经常需要从运行在IBM主机上的程序中获取数据；或者把数据发送到主机或UNIX应用程序中去。即使在同一个平台上，不同软件厂商生产的各种软件也常常需要集成起来。通过WebService，应用程序可以用标准

27、的方法把功能和数据“暴露”出来，供其它应用程序使用。例如，有一个订单登录程序，用于登录从客户来的新订单，包括客户信息、发货地址、数量、价格和付款方式等内容；还有一个订单执行程序，用于实际货物发送的管理。这两个程序来自不同软件厂商。一份新订单进来之后，订单登录程序需要通知订单执行程序发送货物。通过在订单执行程序上面增加一层WebService，订单执行程序可以把“AddOrder”函数“暴露”出来。这样，每当有新订单到来时，订单登录程序就可以调用这个函数来发送货物了。长项三：B2B的集成用WebService集成应用程序，可以使公司内部的商务处理更加自动化。但当交易跨越供应商和客户、突破公司的界

28、限时会怎么样呢？跨公司的商务交易集成通常叫做B2B集成。WebService是B2B集成成功的关键。通过WebService，公司可以把关键的商务应用“暴露”给指定的供应商和客户。例如，把电子下单系统和电子发票系统“暴露”出来，客户就可以以电子的方式发送订单，供应商则可以以电子的方式发送原料采购发票。当然，这并不是一个新的概念，EDI(电子文档交换)早就是这样了。但是，WebService的实现要比EDI简单得多，而且WebService运行在Internet上，在世界任何地方都可轻易实现，其运行成本就相对较低。不过，WebService并不像EDI那样，是文档交换或B2B集成的完整解决方案。

29、WebService只是B2B集成的一个关键部分，还需要许多其它的部分才能实现集成。用WebService来实现B2B集成的最大好处在于可以轻易实现互操作性。只要把商务逻辑“暴露”出来，成为WebService，就可以让任何指定的合作伙伴调用这些商务逻辑，而不管他们的系统在什么平台上运行，使用什么开发语言。这样就大大减少了花在B2B集成上的时间和成本，让许多原本无法承受EDI的中小企业也能实现B2B集成。长项四：软件和数据重用软件重用是一个很大的主题，重用的形式很多，重用的程度有大有小。最基本的形式是源代码模块或者类一级的重用，另一种形式是二进制形式的组件重用。当前，像表格控件或用户界面控件这

30、样的可重用软件组件，在市场上都占有很大的份额。但这类软件的重用有一个很大的限制，就是重用仅限于代码，数据不能重用。原因在于，发布组件甚至源代码都比较容易，但要发布数据就没那么容易，除非是不会经常变化的静态数据。WebService在允许重用代码的同时，可以重用代码背后的数据。使用WebService，再也不必像以前那样，要先从第三方购买、安装软件组件，再从应用程序中调用这些组件；只需要直接调用远端的WebService就可以了。举个例子，要在应用程序中确认用户输入的地址，只需把这个地址直接发送给相应的WebService，这个WebService就会帮你查阅街道地址、城市、省区和邮政编码等信息

31、，确认这个地址是否在相应的邮政编码区域。WebService的提供商可以按时间或使用次数来对这项服务进行收费。这样的服务要通过组件重用来实现是不可能的，那样的话你必须下载并安装好包含街道地址、城市、省区和邮政编码等信息的数据库，而且这个数据库还是不能实时更新的。另一种软件重用的情况是，把好几个应用程序的功能集成起来。例如，要建立一个局域网上的门户站点应用，让用户既可以查询联邦快递包裹，查看股市行情，又可以管理自己的日程安排，还可以在线购买电影票。现在Web上有很多应用程序供应商，都在其应用中实现了这些功能。一旦他们把这些功能都通过WebService“暴露”出来，就可以非常容易地把所有这些功能

32、都集成到你的门户站点中，为用户提供一个统一的、友好的界面。将来，许多应用程序都会利用WebService，把当前基于组件的应用程序结构扩展为组件/WebService的混合结构，可以在应用程序中使用第三方的WebService提供的功能，也可以把自己的应用程序功能通过WebService提供给别人。两种情况下，都可以重用代码和代码背后的数据。2.5.2WebService技术的缺点从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，WebService不能带来任何好处。短处一：单机应用程序目前，企业和个人还使用着很多桌面应用程序。其中一

33、些只需要与本机上的其它程序通信。在这种情况下，最好就不要用WebService，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。短处二：局域网的同构应用程序在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在

34、这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。有趣的是，在.NET Remoting中，也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，应当从具体应用环境出发，选择最适当的解决方案。第三章 WebService技术与CORBA技术CORBA是20世纪90年代由OMG提出的分布式对象计算规范，经过十几年的的发展，已经在很多关键业务处理中得到了广泛的应用。CORBA和WebService都是实现分布式技术的

35、技术框架，在体系结构、组成、技术实现甚至研究方法上都有可比之处，因此，将CORBA和WebService进行比较，借鉴CORBA研究和应用中的成果，是发展和完善WebService技术的一种途径。3.1 CORBA技术的简介CORBA实现了分布异构环境中对象之间的透明请求调用，应用程序无需考虑底层硬件平台、操作系统、通信协议等细节，保证了分布式应用的互操作性，其体系结构如图3-1所示。ORB核心（GIOPIIOP）动态调用IDL存根ORB界面静态IDL框架动态框架调用对象适配器客 户服 务 器图 3-1 CORBA组成部分对象请求代理ORB负责接收客户端的请求，并传递到目标对象，将执行结果返回

36、给客户程序。ORB是CORBA的核心，使应用程序无需关心目标对象的物理位置、实现和现行状态等。CORBA使用OMG IDL定义了对象接口，并通过语言映射技术翻译成对应的编程语言，生成客户端的存根和服务端的框架。存根将请求进行封装以及对响应进行解封装；框架则在服务端完成互补的类似工作。客户端程序通过IDL存根发起对远程对象的请求、请求到达服务端的对象适配器。对象适配器负责对象登记、定位、激活和撤销等，它将请求调度到适合的对象实现，并将执行结果返回给客户。3.2 WebService技术和CORBA技术CORBA和WebService的共同点在于，它们都提供了一中分布计算领域的技术框架，因而都对分

37、布式应用面临的问题提出了解决方法。分布式应用最基本的要求是应用能够跨平台调用，而CORBA和WebService都能够屏蔽底层平台的差异，使应用程序与操作系统、通信协议无关，简化了分布式应用的开发。分布式应用请求模式客户端调用服务端的功能，这使二者都在体系结构上有一个对方的概念。因为客户端要调用服务端，要求客户端对服务端有一定理解，因此，二者都采用了某种语言来描述服务方的接口。客户端和服务端的分离，使客户端在请求服务的时候，总需要一定方式来标识服务方。如果客户端不知道服务方的标识，它就需要某种方式来查找所需的服务。CORBA和WebService都通过唯一标识来识别服务方，并且都提供了服务的查

38、找手段。应用在进行关键业务处理时，要求操作的可靠性、安全性和服务质量，而CORBA和WebService中都制订了对应的规范来满足这些要求。表 3-1 WebService和CORBA对比工程WebServiceCORBA问题域Internet企业计算环境基本模型面向服务面向对象耦合性松散耦合紧密耦合数据描述XML格式文档二进制接口描述语言WSDLIDL传输协议SOAP（HTTP,SMTP）等HOP,GIOP位置表示URLIOR防火墙穿越容易难查找UDDI名字服务，交易服务安全性研究中安全服务事务处理研究中对象事物服务灵活的通信机制研究中事件、通知服务从表中可以看到，WebServices与C

39、ORBA最根本的差异在与出发点不同。CORBA是20世纪90年代提出来的，主要是针对企业环境中业务处理所面临的问题。面向对象是实际应用中证明非常有效的设计和开放模式，因此CORBA采用了面向对象的计算模式（这也决定了服务位置标示采用对象引用的方式）；并且在企业环境中，业务联系比较紧密，体现在处理业务的应用程序之间也是紧密耦合的，因此其数据描述也采用了二进制方式。企业环境中关系可能很复杂，这要求非常灵活的通信机制，因此CORBA提供了事件、通知等多种方式。WebServices是伴随着Internet的飞速发展而出现的。Internet中主要应用是基于Web服务的应用，因此WebServices

40、采用了面向服务的模型。在广阔的Internet上，业务之间的关系本身比企业内的应用简单，这可以从早期的Web应用主要是无状态的请求/应答模式看到，因此，WebServices中，请求方和服务之间也没有始终保持的链接通道，是非常松散的耦合关系。为了保证松散耦合应用程序能够互相理解，具有自描述性的XML成了WebServices的数据描述方式，这也使WebServices具有可扩展性好、易于集成的优点。在Internet上，URL成为WebServices标示目标服务自然的选择。从上述分析可知，WebServices环境中，请求方和服务方是松散的耦合，请求以XML文档的形式进行传输，接口的细微变化

41、不会影响程序的正常执行，具有更好的课扩展性；而CORBA环境中对象请求采用二进制传输，请求方和服务方是紧密耦合的，服务端接口一旦发生变化，客户端就必须作相应修改，否则就可能崩溃。CORBA采用IIOP进行传输，端口是动态分配的，请求很可能被防火墙拒绝；而WebServices主要基于HTTP，很容易穿越防火墙。在WebServices中，业务处理在Intenet上进行，这使参与者的信息更容易被窃听和非法访问，因此安全性要求更高。WebServices一个明显的劣势在于性能。XML文档比同等信息量的CDR数据耗费更多内存，也增加了网络流量和传输时间，XML文档的解读和转换比CDR数据的编解码需要

42、更多内容和处理时间。因此，一般来讲，面向Internet的业务处理选择WebService技术框架较为适宜。在企业环境中，如果业务之间关系紧密，或者对性能要求较高，CORBA等分布式对象模式更合适，如果业务关系较为松散，更关注开放性，则WebService是更佳选择。第四章WebService技术中的关键技术WebService涉及的最基本的技术规范包括XML、SOAP、WSDL和UDDI。WSDL是程序员描述WebService的编程接口。WebService可以通过UDDI来注册自己的特性，其他应用程序可以通过UDDI找到Web服务。SOAP则可提供了应用程序和Web服务之间的通信手段。而

43、WSDL、SOAP、和UDDI都是建立在XML基础之上。4.1 XML4.1.1简介为了实现异构系统(不同的平台、编程语言和组件模型等)之间的互操作性，需提供一套标准通用的数据语言。可扩展标记语言(XML Extensible Markup Language)已经成为Internet的通用语言。在WebServices平台中，采用XML表示数据的基本格式。XML能创建不依赖于平台、编程语言的开放数据，具有平台无关性。作为一个服务平台，WebServices必须提供一种标准的数据类型系统，用于沟通不同系统之间的不同类型。万维网联盟(W3C)制定的XML Schema(XSL)定义了一套标准的数据

44、类型来扩展这套数据类型。WebServices平台采用XSD(XML Schema Definition)作为其数据类型系统。无论使用哪种语言构造WebServices，最终都将被转换为XSD类型。在实际应用中，开发工具一般会帮助开发者完成这一转换过程。4.1.2XML和HTML的差异XML和HTML的不同可以归纳为三点：1. XML扩展性优于HTMLXML（Extensible Markup Languages）是扩展标记语言的英语缩写，他可以创建个性化的标记语言，可以称之为元语言。XML的标记语言可以自定义，这样可以提供更多的数据操作，而不像HTML一样，只能局限于按一定的格式在终端显示出

45、来。HTML的功能只有浏览器放入显示和打印，仅仅适合静态网页的要求。2. XML的语法比HTML严格由于XML的扩展性强，它需要稳定的基础规则来支持扩展。它的严格规则为：起始和结束的标签相匹配嵌套标签不能相互嵌套区分大小写相对应XML的严格规则，HTML语言并没有规定标签的绝对位置，也不区分大小写，而这些全部由浏览器来完成识别和更正。3. XML与HTML互补XML可以获得应用之间的相应信息，提供终端的多项处理要求，也能被其他的解读器和工具所使用，在现阶段，XML可以转化成相应的HTML，来适应当前浏览器的需求。4.2 SOAP简单对象访问协议（SOAP Simple Object Acces

46、s Protocol）是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。SOAP可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。SOAP包括三个部分： SOAP的封装：它定义了一个框架，该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。 SOAP的编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。 SOAP的RPC表示：它定义了用于表示远程过程调用和应答的协定。

47、SOAP协议的消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的SOAP消息都使用XML编码。一条SOAP消息就是一个包含有一个必需的SOAP的封装包，一个可选的SOAP标头和一个必需的SOAP体块的XML文档。把SOAP绑定到HTTP提供了同时利用SOAP的样式和分散的灵活性的特点以及HTTP的丰富的特征库的优点。在HTTP上传送SOAP并不是说SOAP会覆盖现有的HTTP语义，而是HTTP上的SOAP语义会自然的映射到HTTP语义。在使用HTTP作为协议绑定的场合中，RPC请求映射到HTTP请求上，而RPC应答映射到HTTP应答。然而，在RPC上使

48、用SOAP并不仅限于HTTP协议绑定。SOAP也可以绑定到TCP和UDP协议上。性能：SOAP用XML将消息编码，因此在调用过程的任何一步都极易处理消息。另外，调试SOAP消息的方便性使各种SOAP执行能快速聚合在一起，这点很重要因为SOAP就是要达到大范围的协同工作。（CORBA、DCOM和RMI对参数和返回值使用二进制编码。除此之外，他们假设发送端和接收端充分了解消息的前后关系，因此对诸如参数名称或类型的任何元信息都不编码。这种方法产生了良好的性能，但使中介很难处理消息。因为每个系统使用不同的二进制编码，所以建立互操作的系统很难）。表面看来，基于XML的模式本应比基于二进制的慢，但它并不像表面那么简单。首先，当SOAP被用于通过因特网发送消息时，在每个端点给消息编码/解码的时间与在端点间传输字节的时间相比较是微不足道的，所以这种情况下使用XML没太大