SOA实例

SOA实例

汽车工作订单（Automotive Work Order）描述了一家汽车维修公司管理其顾客运营的流程。我们将通过这个领域中的问题来阐述 SOAD 的观点。

工作订单代表汽车服务公司和顾客之间的约定，以进行一系列例行维修或应急维修，例如例行 50,000 英里服务，更换刹车片或轮胎，或者换油。

业务场景如下：

• 当顾客打电话预约时创建工作订单。

• 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。

• 在安排预约之前确保所有必需的零件都有库存。

• 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。

• 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。

• 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。

• 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。

• 记录所用的零件和备件的实际价值以及劳务。

• 在完成所有的维修时计算总费用。

• 创建发票并且将其交给顾客。

工作订单的流程示意图：

工作订单的类图实例：

上面这些都是OOAD的设计，它包含了所有的业务规则，并且需要很好理解它的业务流程。IBM提出这种设计的缺点：

• 许多步骤涉及到遗留系统和数据库的连接，它们不可能遵循OO范式来进行设计。

• 如果修改流程或者工作流，那么里面的代码就必须更改。

所以IBM提供了用SOAD的解决方案，提出应该对服务进行分组，而不是对服务还有它的行为跟数据进行封装。

工作订单的服务模型示例：

工作订单的业务流程模型：

工作订单的业务交互模型：

跟OOAD的设计对比一下，就能看出为什么SOA那么受追捧。OOAD各种类和对象之间的关系是错综复杂的，相互之间的调用都牵涉到业务流程，一旦业务做出改动，那么整个设计都得产生很大的变动。SOAD的方法把服务跟流程分离出来，服务模型里面只需定义本地服务的接口和操作，不需理会这个流程是按照什么顺序去走的。因为一个流程可能牵涉好多个服务，多个服务之间的前后顺序可能需要根据业务的需求进行调整，如果服务之间是相互独立，那么流程的改变就不会影响到服务的设计。取上面的例子，制定一个订单过程中，除了订单处理，还有日程安排、检查库存、客户服务等等，如果是OOAD，可能订单处理的类里面就要加入日程、库存和客服的对象或者方法，那么一旦需要增加新的业务流程，那么就需要修改这个类的设计；如果换成SOAD，就可以制定不同的业务流程，调用不同的服务和顺序来达到目的，而不需要去改动任何设计。