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

　　在这一部分中，我们将更详细地描述 SOAD 的需求，并且开始确定它的主题和原理。目的是将关于这个主题的讨论引到进一步的设计工作。进一步的工作无疑需要形式化 SOAD 方法。

　　SOAD 必须提供什么?

　　已经为 SOAD 确定了下列需求：

　　正如任何其他的项目和方法一样，必须正式(至少半正式)地定义 流程和 表示法。通过选择和组合 OOAD、BPM 和 EA 原理，就可以在需要时确定额外的原理。

　　必须有结构化的方法来概念化服务：

　　OOAD 为我们提供了应用程序层上的类和对象，而 BPM 具有事件驱动的流程模型。SOAD 需要将它们结合在一起。

　　方法不再是面向用况的，而是由业务事件和流程驱动的。用况建模是在更低的层次上作为第二步进行的。

　　方法包括语法、语义和策略。这就需要特别的组合、语义代理和运行时发现。

　　SOAD 必须提供定义良好的品质因素和最佳实践(例如回答粒度问题)。必须回答 BPEL 提出的角色问题。例如，谁为哪部分工作负责：是开发人员、架构师，还是分析人员?

　　SOAD 活动还必须回答这样的问题：什么 不是好的服务?例如：不可重用的任何东西都不可能成为好的一流 SOA 成员(即服务)。另一个例子就是带有挑战性的非功能要求的嵌入式实时系统，它们不能承受任何 XML 处理开销。

　　SOAD 必须易于进行端到端建模，并且有全面的工具支持。假如 SOA 给业务带来了灵活性和敏捷性，就应该对从企业到体系结构和应用程序设计领域产生的支持方法有相同的期望。

　　品质因素

　　一些通用原则或品质因素已经确定，并且可以作为 SOAD 中的设计基准：

• 　　构思良好的服务给业务带来了灵活性和敏捷性;它们通过松散耦合、封装和信息隐藏使重构更加容易。
• 　　设计良好的服务是有意义的，并且不只适用于企业应用程序;服务之间的依赖性减到最少，并且是显式声明的。
• 　　服务抽象是内聚、完整和一致的;例如，在设计服务和它们的操作签名时应该考虑 创建(Create)、 读取(Read)、 更新(Update)、 删除(Delete)和 搜索(Search)(CRUDS) 隐喻。

　　常常声明的假定是，服务是无状态的(例如非对话式的);为了要求服务在特定的问题域和上下文中是无状态的，将削弱这种声明。

　　领域专家无需深奥的专业知识就可以理解服务命名。

　　在 SOA 中，所有的服务都遵循相同的设计体系(通过模式和模板连接的)和交互模式;底层体系结构形式可以容易地标识(例如在体系结构复审期间)。

　　服务和服务使用者的开发除了领域知识之外只需要基本的编程语言技能;中间件专业知识只有少数的专业人员才需要，在理想的情况下，这种知识是为工具和运行时厂商所用，而不是为制作像 SOA 这样的企业应用程序的公司所用。

　　服务标识和定义

　　自顶向下的业务级建模技术(如 CBM)可以为 SOA 建模活动提供起点。但是正如我们在前面提到的，SOA 实现很少是在全新的项目中开始的;创建 SOA 解决方案几乎总需要涉及集成现有的遗留系统，方法是将它们分解成服务、操作、业务流程和业务规则(同时参见 图 6)：

　　将现有的应用程序和厂商软件包分解成表示相关操作组的离散服务集(自底向上方法)。

　　从应用程序中将业务流程和规则抽象为由业务编排模型管理的单独 BPM。

　　图 6. 服务分解

　　所有的 OOAD 都同标识和定义服务有关;但是还需要具有更高层的观点。此外，当 SOA 致力于比经典开发项目层次更高的开发时，就有了发挥其他创造性思维的空间。

　　直接和间接业务分析

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

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

　　域分解

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

　　服务粒度

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

　　命名约定

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