理想情况下，服务调用总能成功完成并返回需要的结果。不幸的是，在现实中，服务可能而且也会失败。这种失败可以有一大堆的问题引起。它可以是由服务本身引起，如入参验证失败，或只是服务实现的一个 bug，或通信问题 (如服务不可达或实现不可访问底层的数据库)。最后，失败可以由部署问题引起，如软件升级之后，必需的一个库没有被正确地部署。
一种被广泛采用的失败处理机制是异常处理，包括捕获并记录错误，以及在失败发生时选择一个备选执行路径。在应用程序和组件实现中，它已经成为一种标准机制。问题在于，它特别依赖于应用程序设计者和开发者对可能异常情况的预见能力，以及在运行时正确的利用代码 1 处理它们的能力。这种方法基于以下假设：
- 应用程序作为一个整体完全地被设计，包括所有可能的异常状况。这意味着应用程序所有的执行路径被全部定义，结果是，它可以被应用程序团队完全地测试。
- 应用程序在单台机器（或有限数量的机器）上运行，使用标准化的异常报告模式，在本地文件日志文件中报告所有的异常。
- 应用组件中发生的变更被集中管理，这意味着应用程序开发团队可以对变更进行完整的控制。
在分布式系统的情况下，试图实现这种异常处理方法明显变得复杂，因为在这种情况下，异常不仅可以由应用程序代码本身，也可以由基础设施（如网络）故障引起，这使得分析所有可能的异常场景变得更加困难。此外，在此情形下，异常日志在多台物理机间传播，也使得协调它们明显更复杂。在面向服务架构（SOA）上下文中的特性，如松耦合（组织性和技术性），自治以及依赖已有实现业务功能的应用使得异常处理变得更加复杂。
由于每个服务是自行设计、实现和维护，并可用到多个企业解决方案（在服务设计时，它们可能是未知的）中，特定服务的异常处理实现围绕 3 点进行：处理异常；向本地服务实现记录异常；在它们不能被本地解决时，将它们向服务消费者报告为。如果没有采取特殊的度量，这将导致“异常处理孤岛”（见图 1） 2 。
图 1 异常处理孤岛
以下的复杂问题在单片应用程序中并不是什么大问题，为了支持 SOA 下的异常处理，必须被处理 [2]。
- SOA 的分布式和异构的天性使得它特别容易失败，在多个层次上引起异常 [3]。系统级的异常，由消息传递、通信和其他基础设施失败引起。应用级异常，由于错误的消息语义或应用中的逻辑错误导致。业务级异常，由于违反最佳实践、合规法律、规章制度，或业务经理要求的业务政策引起。后者甚至可能对服务执行本身不可见，可能需要服务管理解决方案适当的检测它们。
- 有一种异常情况是任何参与者中的异常处理无法检测的，即与横跨不同业务过程的一个或多个服务（有时横跨多个公司）的特定业务事务相关的异常情况。在此情形下，异常处理可能需要聚合业务事务级别的异常信息。这意味着特定服务的异常信息必须被使用该服务的业务事务割断。此外，这种隔断的需要还因为隐私、健康保险携带和责任法案（Health Insurance Portability and Accountability Act，HIPAA) 和其它的合规要求而加强。
- 单个服务缺少整个解决方案（业务过程）的视角。缺少过程范围的视角，将使得错误修正变得困难。因此，服务实现一旦检测到异常，并不总能选择一条可选执行路径，同时还不得不通知消费者，因为它可能有修正这种情形所需要的上下文。然而，SOA 递归组合的特性使得情况进一步的复杂化：消费者常常是另一个服务，因此也不是解决该问题的合适位置 [4]。不是所有的异常都能被自动处理，有时唯一处理失败的办法就是通过人工干预。要做到这些，就需要决定谁是合适的人，并通知他们关于异常的事情。
- 松耦合、异构的服务对于异常的发现和处理常常各不相同。有些可能会使用一些特殊的组件，如 log4j、log4ne、.NET 企业库等等，其它则使用专有解决方案。此外，正如 [1] 中所定义的，包装现有应用程序的功能是当前服务实现普遍的做法。这些传统应用可以以不同的方式检测、记录和通知异常。
对异常处理实现应用 SOA 原则，是 SOA 中一种优雅的异常处理解决方案。这将导致所有主要的异常管理元素“服务化”[4]，（即，日志，异常解决和通知）。图 2 显示了异常日志、解决和通知的总体架构。
图 2 异常日志、解决和通知的统一架构
服务实现中的工具代码用于检测和记录系统级和应用级异常。日志使用标准日志组件（如 Log4J、Log4NET、.NET 企业库等）暴露的通用 API。日志实现将调用请求翻译成对异常记录服务的服务调用。在这种情形下，为了降低异常记录的效率影响，服务调用常常使用异步调用。尽管这个实现是以日志服务为中心，但是异常处理还依赖其它几个元素：
- 日志服务接收所有的日志请求，将它们保存在日志数据库中，并将它们转发给异常解解决服务。
- 异常解决服务使用异常解析规则处理每个日志消息，这些规则指明消息是否应该被忽略（如信息消息）、自动解决或是否需要人工干预。
- 通知服务接收通知请求，并使用一组规则分发通知（如，电子邮件网关、分页网关、企业管理解决方案）。
- 异常 / 日志门户可以让人们查阅和浏览异常日志信息。
- 服务管理监视服务通信量决定业务级别异常，并将它们报告给日志服务，它将它们和其它任何系统中的异常等同对待。
以上的功能划分确保了异常记录和解决风格一致。这允许公式化企业最佳实践（“公共知识”），并改善异常的审计、监视和控制。这代表了合规制定取得了重大进展。
异常解决服务集中化允许更快地实现特定异常类型处理的变更。最常用的异常解决方法是：
- 自动解决，解决那些不需要人工干预的问题。
- 半自动解决，评估规则集并建议可能的解决方案。
- 依靠人来进行人工解决。
附注：服务异常定义
SOA 中的异常处理非常依赖服务异常定义语义。服务异常可以属于 3 组（即系统、应用或业务）之一，因此它在服务有效负荷（回复）中可能有不同的表示。服务有效负荷可以被编码进 SOAP 消息；即使在消息使用其它编码时，这些想法也是可应用的。SOAP 报文提供了特殊化的元素（SOAP Fault）用于异常的传播。使用 SOAP Fault 的最佳实践在别处描述 [6]。
SOAP Fault 最适合报告系统级别的异常，而且应该总被用于报告这类异常。（通过给 SOAP Fault 元素补充执行堆栈的内容，J2EE 实现通常提供了与问题有关的额外信息。）系统级别的异常通常与系统的软硬件错误相关。这意味着服务调用可以在问题解决之后重试，这种重试可以自动地（如，通过故障转移）也可以是手动地（如，在物理替换了错误元件之后）。
应用和业务级别异常需要更多数据来正确定义错误起因。这些情况下，往往需要为每个具体错误使用特定模式来定义信息，这样可以有效地扩展领域语义模型以描述失败场景。另一个复杂情形是，基于一次服务调用可能返回多个错误。这种情形的典型例子就是验证错误。为了降低通信开支，通常返回所有的验证错误（即将它们一批打包），这样可以同时解决他们。
这些异常类型可以被作为包含扩展细节信息的 SOAP Fault，或作为包含指示错误的有效负荷的普通服务响应被传递回来。两种方法各有优缺点，总结如下：
SOAP Fault 特殊化的有效负荷 优点 - 直接被 Web 服务规范和工具支持。
为所有类型异常提供统一的传递方式。
直接映射到诸如 Java、C#编程语言的异常。
明确隔离系统级别和应用级别异常。
允许引入同时支持成功和失败场景的语义模型。
无需使用 SOAP。
缺点 - 需要区分语义模型为成功和失败场景
- 要求服务消费者检查回复有效负载，并显式区分应用级别的成功和失败场景。
不考虑在以上总结表中的这些缺点，使用特殊化的有效负荷汇报应用程序和业务级别异常是更好的方法，因为它增加了灵活性和扩展性。
图 2 给出解决方案需要以下前提：
- 所有日志、消息、包含信息、警告、异常等必须遵守标准格式，如公共基础事件（Common Base Events，CBE）[5]。
- 所有参与者（即服务消费者和提供者、日志、异常解决和通知服务）应该能解释异常 / 日志信息，这要求遵循企业语义模型（参见服务异常定义附注）。
- 分析和理解失败需要跨越服务边界链接日志消息。这要求横跨业务事务范围的唯一相关 ID。
本文所描述的异常管理方法，应用面向服务架构的原则为有效管理 SOA 实现中的异常提供了基础。它介绍了使用特殊化的基础设施来构建灵活、可扩展的异常处理解决方案。它通过提供整个企业统一的异常处理方法改善实现的一致性。通过提供横跨多个服务消费者和提供者之间的单一、统一的日志，它同样也简化了维护并改善了可测试性。
关于作者
Boris Lublinsky 在软件工程和技术架构方面拥有超过 25 年的经验。最近几年，他关注企业架构，SOA 和过程管理。在他的整个职业生涯中，Lublinsky 博士是一个活跃的技术演讲者和作者。他已在不同杂志超过 40 份的技术出版物上发表文章，包括：Avtomatika i telemechanica，IEEE Transactions on Automatic Control，Distributed Computing，Nuclear Instruments and Methods，Java Developer’s Journal，XML Journal，Web Services Journal，JavaPro Journal，Enterprise Architect Journal 和 EAI Journal。目前 Lublinsky 博士为大型保险公司工作，他的职责包括开发和维护 SOA 策略和框架。通过 blublinsky@hotmail.com 可以联系他。
参考文献
1.B. Lublinsky，将SOA 定义为一种体系结构风格（原文： Defining SOA as an architectural style ）。IBM Developworks，2007 年 1 月
2.Ramesh Ranganathan，管理 SOA 中的异常。 IT 工具箱：工程技术，2005 年 9 月。
3.Sean Fitts，当异常是规则时：完成可靠和可跟踪的面向服务架构。SOA/WebServices 期刊，2005 年 9 月。
4.Peter Abrahams，解决加速器 - SOA 的异常处理。It-director，2005 年 9 月。
5.Andy Brodie，Amanda Watkinson，公共事件基础架构：从技术预览到产品发布（原文： The common event infrastructure: From technical preview to production ）。DevelopWorks，2005 年 4 月。
6.Russell Butek Ping Wang， Web 服务编程技巧与窍门：在 JAX-RPC 应用程序中构建有状态会话（原文： Web services programming tips and tricks: Exception handling with jax-rpc ）。DeveloperWorks，2004 年 2 月。
1 这种手段一般基于 try/catch 块（当今的大多数编程语言都支持，如 Java 或 C#），允许决定异常并为随后的分析记录信息。
2 相比于“数据孤岛”和“自动化孤岛”。 查看英文原文： Implementing Exceptions in SOA
译者简介：胡键，自 2000 年西安交通大学硕士毕业后一直从事软件开发。2002 年开始使用 Java，在项目开发中经常采用 OpenSource 工具，如 Ant、Maven、Hibernate、Struts 等，目前正在研究信息集成方面的规范和技术。可以通过 jianhgreat@hotmail.com 与他联系，或访问博客： http://foxgem.javaeye.com/ 。参与 InfoQ 中文站内容建设，请邮件至 china-editorial@infoq.com 。
评论