业务驱动服务，服务驱动技术
从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。
业务敏捷是基本的业务需求
SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。
一个成功的SOA总在变化之中
SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。
SOA基础
在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。但MDA有一些局限性：首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。
SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM的目标是仅仅创建用户想要的，而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。AM的主要弱点是其规模上的限制，例如，XP在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。
从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避开它们。但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。
在SOA中有三个抽象层次，按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来实现这个连接。
SOA的五视图实现方法
企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-view approach）。
四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。弟五个视图，use-case视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。
为了表示面向对象的架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠：由业务模型和服务模型表示的业务领域和由服务模型及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。
SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。
SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说，SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示，涉众（stakeholders，译者注：RUP中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。
我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、工作流以及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层次。幸运的是，这方面的产品即将上市。
另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在，我们来使用它们集成吧”，对Web services技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发展，IT走出低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
