计算机科学与技术毕业设计论文WebService技术研究Web服务的设计及其安全性研究.doc

《计算机科学与技术毕业设计论文WebService技术研究Web服务的设计及其安全性研究.doc》由会员分享，可在线阅读，更多相关《计算机科学与技术毕业设计论文WebService技术研究Web服务的设计及其安全性研究.doc（27页珍藏版）》请在三一办公上搜索。

1、河北农业大学本科毕业设计论文题 目： WebService技术研究 Web服务的设计及其安全性研究学 院： 现代科技学院学生姓名： 专 业： 计算机科学与技术班级学号： 指导教师姓名： 指导教师职称： 副教授二七年六月十六日摘要：Web服务的关键能力是提供一种综合的，全方位的，交互的，容易集成的解决方案。因此，其作为方便的服务被用于广大领域使用的同时，也成为了黑客们的美食。所以保护Web服务的安全问题迫在眉睫。本文先从介绍WebService的基础知识入手，先后介绍了WebService的技术构架、所用到的标准和协议，进而介绍WebService的技术背景和现状。随后介绍了WebService

2、设计中需要解决的问题，比如管理好与外系统的协同关系，掌握底层的传输模型，提供与应用相适应的安全策略，计划好部署的相关事项。本章最后引出了WebService的安全问题。并在下一章对安全问题进行了详细的研究。包括对WebService安全问题的分析，对WebService安全模型和安全规范的分析（如SOAP安全问题分析，WebService安全模型框架和规范）。随后介绍了WebService设计中需要注意到的安全问题，如保护基础结构的安全、保护连接的安全、身份验证和授权以及互操作性。在文章的最后介绍了一下本次毕业设计中WebService的一个简单的设计。关键字：WebService、Web服务

3、、技术、设计、安全。AbstractThe critical ability that Web serves is it is synthetis to provide one kind,the all direction, each other, easy the to be integrated settlement scheme. His also becomes the good food therefore being as the convenient service by the at the same time that is used the vast domain to u

4、se for hackers. It is extremely urgent so protecting Webs the person who serves safe question. This text, article, etc. is started with from the rudimentary knowledge to introduce WebService first, standard and the agreement to introduce the technology frame of WebService priority and uses, and then

5、 introducing technology background and the present situation of WebService. Introduce in WebServices design the problem that need to be solved soon afterwards, and for example manage well to work in coordination with the relation, and grasps the transmission model of first floor, and provides and ap

6、plies the safe tactics adaptable each other, and plans the being mutually related item of good deployment with the outer system. The safe question of WebService was finally drawn forth by this chapter. Carry on detailed research to the safety question under one chapter. Includes the analysis to WebS

7、ervices safety question, the analysis ( if analysis of question SOAPs safety, WebServices safety model frame and standard ) of model and safety standard to WebServices safety. Introduce in WebServices design the person who need to pay attention to safe question soon afterwards, if the safety of prot

8、ection foundation structure and protects safety and social status that links is verified and is empowered as well as the nature operates mutually. The simple design of WebService in finally introducing one time this graduation project at the essay.Key words:Webservice,web technology,web design, Secu

9、rity目录1.WebService简介11.1何谓 Web 服务？11.2Web Service技术架构11.3Web Service所用到的标准和协议21.3.1 水平 Web 服务标准21.3.2 水平标准主体31.4 Web Service技术背景51.5 WebService的现状52.WebService设计需要解决的问题62.1标准提供了协同的能力62.2理解传输模型72.3 DOM vs. SAX72.4文档交换vs. RPC模型82.5利用设计模式82.6安全93.对安全性的进一步讨论103.1 Web服务的安全问题分析103.2 Web服务安全模型和安全规范分析113.2.

10、1 SOAP安全问题分析113.2.2 Web服务安全模型框架和规范144.3 Web服务设计中需要注意到的安全问题174.3.1保护基础结构的安全174.3.2保护连接安全174.3.3身份验证和授权184.3.4 互操作性194.WebService的简单设计194.1 设计的分析194.3内容详情194.3设计总结215.参考文献22 1.WebService简介1.1何谓 Web 服务？近些年来，人员、信息与流程之间的交互越加紧密，推动着软件开发方式的相应转变。成功的IT系统日益要求跨平台的互操作性以及可随时间轻松改进的灵活服务。于是XML 开始流行并占据主导地位，可独立于编程语言、软

11、件平台和硬件来表示和传输结构化数据。基于对 XML 的广泛接受，Web 服务成为使用标准传输、编码和协议来交换信息的应用程序。Web 服务拥有来自不同供应商和业务的广泛支持，以端对端的安全性、可靠的消息传送、分布式事务以及更多优势，使得所有平台上的计算机系统皆可跨越公司内联网、 外联网和互联网进行通信。从表面上看：Webservice 就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Webservice 的应用程序叫做客户。更专业的描述如下：Webservice是描述一些操作（利用标准化的 XML 消息

12、传递机制可以通过网络访问这些操作）的接口。Webservice是用标准的、规范的 XML 概念描述的，称为 Webservice的服务描述。这一描述囊括了与服务交互需要的全部细节，包括消息格式（详细描述操作）、传输协议和位置。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。这允许并支持基于Webservice的应用程序成为松散耦合、面向组件和跨技术实现。Webservice履行一项特定的任务或一组任务。Webservice可以单独或同其它 Webservice一起用于实现复杂的聚集或商业交易，以及企业集成（EAI）。 WebService基于

13、一套描述软件通信语法和语义的核心标准。XML 提供表示数据的通用语法；简单对象访问协议 (SOAP) 提供数据交换的语义；Web 服务描述语言 (WSDL) 提供描述 WebService务功能的机制。其他规范统称为 WS-* 体系结构，用于定义 WebService发现、事件、附件、安全性、可靠的消息传送、事务和管理方面的功能。1.2Web Service技术架构Web Service就是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。它所使用的是Internet上统一、开放的标准，如HTTP、XML、SOAP（简单对象访问协议）、WSDL等，所以Web Service可

14、以在任何支持这些标准的环境(Windows,Linux)中使用。Web Service技术的特点在于：1.跨平台性；2.并且SOAP协议是基于XML和HTTP这些业界的标准的，得到了所有的重要公司的支持。3.由于使用了SOAP，数据是以ASCII文本的方式而非二进制传输，调试很方便；并且由于这样，它的数据容易通过防火墙，不需要防火墙为了程序而单独开一个“漏洞”。4.此外，WebService实现的技术难度要比CORBA和DCOM小得多。5.要实现B2B集成，EDI比较完善与比较复杂；而用WebService则可以低成本的实现，小公司也可以用上。下面我们来看一下常见的Web Service技术架

15、构，如图：图1-1 Web Service技术架构1.3Web Service所用到的标准和协议广大供应商在标准和可靠互操作性方面的协议，使得 Web 服务不同于以往的任何集成技术。1.3.1 水平 Web 服务标准 WS-* 体系结构由于 Web 服务市场的快速扩张，管理Web服务安全性、可靠性和事务的高级标准需求也随之而生。微软公司和业内其他供应商针对这一需求编写了一套规范，统称为 WS-* 体系结构。这些规范的目的是在保留基本 Web 服务简单性的同时，提供高级功能的远景蓝图。WS-* 体系结构最重要的属性是可组合性。协议可组合性使得 Web 服务解决方案可随个人要求（如安全性、可靠的消

16、息传送、附件、发现等）所需，随时完善开发。在隔离状态下，每项要求可满足一个基本需求。组合之后，他们就 可以满足分布式应用程序通常要求的更高级别功能。因此，WS-* 规范即可单独使用，又可相互之间结合使用。这样就消除了在规范试图定义多个功能，或与其他规范紧密耦合所带来的复杂性以及相关开支。还可使开发人员只应用解决直接需求的特定功能即可。而在新的应用程序要求产生之后，无需牺牲后向兼容性即可编写新的规范。图 WS-* 体系结构的语义概述1.3.2 水平标准主体迄今为止，已有数以百计的 IT 供应商以万维网联盟 (W3C)、结构化信息标准促进组织 (OASIS) 和 Web 服务互操作性组织 (WS-

17、I) 赞助商的身份，积极参与了 Web 服务标准化过程。 W3C1998 年，W3C 发布 XML 1.0，奠定了 Web 服务的基石。自此以后，W3C 在 Web 服务标准过程中起到了至关重要的作用，相继发布了 WSDL、SOAP、Web 服务寻址 (WS-Addressing) 和消息传输优化机制 (MTOM) 等一系列规范。OASISOASIS 制定出重要的 Web 服务安全规范，包括 WS-Security 和 SAML。Microsoft 在董事会、执行委员会和董事会流程与政策委员会中拥有正式席位。WS-I随着 Web 服务规范的不断涌现，将各种规范分类并形成“配置文件”以提高互操作

18、性势在必行。微软等公司同成立了 WS-I - 一个旨在促进 Web 服务互操作性的开放性行业组织。WS-I 现已发布应用最为广泛的 Web 服务配置文件，包括 WS-I BasicProfile 和 WS-I BasicSecurityProfile。还发布了各种用于一致性测试的工具。SOAPSoap 是 XML Web Service 的通信协议。当把 SOAP 描述为一种通信协议时，多数人都会想到 DCOM 或 CORBA，并且会问“SOAP 如何激活对象？”或“SOAP 使用什么样的命名服务？”等问题。虽然 SOAP 实现方案可能会包含上述内容，但 SOAP 标准并未对其进行规定。SOA

19、P 一种规范，用来定义消息的 XML 格式 - 这是规范中所必需的部分。包含在一对 SOAP 元素中的、结构正确的 XML 段就是 SOAP 消息。这是不是很简单？SOAP 规范的其他部分介绍如何将程序数据表示为 XML，以及如何使用 SOAP 进行远程过程调用 (RPC)。这些可选的规范部分用于实现 RPC 形式的应用程序，其中客户端将发出一条 SOAP 消息（包含可调用函数，以及要传送到该函数的参数），然后服务器将返回包含函数执行结果的消息。目前，多数 SOAP 实现方案都支持 RPC 应用程序，这是因为习惯于开发 COM 或 CORBA 应用程序的编程人员熟悉 RPC 形式。SOAP 还

20、支持文档形式的应用程序，在这类应用程序中，SOAP 消息只是 XML 文档的一个包装。文档形式的 SOAP 应用程序非常灵活，许多新的 XML Web Service 都利用这一特点来构建使用 RPC 难以实现的服务。SOAP 规范的最后一个可选部分定义了包含 SOAP 消息的 HTTP 消息的样式。此 HTTP 绑定非常重要，因为几乎所有当前的 OS（以及许多以前的 OS）都支持 HTTP。HTTP 绑定虽然是可选的，但几乎所有 SOAP 实现方案都支持 HTTP 绑定，因为它是 SOAP 的唯一标准协议。由于这一原因，人们通常误认为 SOAP 必须使用 HTTP。其实，有些实现方案也支持

21、MSMQ、MQ 系列、SMTP 或 TCP/IP 传输，但由于 HTTP 非常普遍，几乎所有当前的 XML Web Service 都使用它。由于 HTTP 是 Web 的核心协议，因此大多数组织的网络基础结构都支持 HTTP，并且员工已经了解了如何对其进行管理。如今，已经建立了用于 HTTP 的安全保护、监视和负载平衡的基础结构。开始使用 SOAP 时，最容易混淆的是 SOAP 规范及其许多实现方案之间的差异。多数使用 SOAP 的用户并不直接编写 SOAP 消息，而是使用 SOAP 工具包来创建和分析 SOAP 消息。这些工具包通常将函数调用从某种语言转换为 SOAP 消息。例如，Micr

22、osoft SOAP Toolkit 2.0 将 COM 函数调用转换为 SOAP，而 Apache Toolkit 将 JAVA 函数调用转换为 SOAP。函数调用的类型和支持的参数的数据类型随每个 SOAP 实现方案的不同而不同，因此适用于一个工具包的函数可能并不适用于另一个工具包。这并不是 SOAP 的限制，而是所使用的特定实现方案的限制。到目前为止，SOAP 最引人注目的特征是它可以在许多不同的软件和硬件平台上实现。这意味着 SOAP 可用于链接企业内部和外部的不同系统。过去曾试过多种方法以提出一个可用于系统集成的通用通信协议，但它们都没有象 SOAP 一样获得广泛的认可。为什么呢？因

23、为与许多早期的协议相比，SOAP 更小巧，而且更易于实现。例如，DCE 和 CORBA 的实现需要数年时间，所以只发布了很少几个实现方案。而 SOAP 可以利用现有的 XML 分析器和 HTTP 库完成大部分艰苦的工作，因此 SOAP 实现方案在数月内便可完成。这就是为什么现在已经有 70 多个 SOAP 实现方案的原因。当然，SOAP 并不具备 DCE 或 CORBA 的全部功能，虽然功能减少了，但由于其复杂程度大大降低了，因此 SOAP 更易于应用。WSDLWSDL (Web Services Description Language) 表示 Web 服务说明语言。在本文中，我们可以认为

24、WSDL 文件是一个 XML 文档，用于说明一组 SOAP 消息以及如何交换这些消息。换句话说，WSDL 对于 SOAP 的作用就象 IDL 对于 CORBA 或 COM 的作用。由于 WSDL 是 XML 文档，因此很容易进行阅读和编辑；但大多数情况下，它由软件生成和使用。要查看 WSDL 的值，可以假设您要调用由您的一位业务伙伴提供的 SOAP 方法。您可以要求对方提供一些 SOAP 消息示例，然后编写您的应用程序以生成并使用与示例类似的消息，但这样很容易出错。例如，您可能看到一个 2837 的客户 ID，并假设它为整数，而实际上它是一个字符串。WSDL 通过明确的表示法指定请求消息必须包

25、含的内容以及响应消息的样式。WSDL 文件用于说明消息格式的表示法以 XML 架构标准为基础，这意味着它与编程语言无关，而且以标准为基础，因此适用于说明可从不同平台、以不同编程语言访问的 XML Web Service 接口。除说明消息内容外，WSDL 还定义了服务的位置，以及使用什么通信协议与服务进行通信。也就是说，WSDL 文件定义了编写使用 XML Web Service 的程序所需的全部内容。UDDI通用发现、说明和集成 (UDDI) 是 Web 服务的黄页。与传统黄页一样，您可以搜索提供所需服务的公司，阅读以了解所提供的服务，然后与某人联系以获得更多信息。当然，您也可以提供 Web

26、服务而不在 UDDI 中注册，就象在地下室开展业务，依靠的是口头吆喝；但是如果您希望拓展市场，则需要 UDDI 以便能被客户发现。UDDI 目录条目是介绍所提供的业务和服务的 XML 文件。UDDI 目录条目包括三个部分。“白页”介绍提供服务的公司：名称、地址、联系方式等等；“黄页”包括基于标准分类法（例如 North American Industry Classification System 和 Standard Industrial Classification）的行业类别；“绿页”详细介绍了访问服务的接口，以便用户能够编写应用程序以使用 Web 服务。服务的定义是通过一个称为类型模型

27、（或 tModel）的 UDDI 文档来完成的。多数情况下，tModel 包含一个 WSDL 文件，用于说明访问 XML Web Service 的 SOAP 接口，但是 tModel 非常灵活，可以说明几乎所有类型的服务。UDDI 目录还包含若干种方法，可用于搜索构建您的应用程序所需的服务。例如，您可以搜索特定地理位置的服务提供商或者搜索特定的业务类型。之后，UDDI 目录将提供信息、联系方式、链接和技术数据，以便您确定能满足需要的服务。1.4 Web Service技术背景研究一下当前的应用程序开发，我们发现一个绝对的倾向：人们开始偏爱基于浏览器的瘦客户应用程序。这当然不是因为瘦客户能够提

28、供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。 许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBO

29、L语言编写的大型机程序访问。而且，目前还有很多商用程序继续在使用C+、Java、Visual Basic和其他各种各样的语言编写。现在，除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的高级程序到程序交流(APPC)等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。因此只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。Web Service 领域中另一件大

30、事是WS-I.org的成立，WS-I.org是致力于为保证Web Service所承诺的互振作性而成立的一个组织，其主要的工作就是开发保障Web Service互操作性的相关规范，并进行规范实施的测试。WS-I.org的核心成员包括：Accenture、Bea、HP、Intel、Microsoft、Oracle、SAP等，SUN不在其中。1.5 WebService的现状目前，人们对Web服务只有很少的直观认识和了解。Web服务领域还有待通过标准、应用和准确的定义进行补充和完善，并且需要对部署Web服务所必需的组成部份的性能和成本进行概述。SUN J2EE与Microsoft .Net是目前企

31、业Web Service平台市场的两个最重要的应用框架（Application Framework）。它们都为针对分布式N-Tier应用的设计、集成、性能、安全性和可靠性等诸多方面为用户提供了总体的指南和规范，基于这些指南和规范，技术提供商提供了相应的平台、工具和编程环境。尽管如此，Web服务作为一个重要的新市场，将不可避免地改变我们的商业交易方式。我们仅仅能对将来进行估计，而无法给出确切的令人满意的答案。基于供应商和最终用户的一些迹象，Yankee Group分析公司作出了以下几个方面的评估:Web服务行业的现状 普遍采用Web服务还需要至少2年时间 与Web服务的产品相比较，有更多言过其实

32、的广告宣传 大多数行动都集中于对工具包和应用程序进行开发 IBM和微软的合作促进了Web服务安全标准的发展;由此可见，两家公司都在市场开发过程中迈出了重要而积极的一步。 用户要求Web服务中商业交易是正当的状态或事实，有明确的Web服务使用说明，并且能够了解Web服务的成本架构和配置指南。2.WebService设计需要解决的问题在设计Webservice 应用时，以下几点务必要考虑到： 管理好与外系统的协同关系 掌握底层的传输模型 提供与应用相适应的安全策略 计划好部署的相关事项以下，将就这几条相关的设计需求和一些常用模式是如何应用于Webservice模型展开详细讨论。在讨论中，你会发现W

33、ebservice这项新的技术是如何与我们在以往的软件开发相结合的。2.1标准提供了协同的能力Webservice的一个最基本的目的就是提供在各个不同平台的不同应用系统的协同工作能力。为了使得一个公司的网络应用达到最高的效率，存在它自己和它的合作伙伴，供应商以及客户之间的Webservice，应该能够实现无缝的交互。 如果在众多的Webservice之间不能轻松的实现交互，那么该应用的效率将大打折扣。但是，在现实中这种情况是极有可能出现的。由于各个公司对业务的 理解各不相同，就是理解相同的情况下，对于相同的概念也可能用不同的形式加以表现，具体而言就是对于同一数据可能采取不同的xml表示。由于以

34、上的原因， 对于协同性的问题应该在设计应用架构时就加以考虑，而不是留待以后去改变。Webservice 主要由以下几块技术所构成，SOAP (Simple Object Access Protocol), WSDL (Web service Description Language), 以及UDDI (Universal Description, Discovery and Integration)。WSDL是实现协同能力的关键，它提供了一份契约用于与新老的应用之间交互。这项技术使得各个组织可以将标准的制定集中在Service的外部 接口，而不用考虑各组织的具体实现。简而言之，它实现了Webs

35、ervice的接口与实现的分离。从而使得标准的制定，更加容易。并且，基于这份接口描 述，很多工具可以从中自动生成客户端代码，减少了开发者的工作量，并使得大部分开发者摆脱了编写SOAP消息传递代码过程。SOAP是实现在各个Webservice组件之间传递消息的传输层。因此，SOAP应该是一项透明的协同技术。但是，由于很多的SOAP实现 方法却与标准背道而驰，要么添加了新的扩展功能要么删减了一些标准功能。由于对SOAP标准的支持程度不同，使得Webservice的协同能力大打折 扣，实现协同的困难加大了。基于这种情况，当开发者需要Webservice运行在不同平台上时，就要对具体情况加以了解并相应

36、的编码以解决这种不一致 性。如果所有的SOAP实现组织都能够遵循标准的话，那么Webservice的开发者就不需要考虑使用该Webservice的底层平台了。尽管如此，不同SOAP实现的协同还是相当困难，因为协同标准的制定存在大量的分歧，目前一些组织正致力于标准的制定，比如SOAP Builders 和 WS-I。然而，现在Webservice开发者只有针对不同平台，给予不同的实现，使得开发的成本和负担加大了。 2.2理解传输模型SOAP并不是完全透明的解决方案，它把一些复杂的实现细节隐藏起来。Webservice的开发者必须深入的了解SOAP，了解底层的传输机 制以及模型,从而知道SOAP是

37、如何实现的。在一些简单的应用中，某些工具可以帮助Webservice的开发者生成SOAP消息传递的代码，但是这只在 最简单的应用中有效。真正的情况不可能那么简单，可能在某些方面你需要有特殊的处理（这种情况在实际开发中是很常见的），这个时候，你就需要直接操纵 SOAP的消息传递代码，以及一些底层的XML内容。因此，Webservice的开发者需要深入了解SOAP和XML层的内容。在开发Webservice的接口的时候，不要以为使用XML技术，协作性的问题就迎刃而解了，XML并不是解决集成问题的灵丹妙药。这里同样 需要标准的制定，需要一个在业界公认的词汇表。仅仅在你的设计框架中引入XML技术并不能

38、保证系统具有协同性，XML仅仅是用来描述数据的语言，XML自 己并不提供语义去理解数据。就如同英语和德语都使用拉丁字母，但是他们的语义却并不相同。即使使用相同的语言，也不能保证具有良好的协作性。比如你的公司可能使用Order描述一个订单，但你的合作伙伴可能使用 Purchase_Order，而另一个伙伴可能又不相同。你不可能强迫你所有的合作伙伴都采用和你相同的词汇。因此需要有一项技术可以在众多的描述之间 充当翻译的角色。XSLT就是这么一种技术，它用于不同语言的转换。和XSLT的配合使用XML才能解决协同性的问题。2.3 DOM vs. SAX许多的Webservice开发环境，将开发者从底层

39、的XML文档的解析和处理中解放出来，他们提供了自动化或者很方便的工具，使得这一过程变 得很简单。但是对于一些有特殊要求的Webservice应用，比如需要更好的柔性或者对速度要求特别高的应用，就需要手工处理XML文档。这时候两种 XML解析的模型DOM 和SAX的选择，将成为重要的问题。DOM使用树状图的方式解析XML文档，而SAX则更多的采用事件驱动的模型。DOM先将XML文档映射成一颗树，然后通过采用一系列与树相关的操作去处理这份文档。这种方法有很多的好处，首先开发者很容易理解，使用一颗 树这对于开发者来说是最常见不过的了。DOM最常用于XML在Service中需要频繁修改的场合。当然DO

40、M也有它的缺点，在处理XML文档的时候，它 需要载入整个文档，而不管你需要修改的是否只是其中的一小部分。因此它的运行效率以及对内存的使用显然是不能接受的，尤其是面对很大的XML文档。SAX使用事件驱动的模型来处理XML文档。通过一系列事件的触发，来完成对XML的解析，你可以只关心你所要处理的事件，当这些事件发生时， 会调用到相应的回调函数来通知到你。采用这种方式就可以在很大程度上提高XML文档解析的效率。但是它的缺点在于难于使用，以及对同一文档的多次处理会存 在一些问题。总而言之，DOM更适合处理那种文档型的XML文件，而SAX则适于那种想直接将XML结构映射成在你系统中的一个对象的操作。（比

41、如将一个XML结构直接映射成JAVA中的一个Class）或者那种针对XML文件中特殊Tag的操作。2.4文档交换vs. RPC模型这两种交互方式应该在应用架构的设计初始就应该详加考虑，因为它将在很大程度上决定系统的耦合程度。RPC（Remote Procedure Call）本质上就是远程方法的调用。尽管Webservice是基于XML的但是你仍然可以使用远程方法调用这种模式来进行Webservice的实 现，尤其是在那种简单的请求相应的模型中。在这个过程中，传输中的XML文件所描述的更多是有关远程方法的信息，比如方法名，方法参数等等。而文档交换方式，与RPC相比较在XML文件中不是做远程方法

42、的映射，而是一份完整的自包含的业务文档，当Service端收到这份文档后，先 进行预处理（比如词汇的翻译和映射），然后再构造出返回消息。这个构造返回消息的过程中，往往不再是简简单单的一个方法调用，而是多个对象协同完成一个事 务的处理，再将结果返回。这两种方式的区别，类似与打电话和发邮件的不同处理方法。在目前，对于第一种方法提供了很多自动化的工具使得远程方法的调用能够很容易的完成，而后一种方法缺少一系列工具的支持，需要开发者手工完成。尽管如此，在此还是推荐使用文档交换的方式。由于它在以下方面具有RPC所不具备的优点。使用文档方式，你可以充分利用XML文件的功能去描述和验证一份业务文档，而在RPC

43、模型中XML仅仅被用于描述方法的信息。使用文档方式，在客户的Service的提供者之间不再需要紧密的约定，而RPC模型需要客户和Service的提供者紧密相连，一旦方法发生变化，客户端就需要做相应的改动。这不符合低耦合系统的要求，而在文档交换方式中则灵活的多。由于业务数据是自包含的，显然文档模型更利于采用异步处理。2.5利用设计模式设计模式在设计Webservice的时候显然可以起到相当大的作用。设计模式的主要目的就是为解决某些在类似环境下的相像问题提供已有的较为成熟的设计方案。在这里，只简单的提及一些很常用的模式，让我们了解到模式在Webservice中可以起到的作用。Adapter ：为内

44、部系统提供一个不同的接口Faade： 封装复杂的内部实现，提供一系列简单的接口Proxy： 作为其他对象的代理，代替它提供服务Adapter模式用于将一个组件的接口转化成客户所需要的样子，这里的客户就是Webservice。一个常见的情况就是将原有的老的系统包 装成一个Webservice。比如现在使用的是J2EE的平台，而原来有一个C+的系统实现了某些功能，现在需要将它发布成Webservice，那 么就需要利用JNI技术做一个Adapter，为原来的C+组件提供一个Java的接口，然后再转化为Webservice。Faade模式用于构建粗粒度的服务，它包装了细粒度的服务，从而为复杂的系统提

45、供了一个简单的接口。在J2EE中，Session Bean就象是一个Faade，而Entity Bean则是细粒度的服务。在Webservice中也一样，使用Faade模式可以将已有的组件的功能发挥殆尽。Proxy 模式用于充当其他对象的代理，类似于中间人的作用，将处理工作从一个对象传递到另一个对象。在Webservice中，它主要用于隐藏Soap消息构造的过程。也可以用于模拟对象（Mock Object）的创建。以上仅仅是一些可以用于Webservice开发的模式，如果你熟练的将这些模式应用于Webservice开发，你将会发现开发Webservice应用，将好像做一种特殊的面向对象设计。2

46、.6安全Webservice为作为方便的服务被用广大领域使用的同时，也成为了黑客们的美食。在这里我们将就目前对Webservice安全所能做的改进做简单介绍。在Webservice中的安全主要分为以下三个方面。传输 SSL/HTTPS 对连接加密，而不是传输数据消息 数据加密(XML Encryption) 数字签名(XML-DSIG)底层架构 利用应用服务安全机制传输时的安全是最容易被加入到你的Webservice应用中的，利用现有的SSL 和HTTPS协议，就可以很容易的获得连接过程中的安全。然而这种安全实现方法有两个弱点。一是它只能保证数据传输的安全，而不是数据本身的安全，数据一旦到达某

47、地，那么就可以被任何人所查看。而在 Webservice中，一份数据可能到达多个地方，而这份数据却不该被所有的接受者所查看。二是它提供的是要么全有要么全无的保护，你不能选择哪部分数 据要被保护，而这种可选择性也是在Webservice中所常要用到的。第二层的保护是对于消息本身的保护。你可以使用已有的XML安全扩展标准，实现数字签名的功能，从而保证你的消息是来自特定方并没有被修改过。 XML文件的加密技术从更大程度上加强了Webservice的安全，它能够定制数据传输到后，能否被接受者所查看，进一步完善了传输后的安全，业界也在 不断的制定Webservice的安全标准，比如SAML 和 WS-S

48、ecurity。最后一层保护就是依靠底层架构的安全，这更多的来自于操作系统和某些中间件的保护。比如在J2EE中，主持Webservice的应用服务器。 目前很多的J2EE应用服务器都支持Java Authentication and Authorization Service (JAAS)，这是最近被加入到J2SE 1.4当中的。利用主持Webservice的服务器，实现一些安全机制这是很自然的做法。另一种利用底层架构的安全方法就是，做一个独立的负责安全的服 务器，Webservice的使用者和创建者都需要与之取得安全信任。3.对安全性的进一步讨论3.1 Web服务的安全问题分析 Web服务的关键能力是提供一种综合的，全方位的，交互的，容易集成的解决方案。目前，SSL(