使Web Service 24×7可用是一项极具挑战性的任务。随着企业Web Service从试验性阶段到任务关键阶段的不断成熟，高可用性和强大的性能是绝对必需的。您需要考虑许多方面，才能在生产中运行和管理任务关键型的Web Service。
管理架构 用于管理应用程序的常见架构有三种：agent模型、proxy模型和混合模型。Agent是基于现有应用程序容器的基础架构之上的插件。在Java中，Java管理扩展（Java Management Extensions ，JMX）agent通常用于监控应用程序。proxy（在Web Service部署中）是单机的应用程序，位于服务的使用者和生产者之间。每个模型都有它自己的优点和缺点。混合模型是agent和proxy模型的组合。
Web Service有两类与其相关的逻辑：业务逻辑和管理逻辑，但是这里我们只讨论管理方面的逻辑。管理Web Service的工作包括版本管理（和有机增长）、相关性管理、维护服务质量（QoS）、自动配置、安全性、互操作性、审计、日志记录、报警、复原能力和报告。管理员还需要考虑系统的各种“性”，比如可用性、可靠性和可伸缩性。
长久以来，关注点分离（Separation of concerns）已经成为软件开发中的黄金定律。在生产者集中精力提供业务逻辑的同时，一个独立框架，即Web Service管理框架，提供了必要的管理支持。因为大多数Web Service有一些常见的、最基本的管理需求，使管理逻辑形象化以便能够集中管理它是个不错的主意。
OASIS 委员会正致力于定义一个用于管理Web Service的标准互操作模型。该模型称为Web服务分布式管理（Web Services Distributed Management，WSDM（读音为“wisdom”））。
对于重要的应用程序来说，服务的使用者很少直接与生产者（或端点）对话。事实上，“中间人（middleman）”（如图1所示）中途截取来自使用者的请求，读取SOAP头，然后采取智能的行动，比如进行身份验证、授权、策略管理、路由、日志记录，等等。这个“中间人”被称为中间体（intermediary）。中间体负责实现Web Service管理框架的各个方面。除了管理之外，中间体还在使用者和生产者之间提供一个间接层，使基础架构更具弹性。
图 1.
中间体或中间人中途截取来自使用者的请求，读取SOAP头，然后采取智能的行为，比如进行身份验证、授权、策略管理、路由、日志记录，等等。
图2使用中间体描述了一个更加逼真的架构。在现实世界中，它们由一组服务器组成，每台服务器专门负责Web Service管理基础架构的某个方面。
图 2.
在这个真实的架构中，中间体由一组服务器组成，每台服务器专门负责Web Service管理基础架构的某个方面。
根据厂商提供的Web Service管理软件，可以使用不同的架构部署中间体。图2描述了可以使用的架构之一。生产者被部署在集群之中。在这个例子中，它们有一个.Net Web Service的集群和一个J2EE Web Service的集群。
存在内部的和外部的使用者想要调用由这些生产者提供的服务。来自客户端的请求开始由负载平衡器（或XML工具）进行处理，它要么被拒绝，要么被转发给网关服务器之一。接着，网关服务器由Web Service管理引擎进行管理。
根据SOAP头中的信息，如果使用者拥有必要的权限访问服务，请求将被转发给正确的生产者。网关服务器通常是轻量级的应用程序。如图所示，Web Service管理引擎执行大部分工作。出于身份验证的目的，管理引擎和联合LDAP系统（或者像Netegrity SiteMinder这样的安全管理系统）集成在一起。生产者处理请求之后，响应通过网关服务器路由返回给使用者。
使用者决不会知道是哪个生产者处理了请求。在使用者的眼里，中间体就是生产者。Web Service管理框架对使用者来说是透明的。这为服务及其硬件提供了极大的灵活性和弹性。
24x7 Web 服务
一定要从设计阶段就开始考虑管理因素，否则实现24x7式的Web Service十分困难。因此，管理的外观——实现、QoS、性能、安全性，以及自动配置和服务——渗透到整个生命周期中。
实现
服务管理战略应该开始于实现阶段。这涉及到选择正确的平台，以及做出可以为它们自己带来正确有机增长的抉择。现在，让我们讨论一些需要在设计和开发阶段解决的问题。
管理接口。公司采用Web Service面临的主要挑战之一即是架构增长（schema proliferation）。这个问题通常是由计划不充分和管理不力所引起的。面向服务的架构（Service-oriented architectures，SOA）需要纪律、规划和强有力的管理才能成功。开发人员应该已经在为应用程序集成开发“一次性的”架构的过程中丧失信心。拥有联合指导方针和最佳实践意味着做准备工作，但是它们会使应用程序集成更加顺利。把服务考虑为黑盒并在为应用程序实现SOA时采用由外而内的方法是最好的做法。
查找和命名。使用者应该可以访问与可用服务相关的信息。统一描述、发现和集成（Universal Description、Discovery and Integration ，UDDI）是用于动态查找和使用Web Service的知名协议。然而，因为UDDI的复杂性，一些厂商提供可以提供类似的查找和命名服务的更简单的存储库。
对于Web Service来说，查找可以基于静态属性（比如URL、服务类型，等等）或动态属性（比如性能度量或开销）。目录甚至可以基于这些属性对Web Service进行分类。因为静态属性的简单性和易用性，当前的大部分实现都使用它们进行查找。
相关性管理。考虑图3。在这种场景中， Service B 和 Service C 应该对Service A 可用，以便它完成其任务。通常，中间体监听服务的“心跳”，并在服务出现故障时发出警报。然而，中间体只能在同一个实体拥有所有服务时控制端点。例如，如果Service C由第三方的公司提供，则需要建立某种信任级别。
图3
这是一个多次转移的Web Service的引用
具有讽刺意味的是，Web Service的复合性越强，管理其相关性就越困难。为了降低这种风险，可以在Web Service之间使用异步的（面向消息的）调用。
版本管理。Web Service规范中并未提及版本管理。同样地，必须通过一些最佳实践来解决这个问题。策略之一是使用面向对象设计的开－闭原则（open-closed principle）。也就是说，Web服务定义语言（WSDL）对扩展是开放的，但是对于修改是关闭的。另一种流行的策略是利用XML命名空间。Web Service的每个版本都使用其自己的命名空间。中间体根据SOAP消息中指定的命名空间对消息进行路由。
有一些厂商为Web Service的版本管理提供了专门的解决方案。
互操作性。互操作性十分重要，尤其是在服务跨越了共同的边界时。J2EE对象无法理解.Net对象，反之亦然。平台之间语义的差异也导致了出现不相容的情况。为了避免互操作性的缺陷，最好是开发在异构应用程序之间进行传递的对象的XML架构。坚持使用行业标准的架构和数据模型，可以使与业务合作伙伴进行集成更加轻松。因此，Web Service管理框架应该提供机制来测试欲开发的Web Service的互操作性。它应该符合Web Service互操作性（WS-I）概要的最新版本。
服务质量（QoS）
对于具有业务价值的服务来说，它应该支持某种QoS。在商业服务的例子中，不能维护QoS可能具有法律和金钱上的含义。让我们看一看一些定义和量化QoS的重要文献。
服务水平协议（(SLA）。SLA是生产者和使用者之间关于Web Service的预期性能和可用性的正式合同。SLA有助于量化QoS。根据协议的正式性，SLA可以非常宽大，也可以异常严格。通常，SLA的内容包括目的、各方、有效期、作用域、限制、服务水平目标、惩罚、可选服务、排斥和管理。
SLA可以有长期和短期的委派。例如，考虑这样一个Web Service，假定它在一个给定月的95%时间内都是可用的。让我们假定，从1号到29号，服务运行时没有任何问题，但是在30号这一天，它有5个小时出现故障。从技术上说，这没有违反SLA，但是如果服务在业务高峰期间失效5个小时，这是不可接受的。因此，短期委派可以预防Web Service连续45分钟（这是假想的数字）不可用。
Web Service动态和复合的天性（与传统架构相比）使它更加难于确定SLA。因为违反SLA具有法律和金钱上的含义，理解系统功能和相关性尤其重要。
弹性。任务关键型的24x7式应用程序要求对失效具有高抵抗力。冗余、故障恢复、灾难恢复和安全性等联合起来便构成了弹性。对于Web Service来说，端点被集群化，而中间体基于消息的策略集和端点状态对消息进行智能路由。拥有合适的消息收发架构还可以确保把SOAP消息可靠地路由给端点。如果没有消息收发系统，可以实现无状态HTTP会话的故障恢复。
事务。事务的可靠性对于维护操作的完整性十分重要。两阶段提交是用于分布式系统中管理事务的流行机制。Java事务服务（Java Transactional Service ，JTS)、 CORBA OTS和大多数数据库管理系统都支持两阶段提交。然而，如果是Web Service，传统的两阶段提交过于复杂，以至于难以实现，因为Web Service可以使用长期运行的事务。因此， OASIS发布的WS-Transaction规范提供两种协调类型：基本事务和业务行为。前者用于协调持续时间较短的行为，而后者用于协调持续时间较长的行为（例如，需要人工干预的行为）。 借助业务行为，可以基于用例要求、WS-Coordination 和相关规范处理业务异常，标识需要在业务流程的总体输出上达成一致的流程中的操作顺序。WS-Transaction和WS-Coordination联合发挥作用，确保得到可预计的输出。
日志记录。日志是用于记录行为和调试问题的有力工具。在Web Service中，日志记录被委派给事务之外的另一个Web Service。基于业务需求、公司战略和常规的一致性要求，记录警告、错误、安全性以及其他信息。
审计。对于完成记录（和协调）服务使用和在出现问题时跟踪事件次序这样的任务来说，行为审计是必不可少的。行业特定的规则，比如提供金融实践和公司管理规章的法规（Sarbanes Oxley Act，SOX）和保护健康信息的私有性的法规（Health Insurance Portability and Accountability Act，HIPAA），需要公司维护某几种行为的记录。日志记录是实现审计的常用机制。区别在于审计更加严格，而且位于事务之内。如果审计机制失效，事务必须回滚。
警报。警报是面向系统管理员的一项重要功能。当系统违反SLA或某些事件（比如服务器没有响应）发生时，必须发出警报。有时，警报机制可以采取补救措施。
警报可以分为广义上的两类：系统级警报和业务级警报。框架应该提供的一些警报功能，包括简单网络管理协议（SNMP）陷阱，以及e-mail和服务（或脚本）调用。
性能
对于任何企业应用程序的性能来说，正确的工作量描述和容量规划是相当重要的。了解使用趋势和服务模型有助于分配足够的硬件资源。
尽管HTTP用于SOAP传输，但SOAP消息的负载比大多数Web页面都要高很多。因此，网络应该能够处理这种额外的负载。现在，让我们了解一下可用于维护服务的良好性能的其他技术。
XML容器。XML处理是企业应用程序的主要开销之一。XML容器是基于硬件的XML处理器。它们针对像XML压缩、解压缩、验证和转换这样的操作进行了优化。通过把计算和内存密集型的XML处理任务委派给专门的硬件设施，在应用服务器上运行应用程序的效率要高的多。
XML容器通常很容易部署和管理。在处理XML和经常与中间体联合使用的能力方面，它们的效率要比相应的软件容器高的多。它们还可以保护网络不受恶意的XML流量（像在拒绝服务攻击中，意图阻塞网络的恶意SOAP请求）的困扰。DataPower、Westbridge Technologies和Sarvega 是这个领域中处于领导地位的几家厂商。
缓冲。可以在应用程序的各个级别上进行缓冲，以提高性能。关于缓冲，要考虑的一些关键问题有：
数据的静态程度如何?
数据到期的时间有多长?
缓存能有多大?
被缓冲的数据是否相关?
是否可以在请求之间共享数据?
在Web Service中，执行缓冲的方法之一是使用SOAP消息处理器。这会缓冲频繁调用Web Service的结果（假定这些结果是静态的），并在适当的时候立即返回这些结果，而不会调用实现Web Service的后端组件。SOAP消息处理器可以用于检查常见的调用。
HTTP支持丰富的缓冲功能，而HTTP之上的SOAP是常见的选择。然而，在Web Service的环境中使用HTTP缓冲存在一些限制。SOAP是使用HTTP POST进行传输的。对于HTTP POST请求来说，其请求体已经位于HTTP范围之外。因此，基于代理和客户端的HTTP协议实现在确定如何缓冲HTTP POST请求的响应时能力有限。
安全性
在传统的架构中，“信任边界”位于企业网络的边缘。也就是说，防火墙之后的一切都被认为是安全的。借助Web Service——通过为合作伙伴、客户和厂商提供对战略信息的访问——安全性的范围已经变得模糊。
管理Web Service的安全性是中间体最重要的任务之一。必要时，中间体可以利用一些现有的资产，比如LDAP服务器和规则引擎。
OASIS发布的WS-Security规范为SOAP定义了消息的完整性、机密性和身份验证。它规定了如何在SOAP头中组装安全性标记。一套其他的补充规范——一般称为WS-*——指定了另外的机制的使用方法，如信任、策略和SOAP的私有性。
为了确保Web Service事务的安全，您将需要解决以下问题：
身份管理。企业中有许多系统，设计时都没有考虑无缝集成。应用程序大多各自为政。因此， John Doe可能是System 1中的johnd ，System 2中的jdoe和System 3中的johndoe。将Web Service与这些系统集成之后，企业发现，管理和映射这些用户身份，以及在交互作用的系统之间传播安全性环境是十分复杂的事情。像Security Assertion Markup Language（SAML）这样的规范提供一个一致的机制，用于跨企业应用程序联合身份和使用单点登录（集成应用程序的一项重要功能）。
策略管理。对于确保正确的实体在正确的环境中获得对正确资源的访问来说，Web Service中的策略实行十分重要。WS-Policy规范（作为对WS-Security规范的补充）描述了发送者和接收者如何声明性地指定它们的要求和能力。
随着开发平台日渐成熟，开发人员可以通过向导配置策略，而不必与规范的底层细节打交道。中间体作为它们的安全管理框架的一部分，实行了策略。
身份和策略互为补充。身份便于进行身份验证（用户确实是John Doe），而策略便于进行授权（John Doe具有对给定环境中的特定资源的访问权限）。
保护信息传输。加密是用于为敏感数据提供机密性的常用机制。数字签名可以确保数据的完整性。联合使用这两种技术可以保护未定的（in-flight）信息。
一些Web Service部署在机器之间使用安全套接字层（Secure Sockets Layer，SSL），以保护传输中的数据。这是一种强有力的方法，因为SSL加密和解密了整条消息。在图3中，Service A调用了Service B，然后Service B又调用了Service C。如果这里使用了SSL，对每一次往返，都必须进行四组加密和解密。另一个缺点是，在加密和解密阶段之间可能暴露敏感数据。
相反，借助XML加密、XML签名和相关技术，我们可以保护那些携带敏感信息的特定标签。现在，Service B可以查看SOAP头，然后对消息进行路由（使用在通往目的地的途中自始至终受到保护的SOAP体的敏感部分。）。
端点安全性。Web Service安全性的另一个重要，但常常被忽略的部分是保护生产者本身。例如，密码必须一直以加密后的格式存在（在内存中和在存储器中）。这类需求必须由生产者进行管理。通常，通过以下在开发服务的平台上的应用程序安全性的最佳实践来保护生产者。
正如Bruce Schneier所说，安全性既是技术，也是过程。没有彼此的存在，应用程序就不会是安全的(参见 参考资料)。
自动配置和服务
自动配置是按照服务的原定使用方式来设置服务。例如，服务的黄金版本可以提供无限制的使用，而白银和青铜版本则提供受限制的使用。为了能够做到这一点，您应该有一个测量机制来跟踪点击的次数。其他自动配置行为包括围绕服务设置安全性和业务策略和配置硬件。对于商业性质的Web Service来说，对租借、定价和记帐可能由另外的要求。
了解管理Web Service的这些方面有助于确保您提供一个高度可用、任务关键型的企业应用程序。所以，现在就使用这些指导方针开始构建功能强大的Web Service吧。