服务建模方法论介绍【转载】

众所周知，面向对象的应用构建在类和对象之上。

随后发展起来的建模技术将相关的对象按照业务功能进行分组，就形成了组件的概念；对于跨组件的功能调用，则采用接口的形式暴露出来。

进一步的将接口的定义与接口的具体实现进行解耦，就催生了SOA。而作为业务和IT之间的契约的服务，是SOA最重要的概念。

因此面向对象、基于组件、面向服务是三个递进的抽象层次。

现在我们有OOAD（Object Oriented Analysis Design）和CBD（Component Based Development）来进行面向对象和基于组件的建模与开发。但是没有一个好的方法来进行SOA的分析、设计和开发。SOMA（Service Oriented Modeling Architecture）就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。

需要特别指出的是，SOMA的出现并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一样，SOMA也要借助OOAD和CBD进行实现层面的建模。

与OOAD和CBD相比较而言，SOMA贯穿整个IT建设的生命周期，在项目规划、设计、实施、运行中都起到重要的作用。本文就不展开阐述了，相关信息可见参考资料。

SOMA另外一个显著的特点就是将IT与业务对齐。在具体的实施过程中，SOMA将业务特性，如：业务目标、关键业务指标等，延伸到IT的分析和架构决策过程，从而缩小业务与IT之间的差距。具体来看，业务组件模型（或者类似业务分析方法论的结果）、端到端的业务流程以及关键业务指目标是SOMA的三项主要输入，SOA的实现则是SOA的输出，从这也可以看出SOMA的定位是在业务和IT之间。

图1：SOMA方法论

按照实施的阶段，SOMA分为服务发现、服务规约以及服务实现三个阶段。

1）服务发现：采用自上而下、自下而上和中间对齐的方式，得到服务的候选者。

自上而下 （业务领域分解）方式从业务着手进行分析，我们将业务进行领域分解、流程分解，以及进行变化分析。

业务组件模型是业务领域分解的输入。根据业务组件模型的详细描述，我们可以将业务领域按照业务职责细分为业务范围，并直接其映射到IT范畴的子系统，实现业务与IT的无缝连接。

顶级的业务流程是流程分解的输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。在大部分情况下，服务候选者组合都是一个很长的列表，加上自下而上和中间对齐方式还有可能发现新的服务，因此将服务候选者按照某种方式进行分类是一件非常必要的事情。业务领域分解的结果——业务范围是一个业务概念，同时可以无缝映射到IT范畴，因此它是一个好的分类原则。根据业务范围，服务候选者组合可以被划分服务候选者目录。

变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从对未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。

自下而上（已有资产分析）方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。

通过对已有资产的业务功能、技术平台、架构以及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。

中间对齐（业务目标建模）方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。

业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。

结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如：通过对已有资产分析进行的技术可行性评估、通过业务目标建模发现的业务事件等等。

2）服务规约：定义实现服务的服务组件的细节，包括，数据、规则、服务、可配置概要、可能的变更，同时还会涉及到消息、事件的定义和管理。

经过服务发现的阶段，我们得到了候选服务目录，接下来就需要决定暴露哪些服务。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求，企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

这些规则包含以下几个方面：

• 业务对齐：该服务候选者可以支持相关的业务流程和业务目标。
• 可组装：该服务候选者满足技术中立、自包含以及无状态等特点，同时还满足复合应用的相关非功能性需求。
• 可重用：该服务候选者可以在不同的应用、流程中重用，从而减少重复的功能实现，降低开发和维护的成本。

基于企业应用开发的经验，我们还可以有其他一些方面的考虑。

在决定暴露特定的服务候选者为服务以后，服务规约还需要定义服务的消息、非功能性需求以及服务之间的依赖关系、组合关系。

3）服务实现：

根据对业务领域的理解和现有IT系统的分析，将服务的实现分配到相应的服务组件，并决定服务的实现方式。具体的实现方式，可以由已有系统暴露相关功能为服务，或者重新开发相关功能提供服务，也可以由合作伙伴来提供服务。无论采用哪种方式，都需要对于关键点进行技术可行性的分析。

转自：http://www.ibm.com/developerworks/cn/webservices/0610_jinge/index2.html