在SOA中实现异常

理想情况下,服务调用总能成功完成并返回需要的结果。不幸的是,在现实中,服务可能而且也会失败。这种失败可以有一大堆的问题引起。它可以是由服务
本身引起,如入参验证失败,或只是服务实现的一个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

This entry was posted in SOA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s