毕业论文Webservice技术浅析.doc

南昌航空大学科技学院web设计论文 指导教师：张洁 班级：1082061 学号：29 姓名：袁羽 WebService技术浅谈摘要随着电子商务技术的快速发展，原来那种基于特定系统和特定环境的开发方式逐渐无法适应新的需求变化。WebService技术的出现，给异构系统间的商务应用集成带来了前所未有的希望。WebService技术是通过构筑一个通用的、与平台和语言无关的技术层，使得各种不同平台上的应用系统间，实施彼此的连接和集成。本文首先对WebService技术进行了简介，在了解它的使用情况和优缺点后，对它和目前现有分布式CORBA技术进行了分析和对比，进而对它的体系结构有深入的了解。其次介绍了WebService技术中的关键技术，其中包括可扩展性标记语言（XML）、简单对象访问协议（SOAP）、Web服务描述语言（WSDL）和统一描述、发现与集成（UDDI）注册中心。最后本文依据WebServices的技术原理、体系架构及关键技术，提出了一个WebServices技术在旅游系统中的应用。关键词： WebService技术CORBA技术XMLSOAPUDDI协议绪论不断发展的计算机技术使得传媒业发生了巨大的变化，并得以普及。World Wide Web、Java技术以及XML似乎无处不在，这些技术均得以快速应用，而且已成为企业级计算机的主要技术。Web服务最早出现在1999年，也是不断发展的技术。Web服务是随着传媒业的巨大扩张而出现的，这项技术已经得到商务活动的认可，并且开始被大量的开发人员采纳。随着时间的推移，WebService技术也越来越完善，并且渗透于人们生活的方方面面。关于WebService技术已经有不少文献进行了讨论，在有些文献中主要描述了WebService技术的前瞻性，其他一些则把重点描述了WebService技术在生活、军事、气象、医疗等实际应用前景。对于初涉WebService技术的人们来说这些都比较抽象且不易理解，本文在以上基础上对WebServices技术的研究现状、WebServices应用的关键技术和WebServices技术与CORBA技术的比较这三个方面做出了详细的介绍，可以加深人们对WebServices技术的理解。一、WebService技术的简介1.1WebService技术的出现1999年，惠普公司成为第一个引入Web服务概念的软件厂家。惠普公司的eSpeak平台使开发人员可以建立与实现电子Web服务，这是与Web服务相似的程序单元。但是，eSpeak的基础技术具有专业性质，从而使这个平台没有得到广泛的行业支持。2000年6月，微软公司正式提出了Web服务的概念，把Web服务作为.NET项目的关键组件，这个项目用的是全新的方法在开发、构建与使用软件，能够牢牢掌握Internet。微软公司声称将整个公司的命运都压在Web服务上，使Web服务几乎立即成为“下一件大事”。现在几乎每个主要软件厂家都在推出Web服务工具和应用程序。随着Web服务的发布，许多人认识到这个技术可能对分布式计算机带来革命。过去，CORBA与DCOM都已经提交到标准组织，让公司可以选择其中一个标准作为通用分布式计算的标准。但这种情况并没有发生，因为公司已经在Windows或Java平台上投入大量资金，使用了相应的分布式技术，移植到平台会需要大量业务时间，经费和员工生产率。行业对相互操作性问题的经验导致了WebService技术开放标准的开发，努力实现跨平台通信。Web服务使用的主要标准是XML，这是个数据标记语言，使用程序和平台之间可以交换信息。微软与DevelopMentor公司建立简单对象访问协议（SOAP Simple Object Access Protocol）作为Web服务之间传输信息与指令的消息协议，用XML作为基础协议。另外两个Web服务规范是Web服务描述语言（WSDL WebServices Description Language）和统一描述、发现与集成（UDDI Universal Description Discovery and Integration），也用XML作为基础协议。WSDL提供了描述Web服务及其特定功能的标准方法，UDDI定义建立目录XML规则，公司可以用这个目录对本身及其Web服务进行公告。尽管Web服务还没有充分发挥所有潜力，但已经对业务通信带来了变革。在教学、制造、财务服务与旅游等等行业中得以广泛的使用11。1.2WebService技术概述WebService它不是一种框架，而是一种技术。WebServices是由企业发布的完成其特定商务需求的在线应用服务，其他公司或应用软件能够通过Internet来访问并使用这项在线服务，它是一种构建应用程序的普遍模型，可以在任何支持网络通信的操作系统中实施运行；它是一种新的web应用程序分支，是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。WebService是一个应用组件，它逻辑性的为其他应用程序提供数据与服务。各应用程序通过网络协议和规定的一些标准数据格式（HTTP，XML，SOAP)来访问WebService，通过WebService内部执行得到所需结果。WebService可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他WebService应用程序可以发现并调用它部署的服务。官方的解释就是：WebService主要是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。WebServices技术可以理解为：各个站点之间互相调用方法实现功能，不受操作系统，编程语言等等的限制，比如：工行的网上银行系统是使用java编写的，中行的网上银行系统是使用.net编写的，可是他们各自提供转账的对外接口，实现跨语言、平台的信息交互。在工行的提款机上可以使用中行的卡取钱，它其实是调用了人家中行的系统的方法和中行的数据库交互，中行的数据库是不允许工行的程序去访问的。1.3WebService技术的体系结构Web服务的一个主要思想，就是未来的应用将由一组应用了网络的服务组合而成。只要两个等同的服务使用统一标准和中性的方法在网络上宣传自己，那么从理论上说，一个应用程序就可以根据价格或者性能的标准，从两个彼此竞争的服务之中选出一个。除此之外，一些服务允许在机器之间复制，因而可以通过把有用的服务复制到本地储存库，来提高允许运行在特定的计算机（群）上的应用程序的性能。WebServices体系结构是面向对象分析与设计（OOAD）的一种合理发展（logical evolution），同时也是电子商务解决方案中，面向体系结构、设计、实现与部署而采用的组件化的合理发展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。这两种方式在复杂的大型系统中经受住了考验。和面向对象系统一样，封装、消息传递、动态绑定、服务描述和查询也是WebServices中的基本概念，而且，WebServices另外一个基本概念就是：所有东西都是服务，这些服务发布一个API供网络中的其他服务使用，并且封装了实现细节。下面就来看一下WebServices的体系结构-面向服务的体系结构（SOA）。图 1-1 面向服务的体系结构（SOA）从图1-1可以看出，SOA结构中共有三种角色：Service provider：发布自己的服务，并且对使用自身服务的请求进行响应。Service broker：注册已经发布的Service provider，对其进行分类，并提供搜索服务。Service requester：利用Service broker查找所需的服务，然后使用该服务。SOA体系结构中的组件必须具有上述一种或多种角色。在这些角色之间使用了三种操作：publish操作：使Service provider可以向Service broker注册自己的功能及访问接口。find操作：使Service requester可以通过Service broker查找特定种类的服务。bind操作：使Service requester能够真正使用Service provider。为支持结构中的三种操作（publish、find和bind），SOA需要对服务进行一定的描述，这种服务描述（Service Description）应具有下面几个重要特点：首先，它要声明Service provider的语义特征。Service broker使用语义特征将Service provider进行分类，以帮助具体服务的查找。Service requester根据语义特征来匹配那些满足要求的Service provider。（因此，语义特征中重要的一点就是对Service provider的分类）其次，服务描述应该声明接口特征，以访问特定的服务。最后，服务描述还应声明各种非功能特征，如安全要求，事务要求，使用Service provider的费用等等。接口特征和非功能特征也可以用来帮助Service requester对Service provider的查找。注意，服务描述和服务实现是分离的，这使得Service requester可以在Service provider的一个具体实现（implementation）正处于开发阶段、部署阶段或完成（execution）阶段时，对其（具体实现）进行绑定。另外，SOA中的组件相互之间必须能够进行交互，才能进行上述三种操作。所以WebServices体系结构的另一个基本原则就是使用标准的技术，包括服务描述、通讯协议以及数据格式等。这样一来，开发者就可以开发出平台独立、编程语言独立的WebServices，从而能够充分利用现有的软硬件资源和人力资源。最后，SOA体系结构没有对WebService的粒度进行限制，因此一个WebService即可以是一个组件（小粒度），该组件必须和其他组件结合才能进行完整的业务处理；WebService也可以是一个应用程序（大粒度）5。1.4WebService技术的工作流程在使用WebService时，包括三个阶段的通信。第一阶段的通信被称为发现阶段(Discover)，其主要作用是确定在服务器上有哪些服务。经过发现阶段我们一般可以确定服务器一共提供了哪些服务，在使用这些服务之前我们还必须知道这些服务支持什么样的界面。第二阶段的通信就是发送请求获得WebService描述语言WSDL。 第三阶段的通信主要是向WebService服务器发送信息服务请求，并等待服务器的应答。1.5WebService技术的优缺点1.5.1WebService技术的优点在以下四种情况下，使用WebService会带来极大的好处。长项一：跨防火墙的通信如果应用程序有成千上万的用户，而且分布在世界各地，那么客户端和服务器之间的通信将是一个棘手的问题。因为客户端和服务器之间通常会有防火墙或者代理服务器。在这种情况下，使用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提供给别人。两种情况下，都可以重用代码和代码背后的数据。1.5.2WebService技术的缺点从以上论述可以看出，WebService在通过Web进行互操作或远程调用的时候是最有用的。不过，也有一些情况，WebService不能带来任何好处。短处一：单机应用程序目前，企业和个人还使用着很多桌面应用程序。其中一些只需要与本机上的其它程序通信。在这种情况下，最好就不要用WebService，只要用本地的API就可以了。COM非常适合于在这种情况下工作，因为它既小又快。运行在同一台服务器上的服务器软件也是这样。最好直接用COM或其它本地的API来进行应用程序间的调用。当然WebService也能用在这些场合，但那样不仅消耗太大，而且不会带来任何好处。短处二：局域网的同构应用程序在许多应用中，所有的程序都是用VB或VC开发的，都在Windows平台下使用COM，都运行在同一个局域网上。例如，有两个服务器应用程序需要相互通信，或者有一个Win32或WinForm的客户程序要连接局域网上另一个服务器的程序。在这些程序里，使用DCOM会比SOAP/HTTP有效得多。与此相类似，如果一个.NET程序要连接到局域网上的另一个.NET程序，应该使用.NETremoting。有趣的是，在.NET Remoting中，也可以指定使用SOAP/HTTP来进行WebService调用。不过最好还是直接通过TCP进行RPC调用，那样会有效得多。总之，应当从具体应用环境出发，选择最适当的解决方案。二、WebService技术与CORBA技术CORBA是20世纪90年代由OMG提出的分布式对象计算规范，经过十几年的的发展，已经在很多关键业务处理中得到了广泛的应用。CORBA和WebService都是实现分布式技术的技术框架，在体系结构、组成、技术实现甚至研究方法上都有可比之处，因此，将CORBA和WebService进行比较，借鉴CORBA研究和应用中的成果，是发展和完善WebService技术的一种途径。2.1CORBA技术的简介CORBA实现了分布异构环境中对象之间的透明请求调用，应用程序无需考虑底层硬件平台、操作系统、通信协议等细节，保证了分布式应用的互操作性，其体系结构如图2-1所示。ORB核心（GIOPIIOP）动态调用IDL存根ORB界面静态IDL框架动态框架调用对象适配器客 户服 务 器图 2-1 CORBA组成部分对象请求代理ORB负责接收客户端的请求，并传递到目标对象，将执行结果返回给客户程序。ORB是CORBA的核心，使应用程序无需关心目标对象的物理位置、实现和现行状态等。CORBA使用OMG IDL定义了对象接口，并通过语言映射技术翻译成对应的编程语言，生成客户端的存根和服务端的框架。存根将请求进行封装以及对响应进行解封装；框架则在服务端完成互补的类似工作。客户端程序通过IDL存根发起对远程对象的请求、请求到达服务端的对象适配器。对象适配器负责对象登记、定位、激活和撤销等，它将请求调度到适合的对象实现，并将执行结果返回给客户。2.2 WebService技术和CORBA技术CORBA和WebService的共同点在于，它们都提供了一中分布计算领域的技术框架，因而都对分布式应用面临的问题提出了解决方法。分布式应用最基本的要求是应用能够跨平台调用，而CORBA和WebService都能够屏蔽底层平台的差异，使应用程序与操作系统、通信协议无关，简化了分布式应用的开发。分布式应用请求模式客户端调用服务端的功能，这使二者都在体系结构上有一个对方的概念。因为客户端要调用服务端，要求客户端对服务端有一定理解，因此，二者都采用了某种语言来描述服务方的接口。客户端和服务端的分离，使客户端在请求服务的时候，总需要一定方式来标识服务方。如果客户端不知道服务方的标识，它就需要某种方式来查找所需的服务。CORBA和WebService都通过唯一标识来识别服务方，并且都提供了服务的查找手段。应用在进行关键业务处理时，要求操作的可靠性、安全性和服务质量，而CORBA和WebService中都制订了对应的规范来满足这些要求。表 2-1 WebService和CORBA对比项目WebServiceCORBA问题域Internet企业计算环境基本模型面向服务面向对象耦合性松散耦合紧密耦合数据描述XML格式文档二进制接口描述语言WSDLIDL传输协议SOAP（HTTP,SMTP）等HOP,GIOP位置表示URLIOR防火墙穿越容易难查找UDDI名字服务，交易服务安全性研究中安全服务事务处理研究中对象事物服务灵活的通信机制研究中事件、通知服务从表2-1中可以看到，WebServices与CORBA最根本的差异在与出发点不同。CORBA是20世纪90年代提出来的，主要是针对企业环境中业务处理所面临的问题。面向对象是实际应用中证明非常有效的设计和开放模式，因此CORBA采用了面向对象的计算模式（这也决定了服务位置标示采用对象引用的方式）；并且在企业环境中，业务联系比较紧密，体现在处理业务的应用程序之间也是紧密耦合的，因此其数据描述也采用了二进制方式。企业环境中关系可能很复杂，这要求非常灵活的通信机制，因此CORBA提供了事件、通知等多种方式。WebServices是伴随着Internet的飞速发展而出现的。Internet中主要应用是基于Web服务的应用，因此WebServices采用了面向服务的模型。在广阔的Internet上，业务之间的关系本身比企业内的应用简单，这可以从早期的Web应用主要是无状态的请求/应答模式看到，因此，WebServices中，请求方和服务之间也没有始终保持的链接通道，是非常松散的耦合关系。为了保证松散耦合应用程序能够互相理解，具有自描述性的XML成了WebServices的数据描述方式，这也使WebServices具有可扩展性好、易于集成的优点。在Internet上，URL成为WebServices标示目标服务自然的选择。从上述分析可知，WebServices环境中，请求方和服务方是松散的耦合，请求以XML文档的形式进行传输，接口的细微变化不会影响程序的正常执行，具有更好的课扩展性；而CORBA环境中对象请求采用二进制传输，请求方和服务方是紧密耦合的，服务端接口一旦发生变化，客户端就必须作相应修改，否则就可能崩溃。CORBA采用IIOP进行传输，端口是动态分配的，请求很可能被防火墙拒绝；而WebServices主要基于HTTP，很容易穿越防火墙。在WebServices中，业务处理在Intenet上进行，这使参与者的信息更容易被窃听和非法访问，因此安全性要求更高。WebServices一个明显的劣势在于性能。XML文档比同等信息量的CDR数据耗费更多内存，也增加了网络流量和传输时间，XML文档的解析和转换比CDR数据的编解码需要更多内容和处理时间。因此，一般来讲，面向Internet的业务处理选择WebService技术框架较为适宜。在企业环境中，如果业务之间关系紧密，或者对性能要求较高，CORBA等分布式对象模式更合适，如果业务关系较为松散，更关注开放性，则WebService是更佳选择。三、WebService技术中的关键技术WebService涉及的最基本的技术规范包括XML、SOAP、WSDL和UDDI。WSDL是程序员描述WebService的编程接口。WebService可以通过UDDI来注册自己的特性，其他应用程序可以通过UDDI找到Web服务。SOAP则可提供了应用程序和Web服务之间的通信手段。而WSDL、SOAP、和UDDI都是建立在XML基础之上。3.1XML3.1.1简介为了实现异构系统(不同的平台、编程语言和组件模型等)之间的互操作性，需提供一套标准通用的数据语言。可扩展标记语言(XML Extensible Markup Language)已经成为Internet的通用语言。在WebServices平台中，采用XML表示数据的基本格式。XML能创建不依赖于平台、编程语言的开放数据，具有平台无关性。作为一个服务平台，WebServices必须提供一种标准的数据类型系统，用于沟通不同系统之间的不同类型。万维网联盟(W3C)制定的XML Schema(XSL)定义了一套标准的数据类型来扩展这套数据类型。WebServices平台采用XSD(XML Schema Definition)作为其数据类型系统。无论使用哪种语言构造WebServices，最终都将被转换为XSD类型。在实际应用中，开发工具一般会帮助开发者完成这一转换过程。3.1.2XML和HTML的差异XML和HTML的不同可以归纳为三点：1. XML扩展性优于HTMLXML（Extensible Markup Languages）是扩展标记语言的英语缩写，他可以创建个性化的标记语言，可以称之为元语言。XML的标记语言可以自定义，这样可以提供更多的数据操作，而不像HTML一样，只能局限于按一定的格式在终端显示出来。HTML的功能只有浏览器放入显示和打印，仅仅适合静态网页的要求。2. XML的语法比HTML严格由于XML的扩展性强，它需要稳定的基础规则来支持扩展。它的严格规则为： 起始和结束的标签相匹配 嵌套标签不能相互嵌套 区分大小写相对应XML的严格规则，HTML语言并没有规定标签的绝对位置，也不区分大小写，而这些全部由浏览器来完成识别和更正。3. XML与HTML互补XML可以获得应用之间的相应信息，提供终端的多项处理要求，也能被其他的解析器和工具所使用，在现阶段，XML可以转化成相应的HTML，来适应当前浏览器的需求。3.2SOAP简单对象访问协议（SOAP Simple Object Access Protocol）是一种轻量的、简单的、基于XML的协议，它被设计成在WEB上交换结构化的和固化的信息。SOAP可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP），简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到远程过程调用（RPC）等大量的应用程序。SOAP包括三个部分： SOAP的封装：它定义了一个框架，该框架描述了消息中的内容是什么，谁应当处理它以及它是可选的还是必须的。 SOAP的编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。 SOAP的RPC表示：它定义了用于表示远程过程调用和应答的协定。 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上使用SOAP并不仅限于HTTP协议绑定。SOAP也可以绑定到TCP和UDP协议上。性能：SOAP用XML将消息编码，因此在调用过程的任何一步都极易处理消息。另外，调试SOAP消息的方便性使各种SOAP执行能快速聚合在一起，这点很重要因为SOAP就是要达到大范围的协同工作。（CORBA、DCOM和RMI对参数和返回值使用二进制编码。除此之外，他们假设发送端和接收端充分了解消息的前后关系，因此对诸如参数名称或类型的任何元信息都不编码。这种方法产生了良好的性能，但使中介很难处理消息。因为每个系统使用不同的二进制编码，所以建立互操作的系统很难）。表面看来，基于XML的模式本应比基于二进制的慢，但它并不像表面那么简单。首先，当SOAP被用于通过因特网发送消息时，在每个端点给消息编码/解码的时间与在端点间传输字节的时间相比较是微不足道的，所以这种情况下使用XML没太大问题。其次，当SOAP用于封闭环境下的点对点间的消息传送，如在同一公司部门间的传送时，各端点可能将运行相同的SOAP执行。这样，这个特定执行就拥有专门的优化机会。例如，一个SOAP客户端可添加一个HTTP header标记到SOAP请求上，这个请求说明它支持一个特定的优化。如果SOAP服务器也支持那个优化，它会在第一个SOAP响应中返回一个HTTP header标记，告诉客户端可以在下面的通信中使用这种优化。接下来，客户端和服务器可以开始使用这种优化了。3.3WSDL和UDDI规范作为一个服务平台，WebServices必须具备相应的一套机制。用机器能阅读的方式提供一个正式的描述文档，为程序员调用服务提供帮助，使其更易于了解和使用WebServices，所采用的解决办法是通过WSDL和UDDI协议达到其目的。3.3.1WSDL服务描述(WSDL WebService Description Language)最初由Microsoft，IBM，Ariba三家公司于2000年9月推出。它是描述网络（network）服务或终端（endpoint）的一种XML语言，它用于定义WebServices以及如何调用它们（描述Web服务的属性，例如它做什么，它位于哪里和怎样调用它）。WSDL文档可用于动态发布WebServices、查找已发布的WebServices以及绑定WebServices。WSDL 文件包含以下元素：Type：使用某种语法（如XML模式）的数据类型定义（string、int）。 Message：要传递的数据。Part：消息参数。Operation：服务支持的操作的抽象描述。Port Type / Interface：一个或多个端点支持的操作的抽象集，此名称已更改，因此可能会遇到两者中的任何一个。 Binding：特定端口类型的具体协议和数据格式规范。Port / Endpoint：绑定和网络地址的组合，此名称也已更改，因此可能会遇到两者中的任何一个。Service：相关端点的集合，包括其关联的接口、操作、消息等。在WSDL中包含了使用SOAP的服务描述的绑定，也包含了使用简单HTTP GET和POST请求的服务描述的绑定。WSDL将Web服务定义成一系列的端口（port），每个端口用来表示从抽象端口类型（port type）到用于调用Web服务的具体通信协议的一个映射。端口类型由一组与Service provider交换信息的操作组成，它支持对包含消息的数据类型的定义。一个完整的WSDL服务描述是由一个服务接口和一个服务实现文档组成的。 由于服务接口表示服务的可重用定义，它在UDDI注册中心被作为tModel发布。服务实现描述服务的实例。每个实例都是使用一个WSDL service元素定义的。服务实现文档中的每个service元素都被用于发布UDDI businessService。因为WSDL包含了对服务接口的完整描述，所以可以使用它来创建能简化服务访问的存根，该存根为一段Java代码（假设使用Java），它自动生成了访问Web服务的类。如果需要访问Web服务，只需调用该类中对应的方法即可，而不用在客户端程序中再写入那些令人头疼的配置信息了。通过IBM提供的工具包可以轻松创建WSDL文档对应的存根。（由此看出，不用WSDL也可以访问Web服务）WSDL取代了IBM的NASSL（Network-Accessible Service Specification Language）和Microsoft的SCL（SOAP Contract Language）。3.3.2UDDI服务发布与发现(UDDI Universal Description Discovery and Integration)，即“通用描述、发现和集成”。该规范仍由上述三家公司于2000年7月提出。它提供了在Web上描述并发现商业服务的框架。UDDI通过服务注册，以及使用SOAP访问这些注册信息的约定来实现上述目标。UDDI计划的核心组件是UDDI商业注册，它使用一个XML文档来描述企业及其提供的Web服务。从概念上来说，UDDI商业注册所提供的信息包含三个部分：“白页(White Page)”包括了地址，联系方法，和已知的企业标识；“黄页(Yellow page)”包括了基于标准分类法的行业类别；“绿页(Green Page)”则包括了关于该企业所提供的Web服务的技术信息，其形式可能是一些指向文件或是URL的指针，而这些文件或URL是为服务发现机制服务的。所有的UDDI商业注册信息存储在UDDI商业注册中心中。 借助XML和SOAP，集成和交互的问题将从层次上被简化。XML提供了跨平台的数据编码和组织方法，而SOAP建立在XML之上，定义了一种跨系统平台的信息交换的简单包装方法。绑定于HTTP之上的SOAP协议，可以跨语言、跨操作系统进行远程过程调用(RPC)，实现了编程语言和系统平台的无关性。而以前的调用方式则和复杂的分布式对象标准或是中间件有密切的关系，从长期的眼光来看，这些都不是高效的解决方案。XML和SOAP这样的跨语言、跨平台的解决方案大大简化了不同企业系统之间的交互问题。但如果仅仅是XML和SOAP的话，对于公司间的交流仍存在着巨大的鸿沟。UDDI规范在XML和SOAP的基础之上定义了新的一层，在这一层次，不同企业可以用相同的方法描述自己所能提供的，并能查询对方所能提供的服务。UDDI注册使用的核心信息模型由XML Schema定义。使用XML 是因为它提供了平台无关的数据描述并很自然的描述了数据的层次关系。而选择XML Schema是因为它支持丰富的数据类型，便捷的描述方式及其按信息模型对数据进行验证的能力。UDDI XML Schema定义了四种主要信息类型，它们是技术人员在需要使用合作伙伴所提供的Web服务时必须了解的技术信息。它们是：商业实体信息、服务信息、绑定信息和服务调用规范的说明信息。UDDI程序员API规范分为两个逻辑部分：查询API和发布API。查询API又分为两个部分：一部分被用来构造搜索和浏览UDDI注册信息的程序，另一部分在Web服务出现错误时使用。程序员可以利用发布API创建各种类型的工具，以直接与UDDI注册中心进行交互，便于企业技术人员管理businessEntity或tModel结构的发布信息。UDDI调用模型每一个独立发布的Web服务都是使用一个bindingTemplate结构来建模的。对这个Web服务的调用通常通过缓存bindingTemplate数据来实现。注意到这一点后，在你准备编写调用某种Web服务的程序时，该如何使用UDDI就很清楚了。下面列出了基本步骤：编写调用远程Web服务的程序时，程序员使用UDDI商业注册中心(通过使用Web界面或其它基于查询API的工具)来定位businessEntity信息，这些信息是由(或为)提供该Web服务的企业注册的。程序员可以进一步获得更详细的businessService信息，或是得到一个完整的businessEntity结构。因为businessEntity结构包含了有关已发布的Web服务的所有信息，因此程序员只需简单地选择一个bindingTemplate并保存留待以后使用。基于Web服务在bindingTemplate的tModel中提供的调用规范的相关信息，程序员可以按照该Web服务的调用规范编写程序。在运行时，程序可以按需要使用已保存下来的bindingTemplate的信息来调用Web服务8。一般说来，只要远程Web服务和调用它的程序都准确的实现了必要的接口(按照在tModel中所引用的调用规范)，对远程服务的调用就一定会成功。结束语WebServices是服务器向客户端提供的一种跨越互联网的服务，是建立在一些通用协议(如HTTP、SOAP、XML等)基础之上的。由于这些协议在涉及到网络、操作系统平台、对象模型和编程语言的选择时没有任何倾向和特殊限制，因此呈现出很强的生命力。未来的Internet将通过WebServices所提供的多种服务为广大开发人员提供一个开放的可编程环境。基于XML的WebServices技术使得整个的应用程序开发技术从以操作系统为中心的应用程序组织模式扩展到以网络为中心的组织模式，即在视野上从本地扩大到了全球。两个中心的标志性技术分别为基于本地的组件技术（com、javabean等）和基于网络的WebServices（xml/soap）技术。 它的一大好处是：由于XML的支持，使得数据共享方式从原来的人-人、机器-人模式发展到机器-机器模式（软件-软件），WebServices就是这个模式的具体应用。它为我们在环球范围内实现全方位的全自动化数据共享提供了可能，它让我们看到了一个可真正在全球范围实现自动化生产的大工业产业模式，相信这一天的到来已经不远了。参考文献1 柴晓路.WebService技术系列概述J.互联网世界,2002,(5):8083.2 程炜,杨宗凯,乐春晖.基于WebService的一种分布式体系结构J.计算机应用研究,2002,19(3).3 王春樵.面向服务架构分布式网络应用的方向J.广东通信技术,2002,22.4 王绘,尹治本.WebService的深入剖析与研究J.电脑知识与技术,2005,(33).5 Jennifer Niederst. Web Design in a Nutshell:A Desktop Quick Reference , OReilly，1998,11.6 吴岳忠,李长云.Web服务技术综述J.株洲工学院学报,2006,(06).7 饶元,冯博琴.新网络体系结构WebServices研究综述J.计算机科学,2004,(05). 8 Ethan Cerami. WebServices Essentials M.OReilly,2002,02.9 BallingerK. .NETWebServices架构与实现M.张晓坤译.北京:中国电力出版社,2004.10 Harvey M.Deitel.Java Web服务高级教程M.北京:机械工业出版社,2003.7.11 Richard Monson-Haefel.J2EE WebService高级编程M.北京:清华大学出版社,2005,4.袁节膅薂羄肅蒃薁蚃芀荿薀螆肃芅蕿袈芈膁蚈羀肁蒀蚇蚀袄莆蚇螂肀莂蚆羅袂芈蚅蚄膈膄蚄螇羁蒂蚃衿膆莈蚂羁罿芄螁蚁膄膀螁螃羇葿螀袅膃蒅蝿肈羆莁螈螇芁芇莄袀肄膃莄羂艿蒂莃蚂肂莈蒂螄芈芄蒁袆肀膀蒀罿袃薈葿螈聿蒄葿袁羁莀蒈羃膇芆蒇蚃羀膂蒆螅膅蒁薅袇羈莇薄罿膄芃薃虿羆艿薃袁节膅薂羄肅蒃薁蚃芀荿薀螆肃芅蕿袈芈膁蚈羀肁蒀蚇蚀袄莆蚇螂肀莂蚆羅袂芈蚅蚄膈膄蚄螇羁蒂蚃衿膆莈蚂羁罿芄螁蚁膄膀螁螃羇葿螀袅膃蒅蝿肈羆莁螈螇芁芇莄袀肄膃莄羂艿蒂莃蚂肂莈蒂螄芈芄蒁袆肀膀蒀罿袃薈葿螈聿蒄葿袁羁莀蒈羃膇芆蒇蚃羀膂蒆螅膅蒁薅袇羈莇袄芈蒇袇螀芇蕿蚀聿芆艿蒃肅芅蒁螈羁芄薃薁袆芃芃螆螂芃莅蕿肁节蒈螅羇莁薀薈袃莀艿螃蝿荿莂薆膈莈薄袁肄莇蚆蚄羀莇莆袀袆羃蒈蚂螂羂薁袈肀肁芀蚁羆肁莃袆袂肀薅虿袈聿蚇蒂膇肈莇螇肃肇葿薀罿肆薂螆袅肅芁薈螁膅莃螄聿膄蒆薇羅膃蚈螂羁膂莈蚅袇膁蒀袀螃膀薂蚃肂腿节衿羈腿莄蚂袄芈蒇袇螀芇蕿蚀聿芆艿蒃肅芅蒁螈羁芄薃薁袆芃芃螆螂芃莅蕿肁节蒈螅羇莁薀薈袃莀艿螃蝿荿莂薆膈莈薄袁肄莇蚆蚄羀莇莆袀袆羃蒈蚂螂羂薁袈肀肁芀蚁羆肁莃袆袂肀薅虿袈聿蚇蒂膇肈莇螇肃肇葿薀罿肆薂螆袅肅芁薈螁膅莃螄聿膄蒆薇羅膃蚈螂羁膂莈蚅袇膁蒀袀螃膀薂蚃肂腿节衿羈腿莄蚂袄芈蒇袇螀芇蕿蚀聿芆艿蒃肅芅蒁螈羁芄薃薁袆芃芃螆螂芃莅蕿肁节蒈螅羇莁薀薈袃莀艿螃蝿荿莂薆膈莈薄袁肄莇蚆蚄羀莇莆袀袆羃蒈蚂螂羂薁袈肀肁芀蚁羆肁莃袆袂肀薅虿袈聿蚇蒂膇肈莇螇肃肇葿薀罿肆薂螆袅肅芁薈螁膅莃螄聿膄蒆薇羅膃蚈螂羁膂莈蚅袇膁蒀袀螃膀薂蚃肂腿节衿羈腿莄蚂袄芈蒇袇螀芇蕿蚀聿芆艿蒃肅芅蒁螈羁芄薃薁袆芃芃螆螂芃莅蕿肁节蒈螅羇莁薀薈袃莀艿螃蝿荿莂薆膈莈薄袁肄莇蚆蚄羀莇莆袀袆羃蒈蚂螂羂薁袈肀肁芀蚁羆肁莃袆袂肀薅虿袈聿蚇蒂膇肈莇螇肃肇葿薀罿肆薂螆袅肅芁薈螁膅莃螄聿膄蒆薇羅膃