Web Services面临管理挑战（by AMT 周瑛 编译）

Web Services面临管理挑战

by AMT 周瑛 编译

随着Web Services在企业内的应用越来越广泛，有条理地对Web Services进行管理变得越来越重要。但是Web Services的管理原则以及支持这种管理原则的技术还远未成熟。

要搞清楚什么是Web Services的管理本身就是一项十分艰巨的任务。虽然业内对一些基本的管理特性已经达成了共识，但是Web Services的用例相对来讲还没有统一的定义。因此，怎样管理Web Services，能够达到什么样的目标也是一个未知数。目前的管理技术都是一些十分年轻的技术，即使是对以前的管理技术的扩展，也往往超出了以往的管理边界。

下面是MATA Group预测的Web Services管理的进展：

Web Services的管理需求正迅速成为对行业领导者的一个重要挑战。随着Web Services在各种环境中的应用越来越广泛，各种由于缺乏管理而在的潜在问题变得越来越突出。Web Services目前面临的情况与网站在1997年面临的情况是十分相似的。那个时候，几乎所有的技术都能够把HTML界面配置成一个网站。结果，产生了大量的缺乏管理的、质量控制和服务水平不一的站点，伴之而来的是高额的成本。很快很多公司就整合了基础设施和对这些网站的控制，并提供了相应的管理工具，整合了平台和架构，为管理好这些站点打好了基础。很可能在许多公司，Web Service会出现同样的情况。如果不考虑对Web Services进行管理，让Web Services自由发展增长的话，最后的结果只可能是一系列不可靠的Web Services。这一系列的Web Services最后必然需要在统一的基础设施、统一的开发平台上进行整合，这样才能保证它们能提供高水平的服务质量。但是 WebServices管理技术面临着一个重大挑战，那就是如何区分服务管理和Web Services的创建。

Web Services管理平台的一些功能是比较清晰的，相对来说没有什么争议。

首先管理平台必须能够定义和监控服务的质量。服务质量指标可以与其他的网络业务相似，可能包括吞吐量、响应时间、可用性、错误状况等。虽然还没有对具体参数的清晰定义，但把这项工作归给管理工具是合理的。可能这些指标会由Web Services本身通过一个标准应用接口来发布。但是当将这些传统的指标具体应用到具有Web Services特性的接口上时，问题就出现了。比如说，可用性到底是指什么？是指服务中的SOAP接听方接受请求，还是服务响应？如果是前者，可能对可用性的要求太高了，因为可能接听方是可用的而逻辑服务功能不可用；如果是后者，又定义得过于粗糙，没有实际意义。可能的一种情况是，Web Services的管理工具提供一种柔性的指标定义，对不同类型的请求使用不同的衡量指标，虽然目前市场上这样的基于指标的监控并不受欢迎。

其次，为了跟踪这些指标统计数据，Web Services管理平台必须能够监控进入和离开服务的SOAP信息流。这样才能跟踪有用的合计性能指标（平均吞吐量等），并实时更新这些指标，而不是使用历史数据来计算指标。在许多已经发布的管理工具中都使用了能够实现这种功能的架构，比如说Amberpoint, Talking Blocks, Flamenco, Actional。但你这种架构也引起了很多问题。如果管理平台需要对所有的SOAP信息流进行检视，那么为什么不让它对这些信息流进行其他的控制呢？正是在这里，管理工具应有的功能定义变得模糊。保证安全性是管理工具的功能吗？复杂服务的设计呢？负载平衡？生命周期控制？虽然上述的每一项功能都是Web Services需要的，但是许多其他的情况下，这些并不包括在管理工具中。尽管如此，在这种情况下，很可能要扩展管理的定义，把这些功能都包括进来。最终，针对信息的使用者，将形成工具和接口的新的分类。许多目前的Web services管理工具试图把这些观点结合起来，把服务设计也包括进来，但是由于它们对这些技术的使用者没有一个清晰的认识，就注定这样的管理工具是站不住脚的，更多的工具分类必然形成。

当Web services分别应用于企业内部和企业外部时，其管理和控制的目标也是不一样的。对于在内部使用的Web services，管理控制的重点应该放在监控和服务失败挽救上面。这里所讲的服务失败既是技术层次上的（比如服务响应时间过长），又是过程层次上的（比如一个过程实例花费的时间过长）。困难在于，如何才能监控在两种情况下大不相同的属性组，如何才能采取完全不同的纠正措施。比如说，如果某个特定的服务实例没有在规定的时间内作出响应，那么首先应该检查处理系统及其组件的工作状况。如果它们都没有问题，接下来就应该检查服务的使用是否超过吞吐量限制，并启动一个新的应用实例来清除这个负载障碍。在业务相关的情况下，纠正措施往往会启动一个新的流程来告诉顾客产生了一个延迟，并调查延迟的原因。在前一种情况下，纠正措施是传统的IT控制类的措施；在后一种情况下，则涉及到复杂的工作流和应用启动。当范围扩大到企业之外时，管理工具的关键功能往往又是和企业内部管理的关键功能不同的。

供应商们正从两个角度来评述这些问题：一种是从上而下的角度，另一种是从下而上的角度。从下而上的角度对于操作层员工来说是最熟悉的，这涉及到为现存的系统监控和控制工具增加Web services能力。通过这种方法得到的集成的工具能够轻而易举的解决前面所提到的问题，但是却不能把它们的标准和在系统内执行的业务活动联系起来。从上而下的角度认为Web services能够紧密连接端到端的业务流程，并且管理工具能够使用这些定义。这些管理工具试图把所有东西同业务相关的标准联系起来，响应用这些术语描述的查询。

最后，很可能不同的Web services交互类型有不同的管理需求。数据服务很可能从数据库中创建和执行。这样，那些以数据库为中心的服务必须在一定程度上也参与到管理平台中来。此外，这个平台还包括手工编写的服务，应用集成产生的服务，套装软件产生的服务等等。可以通过下图描述一下：