面向服务的分析与设计原理

　　例如，您可能将工作订单(Work Order)和工作订单项(Work Order Item)一起分到工作订单服务(Work Order Services)，并且创建日程安排(Scheduling)、目录(Catalog)和库存(Inventory)服务。另外，因为没有服务实例，所以没有与服务之间的关系等价的东西。工作订单的服务模型可能看起来如 图 9所示。

　　图 9. 工作订单的服务模型示例

　　与 OO 范式不同，这个模型并不表示功能系统。既没有考虑流，也没有描述业务事件或规则。在 SOA 范式中，在服务外面维护的业务流程编排决定了执行服务调用的顺序和时间。

　　从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。

　　然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的 流程会持续几分钟以上;事件之间的业务流程状态以数据的形式保存在数据库中。

　　这种类型的流程可以用状态转换模型(例如 UML 中可用的)很好地进行表示。 图 10显示了用有限状态机(finite-state machine)方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。

　　图 10. 工作订单的业务流程模型

　　业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。

　　图 11显示了部分编排的示例，其中包括 图 10所示的业务场景中的步骤 1 到 5(例如，顾客定义他们的交通工作所需的工作，并且安排预约以进行实施)。

　　图 11. 工作订单的业务交互模型

　　总结和展望

　　在本文中，我们已经讨论和激发了对创新的中间相遇的方法的需求，这种方法搭建了业务和 IT 之间的桥梁，并且支持 SOA 项目的分析和设计阶段。我们还提议将这种新的交叉学科的 SOAD 方法作为一个整体的建模规则，它以现在构建良好且广为赞誉的 OOAD、EA、和 BPM 为基础。

　　在详细定义 SOAD 表示法和流程的同时，还确定了关键的原理，比如服务概念化(或标识)、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取(以供重用)。

　　SOAD 需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的最佳实践。

　　我们还认识到，UML 在流程的表示法选择方面将继续占支配地位;可能需要进行增强以满足更广泛的 SOAD 的要求。

　　完成 SOAD 方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。

查看本文来源