发表于 2004年5/6月号

管理Web服务
作者：Mike Lehmann

利用基于SOAP的线上消息管理优势

如果你认为业界对"Web服务"一词的定义不够准确，那么你就努力去找到一个确切Web服务管理的定义吧。有人认为Web服务管理和Web服务配置、监控、审计和登录一样简单。另外一些人则说的更为抽象一些，他们使用诸如服务虚拟化、通知、协议调解和供给等一些术语。

让我们来研究一下这方面的问题,只要你从处理少数Web服务转向处理更正式的商务应用方案，就会涉及到这类问题在这些更正式的商务方案中，一个商务流程或一个复合应用里经常会有大量的Web服务绑在一起使用。

Web服务组件管理

在最低层次上，一个Web服务仅仅是在你的后端信息基础设施上执行的另一个程序。从管理的角度来看，你会希望一个平台能为Web服务管理提供一些核心的基础功能，其中包括部署、配置和安全支持，以及一些基本的监控和诊断功能。

有了Oracle应用服务器控制--Oracle应用服务器10g的管理控制台,就包括了所有这些基本功能,如图1所示。利用这一基于浏览器的环境，你可以很容易地管理任何J2EE Web服务。

随着本行业对J2EE 1.4的采用，这一控制台将向前发展，以便开发人员能够配置和监控JAX-RPC标准的所有新技术，其中包括JSR 109配置、JAX-RPC处理器（handlers），以及进一步发展来支持Web服务的可靠性、事务处理和安全性。这一集成化的管理控制台体现了将JAX-RPC作为J2EE的一部分进行标准化的重要价值--J2EE服务器所提供的管理基础设施就像应用于经典J2EE组件那样，同样也能很好地应用于各种Web服务。

在J2EE 10g (OC4J) Developer Preview 10.0.3的Oracle应用服务器容器中，我已经建立了一些JAX-RPC实例，请见"下一步"），已经将作为应用服务器控制基础的管理基础设施扩展成包含Java管理扩展（Java Management Extensions，JMX）。在这里，以前的功能仍然可用，但是新的管理控制台将通过标准JMX Mbeans来配置和监控Web服务。要通过一个JMS浏览器直接查看Web服务的MBeans，可到OC4J 10.0.3 Developer Preview的http://127.0.0.1:8888/adminoc4j上查询Web服务MBeans。

与SOAP的区别

尽管将Web服务作为一个组件进行管理为管理Web服务提供了一个令人感兴趣的开端，但它忽视了一个关键的方面，那就是大多数Web服务不同于基于二进制协议的编程模型，如CORBA和DCOM：Web服务是一种消息传递技术，在这种技术中，线上的消息是基于XML的（简单对象访问协议［SOAP］），并由XML描述（Web服务描述语言［WSDL］）。

在我最近的专栏中，我解释了如何编写一个JAX-RPC处理器以进行基于内容的SOAP登录和审计。该方法的优势是能够解释、查询和管理一个正在发往其目的地的原始XML消息。

尽管这一方法具有全面访问线上消息的直接吸引力，但它却有一些问题。例如，对于诸如登录或审计之类比较普通的应用，它并不是特别简单和清晰--必须为每一个Web服务定制编写一个处理器并对其进行配置。尽管处理器可以使一些困难问题的解决成为可能，但它们并不能使事情变得简单。

如果你退几步设想一下，在一个异构的环境中运行Web服务（就像Web服务的最常见应用情况那样），因为其核心是一种集成技术，所以处理器更容易出现问题。因为它们是专门针对JAX-RPC设计的，所以如果你的Web服务终端是用C、Visual BASIC或Perl实现的，那么这些处理器就不能正常工作。

原始入站SOAP消息主体	具有新参数的SOAP消息主体
... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> </ns0:getEmpSalaryElement> </env:Body> ...	... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> <salary_type>Commission</salary_type> </ns0:getEmpSalaryElement> </env:Body> ...

管理消息

一个更通用的方法是在服务使用者和服务提供者之间放置一个媒介。截取线级（wire－level）通信量进行带外处理并不是一个新的概念。这种概念已在Web领域通过硬件和软件用于实现负载平衡、加速、路由和缓冲。

一旦你意识到你不仅可以检查和处理SOAP消息的内容，而且通过WSDL还可以深入理解该消息的格式、操作及其终点，那么这一方法的消息管理能力非常令人感兴趣。

例如，以我最近的专栏中所述的员工工资服务为基础举一个简单的应用实例。该服务获取一个员工号并返回相应的工资信息。设想在经过数月的操作之后，公司内的几个主要部门都开始使用这个服务，而且许多人都要求它还要包含佣金信息。开发人员决定要求这一服务的使用者们修改入站消息（该消息以前只是一个员工号），以包含一个另外的参数<salary_type>，来指明是要返回工资还是返回佣金或是两者都返回。表2给出了这两种格式之间的区别。

在理想的情况下，Web服务的提供者和使用者会同时修改其环境来支持新的参数，并将系统升级。在Web服务领域，提供者与使用者通常具有不同的工作重点和优先次序，他们的升级日程安排互不相关、基础设施难以改变，这些升级的保障条件也互不相同。

解决这些问题的方案是什么呢？ 从管理层面说有许多选项可用来理解线上消息。一个选项是在线上查找具有老标记的消息，并将他们发送至一个老的实现，这是一种简单的版本说明解决方案。另一种方法是将没有<salary_type>参数的老格式的消息进行转换来包含一个默认值。这种实现的抽象称作服务虚拟化。

这一方法的结果是服务提供者可以按照一个与服务使用者无关的时间安排进行升级。而更大的好处是，因为管理过程是在线上发生的，与实施无关，所以即使你的后端环境包含一些异构的Web服务实现，也有可能进行升级。相应地，服务使用者可以选择根据其自己的时间安排进行升级或利用新的特性。

下一步 下载OC4J 参阅与本文有关的一些示例 阅读更多关于Oracle应用服务器的资料

这一基础设施有很多实际用途。如果你的服务使用者需要传送SOAP消息，但你已经不能升级你的基于二进制的后端基础设施了，那么应当怎么做呢？ 你可以使用这一方法在后端的入站SOAP协议与二进制协议之间进行中介传送。或者，你可以根据发送该消息的服务使用者的类型或者安排机器升级周期的必要性等这样一些因素，将该消息发送至不同的机器。

正是有了这种想法，才出现了很多关于Web服务管理的非常夸张的流程和新兴的实现原型。这些是在可靠性、安全性、事务处理、网格计算，甚至是商务流程管理等方面对其他新兴Web服务标准的自然补充。但是需要记住的重要事情是：这并非不可思议；这只是对Web服务带给人们的固有特性的利用和创新。

标准，标准，还是标准

能够将Web服务作为资源进行管理方面现在已经有了具体的研究成果。大多数厂商追求的标准是适用于分布式管理的Web服务（Web Services for Distributed Management，WSDM），即一种针对Web服务的OASIS技术成果，就像用于J2EE应用程序的Java Management Extensions (JMX)那样：提供一种与厂商和实施无关的方法来将异构的各种Web服务当作可管理的资源来管理。

该标准实际上将会转变为一组Web服务和每个Web服务的实施预期将提供的一些操作--配置、监控和其他管理任务的操作。如果按照标准进行实施，则任何Web服务都将能够由一个遵循WSDM标准的管理基础设施进行管理。

OASIS WSDM技术委员会于2003年2月开始了各项标准的制定工作，并在继续制定1.0标准，这一标准有望在2004年中制定完成。

在Oracle应用服务器的下一个主要版本中，将把Web服务管理看作是一个预期会得到越来越重视的领域。