Services在WebLogic 8.1 SP2上的实现

Web Services是松散耦合的、面向服务的应用程序，能够在Web上动态地交互。该方法使您能够为分布式的、基于Web的应用程序创建共享的动态组件，并且增加了灵活性，能够将较大的软件系统分为较小的模块化组件。通常，这些组件与现有的后端应用程序接合，迄今为止，对于外部的软件应用程序而言，这些后端应用程序被认为是封闭的。

Web Services的概念实际上就是对诸如RMI、COM和CORBA等现有面向服务的技术的扩展，同时结合了以下针对异构环境的属性：

· 通过使用标准的Internet协议（例如HTTP / s）的XML消息进行通信。

因此，Web Services的评估带来了互操作性、容易而又广泛的可访问性，以及跨平台、跨语言的数据建模（XML）方法，使开发异构分布式应用程序变得容易。

· 在Web Services和客户之间传送数据和通信的标准。

这就强调了报文格式和连接协议的标准。这通过简单对象访问协议（SOAP）处理，简单对象访问协议是一种轻量级的基于XML的协议，用于在分散型、分布式的环境中交换信息。该协议由描述SOAP消息的一个封装组成。这个封装包含消息的主体，它定义了所有权和处理细节。为了表示特定应用程序的数据类型的实例，以及表现远程过程调用和响应的约定，需要一套编码规则。

该信息被嵌入多用途Internet邮件扩展（MIME）编码包里，可以通过HTTP或者其他Web 协议进行传输。MIME是格式化非ASCII消息的一种规范，以便它们可以通过Internet传送。

· WSDL（Web Services描述语言）提供了一种标准，用来为客户描述Web Services。这是一种基于XML的规范，它描述了Web Services的操作、输入和输出参数，以及客户应用程序连接Web Services的方法。

· 为了确保安全的Web Services，需要一种数字签名或者加密SOAP请求和响应的标准。

· 统一描述、发现和集成（UDDI 2.0）规范提供发现和注册Web Services的标准。

一个系统可能由在不同的硬件和环境中运行的多个应用程序和Web Services应用程序组成。从性能的角度来看，我们需要将注意力集中于单个的Web Services组件，他们的体系结构及其运行的环境。下面给出的是一种典型的Web Services场景。让我们来试图理解涉及Web Services操作的客户服务器通信中相关的事件。

1. 客户应用程序通过网络向应用程序服务器发出SOAP消息请求。

3. Web Services读取SOAP消息请求，并且识别它需要运行的操作。该操作对应于后端组件的一个方法，该方法将在以后的步骤中被调用。对于所调用的操作，来自SOAP消息的请求参数在Web Services层进行从XML到Java的转换。一个反序列化类被用来达到该目的。该反序列化类可以是由应用程序服务器为内置数据类型而提供的，也可以是用户为非内置数据类型所创建的。

5. 方法调用完毕之后，后端组件返回响应，由Web Services使用合适的序列化类将该响应从Java转换为XML，然后将它打包为SOAP消息响应。

6. Web Services将SOAP消息响应返回到调用Web Services的客户应用程序。

上述体系结构描述了一个非常基本的场景，但是由于各种各样原因，真正的Web Services能通过添加基于功能的中间组件，给系统内带来更多的复杂性。它们可能需要访问SOAP消息，进行处理、加密或者修改。SOAP消息处理程序正是为达到此目的而设计，它们提供了截取SOAP消息的机制。

依赖于用例的不同，SOAP消息处理程序能够提高或者负面影响性能。在这一层上，一个为静态响应内容而实现的高速缓冲策略，可以通过避免真实Web Services和后端方法调用来有助于提高性能。但是另一方面，使用加密/解密工作的处理程序保证在SOAP消息主体中数据的安全将造成额外的处理开销，并且会对性能造成负面影响。

组成Web Services系统的全部组件会影响性能，而正确理解各个组件的能力和局限性将有助于设计一个更好的系统。

下面的图表展示了通信中所涉及各个层。我们将讨论每一个层，并且评价可能的选择、能力、局限性以及对性能可能造成的影响。

这些对象负责事务方法的执行。在这个时期我们还不能将一切现有的J2EE组件的方法直接发布到Web Services操作中。目前，以下三个选择可以将现有的组件直接发布到Web Services操作：

无状态会话EJB：用这种方法实现的Web Services操作是接口驱动的，这表明底层的无状态会话EJB的事务方法决定了Web Services操作的工作方式。无状态会话EJB后端的特性如下：

· Web Services可以从EJB的功能中受益，例如持久性、安全性、事务特性和并发性。

Java类：用Java类实现的Web Services操作类似于用EJB方法实现的那些Web Services操作。不过，创建Java类通常比创建EJB更简单、更快捷。作为后端组件，Java类避免了EJB 功能（例如持久性、安全性、事务特性和并发性）的开销。

将Java类作为Web Services发布几乎没有局限性和约束条件：

JMS消息使用者或产生者。Web Services操作能够为需要将数据发送至JMS 目的/队列或者从JMS目的/队列接收数据的客户而编写。请记住单个的Web Services操作不能既发送数据又接收数据；为了能够既发送数据又接收数据，需要为客户应用程序创建两个Web Services操作。因为在服务器上处理消息的最初驱动消息的bean把响应放在对应于接收Web Services操作的JMS目的处，所以发送的Web Services操作与用于接收的Web Services操作是相联系的。

虽然这里的选择比较有限，您可以编写新的组件来提供访问不能将自己发布到Web Services操作的其他现有组件的途径。然而，正确的组件选择将以应用程序的用例和特征要求为基础。

理解在这个层上是哪种数据类型用于方法也是重要的。有时，它们对后端组件的性能影响并不像它们对Web Services层的影响那样大，而Web Services层就在其最顶部。它们不仅影响Web Services子系统的复杂性，而且对性能和响应时间也产生影响。

我们将在下一部分里获悉更多有关于此的内容，理解它对系统的复杂性和性能会有什么样的影响。

理解这些后端组件如何与其他子系统和外部组件相互交互也是很重要的。例如，Web Services后端组件可能会与保存在其他硬件和不同环境中的数据库相互交互。在这个层上适当的调优和优化有助于将结果返回到正在等待响应的Web 服务层。

本层为客户请求识别正确的Web Services。它调用该服务，读取SOAP消息请求，并进一步确定将要调用的操作。XML解析是该过程中的一个开销大项。该操作对应于后端组件的一个方法。对于所调用的操作，来自SOAP消息的请求参数在反序列化类的帮助下进行从XML到Java的转换。在接收到返回的响应之后，该层在序列化类的帮助下将Java响应转换回XML，最后把该响应返回给客户。

让我们稍微深入地讨论数据类型，看一看它们怎样影响该层。Web Services操作既支持作为参数的内置和非内置数据类型，并且返回支持后端组件的方法签名的值。这表明如果Web Services可以用XML schema来表现，那么Web Services就能处理任何数据类型。内置数据类型是由JAX-RPC规范所指定的那些数据。

如果Web Services只使用内置数据类型，那么应用程序服务器将自动处理在XML 和Java之间的数据转换。但是，如果Web Services操作更复杂一些，并使用非内置数据类型作为参数或者返回值，那么就需要：

根据内置或非内置数据类型，使用反序列化/序列化类进行从XML 到Java或从Java到XML的数据转换。这种序列化/反序列化处理增加了请求处理的开销，并且影响性能（取决于如何实现）。

另外一个重要的决策是在面向RPC或者面向文档的Web Services之间作出选择。以下是对这两个类别的比较：

格式/类别	面向RPC	面向文档
子类目	无	标准 – 文档	文档 – 包装
SOAP消息	既包含参数又包含返回值	包含XML文档	包含XML文档
参数&返回类型	所允许的任何数目的参数	仅允许一个参数	所允许的任何数目的参数
所用编码	SOAP编码	文字编码	文字编码

· 标准的面向文档的Web Services操作只采用一个参数，通常是一份XML文档。这表明实现操作的方法也必须只有一个参数。但是，文档包装的Web Services操作可以采用许多参数，尽管其参数值将在SOAP消息里包装成一个复杂的数据类型。

· 在单个WebLogic Web Services里的全部操作必须不是面向RPC就是面向文档的； WebLogic Server不支持在同一Web Services内混合两种格式。

在默认情况下，WebLogic Web Services的操作是面向RPC的。您需要指明是否希望它们是面向文档的。

安全是另一个重要的组件，它影响性能。该规范提出一套标准的SOAP扩展，用来创建安全的Web Services，从而实现完整性和机密性。

该规范提供了三种主要的机制：安全令牌传播、消息完整性和消息机密性。这些机制本身不提供完整的安全解决方案。相反，Web Services安全作为一个组成部分，可以与其他Web Services扩展以及更高层的特定应用程序协议联合使用，以适应多种多样的安全模型和加密技术。

这些机制可以独立使用（例如，传递一个安全令牌），或者以紧密集成的方式使用（例如，签署和加密消息，并且提供与签署和加密所用的密钥相关的安全令牌级别）。

为了确保WebLogic Web Services的安全，对三个在概念上不同的安全类型进行类或者多类的配置：

消息级的安全（数字签名和加密）

消息级的安全指定是否应该数字式地签名或者加密在客户应用程序与它所调用的Web Services之间的SOAP消息。

传输级的安全（SSL）

传输级的安全是指确保客户应用程序与Web Services之间采用安全套接字协议层（SSL）的连接的安全性。如果需要服务器对客户应用程序出示一份证书，则可将此配置为单向SSL，或者如果需要客户应用程序与服务器相互出示证书，则可将此配置为双向SSL。

访问控制安全

访问控制安全是指通过配置Web Services来控制允许访问的那些用户。WebLogic Web Services作为标准J2EE企业应用程序进行打包。因此，为确保访问Web Services访问控制的安全性，可以在以下水平上进行配置：

正在试图访问WebLogic Web Services的客户可以使用基本的HTTP 认证或者SSL认证。因为许多先前的组件都是标准J2EE组件，您可以通过使用标准的J2EE安全过程来保证安全。如果实现Web Services的后端组件是Java类或者JMS监听器，那么确保Web Services安全的惟一方法是给整个Web Services添加安全约束，或者为调用Web Services的URL添加安全约束。

安全配置对的性能影响是一个广为人之的问题。这种影响因应用程序安全的不同而不同。一种常规的比较表明对启用SSL功能的HTTP的影响大约比对正常的HTTP协议的影响高30%。

调用Web Services是指客户应用程序为使用Web Services而采取的行动。您可以使用任何技术来编写调用Web Services的客户应用程序：Java、Microsoft SOAP Toolkit、Microsoft .NET，等等。

WebLogic Server提供可选的运行时客户JAR文件，为了便于您开发独立的客户应用程序，该JAR文件包括您调用Web Services所需的类。

在这里，我们将为独立的Java客户讨论可能的客户场景。这些客户可以分成以下几种类别：

静态客户：对于静态客户，您也能产生包含存根（stub）的特定Web Services的JAR文件，按照JAX-RPC规范定义客户应用程序用存根来静态地调用Web Services。这些存根实现JAX-RPC接口，例如存根和服务。请注意：这是为Web Services特别编写的，并且与其他不使用特定Web Services的JAR文件的客户或者实际上处于动态的客户相比较，这也能运行得很好。

动态客户：动态客户使用最小的一组Web Services类。他们提供通用的应用程序，能与任何基于其已发布属性的其他Web Services交互。他们不依赖于特定服务器的JAR文件和类进行通信，并且不受任何一个特定服务的约束。下面是动态客户的可能的场景：

下面是一个比较，其中不同的客户类（API）已经用于一个普通的动态Web Services客户。在这两种情况下都调用了一个“echoString”操作。这两种情况之间的惟一的差别是用于编译和提供运行时间环境的特定的Web Services客户端类。

适当的JVM调优对于在服务器上部署的Web Services是很必要的。对消息很大或者数据类型复杂的Web Services操作来说，要在服务器里创建许多临时的对象。这不仅需要对总的堆大小进行适当的调优，而且对于大的幼儿园（nursery）来说，处理这些临时的对象也需要配置。根据应用程序的性质，您需要为该堆内的老一代和年轻一代的对象空间微调适当的GC算法。

类似于服务器端JVM，客户端JVM在性能研究里具有非常重要的作用。解析、序列化/反序列化的开销也适用于客户。因此，请不要忘记在评价总体系统的性能时考虑客户JVM的影响。

下表给出对在WebLogic Server上调用相似操作的不同协议的性能比较。用一种sendString方法/操作来获得比较数据。在全部三个测试案例中，都有一个客户，用100 KB的字符串发出多个请求，并与服务器上运行的远程服务相互作用。该比较展示了以SOAP为基础的通信与其他流行的协议相比的性能。

上述分析突出了Web Services系统性能角度的不同重要属性。这项研究将有希望提供关于设定实际性能目标的信息，并且将有助于设计和构造Web Services应用程序，使其获得最佳的性能。

正如任何基准的练习一样，这些结果是从一种“实验室”环境里获得的。因此，使用不同的参数在不同的环境里运行相同的测试将产生不同的性能数据。读者应该将精力集中于不同基准场景之间的相对差异，借此获得比较图。