使用面向服务分解技术来满足架构目标

在本文中，设计了一组定义企业架构蓝图的服务来支持业务目标。了解层次结构分解如何能够帮助您调整服务以同时支持目前和将来的业 务功能。您还将了解如何定义服务接口来作为面向服务的体系结构（Service-Oriented Architecture，SOA）分解的一部分，并使用某种语义数据模型来实现最大限度的互操作性。
引言

通 常，企业已经拥有一组支持大多数必需业务功能的应用程序。因此，谈到服务定义，您可能以为这不过就是将现有的应用程序功能作为一组服务来公开，类似于传统 的企业应用程序集成（enterprise application integration，EAI）实践。其实不然。在实现基于面向服务的体系结构（Service-Oriented Architecture，SOA）的解决方案时，正确定义服务是最困难的任务之一。遗憾的是，此方法很少有效。这种方法本质上是“一种技术优先的方法和 导致灾难和/或严重过度设计 (over-engineering) 的方法”。1（请参见 参考资料。）

一种更好的面向服务的分解方法基于企业范围的业务模型。此方法包括设计一组定义企业架构蓝图的服务，以支持当前业务目标并提供用于将来变更的功能。此方法要求您“从场景/业务需要开始，参照现有的/新的系统分析那些需要，对准切点，然后为获得有意义的服务做好计划”。1（请参见 参考资料）。以这种方式定义的服务可以实现 IT 与业务功能之间的可跟踪性。此方法是“一个能够帮助您坚持企业架构远景的交付策略的示例”。2（请参见 参考资料）。

本文将讨论一种面向服务的分解方法，此方法符合企业业务驱动因素和面向服务的计算原则。此方法的基础是基于业务模型将企业 IT 功能初步划分为服务，然后重构初始的服务定义，以便服务与总体企业架构目标一致。这种方法可以实现为具有以下活动的多步骤过程：

层次结构分解，基于企业业务模型，以确保最终的服务与当前和将来的业务功能一致

初始服务分解的重构，以使服务与架构目标一致，例如性能、可伸缩性、安全性，等等

使用企业语义数据模型，基于业务模型，以确保最终服务的互操作性

ACME Insurance

本 文使用虚构的 ACME Insurance 公司作为示例。ACME 专门从事两个保险行业：个人汽车保险和内陆水运保险。ACME 处理与完整的保险服务生命周期相关联的所有问题——包括评级、承保和保险单维护。为了最大限度降低复杂性，本示例完全集中于签发过程。有些细节虽然从保险 公司的角度看是必需的，但是如果不会为我们的讨论增添价值，我们将省略这些细节。

保险签发的核心在于用于确定适当的客户保险费的专有评级模型。该模型是由 ACME 的保险代理人随时间推移而开发出来的，它根据与特定行业相关联并由特定保险产品定义的规则和风险因素，从而确定与保险单的签发相关联的风险。

ACME 已经拥有一个保险管理系统。IT 人员开发并发展了该系统，系统中具有若干支持所有必需功能的专有和现成的软件包。如 图 1 所示的应用程序目前支持签发流程。

图 1. 当前的 ACME 应用程序:


本文转自：IBM developerWorks 中国

请点击此处查看全文