从建模的观点来看，由此带来的挑战是如何描述设计良好的操作、服务和流程抽象的特征以及如何系统地构造它们。这些相关问题都是当前行业内和学术界最常讨论的问题。据我们所知，最近几乎所有的 SOA 项目或专题研讨会都将这样的服务建模方面作为重要的主题，并引起了许多的争论。因此，让我们更近地作一番审视。
为什么 BPM、EA 和 OOAD 还不够？
早期的 SOA 实现项目经验表明，诸如 OOAD、EA 和 BPM 这样的现有开发流程和表示法仅仅涵盖支持 SOA 范式所需的部分要求。SOA 方法在加强已经制定的良好通用软件体系结构原则（如信息隐藏、模块化和问题分离）的同时，还增添了附加的主题，例如，服务编排、服务库和服务总线中间件模式，在建模时需要对它们给予特别的关注。
图 1 展示了现有的 EA、BPM 和 OOAD 建模方法的主要应用领域，也是我们随后讨论 SOAD 的出发点。图中的水平轴表示项目生命周期阶段；垂直轴表示不同抽象层或领域之间的区别，而建模活动通常就是在其上进行的。
图 1. BPM、EA 和 OOAD 的位置
SOA 的远景是相当容易理解的，因为它的技术基础众所周知。例如，在任何 SOA 工作中，应用通用的软件体系结构原则和 OO 技术都是一个有效的开端。然而，正如我们已经提到的，早期采用者最常询问的问题是如何标识正确的服务。如前所述，OOAD、EA 和 BPM 在各自独立地应用时不能提供满意的答案，而这正是我们现在要说明的。
在由 Booch 和 Jacobson 撰写的开创性的书（大约 10 年前出版的）中介绍的 OOAD 方法在定义 SOA 方面提供了非常好的起点。同样地，虽然许多年来在体系结构层次中应用 OOAD 技术和统一建模语言（Unified Modeling Language，UML）表示法是一个常见的实践，但是 OOAD 还是与像类和单独的对象实例这样的微观层次的抽象有关。由于每个问题域常常都创建单独的用况模型，因此，应用程序开发项目，这个企业的大方向在许多情况下变得模糊。此外，由于种种原因，用况模型并不总是与其对等的 BPM 保持同步。
诸如 Treasury 企业体系结构框架（Treasury Enterprise Architecture Framework，TEAF）、面向特征的领域分析（Feature-Oriented Domain Analysis，FODA）和 Zachman 这样的 EA 方法都将城市规划级的观点加在解决方案体系结构之上，但是并没有解决如何找到易于重用且具有持久性的高质量企业抽象的问题。
虽然 BPM 方法（如 BPMI）在功能工作单元之上提供了端到端视图，但是它们通常都没有触及体系结构和实现领域。例如，在像用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL）这样的语言出现之前，BPM 表示法缺少操作语义。此外，我们还看到了许多流程建模与开发活动彼此分离的情况。
最后，现有的规则中没有一个可以解决如何为 SOA 启用现有的应用程序的问题；大部分时间都采用自顶向下流程。现有的系统通常都存放有大量的重要数据和业务逻辑，并且不能简单地加以替代。因此，为了研究包装和重构策略，必须对这些系统进行自底向上的分析。因此，对现有应用程序的考虑会将我们带到中间相遇的流程。
由于这些原因的存在，所以需要混合 SOAD 建模方法。这种方法以最佳的方式组合了 OOAD、BPM 和 EA 中的原理，并且融入了一些具有创新性的原理。图 2 展示了这种新的方法的 SOAD 资源（原理和技术）：
图 2. SOAD 及其组成部分：OOAD、BPM 和 EA
EA
将企业应用程序和 IT 基础设施发展成 SOA 可能是一个大的负担，会影响多个业务线和组织单元。因此，需要应用 EA 框架和参考体系结构（如开放组织体系结构框架（The Open Group Architecture Framework，TOGAF））以及 Zachman，以努力实现单独的解决方案之间体系结构的一致性。
文章来源于领测软件测试网 https://www.ltesting.net/
