分析教案soa开发

1、1教育部-IBM 精品课程服务计算与SOA开发第六章 Web服务实现方式西安电子科技大学 软件学院主讲人：鲍亮2概述SOAP、WSDL、UDDI通常被认为是Web服务的支撑协议，通过上面章节对Web服务协议的讲解，有助于我们了解Web服务的基本设计思路。规范与协议定义了关于Web服务最基本的特征，但涉及具体实现这些特征的细节，却没有做出深入的决定。而各个软件提供商，会根据自己现有产品的特征，遵循规范来提供自己的Web服务平台。本章将从程序开发的角度来剖析Web服务的开发及运行过程。3课程内容6.1 Web服务实现平台的发展历程6.2 目前主流的实现平台6.3 Web服务引擎的工作原理6.4 开

2、源服务引擎Axis26.5 IBM WebSphere服务引擎6.6 本次课程总结46.1 Web服务实现平台的发展历程56.1.1 Web服务实现平台的发展历程Web服务的起源来自于程序员对于Web页面之间进行程序调用的需要，Web服务的一个重要理念就是获取跨平台的互操作性，Web服务的相互间的调用应该是平台无关的。我们不可能涵盖所有的Web服务实现方式，因此将着重介绍Java世界的Web服务，但这并不影响我们对Web服务的全面理解。66.1.1 Web服务实现平台的发展历程Web服务的开发运行模式与传统的C/S、B/S没有太大的区别，按照不同的功能角色，也有客户端与服务端之分。服务端一般需

3、要Web服务引擎的支持，而客户端只需要XML的支持。需要注意的是，此处提到Web服务的客户端，在通常的IT架构中，一般会运行在企业环境中，而不是指我们通常理解的终端用户，而是某一段获取服务的程序。因此，可以说Web服务是通过程序访问的。76.1.1 Web服务实现平台的发展历程例如，类似于Web服务，但并不基于SOAP的服务调用协议的REST，比Web服务更容易被广大Web页面开发者接受。与Web服务相比，REST更容易直接嵌入到Web页面中。一般的网页开发人员，不需要Web服务开发的相关知识，就可以直接获得服务。当然，REST更适合于从Web页面直接调用服务的场合。本章中所描述的Web服务，

4、除非特殊说明，默认是指基于SOAP的Web服务。86.1.1 Web服务实现平台的发展历程SOAP协议是Web服务的默认消息传递协议，因此，提供Web服务的平台，都通常会设置一个SOAP引擎，在Web服务的两端提供SOAP消息的封装及其解包功能。SOAP 4J是最先出现的Java SOAP引擎之一。以此为基础，开源的Apache的第一代SOAP引擎出现了，即SOAP2.x。随后，Apache又重新设计了AXIS引擎，发展到现在的Axis2，Axis已经成为流行最广的Web服务引擎之一。96.1.1 Web服务实现平台的发展历程IBM的Web服务引擎的发展历程也大致遵循了同样的规律，即在保持了与

5、主流兼容的同时，又着重在面向企业的Web服务上做了很大努力。如图所示描绘了IBM Web服务引擎与Apache SOAP引擎的渊源及同步发展的历程。IBM SOAP 4JIBM WebSphere5内嵌SOAPIBM WebSphere内嵌Axis 1.0IBM WebSphereSOAP engineApache 2.1Apache 2.3Apache Axis 1.0Apache Axis2106.2 目前主流的Web服务实现平台116.2.1 概述随着互联网的兴起，基于web的应用越来越多，传统的Html已经满足不了如今的需求。我们需要一个交互式的web，于是便诞生了各种web语言，如A

6、sp，Jsp，Php等。当然，这些语言与传统的语言有着密切的联系，如Php语言基于C和C+语言，Jsp基于Java语言。这些语言需要WEB容器来编译它。下面就来介绍几种主流的WEB服务器：126.2.2 TomcatTomcat是一个开放源代码、运行Servlet和JSP Web应用软件容器。Tomcat Server是根据servlet和JSP规范进行执行的。Tomcat使用了JServ的一些代码，特别是Apache服务适配器。随着Catalina Servlet引擎的出现，Tomcat第四版号的性能得到提升，使得它成为一个值得考虑的Servlet /JSP容器，因此目前许多WEB服务器都采

7、用Tomcat。136.2.3 Microsoft IISMicrosoft的web服务器产品为Internet Information Server（IIS），IIS是允许在公共Intranet和Internet上发布信息的Web服务器。IIS是目前最流行的Web服务器产品之一，很多著名的网站都是建立在IIS的平台上。IIS提供了一个图形界面的管理工具，称为Internet服务管理器，可用于监视配置和控制Internet服务。146.2.3 Microsoft IISIIS是一种Web服务组件，其中包括Web服务器、FTP服务器，NNTP服务器和SMTP服务器，分别用于网页浏览、文件传输、新

8、闻服务和邮件发送等方面，它使得在网络（包括互联网和局域网）上发布信息成了一个很容易的事。它提供ISAPI（Intranet Server API）作为扩展Web服务器功能的编程接口；同时，它还提供一个Internet数据库连接器，可以实现对数据库的查询和更新。156.2.4 ApacheApache源于NCSAhttpd服务器，经过多次修改，成为世界上最流行的Web服务器软件之一。Apache的特点是简单、速度快、性能稳定、源代码开放、支持跨平台的应用以及可移植，并可做代理服务器来使用。Apache是以进程为基础的结构，进程要比线程消耗更多的系统开支，不太适合多处理器环境，因此，在一个Apac

9、he web站点扩容时，通常是增加服务器或扩充群集节点而不是增加处理器。166.2.5 IBM WebSphereWebSphere软件平台能够帮助客户在web上创建自己的业务或将自己的业务扩展到web上，为客户提供了一个可靠、可扩展、跨平台的解决方案。WebSphere软件平台提供了一整套全面的集成电子商务软件解决方案。作为一种基于行业标准的平台，它拥有足够的灵活性，能够适应市场的波动和商业目标的变化。以这一平台为基础，客户可以将不同的IT环境集成在一起，从而能够最大程度地利用现有的投资。176.2.5 IBM WebSphereWebSphere Application Server是一种

10、功能完善、开放的Web应用程序服务器，是IBM电子商务计划的核心部分。它是基于Java的应用环境，用于建立、部署和管理Internet和Intranet Web应用程序。这一整套产品进行了扩展，以适应Web应用程序服务器的需要，范围从简单到高级直到企业级。186.2.6 BEA WebLogicBEA WebLogic Server是一种多功能、基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础。各种应用开发、部署所有关键性的任务，无论是集成各种系统和数据库，还是提交服务、跨Internet协作，起始点都是BEA WebLogic Server。由于它具有全面的功能、对开放标准的

11、遵从性、多层架构、支持基于组件的开发，基于Internet的企业都选择它来开发、部署最佳的应用。196.2.7 IPlanet Application ServerIPlanet Application Server满足最新J2EE规范的要求。它是一种完整的WEB服务器应用解决方案，它允许企业以便捷的方式，开发、部署和管理关键任务Internet应用。该解决方案集高性能、高度可伸缩和高度可用性于一体，可以支持大量的具有多种客户机类型与数据源的事物。206.2.8 Oracle IASOracle IAS的英文全称是Oracle Internet Application Server，即Inte

12、rnet应用服务器。Oracle IAS是基于Java的应用服务器，通过与Oracle数据库等产品的结合，Oracle IAS能够满足Internet应用对可靠性、可用性和可伸缩性的要求。Oracle IAS最大的优势是其集成性和通用性，它是一个集成的、通用的中间件产品。216.3 Web服务引擎的工作原理226.3.1 Java SOAP服务引擎的工作原理Web服务的实现架构实际上就是围绕约定的消息格式，提供特定信息（如SOAP）的传递与解析的协议栈。典型的Web服务的应用场景是从另一个现有应用程序发出请求，获得服务器所提供的业务应用程序的服务。因此，通常可以把这个过程的必要参与者划分为服务

13、的请求方（客户端）与服务的提供方（服务端）。236.3.1 Java SOAP服务引擎的工作原理一、Web服务的客户端Web服务的客户端，即客户端程序，代表客户端调用Web服务的编程模式。Web服务的客户端，按照功能可以划分为下面几部分：服务代理接口参数类型注册接口消息传送接口246.3.1 Java SOAP服务引擎的工作原理1.服务代理接口服务代理（Service Proxy）接口是一段代码，客户端程序通过调用这段代码，来访问某个web服务。服务代理接口代码是对用户可见的程序接口。 web服务的客户端的调用方式是由web服务的接口决定的，与服务的具体提供方式无关。256.3.1 Java

14、SOAP服务引擎的工作原理2.参数类型注册接口web服务所传送的消息实际上是由基于XML的扩展协议所约束的。例如，SOAP消息是XML上的扩展协议。web服务的调用，除了需要描述服务提供的方法名称，还需要考虑到方法的消息类型，即参数类型以及返回类型。266.3.1 Java SOAP服务引擎的工作原理尽管web服务平台无关，但是提到类型映射的时候，不得不承认它还是平台相关的，只不过这样的相关性隐藏在类型注册接口中。如图：web服务两端的数据类型映射JAX-RPC客户端1.Java to XML映射3.XML to Java映射JAX-RPC服务器端2.XML to Java映射4.Java t

15、o XML映射请求SOAP消息响应276.3.1 Java SOAP服务引擎的工作原理3.消息传送接口web服务的请求消息与服务的结果内容是怎样在客户端与服务器端流动的呢？这依赖于web服务发生的上下文环境。例如，大多数情况下，web服务发生在web环境中，即HTTP/Internet环境中，那么，web服务的客户/服务器两端的信息流就是基于HTTP来传输的。286.3.1 Java SOAP服务引擎的工作原理3.消息传送接口消息传送接口的作用就是将web服务的SOAP消息打包封装到对应的消息载体中。消息传送接口是由web服务平台提供的，无论是web服务的客户端还是服务端，都不需要用户来完成这

16、项复杂的工作，web服务的平台提供商会根据自己平台的特性，提供针对不同场景的消息传送模块来完成消息的传输。296.3.1 Java SOAP服务引擎的工作原理二、Web服务的服务器端web服务的服务器端代表了调用web服务的逻辑实践，web服务的服务器端也可划分为3个层次，与web服务的客户端对应，与客户端完成类似的功能：306.3.1 Java SOAP服务引擎的工作原理1.参数类型注册接口：在调用web服务的时候，将数据从web服务消息（SOAP）映射到web服务实现代码的数据类型；在完成逻辑调用、返回结果的时候，将消息内容从业务程序的数据类型翻译成SOAP格式。316.3.1 Java

17、SOAP服务引擎的工作原理2.消息传送接口：消息传送接口与具体的web服务传输平台相关，负责将具体的web服务消息利用通信层进行打包封装，传递及接受。326.3.1 Java SOAP服务引擎的工作原理3.注册服务管理：在客户端的对应位置上，这里是服务代理接口，因为客户程序需要通过它访问远端的web服务；而在服务器端，需要的是如何将服务请求转发给恰当的服务实现体。336.3.1 Java SOAP服务引擎的工作原理web服务的服务器端，需要考虑如何把一般的程序包装成web服务。而web服务的实现，仍然是传统的方式，与通常的程序没有区别，目前并不存在一种专门针对web服务的程序语言。对于web服

18、务的开发者而言，web服务通常的开发模式更像是部署（Deploy）或包装（Wrap）的过程。346.3.2 开发Web服务的方式完整的web服务开发包括3个阶段：开发、部署、发布。1.开发阶段：此阶段包括逻辑模块的开发与部署，WSDL服务定义文件的设计与生成。在web服务的开发阶段，有两种可以实施的方案：可以先设计WSDL，即服务的接口定义，然后生成服务逻辑代码，即自上而下的方式；还可以先完成业务逻辑代码的开发或者使用已经存在的逻辑代码，再根据代码暴露出服务的接口WSDL（自底向上）包装web服务。356.3.2 开发Web服务的方式如下图1：自顶向下的web服务开发模式通常用于基于标准WSD

19、L的开发，即先获得预定义的WSDL，然后按照其中的web服务定义开发服务的业务逻辑实现。如下图2：是自底向上的方式，这种方式在目前更为常见，大多数SOA应用都是基于当前的应用创建服务。因此，总是先有应用，再有服务。366.3.2 开发Web服务的方式图1：图2：web服务逻辑模块平台部署描述文件注册web服务附属文件逻辑模块web服务部署描述文件注册web服务附属文件web服务定义文件生成并部署web服务376.3.2 开发Web服务的方式2.部署阶段：指定web服务的传输协议（绑定），明确服务的终端地址，创建web的附属文件，以平台可识别的方式将web服务注册到相应服务描述部署文件。3.发布

20、阶段：将web服务的接口和调用地址公开供客户端调用，常用的发布方式为基于web提供WSDL的链接，当然，UDDI也是一个选择。386.3.3 Web服务引擎的工作原理web服务的开发模式也是一个不断发展的过程，从最初以Apache SOAP引擎为代表的方式，到目前常见的JAX-RPC方式。而自从J2EE平台正式开始提供web服务的支持，web服务的编程模式逐渐趋于稳定。396.3.3 Web服务引擎的工作原理一、SOAP引擎的web服务的运行时环境SOAP引擎架构如下图所示：web服务的客户端需要设定调用方法的参数，然后通过代理调用服务。RPCrouter是服务器端用于侦听的端口，服务的客户与

21、服务器两端都需要类型映射注册表来帮助建立Java类与SOAP数据类型的映射关系。406.3.3 Web服务引擎的工作原理图：SOAP引擎的实现方式service requestorSOAP RPC LayerClient ProxyCallMappingRegistryPara-meterSOAP Message LayerSOAP Transport LayerTransport Layer(HTTP,HTTPS,SMTP,JMS)Service ProviderSOAP ProviderPluggableProvidesMappingRegistryRPC RouterServletSer

22、viceManagerMessageRouterServletDeploymentDescriptor416.3.3 Web服务引擎的工作原理二、IBM的SOAP引擎AxisAxis的全名是Apache扩展交互系统（Apache eXtensible Interaction System）。一句话概括，Axis其实就是一个消息处理的句柄链机制的运行环境。426.3.3 Web服务引擎的工作原理Axis的工作原理并不复杂：配置好一系列控制句柄，Axis运行处理框架会依次地调用句柄来处理消息。消息和消息相关的环境属性，被包裹在一个上下文中，在一个控制句柄链表中传递，每传到链上一个句柄节点，由句柄执

23、行相应的动作，将处理结果体现到消息上下文上，并把它传递给下一个句柄。436.3.3 Web服务引擎的工作原理作为服务器端的处理框架的工作过程有以下几个方面：1.传输侦听端口创建消息上下文传输侦听端口由具体的底层传输协议决定。传输侦听端口会把传输层的消息打包封装在消息对象中，并为消息对象创建消息上下文，为消息上下文设置各种属性，然后传输侦听端口将配置好的消息上下文对象交给Axis引擎，由Axis引擎负责消息上下文在会话生命周期的维护。446.3.3 Web服务引擎的工作原理2.生成的服务器端消息在Axis引擎的传递路径上传递Axis引擎的链结构按照句柄动作的分类划分为逻辑上的3个层次：传输层、全

24、局层和服务层。Axis处理架构的核心就是控制句柄链，链条上的处理节点可以随时方便地增减。456.3.3 Web服务引擎的工作原理Axis迅速占据了web服务平台的主导地位。由于是开放源代码，加上架构上先天的可扩展性，被很多商业web服务平台提供商选做其web服务系统的架构。Axis本身支持JAX-RPC API，可以将Java Bean包装成JAX-RPC兼容的web服务，但其本身并不支持更多的J2EE特征，例如，将EJB包装成web服务。466.3.4 特殊类型的Web服务实现方式关于SOA，有这样一个观点，SOA并不以是否使用web服务作为行为准则，所谓的“服务”应该根据企业的具体应用场景

25、而有不同的体现形式。此处，我们再介绍两种不同的“服务”生成方式，它们并不是基于某种开放规范的，但在特定的场合中，还是非常有用的。基于EJB绑定的web服务直接绑定数据库操作的web服务476.3.4 特殊类型的Web服务实现方式一、基于EJB绑定的web服务WebSphere Application Server（WAS）支持Web Service使用HTTP或Java消息服务（JMS）的服务方式，访问Enterprise JavaBeans（EJB），还可以通过RMI-IIOP协议在服务器和客户端之间传输请求。486.3.4 特殊类型的Web服务实现方式SOAP消息的地址信息是与绑定的传输协

26、议相关的。例如，SOAP/HTTP需要HTTP的URL来定位web服务，SOAP/JMS则需要JMS的目的地等信息。而使用RMI-IIOP，WebSphere Java客户机仍然可以使用WSDL文件和JAX-RPC编程模型，而不是使用标准J2EE编程模型来调用EJB。496.3.4 特殊类型的Web服务实现方式注意，这种调用方式只适用于企业内部的服务调用、对性能有更高要求的场景下，因为它是以牺牲了通用性为代价的。一般来说，不鼓励使用这种方式。除非是既要保持web服务的接口，又不想放弃直接调用EJB的性能。这样的场合还是不多见的。506.3.4 特殊类型的Web服务实现方式二、直接绑定数据库操作

27、的web服务据统计，企业应用环境中，大部分的操作都是与数据相关的，应用开发项目绝大多数都是在对数据库进行增删改查的一般性事物操作。在这种情况下，一般会按照下面的架构图构筑SOA系统。DataEntity BeanSession BeanWeb Service516.3.4 特殊类型的Web服务实现方式但是，一旦数据库表结构发生变化，需要重新调整源代码。针对这种纯粹的数据访问类型的web服务，还有更简单的开发模式，就是DADX/WORF模式的web服务。如图：DADX/WORF模式的web服务Data逻辑封装Web Service526.3.4 特殊类型的Web服务实现方式如上图所示，可以将数据

28、库的操作直接映射成为访问数据库的web服务。DADX（document access definition extension）技术允许将SQL语句或数据库存储过程直接包装成web服务。在IBM DB2服务端，存在着WORF的运行环境（Web Service Object Runtime Facility），它能够动态地读取DADX文件而执行对应的SQL语句或存储过程，并以web服务响应的方式返回结构。536.4 开源服务引擎Axis2546.4.1 背景介绍在SOAP规范发布之前，开发人员就已通过Internet协议交换XML信息，但SOAP承诺对此技术进行规范化，并实现更好地互操作性。SO

29、AP还提供了各种hook机制，以方便扩展，从而可以添加高级基础结构功能，以增强未来的XML消息交换。WSDL规范在SOAP推出后不久发布，添加了web服务元数据的标准表示方法。556.4.1 背景介绍一、SOAP和WSDL挑战尽管在整个行业中SOAP+WSDL迅速崛起，但仍然在很多方面存在问题，会妨碍SOAP达到很多人所期望的完全成功。第一个方面就是互操作性。尽管SOAP最诱人的一个重要方面就是它的互操作性承诺，但实际进展却并不明显。566.4.1 背景介绍一、SOAP和WSDL挑战SOAP web服务的另一个问题是基础结构扩展和基本SOAP处理之间不断地混淆不清。SOAP的设计运行方便地添加

30、此类扩展，但这些扩展通常仅在其为受多个框架支持的标准时才有用。这要求整个行业进行协作，但通常很难办到。576.4.1 背景介绍二、SOAP的阻力前一部分中详细讨论的互操作性和标准化问题限制了 SOAP Web 服务的适用性，同时，SOAP 框架本身也通常很复杂，难于使用。优势有限以及潜在的复杂性让很多开发人员转而采用比 SOAP 更简单的替代方法。586.4.1 背景介绍二、SOAP的阻力SOAP的大部分阻力都来自于REST 。严格来说，REST是可应用到 Web 服务的 HTTP 协议的基本规则的规范化技术。REST 被限制为使用 HTTP 作为传输层，而 SOAP 从理论上来说是独立于传输

31、层的。REST 并不包含任何直接添加基础结构扩展的方法，但在 SOAP 真正开始提供此类扩展前，此限制都可以被视为无足轻重的方面。596.4.1 背景介绍三、Apache方法Apache 项目数年来已在 Web 服务方面进行了大量的工作，其主要精力放在 Java 平台开发上。Apache 当前的 Java SOAP Web 服务生产平台是第三代 Axis 框架。Axis 得到了广泛的使用，这既包括开发人员下载并直接使用，也包括将其作为 SOAP 引擎嵌入到若干不同的应用服务器中。Axis 通常被认为是使用最广泛的 Java SOAP Web 服务平台。606.4.1 背景介绍四、Axis2的出

32、现Axis2 是 Axis 的后续版本。它设计为轻量SOAP处理引擎，可以采用很多方式进行扩展。与原来的 Axis 不同，Axis2 并不刻意对实现任何特定 API 进行约束。Axis2 最好的特性之一就是为 SOAP 消息使用的 AXIOM 对象模型。另一个 Axis2 的特性是对可插入数据绑定的支持。616.4.2 Axis2基础Web Service是现在最适合实现SOA的技术，而Axis2是实现Web Service的一种技术框架。支持开发 Axis2 的动力是探寻模块化更强、灵活性更高和更有效的体系结构，这种体系结构可以很容易地插入到其他相关 Web 服务标准和协议的实现中。 Apa

33、che Axis2 是Axis的后续版本，是新一代的SOAP引擎。626.4.2 Axis2基础一、Axis2的主要特点如下：1）采用名为 AXIOM（AXIs Object Model）的新核心 XML 处理模型，利用新的XML解析器提供的灵活性按需构造对象模型。 2）支持不同的消息交换模式。 3）提供阻塞和非阻塞客户端 API。 4）支持内置的 Web服务寻址 (WS-Addressing) 。 636.4.2 Axis2基础一、Axis2的主要特点如下：5）灵活的数据绑定，可以选择直接使用 AXIOM，使用与原来的 Axis 相似的简单数据绑定方法，或使用 XMLBeans等专用数据绑定

34、框架。 6）新的部署模型，支持热部署。 7）支持HTTP，SMTP，JMS，TCP传输协议。 8）支持REST (Representational State Transfer)。646.4.2 Axis2基础二、Axis2体系结构Axis2 具有模块化体系结构，由核心模块和非核心模块组成。同时，Axis2 体系结构的设计充分考虑了以下原则：逻辑和状态分离，以提供无状态处理机制。 所有信息位于一个信息模型中，允许对系统进行挂起和恢复。 能够在不更改核心体系结构的情况下扩展功能。656.4.2 Axis2基础二、Axis2体系结构Axis2 核心体系结构包括以下核心和非核心组件：核心组件 ：XM

35、L 对象模型 (AXIOM) SOAP 处理模型：处理程序框架 信息处理模型：上下文和描述 其他组件 ：部署模型 传输 客户机 API 核心生成模型 666.4.2 Axis2基础二、Axis2体系结构如图：Axis2体系结构关系图676.4.2 Axis2基础二、Axis2体系结构下面简单介绍一下各组件特点：1.信息处理模型：此模块管理 SOAP 引擎的状态。该模型定义一组用于存放状态的类，而引擎管理这些信息对象的生命周期。信息模型包含两种用于存放状态的类：Description类和Context 类。686.4.2 Axis2基础二、Axis2体系结构2. XML对象模型（AXIOM）：A

36、XIOM 用于处理 SOAP 消息。它使用 StAX (Streaming API for XML) 来解析 XML。StAX 是一个标准的流式 Pull 解析器 Java API。AXIOM 非常精巧，不会减慢 XML 信息集的构建速度。换句话说，对象只有在绝对必要时才会创建。696.4.2 Axis2基础二、Axis2体系结构3.SOAP处理模型：Axis2 体系结构定义了两个管道（或流），分别称为 InPipe (InFlow) 和 OutPipe (OutFlow)，用于处理服务器端的请求消息和响应消息。管道或流包含一系列分为阶段的处理程序。阶段按照预先定义的顺序执行，如下图所示。处理

37、程序充当 SOAP 消息的拦截器，可以处理 SOAP 消息的 Header 或 Body。706.4.2 Axis2基础二、Axis2体系结构3.SOAP处理模型：716.4.2 Axis2基础二、Axis2体系结构4.部署模块：此模块配置 Axis 引擎并部署服务和模块。Axis2 引擎的全局配置包括：全局模块 (Global modules) 全局接收器 (Global receivers) 传输 (Transports) 用户阶段定义 (User phase definitions) 726.4.2 Axis2基础二、Axis2体系结构5.传输：此模块包含与传输层交互的处理程序。传输处理

38、程序有两种类型：TransportListener 从传输层接收 SOAP 消息，然后将其传送到 InPipe 进行处理。TransportSender 发送通过指定传输从 OutPipe 接收到的 SOAP 消息。736.4.2 Axis2基础二、Axis2体系结构6. 客户端API：Axis2 客户端 API 调用遵循 WSDL 2.0 定义的 In-Only 和 In-Out 消息模式的操作。客户端 API 支持 In-Out 操作的阻塞和非阻塞调用。 746.4.2 Axis2基础二、Axis2体系结构7.核心生成模型：此模块从 WSDL 文件中生成客户端存根和服务器框架代码。Axis

39、2 代码生成器发出采用正确 XML 样式表的 XML 文件，以用所需语言生成代码。 756.4.3 深度探索Axis2：AXIOMAXIOM文档对象模型是Apache Axis2 Web服务的基础。下面我们将介绍 AXIOM 的工作原理、Axis2 的各个部分如何构建于 AXIOM 之上，以及 AXIOM 与其他的 Java文档对象模型的性能比较。766.4.3 深度探索Axis2：AXIOM一、为什么需要另一种文档模型？AXIOM 是 Axis2 中一个主要的创新，并且是 Axis2 能够比原来的 Axis 提供更好性能的原因之一。每种模型都声称与其他模型相比具有某些优点，要么是在性能、灵活

40、性方面，要么是在严格遵守 XML 标准的程度方面，并且每种模型都拥有忠实的支持者。那么，Axis2 为什么需要一种新的模型呢？答案在于 SOAP 消息的结构，尤其是如何在基本的 SOAP 框架中添加相应的扩展。776.4.3 深度探索Axis2：AXIOM1.SOAP简介SOAP 本身仅仅只是 XML 应用程序负载的简单包装。图1 提供了一个示例，其中只有那些具有 soapenv 前缀的元素才真正是 SOAP 中定义的。文档中大部分是应用程序数据，这些数据组成了 soapenv:Body 元素的内容。图1：SOAP示例786.4.3 深度探索Axis2：AXIOM1.SOAP简介尽管基本的 S

41、OAP 包装非常简单，但是通过使用称为 Header 的可选组件，它提供了不受限制的扩展能力。Header 为添加各种各样的元数据提供了合适的位置，这些元数据与应用程序数据在一起，不会被应用程序看到。796.4.3 深度探索Axis2：AXIOM1.SOAP简介图2 显示了与图 1 SOAP 示例相同的应用程序数据，但其中包括 WS-Addressing 信息。尽管原始的 SOAP 消息只能用于 HTTP 传输（因为 HTTP 提供了双向的连接，使得响应可以立即发送回客户端），但图 2 中的版本可以用于其他协议，因为 SOAP 请求消息中直接包括了响应元数据。806.4.3 深度探索Axis2

42、：AXIOM1.SOAP简介图2：使用WS-Addressing的SOAP示例816.4.3 深度探索Axis2：AXIOM2.文档模型面临的一个进退两难的问题因为 SOAP Header 的关键思想是允许在消息中添加任何元数据，所以 SOAP 框架必须能够接受某些扩展需要添加的任何内容。一般来说，处理任意的 XML 的最简单方法是使用某种形式的文档模型，这正是文档模型的任务所在，即不对该 XML 的形式进行任何假设，如实地表示 XML。826.4.3 深度探索Axis2：AXIOM2.文档模型面临的一个进退两难的问题但是对于处理在不同应用程序之间进行数据交换时所使用的 XML 来说，文档模型

43、并不是一种非常高效的方法。通常，应用程序数据具有预定义的结构，并且大多数开发人员更倾向于以数据对象而不是原始的 XML 的形式对这些数据进行处理。数据对象和 XML 之间的转换任务由数据绑定负责完成。与使用文档模型相比，数据绑定为开发人员带来了更大的方便，同时，它在性能和内存使用方面的效率也更高。836.4.3 深度探索Axis2：AXIOM2.文档模型面临的一个进退两难的问题所以，大多数应用程序希望使用数据绑定来处理 SOAP 消息的应用程序负载，但是对于处理 Header 中的元数据，使用文档模型的方法更合适。理想的方法是在 SOAP 框架中同时使用这两种技术，但普通的文档模型不支持这种用

44、法。它们希望处理整个文档，或者至少是文档中一个完整的子树。它们无法处理文档中所选的部分，但这是处理 SOAP 的最合适的方式。846.4.3 深度探索Axis2：AXIOM3.以“拉”方式构建AXIOM树原始的 Axis 使用标准的推式 (SAX) 解析器进行 XML 处理，而 Axis2 使用拉式 (StAX) 解析器。在使用推方式的情况下，由解析器来控制解析操作，需要向解析器提供要解析的文档和处理程序。相反，在使用拉方式的情况下，解析器实际上是一个高效的迭代器，可以根据需要对文档中的不同部分进行遍历。856.4.3 深度探索Axis2：AXIOM3.以“拉”方式构建AXIOM树AXIOM

45、构建于 StAX 拉式解析器接口的基础之上。AXIOM 提供了一种可以按需扩展的虚拟文档模型，仅构建客户端应用程序所请求的树结构文档模型表示。这种虚拟的文档模型工作于 XML 文档的元素级。当解析器报告元素开始标记时创建元素表示，但是该元素的初始形式仅仅只是一个壳，其中保存了对解析器的引用。866.4.3 深度探索Axis2：AXIOM二、使用AXIOM就所提供的 API 而言，所有的 XML 文档模型都具有很多相同之处，但是与其他的文档模型相比，它们又各有千秋。原始的 W3C 文档对象模型 (DOM) 设计提供跨语言和跨平台的兼容性。JDOM 使用了具体类而不是接口，并且在这种 API 中集

46、成了标准的 Java 集合类。876.4.3 深度探索Axis2：AXIOMdom4j 将类似 DOM 的接口和 Java 集合类组合到一起，这种非常灵活的 API 提供了很多强大的功能，但却在一定的程度上增加了复杂性。 AXIOM 与其他文档模型有许多相似之处。它还具有一些与其按需构建的处理过程相关的显著特征，以及支持其用于 Web 服务的专门特性。886.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM与 DOM 和 dom4j 一样，AXIOM 使用接口定义了用于访问和操作树表示的 API。为了简要地了解实际应用中的 AXIOM API，我们将对一些示例进行研究，这些示例

47、来自于对 AXIOM 与其他的文档模型进行性能测试对比的代码。896.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM图3中提供了第一个示例，这个示例基于为输入文档构建 AXIOM 表示的代码。图3 中的代码选择了 AXIOM 接口的基本链表实现。这个工厂接口包括用于从各种来源直接构建文档的方法、用于创建 XML 文档表示的不同部分的方法。图 3 使用了相应的方法从输入流构建文档。906.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM如图3：将文档解析为AXIOM916.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM图4提供了用于遍历文档表示

48、中的元素并累计摘要信息（元素的计数，属性值文本的计数和总长度，以及文本内容的计数和总长度）的代码。底部的 walk() 方法接受需要进行汇总的文档以及摘要数据结构作为参数，而顶部的 walkElement() 方法则处理一个元素（递归地调用自己以便对子元素进行处理）。926.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM如图4：导航AXIOM936.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM最后，图 5 给出了用于将该文档表示转换为输出流的代码。作为 OMNode 接口的一部分，AXIOM 定义了许多输出方法，包括针对各种不同的目标（如输出流、普通字符写

49、入程序、或 StAX 流写入程序），带和不带格式信息，带和不带在写入之后访问文档表示的功能。946.4.3 深度探索Axis2：AXIOM1.实际应用中的AXIOM如图5：从AXIOM写入文档通过从元素中获得 StAX 解析器，OMElement 接口定义了另一种访问文档信息的方法。这种使用解析器从文档表示中提取 XML 的能力提供了很好的对称性，当按需构建 AXIOM 表示时，这种方式非常合适。956.4.3 深度探索Axis2：AXIOM2.AXIOM中的MTOMAXIOM 的最有趣的特性之一是，它对 SOAP 附件最新版本中所使用的 W3C XOP 和 MTOM 标准提供了内置的支持。这

50、两种标准协同工作，其中 XOP（XML 二进制优化打包，XML-binary Optimized Packaging）提供了一种方式，使得 XML 文档在逻辑上可以包含任意二进制数据的大对象。966.4.3 深度探索Axis2：AXIOM2.AXIOM中的MTOM而 MTOM（SOAP 消息传输优化机制，SOAP Message Transmission Optimization Mechanism）则将 XOP 技术应用于 SOAP 消息。XOP 和 MTOM 都是新一代 Web 服务框架的关键特性，因为它们最终提供了可互操作的附件支持以及解决本领域中当前问题的能力。976.4.3 深度探索

51、Axis2：AXIOM2.AXIOM中的MTOMMTOM 构建于 XOP 之上。首先定义了一个抽象的模型，表示如何将 XOP 用于 SOAP 消息，然后对该模型进行特殊化使其专门用于 MIME Multipart/Related 打包，最后将其应用于 HTTP 传输。通过这些处理，它提供了一种标准的方式，通过广泛使用的 HTTP 传输将 XOP 应用于 SOAP 消息。 986.4.3 深度探索Axis2：AXIOM3.数据绑定挂钩 大多数 Web 服务开发人员需要以 Java 对象而不是 XML 文档的形式使用数据。Web 服务框架中的数据绑定实现通常无法与专门的数据绑定框架相比，所以希望更

52、好地控制 XML 处理过程的用户不得不将该框架与低效的转换代码结合在一起。因为这些问题，Axis2 重新进行了设计，以支持使用各种数据绑定框架作为数据绑定“插件”。996.4.3 深度探索Axis2：AXIOM3.数据绑定挂钩 这种数据绑定支持使用对 Axis2 中包含的 WSDL2Java 工具的自定义扩展。该工具基于 WSDL 服务描述为客户端或服务器端消息接收者以存根的形式生成 Axis2 连接代码。客户端存根可作为代理进行服务的调用，它定义了实现服务操作的方法调用。服务器端消息接收者可作为客户端的代理，调用实际的用户定义的服务方法。1006.4.4 Axis2数据绑定 Apache A

53、xis2 Web 服务框架的一个主要优势在于，此框架从最开始就设计为使用各种数据绑定方法，并使用此方法来处理 XML 与数据结构间的转换，同时使用 Axis2 框架来处理实际的 Web 服务工作。下面我们将说明如何将这些不同的数据绑定方法与 Axis2 结合使用。1016.4.4 Axis2数据绑定数据绑定 是指处理 XML 和应用程序数据结构间的转换的技术。可以为应用程序编写自定义数据绑定代码，但大部分开发人员发现使用数据绑定框架更为方便，此类框架将以通用的方式处理此转换工作，适用于各种应用程序。1026.4.4 Axis2数据绑定一、链接到Axis2在上一节中，我们已经了解了 Axis2

54、用于 XML 消息绑定的 AXIOM 文档模型。AXIOM 与其他文档模型的不同之处在于，它支持根据需要绑定模型，而不用一次性完成此工作。当使用数据绑定框架在 XML 和应用程序数据结构之间进行转换时，数据绑定 XML 通常只是 AXIOM 文档模型的一个虚拟部件。1036.4.4 Axis2数据绑定Axis2 可为服务客户机和服务提供者生成链接代码。客户机链接代码采用存根类的形式。服务提供者链接代码采用服务特定的实现框架的形式提供。客户机和服务器链接代码生成工作都由 WSDL2Java 工具进行处理。1046.4.4 Axis2数据绑定1.客户机链接代码客户端存根代码为应用程序代码定义访问方

55、法，以调用服务操作。首先要创建存根类的实例，通常使用缺省构造函数，或使用接受以字符串形式提供的其他端点引用的构造函数进行此工作。然后可以调用服务特定的访问方法来实际调用操作。1056.4.4 Axis2数据绑定1.客户机链接代码除了存根类外，还有为客户机代码生成的接口。可以直接使用存根，还可以使用接口来仅仅使用属于服务定义的方法。无论采用哪种方式，调用服务方法时，存根都将使用所选数据绑定框架处理将请求数据对象转换为 XML，以及将返回的 XML 转换为响应数据对象的工作。1066.4.4 Axis2数据绑定2.服务器链接代码Axis2 的服务器端链接代码是作为 Axis2 服务器配置的一部分定

56、义的消息接收器类。此消息接收器必须实现消息接收接口。此接口定义单个接收方法。在接收到请求消息时，Axis2 框架将调用此方法，然后由此方法负责处理请求的所有处理工作。1076.4.4 Axis2数据绑定如果直接使用 XML（采用 AXIOM 元素的形式），则可以利用服务器端链接的标准类之一。否则，就可以使用生成的消息接收器类，其在基于 Axis2 AXIOM 的接口和使用数据对象的服务代码之间进行适配。此服务代码以框架实现的形式生成，其中包含直接引发异常的服务方法。我们需要向框架添加自己的代码，以完成服务器端挂钩。1086.4.4 Axis2数据绑定二、Axis2工具Axis2 提供了一系列工

57、具来帮助开发人员使用此框架。其中最重要的是：1.从现有 Java 代码生成 WSDL 服务定义的工具2.允许从 WSDL 服务定义生成 Java 链接代码的工具。1096.4.4 Axis2数据绑定1.从现有 Java 代码生成 WSDL 服务定义的工具Axis2 提供了 Java2WSDL 工具，可用于从现有服务代码生成 WSDL 服务定义。不过，此工具有很多限制，包括无法使用 Java 集合类以及在从 Java 类生成的 XML 的结构处理方面不灵活。1106.4.4 Axis2数据绑定2.从 WSDL生成代码Axis2 提供了 WSDL2Java 工具，用于从 WSDL 服务定义生成代码

58、。WSDL2Java 提供很多不同的命令行选项，在Axis2 文档包括了选项的完整参考。1116.4.4 Axis2数据绑定三、数据绑定的比较1.Axis2数据绑定（ADB）ADB是 Axis2 的数据绑定扩展，并且构建于位于Axis2核心的Axis对象模型（AXIOM）之上。与其他数据绑定框架不同，ADB 代码仅可用于 Axis2 Web 服务。ADB 还提供了一些增强功能，包括自动附件处理。1126.4.4 Axis2数据绑定2.ADB取消包装为服务定义的操作实际上等效于接口定义中的方法调用。唯一的区别在于，服务将输入和输出定义为 XML 消息，而不是调用参数和返回值。当对合适的 WSDL

59、 服务定义使用取消包装操作时，生成的客户机存根（以及服务器代码框架）将更为简单和直接。1136.4.4 Axis2数据绑定3.XML BeansXMLBeans 是包含数据绑定层的通用 XML 处理框架。对于几乎任何模式构造，XMLBeans 都生成了一组能用于读写匹配此模式的文档。但与其他数据绑定框架不同的是，XMLBeans 缺省情况下并不进行任何工作来执行模式。1146.4.4 Axis2数据绑定4.JiBXJiBX是主要侧重使用现有 Java 类（而不是从模式进行代码生成）的数据绑定框架。JiBX 是唯一支持使用现有 Java 类的备选方案。另外还提供了对取消包装服务方法出色的支持。但

60、集成到 Axis2 中的 JiBX 支持并不处理从模式生成代码的情况，甚至 JiBX 工具所提供的从模式生成代码的独立支持目前还仅限于模式支持。 1156.5 IBM WebSphere服务引擎1166.5.1 Java Web服务的主流编程模式JAX-RPCWeb服务所支持的JAX-RPC兼容性，是基于Java实现的主流web服务引擎所必需提供的。JAX-RPC（Java API for XML-based RPC）是Java世界的web服务编程模型的规范，它规范了如何以类似RPC的方式调用web服务。JAX-RPC涉及使用Java语言的web服务定义语言（WSDL）的编程模型和绑定，通过屏