SOA 建模: 第 1 部分 服务识别

本文是五篇系列文章中的开篇之作，本系列文章是有关基于面向服务的架构（SOA）的软件开发。它介绍了如何使用 IBM® Software Service Profile 扩展的 UML 模型设计同业务需求相连接的 SOA 解决方案，而它至今仍然是独立于解决方案的执行的。作者首先描述了业务目标以及满足这些目标所要执行的业务过程，然后解释了如何使用该过程识别那些完成他们所提需求所必须的业务相关的服务。

建模是如何改进 SOA 的

SOA 的强大功能在于它具备将业务敏捷贯穿业务过程综合和复用的能力。SOA 通过一下两种方式实现这一功能：方式之一是通过鼓励解决方案被组织在可复用的服务周围，这些服务对从执行中分离出来的功能进行压缩；方式之二是为管理功能之间的耦合提供工具。建模能够被用来消除业务需求和一个已经被配置的基于服务的解决方案之间的缺口。模型驱动的开发方法能够被用来生成 SOA 执行，通过使用诸如 Java™ 2 Platform, Enterprise Edition (J2EE) 或者 IBM® CICS® 这些在业务敏捷有效的同时满足业务功能性和非功能性目标的平台。

面向服务的架构（SOA）具有许多含义。从业者通常使用 SOA 来定义一个架构风格，以及描述一种使用该架构风格进行操作的 IT 基础构造。这些是很有用的聚焦拓扑结构的透视图，但是仅有这些还不够。

要实现其潜能，基于 SOA 的 IT 基础构造（此后简称为 SOA 需要同业务相关，从而由业务驱动并且用来对业务加以支持。我们需要一种设计 SOA 解决方案的方法，该方案同它们需要实现的业务需求相连接。如果所给出的业务需求仅仅是一个需求条目的列表，并且 SOA 的抽象级别是从描述 Web 服务集合的若干 XML 文档中得到的话，那么找到这种解决方案是很困难的。

我们所需要的是一种形式化业务需求并且提高抽象级别以便 SOA 能够更加类似业务服务，以及那些服务是如何满足业务目标的方法。这这种方法将被配置的解决方案同其业务价值紧紧联系在一起。与此同时，我们需要一种从支持它们的展开的 SOA 平台中隔离业务关系的方法。

建模和模型驱动开发（MDD）能够帮助我们实现这些目标。建模允许我们将执行细节抽象出来，并且关注于那些驱动架构决定的问题。从某种意义上说，这一方法将描述如何将 SOA 的基本原理之一应用到 SOA 解决方案的开发中：分离关系和松耦合。这里，我们将业务分析师的任务和责任从那些 IT 成员中明确分离出来。

通常的，业务分析师将关注业务组织和操作要求，这些都是满足业务目标所必须的。他们往往并不关注（也没有能力处理）IT 关系，例如复用、内聚性和耦合性、分发、安全性、持续性、数据完整性、并发性、错误恢复等等。进一步，业务过程建模工具通常并不具备处理这些关系的能力。假如它们具备了这些能力，那么它们也许就不再是一款有效的业务分析工具了。

 

本文转自：IBM developerWorks 中国

请点击此处查看全文