在SOA中实现异常

作者 Boris Lublinsky译者 胡键 发布于 2007年6月14日 下午10时46分

社区

SOA

主题

调试

标签

Logging,

异常处理

理想情况下，服务调用总能成功完成并返回需要的结果。不幸的是，在现实中，服务可能而且也会失败。这种失败可以有一大堆的问题引起。它可以是由服务本身引起，如入参验证失败，或只是服务实现的一个bug，或通信问题(如服务不可达或实现不可访问底层的数据库)。最后，失败可以由部署问题引起，如软件升级之后，必需的一个库没有被正确地部署。

一种被广泛采用的失败处理机制是异常处理，包括捕获并记录错误，以及在失败发生时选择一个备选执行路径。在应用程序和组件实现中，它已经成为一种标准机制。问题在于，它特别依赖于应用程序设计者和开发者对可能异常情况的预见能力，以及在运行时正确的利用代码¹ 处理它们的能力。这种方法基于以下假设：

• 应用程序作为一个整体完全地被设计，包括所有可能的异常状况。这意味着应用程序所有的执行路径被全部定义，结果是，它可以被应用程序团队完全地测试。
• 应用程序在单台机器（或有限数量的机器）上运行，使用标准化的异常报告模式，在本地文件日志文件中报告所有的异常。
• 应用组件中发生的变更被集中管理，这意味着应用程序开发团队可以对变更进行完整的控制。

在分布式系统的情况下，试图实现这种异常处理方法明显变得复杂，因为在这种情况下，异常不仅可以由应用程序代码本身，也可以由基础设施（如网络）故障引起，这使得分析所有可能的异常场景变得更加困难。此外，在此情形下，异常日志在多台物理机间传播，也使得协调它们明显更复杂。在面向服务架构（SOA）上下文中的特性，如松耦合（组织性和技术性），自治以及依赖已有实现业务功能的应用使得异常处理变得更加复杂。

由于每个服务是自行设计、实现和维护，并可用到多个企业解决方案（在服务设计时，它们可能是未知的）中，特定服务的异常处理实现围绕3点进行：处理异常；向本地服务实现记录异常；在它们不能被本地解决时，将它们向服务消费者报告为。如果没有采取特殊的度量，这将导致“异常处理孤岛”（见图1）²。

图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月。

---

¹这种手段一般基于try/catch块（当今的大多数编程语言都支持，如Java或C#），允许决定异常并为随后的分析记录信息。
²相比于“数据孤岛”和“自动化孤岛”。

查看英文原文：Implementing Exceptions in SOA

---

译者简介：胡键，自2000年西安交通大学硕士毕业后一直从事软件开发。2002年开始使用Java，在项目开发中经常采用OpenSource工具，如Ant、Maven、Hibernate、Struts等，目前正在研究信息集成方面的规范和技术。可以通过jianhgreat@hotmail.com与他联系，或访问博客：http://foxgem.javaeye.com/。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。

• 更早的 >