直接和间接业务分析

        通过项目相关人员的会谈和 CBM 来进行 BPM 和直接需求分析是一个容易理解且非常合适的标识候选服务的方法。

        过去的经验表明，这条主要的途径应该通过补充间接技术来加以改进。在选择候选服务时，产品经理和其他业务领导应该进行协商。例如，什么是计划付款和开票模型？应该商议假定使用正在构建中的系统的企业的组织结构图。建议还考虑一下非 SOA 项目中任何现有的用况模型。用于对正在构造的系统进行营销介绍的术语是另一个很好的关于服务操作候选者的来源（特别是动词，很少关注营销动词！）。

域分解

        在  Endrei 中定义的域分解、子系统分析、目标模型创建和相关技术是 SOA 流程构造方法或服务概念化框架（它是基于 Levi and Arsanjani 先前完成的工作构建的）最有希望的提议。来自 SEI 的 FODA 工作也为这方面的讨论做出了贡献。

服务粒度

        选择正确的抽象级别是服务建模的一个关键问题。您常常会听到进行粗粒度建模的建议。这有点过于简单化了。您应该将其改为在不损失或损害相关性、一致性和完整性的情况下尽可能地进行粗粒度建模。在任何 SOA 中，都有细粒度服务抽象的空间（假定有业务要求的话）。由于 SOA 并不等同于 Web 服务和 SOAP，因此可以使用不同的协议绑定来访问抽象级别不同的服务。另一种选择就是将一些相关的服务捆绑成粗粒度的服务定义，这是门面模式的变种。

命名约定

        应该定义企业命名模式（XML 名称空间、Java 包名、Internet 域）。简单的例子就是始终用名词来命名服务，而用动词来命名操作。这种非常好的实践来源于 OOAD 空间。

第一类 SOAD 原理

除了组合 OOAD、BPM 和 EA 技术之外，还有几个重要的 SOAD 概念和方面有待充实：

服务分类和聚合
策略和方面
中间相遇流程
语义代理
服务获取和知识代理
服务分类和聚合

        服务有不同的用法和用途；例如，软件服务可以不同于业务服务（如前面的图 5 所示）。此外，还可以将原子服务编排成级别更高、功能齐全的服务。

        服务组合可以通过可执行模型（如 BPEL 建模的模型）来加以简化；这是传统的建模工具和方法不能处理的事情。

策略和方面

        服务具有语法、语义和 QoS 特征，所有这些都必须进行建模；正式的接口契约必须涵盖的比 Web 服务描述语言（Web Services Description Language，WSDL）的多。因此， Web 服务策略（WS-Policy） 框架是一个重要的相关规范。

        除了已经制定的良好体系结构可跟踪性原则之外，业务可跟踪性也是一个理想的品质：应该有可能将所有的运行时构件直接与非技术领域专家可以理解的语言联系起来。这对于直接在业务和服务层公开的抽象非常重要。Sarbanes-Oxley (SOX) 法案（请参阅来自 Astor 的文章）是需要这种业务可跟踪性的业务驱动程序的一个例子。

流程：中间相遇

        在真实世界中，并没有全新的项目，必须始终考虑遗留系统（遗留系统是现有系统的同义词）。因此，需要中间相遇的方法，而不是单纯的自顶向下或自底向上的流程。

        在设计取决于现有的 IT 环境而不是现在和将来的业务需要的情况下，自底向上的方法往往会导致不好的业务服务抽象。而自顶向下的方法可能会产生不足的非功能性需求特征，并且损害其他的体系结构品质因素（例如因域模型中缺乏标准化而导致的性能问题），另外，也会在服务和组件中产生不匹配的不良问题。

服务获取和知识代理

        这是一个知识管理和生命周期问题：如何成功地准备好服务并且使其在概念化之后可以重用？

        应该将重用看作是标识和定义服务最主要的推动标准之一。如果组件（或服务）不可能重用，就不无法将其作为服务进行部署。它可以连接到另一个与企业体系结构相关的服务，但是不能单独作为一个服务而存在。

        然而，即使从开始就计划好了重用，还必须形式化服务获取流程。由多个使用者使用服务是明确的 SOA 设计目标。构建时服务注册中心（例如企业 UDDI 目录）可能能够解决部分问题。

示例：汽车工作订单

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

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

业务场景如下：

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

        如果您将工作订单构造为一个 OO 应用程序，这些软件对象将包含所有必需的业务规则，并且理解应该遵循的业务流程。

        然而，这种方法在实践方面存在着一些缺点：

        许多步骤涉及与现有遗留系统和数据库（例如帐单编制、日程安排以及库存系统）的连接，它们不可能遵循 OO 范式进行设计（在这样的情况下，应用适配器或仲裁器会有所帮助）。 
        为了使系统尽可能地灵活，将一些规则外化是有帮助的，这样就可以在不更改代码的情况下修改流程或工作流。例如像下面这样的规则： 
        标准的 24,000 英里服务包括四公升油。只是在使用四升以上的油或顾客要求优质油（如合成油）时才应该收取额外的邮费。 
        在遗留应用程序中有一套工业标准为普通汽车维修活动进行劳务估价。除非维修人员收取的费用超过该估价的 X% 并且报告产生差别的有根据的原因，否则顾客就应该支付标准的劳务费。 
        如果超过估价的 Y% 以上，就应该联系顾客以进行确认。 
        SOAD 为这些问题提供了极好的解决方案。由于它基于相关的行为对服务进行分组，而不是进行封装（行为及数据），所以这组服务与业务对象略有不同。

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

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

        从概念上讲，从第一次顾客联系到完成工作和帐单支付的整个业务表示单个宏观层次的工作单元，并具有数天到数周不等的生命周期。毕竟，从企业的角度来看，工作单元会产生收入。然而，实际出现的情况是在一段相对长的时间内单独发生的一系列集中活动，例如，定义活动、安排预约、选择零件和备件、进行维修活动等等。在 IT 系统中，没有实际的流程会持续几分钟以上；事件之间的业务流程状态以数据的形式保存在数据库中。

        这种类型的流程可以用状态转换模型（例如 UML 中可用的）很好地进行显示了用有限状态机（finite-state machine）方法如何对业务流进行建模的示例。它是在业务流程进行时工作订单的状态如何改变的高级视图。业务流程编排集中于状态之间的这些转变。单独的操作永久地记录相关的状态改变。

总结和展望

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

        在详细定义 SOAD 表示法和流程的同时，还确定了关键的原理，比如服务概念化（或标识）、服务分类或聚合、策略和方面、中间相遇流程、语义代理和服务获取（以供重用）。SOAD 需要增强现有的软件开发方法，进一步提高企业应用程序开发项目的可用性和适用性。随着时间的推移，还将发展相关的非常好的实践。

        我们还认识到，UML 在流程的表示法选择方面将继续占支配地位；可能需要进行增强以满足更广泛的 SOAD 的要求。完成 SOAD 方法的下一步就是定义所需的端到端流程和表示法，复审活动中的角色和它们的责任，并且继续检查所提议的方法在项目中的有效性。