IBM提出的SOA概念中有三个主要的抽象级别：操作、服务和业务流程。

• 操作：业务模型中的一个基本单元。比如说一个文档服务，那么打开、编辑、保存等就是这个服务里面的一系列操作。
• 服务：具有相同目的的一些操作的归类。例如打开文档、编辑文档、保存文档就可以归类为文档服务；而打开图片、编辑图片和保存图片就可以归类为图片服务。
• 业务流程：为完成一个业务目标而进行的一组活动。它规定一批服务的执行顺序，甚至具体到一组操作的顺序。操作的排序、选择和执行称为服务或流程的编排。

下图是IBM的一篇技术文档《面向服务的分析与设计原理》所定义的一张OOAD、EA、BPM之间的关系图。

图中横纵坐标的名称好像写反了，横坐标表示的是项目的生命周期，纵坐标表示的是不同抽象领域级别。从图中可以看到，基于应用层的是OOAD，也就是面向对象的分析和设计；基于架构层的是EA或SA，也就是企业架构或解决方案结构；基于业务层的是BPM，也就是业务处理模型。我的理解是，最底层的OOAD就是定义各种实现功能的类和对象，架构级别的EA定义的是实现各种功能的组件，而业务级别的BPM定义的是工作流或者业务流程。

文章给出这张图的目的是为了引申SOAD，所以IBM又给出了下面这张图：

很明显可以看出，SOAD的本质是这三种分析设计的结合。我的理解是，OOAD就是定义了SOA里面的操作，EA定义的是SOA里面的组件或者说是服务，而BPM定义了SOA里面的业务流程。所以说SOA并不是跟过去和现在存在的设计方法完全不同的设计方式，它只不过是从不同的抽象角度去设计一个业务模型。这有点像电子电路设计里面的系统级设计->模块设计->逻辑设计->物理设计，几种设计形成一个层次结构，设计的优劣取决于你采用的是自底向上的设计方式还是自顶向下的设计方式，传统的OOAD可以说就是一种自底向上的设计方式，虽然面向对象的方法比起结构化设计有了很大的改进，但是放到复杂的商业逻辑里面，面向对象就显得远远不够，需要从更高的层次去分解商业逻辑。所以就需要SOAD，SOAD分离出业务流程和服务，再从这个基础上去细化对象，这就是一种自顶向下的方法。最近在跟其他一些参加SOA的小组交流的时候，发现有些队伍完全跳到SOA的层次去解决方案，脱离了用例等传统的设计，但从IBM的一些文档可以看到，它所提出的SOA并不是什么新的技术，而是一个新的概念，是要从不同的角度去设计商业模型，而这种新的角度依旧是以组件、面向对象这些为基础的。

这也可以从IBM的设计层次图可以看到：

这三种设计层次不是跳跃的关系，而是包含的关系。而IBM采用SOA的另一个目的是把业务逻辑跟业务开发分离开来。这也解决了传统IT行业里面开发人员不懂业务，业务人员不懂开发的矛盾。采用了SOA，业务人员就可以专心于理解业务需求、分解业务流程、设计业务模型，而架构设计师就可以根据业务人员提交的业务模型进行架构设计，最后是由开发人员去实现里面的类和对象。所以IBM推出了Rational XDE系列产品，其中有提供给非IT人员建模的，也有提供给IT人员设计和开发的。

下面是IBM提供的一个SOA例子：

--------------------------------------------------------------------------------

示例：汽车工作订单

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

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

业务场景如下：

• 当顾客打电话预约时创建工作订单。
• 为每个计划的维修活动或操作创建一个独立的工作订单项，其中包括需要使用的零件、备件和劳务的详细情况。
• 在安排预约之前确保所有必需的零件都有库存。
• 需要为每个工作订单项安排具有适当的装备的维修间以及具备适当的条件的机器。
• 计算估计的总成本，接着顾客认可该预约；或者方案终止，随即取消工作订单。
• 在预约之前，立即在选定的维修间装配必需的零件、备件、工具和设备。
• 当顾客到达时，进行计划的活动以及在检查交通工具时显得有必要的任何其他活动。
• 记录所用的零件和备件的实际价值以及劳务。
• 在完成所有的维修时计算总费用。
• 创建发票并且将其交给顾客。

工作订单的流程示意图：

工作订单的类图实例：

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

• 许多步骤涉及到遗留系统和数据库的连接，它们不可能遵循OO范式来进行设计。
• 如果修改流程或者工作流，那么里面的代码就必须更改。

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

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

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

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

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

昨天听完IBM关于SOA的讲座，回来又认真看了下IBM提供的一些资料，还是觉得我们小组没有理解透SOA的概念，我们前面所做的设计，更多的是从OOAD的方式去考虑。虽然我们设计了很多的服务，但没有很好的把服务跟流程分离出来。我们先前的设计还是比较正确的，只要稍微改动下用例之间的关系，再设计出工作流程，应该就可以了。这样思考下来的话，业务流程就在我们的设计中显得非常重要了，建议大家多思考一下ESB的内容。