面向构件SOA架构设计 解决软件灵活性问题

其实，就现实世界而言，到处都是面向服务的业务。一座城市向居住或来到这个城市的人提供各种各样的服务。这些服务分别由不同的服务提供者提供，这些服务提供者包括政府部门、企业、社会团体和自由职业者等。人们早已习惯为享受某种服务而参与某种业务，商业机构也早已习惯为发展某项业务而向公众或其他团体提供某种服务。可以说，服务和业务是有着某种天然联系的，具有很强的业务亲和力和包容度。面向服务的架构就是要通过将信息技术直接作用于服务的实现，从而实现信息技术与实际业务的优质对接。

面向服务设计原则

封装原则

为了保持自治(Autonomy)和抽象(Abstraction)，服务封装了其内部的逻辑，同时对外部进行隐藏(服务契约规定的除外)。服务从来都不是孤立的，它必定有其适用的上下文环境。上下文环境可以是一个业务规则、一个业务实体或者一些业务逻辑的组合。业务可大可小，因此服务所关注的问题可大可小，服务所表示的业务逻辑的规模和范围也各不相同。此外，服务还可包含其他服务提供的业务逻辑，在这种情况下，一个大的服务由多个子服务组合而成。例如，一个业务自动化处理解决方案通常是一套业务流程的实现。按照业务规则和运行时条件，一个业务流程被分解成预先定义好顺序的一系列步骤。在基于服务来构建该业务流程的自动化解决方案的时候，每一个步骤可以被封装为一个服务，或者可以先将多个步骤组合成的一个子流程，然后再将该子流程封装为一个服务，甚至可以将整个流程封装为一个服务。

关联原则

服务可以被其它服务调用，因此服务与服务之间必须建立某种特殊的联系，我们称为关联。关联过多会造成服务之间的紧耦合，最终导致整个架构的脆弱。为避免这种情况，服务设计者需要谨慎地选择服务，使它们之间建立“松耦合”(Loose coupling)的关系，使得服务之间的耦合降到业务需要的最低，从而使服务之间仅维持相互了解所必须的最少的依赖关系。

服务之间的相互了解是通过服务描述(Service description)来实现的。服务描述至少要包含服务的名称、它所实现的具体功能、以及服务的使用方式和调用的返回值等。为了保证服务描述能够被其它服务容易地理解，需要遵守共同的描述方式和语法——服务契约。通过标准的服务契约，服务可以相互理解，无须或很少人工干预。

复用原则

服务应该是可复用(Reusability)的。它不仅可以被其它服务或使用者调用，而且可以与其它服务一起组合成新的服务。

SOA通过服务、服务契约和消息通讯提供了一个支撑复用性的基本架构。其中，服务的精细度是决定服务复用程度的最重要因素。一般而言，服务的精细度越高，服务越细致，其复用性也就越强。但是随之而来的系统的复杂度也会越来越大，服务多，意味着系统必须同时维护大量不同的服务及其组合，反过来会降低复用的意义。此外，同等条件下，服务的开发成本相比传统的基于模块或类的开发方法要高。原因是，服务不仅要完整实现其业务功能和保证其自身的性能(这一点和传统开发方法一样)，而且还要符合SOA所要求的各项规定，以保证SOA架构的统一。因此，服务不是越多越好，服务的设计者必须准确把握服务的精细度，在保障总实现成本最低的同时，还要遵循SOA架构的标准和规范，从而真正发挥SOA架构的优势。

质量原则

在SOA架构中，服务是最小设计单元。如果把SOA比喻为一座大厦，那么服务就是构建整座大厦的砖石。显然，服务必须满足一定的质量要求，才能真正被SOA所用。这里的质量要求，不仅包括业务功能的要求，还应包括其它非功能性要求，如可用性、性能、伸缩性、安全性以及隐私策略等。在不同的上下文中，对服务质量的要求也不尽相同。因此，服务还应具备灵活适应各种不同服务宿主环境的能力，满足各种环境下对服务质量的要求，甚至可以根据不同的环境自动提供与之相适应的质量属性供其选择。

在服务上下文中，服务质量(QoS)可以看作为一种基于一组定量特性提供保证的机制。这些特性基于重要的功能性和非功能性服务质量属性来进行定义，其中包括实现和部署相关的问题以及其他的重要服务特性，例如：服务测量和计费、性能衡量(如响应时间)、安全需求、(事务)完整性、可靠性、伸缩性和可用性等。对于理解服务的整体行为使得其他应用程序可以与其进行绑定并使其作为商业过程的一部分而执行，这些特性是很必要的。

在Web服务环境中，支持服务质量(QoS)的关键元素包括可用性(服务持续对外提供的能力)、完整性(功能实现的程度)、性能(吞吐量和延迟)、可靠性(用每月或每年的事务失败数表示)、伸缩性和安全性(认证、授权、消息完整性和机密性)。

Web服务采用服务水平协议(SLA)作为服务提供者和使用者的正式协议，即用一种服务提供者和使用者共同理解和同意的形式描述Web服务的详细信息。为达到服务的设计目标，服务提供者和使用者都必须遵守SLA，因此SLA在维持服务供应关系中是一种重要并且应用广泛的工具。

SLA中的衡量标准必须和提供的服务的整体目标关联起来。针对这个问题，Web服务标准组建立了一个标准的策略框架，如Web服务策略框架(WS-Policy)，使得开发人员能够表达服务的策略，Web服务能够理解这些策略并在运行时实施它们。

在面向服务的基础上，我们还需要对业务流程进行梳理和整合，从而使得我们能够迅速地采用面向构件的SOA架构来实现它。因此，我们需要对流程进行重新设计。需要特别指出的是，这里的重新设计是指采用构件技术，用面向服务的思想对业务流程进行梳理、分解和整合，并不是一味地要求业务实际改变原有的流程来适应技术上的要求。虽然我们鼓励业务和技术相结合，但这并不是SOA要解决的问题。

流程设计一方面要将冗繁的、复杂的业务实际分解为若干个流程或子流程，另一方面需要考虑选择什么服务或开发什么服务，然后通过服务的组合来实现具体的业务流程。就前者而言，将业务实际分为若干服务领域是一种常用的分析方法。服务领域是一个业务域，由一系列彼此相关又相互协作的具体业务流程组成，例如贷款、保险、银行、商业、制造和人力资源等。从这个角度上说，一个应用可以分解为若干不同服务领域(业务领域)，每个服务领域可以由一组专门针对该领域开发的服务和一些通用的基础服务组合而成。

总结

面向构件的SOA架构是一项令人鼓舞的技术，人们期待它解决长期困扰软件工程领域的软件复用和软件灵活性问题。需要特别指出的是，面向构件并不是实现SOA架构的唯一手段，我们应该根据项目的实际情况选择适当的技术来实现SOA。