在指南:服务中对业务与服务的协调进行讨论时,已讨论了业务模型与服务确定之间的联系。 通常,此方法在业务项目干系人/用户与 IT
组织实施服务之间提供了非常紧密的连接,这是因为它允许服务操作直接支持流程模型中确定的任务。 一般而言,业务流程模型侧重于角色执行的任务和/或组织内负责达成特定目标的资源,通常是以产品或服务的形式向外界(例如客户或合作伙伴)提供价值。
因此整个流程是此类任务的有序集合,可以分解为多个子流程。它具有关联的组织、资源和数据模型,这是为了全面捕获流程的各个方面,不仅包括执行角色,还包括所需/使用的资源、资源的所有权、责任、对传入或传出任务的项的定义等。 概念:业务流程分解描述了如何达到可以确定候选服务的业务流程模型的描述级别(如下例中所示)。根据不同的工件:业务用例模型详细程度,有必要优化业务用例,,这样才能够达到可生成有用流程模型的分解程度。
下面展示了一个使用 IBM WebSphere Business Integration Modeler 的很简单的流程模型。
在此例中,每个水平泳道代表一个执行流程中任务的特定角色。该流程从绿色实心圆圈开始,至红色空心圆圈结束,并且在某些任务之间有数据流过(以借出请求的形式表示)。显然此流程很基本,但它表示了高级别任务。它们可以是业务观点中的原子操作,但在分解至
IT 级别时,显然需要许多步骤。 通常,在对基于组件的开发进行面向对象的开发时,我们应当将业务视图中的每个任务视为 IT 视图中的一个用例,并分解为多个组件集和类集以形成用例的实施。
在面向服务的解决方案中,服务是以相似的详细程度级别确定的。通常假定针对服务规范的操作与业务流程模型中确定的原子任务是一一对应的。
这是一个吸引人的方法,如果小心使用,就能够得到正确的结果,也可能一旦确定了服务,这些服务就可以直接实施为它们在流程模型中所描述的那样。
具体而言,每个角色(泳道)将成为一个已命名的服务,并且泳道内的每个任务被创建为对相应服务的操作,如下图中所示。
此方法无法顾及之处就是存在影响所要开发服务的种类、对服务确定操作时使用的方法等的非功能需求。 例如,通常由此类工具捕获的详细级别未包含足够的信息,因此无法捕获安全性、服务质量或管理性策略。
通过将流程转换为服务模型中的一组候选服务规范,能够提供一个起点,但只应当将其视作在开发描述实际实施的设计模型之前执行进一步分析的起点。 因此,所有此类服务都应将状态设置为“候选”,正如在 Rational Software
Modeler 属性视图的如下视图中所示。
备选表示法
如果服务模型使用了更以文档为中心的格式,则使用表格形式来捕获流程任务和服务之间的映射可能更合适。以下示例展示了此可能格式。
|