互操作性是实现Web服务的一个充分理由。
但是，一旦安装并开始使用一些Web服务，如何利用它们的互操作性来管理它们呢？也就是说，倒不如将Web服务仅仅当成应用程序堆栈中的另一层，那么如何使用Web服务来管理Web服务呢？如果这么做，那么使用Web服务的互操作性来管理那些跨整个企业的不同资源，从而简化整个操作管理的时候，哪些东西将是必需的呢？
本文研究管理生产Web服务以及使用基于Web服务的解决方案管理生产环境所涉及的一些技术方面的考虑。我将关注一些最新的Web服务管理工具方法和关于处于发展中的Web服务管理规范的前景。此外，我将给出几个针对Java 2 Platform, Enterprise Edition (J2EE) 和.NET框架的、简单的、需要自己编码的管理示例。
典型的管理架构由两种组件构成：一个管理器和任意数量的代理或者观察器，一个代理或观察器对应于一个受观察元素。管理器通知代理应该观察什么。在满足某些条件或者达到某个阈值时，代理向管理器或者管理员发送警报。管理器可以向代理程序查询管理数据。管理员可以查看管理器用户界面中的日志和报告。
您可以看到，受观察的元素并不一定要是一个Web服务、客户机或者Web服务基础架构。无论观察的是什么，在彼此公开Web服务接口的代理和管理器中进行观察都是有价值的。典型的情况是在多个平台上有不同代理的时候。单一的管理器从不同的J2EE应用服务器中收集数据，而且可以运行ASP.NET安装IIS。
代理和应用服务器
如果我们限制自己仅观察Web服务，而不是观察客户机，那么一个代理观察一台服务器就是一种很自然的安排，这样就可能观察任意数量的Web服务。但是随后，相对于服务器，我们应该将代理放在哪里呢？
Michael Hui是Unicenter Web Services Distributed Management (WSDM)——Computer Associates的Web服务管理工具的产品经理，他指出了两种可能的布置：
- 本机：可以将代理嵌入到服务器中。当控制权随传入的请求到达代理的时候，服务器基础设施已经处理了请求的传输协议（通常是HTTP）并且解析了简单对象访问协议（SOAP）信息的XML。代理在反向操作中访问相应处理点上的传出响应。
- 代理：代理截获在线的、在应用服务器外的SOAP消息。
当然，本机观察器可以提供优越的性能，因为它能够担负应用服务器无论如何都必须做的工作。Unicenter WSDM 和其他大多数Web服务管理工具都是这样实现的。只有与消息处理的硬件实现相结合，从而减轻性能损耗的时候，Unicenter WSDM的代理版本才能存在。
这里的硬件主要用于加密和解密。否则，如果想监视有序的数据，就必须本地化。对于像安全套接层（SSL）那样的传输级安全，那是轻而易举的事。Web服务器，比如说IIS，负责在外层加密和解密。对于消息级安全，SOAP的消息体是使用诸如WS－Security之类的方案来加密和签名的，显然，目的地的监视代理仍然应该接收传入的后加密的消息。即使这样，当输出到一个日志中时，管理工具应该能够对敏感的数据进行混编。
要实现本地化则需求针对不同应用服务器使用不同版本的代理。得到最广泛支持的服务器是Microsoft IIS、IBM WebSphere和BEA WebLogic Server。即使某个代理实现了最新的J2EE规范，不同J2EE应用服务器之间的可移植性问题仍未得到很好的解决。
这样的代理是与Service Integrity's SIFT一起提供的；该软件的2.0版在其最终beta版中。 对于WebLogic Server 和 WebSphere, SIFT 服务器组件实现了一个标准的servlet过滤器，用它来监视HTTP的通信量。它可以实现了一个JAX-RPC处理程序，在应用程序服务器已经解析传入请求的SOAP但还没有调用Web服务实现方法之前，对传入请求的SOAP进行封装，就像J2EE1.4中规定的那样。（这是处理传出SOAP响应的反向操作。）
为了编制（或者管理）WebLogic Server中的企业应用程序，SIFT采用了EAR中的每一个WAR文件（或者Enterprise JavaBeans [EJB] JAR），并在web.xml部署描述符中指定了一个servlet过滤器，而且还在web-services.xml中指定了一个JAX-RPC处理程序，SIFT还插入了一个小的插件JAR。在WebSphere中，可以使用不同文件中的不同模式指定JAX-RPC处理程序，webservices.xml（没有连字符）。（对于IIS 6上的ASP.NET，SIFT使用HTTP模块。）
管理您自己的Web服务
通过使用J2EE，servlet过滤器结构通常允许您为Web应用程序编写自己的监视、登录和警告代码。JAX-RPC处理程序的结构允许您特地为Web服务编写自己的管理代码。
这是不是意味着您应该一切从头做起呢？当然，这个工具不像SIFT 2.0或者市场上其他管理工具那样复杂。但是过滤器和处理程序允许您添加这样的工具，或者满足您自己更为简单的管理需要。
可以通过定义实现javax.xml.rpc.handler.Handler接口的类来使用JAX-RPC 处理程序，这个接口包含像handleRequest()和 handleResponse()这样的方法。或者您可以扩展一个GenericHandler抽象类，这个类中包含哑方法 (dummy method) 的实现，这样您就可以只实现那些想要定制的方法。
以下是一个调用自定义跟踪方法的handleRequest()的实现：
public boolean
handleRequest(MessageContext mc) {
SOAPMessageContext messageContext =
(SOAPMessageContext) mc;
trace(messageContext.getMessage().toString());
return true;
}
MessageContext和SOAPMessageContext类分别在javax.xml.rpc.handler和javax.xml.rpc.handler.soap包中定义的。
Handler实现也可以使用HandlerInfo 类存储关于处理程序的额外信息。例如，HandlerInfo类中包含setHeaders()和getHeaders()方法，在那里您可以指定处理程序处理的任何SOAP头代码块。
Handler init()方法被传递给一个 HandlerInfo对象，您可以将该对象定义为一个成员变量。下面的例子中应用了HandlerInfo的一个成员变量作为mHandlerInfo：
public void init(HandlerInfo hi) {
mHandlerInfo = hi;
}
在WebLogic Server上，可以在Web应用程序的web-services.xml文件中指定处理程序。并且可以在根Web服务元素中指定一个处理程序链元素：
<handler-chains>
<handler-chain name="TraceHandlerChain">
<handler class-name="test.TraceHandler" />
</handler-chain>
</handler-chains>
此外，对于每一个您要在其上使用处理程序链的Web服务程序方法，都需要使用与某个操作元素有关的处理程序链属性，通过名称来指定一个处理程序链。有关的更多细节，请参阅WebLogic Server安装中的一些web-services.xml示例文件。
微观管理
在.NET Framework一端，您可以实现抽象的System.Web.Services.Protocols.SoapExtension类，以便在处理过程中检查和修改SOAP消息。
当扩展 SoapExtension时，必须实现ProcessMessage()方法：
public abstract void
ProcessMessage(SoapMessage message);
参数 SoapMessage的类型可以是SoapClientMessage或者SoapServerMessage。
这个方法可以在SOAP消息的4个处理阶段中的任意一个阶段中调用，就像通过SoapMessageStage枚举的成员指定的那样，这些成员是：BeforeDeserialize、AfterDeserialize、BeforeSerialize以及AfterSerialize。SoapMessageStage.AfterSerialize和SoapMessageStage.BeforeDeserialize的值可以访问在线发送的数据流。ProcessMessage()实现应该使用SoapMessage对象的Stage属性来查看处于哪一个阶段中。（要获得更高的优先级，则需要重写ChainStream()方法。）
一旦已经从SoapExtension中派生了出一个类，您就能用两种方法指出它的运行时间：
- 利用可应用配置文件（通常是Web.confi）的soapExtensionTypes元素中的一个附加元素指定SOAP扩展。这样就可以使用配置文件作用域的所有Web服务运行它。
- 定义一个实现抽象类SoapExtensionAttribute的类。这意味着实现ExtensionType属性，以返回SoapExtension的类型。然后将该属性应用于Web服务方法或者客户机代理类方法。
Web服务不仅仅只是Web服务
现在回到相互公开Web服务接口的代理和管理器的定义上来。这就是STFT所做的工作，即允许自己的管理器 SIFT Console提供对ASP.NET和J2EE Web服务的统一管理看法。
现在，进行下一个逻辑步骤并且换出要管理的事件。代理和管理器仍然可以作为一个可彼此交换的Web服务和客户机，但是现在，它们管理的内容不再只是Web服务，而是可能包括整个IT基础架构。
为了管理服务器系统的若干方面，微软提供了Microsoft Operations Manager (MOM) 2000 应用程序。去年秋天，微软引入了MOM Connector Framework (MCF)，MCF的任务只有一个，使MOM 2000被看作是一项Web服务。与此同时，微软和其他软件供应商推出了“产品连接器”，以谐调MOM/MCF API与其他供应商管理工具的API。结果，MOM 2000可以利用其他管理系统进行双向警告。
在检查为定义MCFWeb服务而生成的Web服务描述语言（WSDL）时，您会发现，其中的内容并没有什么是真正以Web服务为中心的。它定义了一个ConnectorService，在其他操作中，ConnectorService有一个可以请求一系列新的和旧的警告的GetData操作。警告XML Schema类型定义了27种子元素，所用这些元素都与Windows企业相关。
Web服务的管理潜能
一个关于Web服务如何提供互操作管理的寻求自我革新的观点是具体化WS-Manageability规范，这个规范是的目标是描述如何才能使用Web服务管理Web服务。OASIS的Web Services Distributed Management (WSDM) 技术委员会是一个活跃于Web服务的标准组织，目前，该组织正在开发WS-Manageability，并十分关注未来如何使用相同的Web服务标准管理其他IT资源。
尽管MOM产品连接器维护了许多链接回MOM 2000的母系链，并且WS-Manageability承诺提供一种“任意到任意”的互操作性。但是现在，Unicenter Web服务管理器有了自己专有的WSDL。计算机协会的Hui解释说，尽管来自分散各处的服务器，但只有Unicenter的代理才可以与之通信。他说，使用WS-Manageability，任何Web服务程序管理提供者的代理都可以与任何其他提供者的管理器进行通信。代理WSDL和管理器WSDL将被标准化。
WS-Manageability的实现虽然还不存在，但在像BEA Systems、计算机协会、Hewlett-Packard和IBM这些组织都在计算机委员会中得到了很好的体现，微软未被包括在内，但它正在努力。
这种利益和竞争为管理Web服务提供了更多的保证。但是Web服务协议能成为操作管理的未来共同语吗？最后，至少在应用程序可以读写SOAP消息的更高级别上，Web服务协议应该是这样的。
同时，现在的Web服务管理工具组提供了与其姐妹产品或者更原始的管理协议（比如简单网络管理协议，即SNMP）的整合。Web服务管理工具可以在告警条件下向SNMP管理器发出一个陷阱（trap），这很普遍。
从长远角度来看，只要您安于现状，那么Web服务最终是否渗透操作管理也就没什么关系了。如果您的中心管理工具能够透明地与其他管理器和代理交换数据，那么谁还关心它们是如何交互数据的呢？
|
