概述 目前，关于SOA(面向服务的架构)的研究和讨论已经成为IT业界的新热点。尽管各方研究者和专家对SOA架构的认识和理解不尽相同，各IT厂商提供的SOA解决方案也不一而足，SOA相关标准仍在不断发展和完善之中，但大家却都有一个共同的认识，那就是SOA代表着今后一段时期软件技术的发展方向，并已经开始从研究阶段进入实施和推广阶段。本文试图从面向构件的角度，介绍一些SOA架构设计的基本思想和方法论。首先简单介绍一些构件设计和实现的基础知识，然后重点介绍面向服务设计的基本原则和方法。
构件的组成要素
构件是软件开发、复用和软件组装的实体单元，包括以下要素：构件类型(componenttype)、构件实现(componentimplement)、提供接口(provides-interfaces)和依赖接口(requires-interface)。
构件类型(componenttype)：构件类型表明构件是处理什么问题和提供哪些接口功能，它包含了构件类型的名称。
构件实现(componentimplement)：对构件类型的具体实现称为构件实现，一个构件类型可能有多个构件实现。
提供接口(provides-interfaces)：提供接口指构件提供给外部程序使用的接口。
依赖接口(requires-interface)：依赖接口指构件运行时所必须依赖的外部程序接口。
构件的基本特征
复用：复用是构件最基本的性质，构件的设计必须满足未来能在新的应用、项目中使用。
封装：构件封装对外界隐藏构件的设计和实现细节，仅通过接口与外界交互。这可以保证构件功能复用的完整性和构件开发及交付的独立性。
组装：构件可以通过组装形成新的构件或系统，组装是构件复用的手段，同时具备可插拔，便于替换，系统可以由不同的开发商开发的构件组装而成。
粒度：构件是有大小的，越是跟领域相关的构件粒度越大，小粒度的构件可以方便的组装成较大粒度的构件。
层次：构件可以按层次进行划分，企业级应系统的复杂逻辑可以通过层次来解决，不同的层次需要不同层次的构件。按照MVC的体系架构，可以把构件划分为：展现层、控制层、业务层、运算层及数据层等。
构件的实现
目前软件市面上有三个代表性的构件技术标准分别是：COM/DCOM、CORBA和EJB。
COM/DCOM：COM(Conponent Object Model)是由Microsoft公司推出的构件接口标准，DCOM是指可以分布式布的COM。
CORBA：CORBA(Common Object Request Broker Architecture)是由对象管理组织(OMG)提出的构件技术标准。
EJB：EJB是由SUN公司提出的构件技术标准。
以上三种构件标准实现的构件互相依赖的方式仍然是基于对象接口式的，当系统复杂度到一定规模时，整个系统会因依赖关系混乱而陷入失控。
比较理想的构件模型是构件之间是数据耦合的，每个构件只单独与数据总线发生联系。当需求发生变化时，可以对各个单独的构件进行添加、减少或者修改而不影响整体的架构和性能。基于数据耦合的构件，据有很高的独立性，对需求变化有较强的适应能力。
构件技术与构件化
构件技术与构件化的区别在于，构件化的关注点不在于构件本身的技术实现，而在于如何把应用系统分解成稳定、灵活、可重用的构件，在于如何利用已有的构件库组装出随需应变的应用软件，从一个面向构件的环境中去分析应用，如何做出灵活、重用的构件来思考。但是，构件技术是构件化的基础，它为构件的工厂化生产提供技术保障。
传统的软件方法学是从面向机器、面向数据、面向过程、面向功能、面向数据流等反映问题的本质；而构件技术关注的是在构件已经可用的情况下，在更高层次上的组装和复用。面向构件的软件设计方法把装配和制造分离，构件运行时负责提供标准接口和框架，负责软件装配，而构件负责软件的制造，使软件开发变成构件的组装。
接下来，我们将开始介绍面向服务(SOA)的设计。
面向服务设计
服务代表一段完整的业务单元，并且可以根据特定用户的需求组织成为更大和新的服务。服务可以由一个或多个构件组合而成。服务开发者必须考虑构件的粒度，以及构件的流程和组装，这样他们在改变服务的实现时，可以尽可能少的影响其它构件、应用和服务。而服务的设计者则更关心选择合适的服务，并将它们以可管理的方式组织，并最终将它们组装为完整的业务流程。
“面向服务”表示一种分离系统关注面的方法，其实质是将一个比较大的问题分解成一系列较小的、互相关联的子问题，从而降低问题的复杂度，使得我们能够较从容地分析、解决和管理它。传统的面向对象的设计方法其实也是一种分离系统关注面的方法，只不过它是在对象层面来分离关注面，相对业务逻辑较远，而面向服务则是在服务层面来分离关注面，直接关注的是业务逻辑，从而使面向服务能够(至少在理论上)更好地满足业务需求。
其实，就现实世界而言，到处都是面向服务的业务。一座城市向居住或来到这个城市的人提供各种各样的服务。这些服务分别由不同的服务提供者提供，这些服务提供者包括政府部门、企业、社会团体和自由职业者等。人们早已习惯为享受某种服务而参与某种业务，商业机构也早已习惯为发展某项业务而向公众或其他团体提供某种服务。可以说，服务和业务是有着某种天然联系的，具有很强的业务亲和力和包容度。面向服务的架构就是要通过将信息技术直接作用于服务的实现，从而实现信息技术与实际业务的优质对接。
面向服务设计原则
封装原则为了保持自治(Autonomy)和抽象(Abstraction)，服务封装了其内部的逻辑，同时对外部进行隐藏(服务契约规定的除外)。服务从来都不是孤立的，它必定有其适用的上下文环境。上下文环境可以是一个业务规则、一个业务实体或者一些业务逻辑的组合。业务可大可小，因此服务所关注的问题可大可小，服务所表示的业务逻辑的规模和范围也各不相同。
此外，服务还可包含其他服务提供的业务逻辑，在这种情况下，一个大的服务由多个子服务组合而成。例如，一个业务自动化处理解决方案通常是一套业务流程的实现。按照业务规则和运行时条件，一个业务流程被分解成预先定义好顺序的一系列步骤。在基于服务来构建该业务流程的自动化解决方案的时候，每一个步骤可以被封装为一个服务，或者可以先将多个步骤组合成的一个子流程，然后再将该子流程封装为一个服务，甚至可以将整个流程封装为一个服务。
关联原则 服务可以被其它服务调用，因此服务与服务之间必须建立某种特殊的联系，我们称为关联。关联过多会造成服务之间的紧耦合，最终导致整个架构的脆弱。为避免这种情况，服务设计者需要谨慎地选择服务，使它们之间建立“松耦合”(Loose coupling)的关系，使得服务之间的耦合降到业务需要的最低，从而使服务之间仅维持相互了解所必须的最少的依赖关系。
服务之间的相互了解是通过服务描述(Service description)来实现的。服务描述至少要包含服务的名称、它所实现的具体功能、以及服务的使用方式和调用的返回值等。为了保证服务描述能够被其它服务容易地理解，需要遵守共同的描述方式和语法——服务契约。通过标准的服务契约，服务可以相互理解，无须或很少人工干预。
复用原则 服务应该是可复用(Reusability)的。它不仅可以被其它服务或使用者调用，而且可以与其它服务一起组合成新的服务。
SOA通过服务、服务契约和消息通讯提供了一个支撑复用性的基本架构。其中，服务的精细度是决定服务复用程度的最重要因素。一般而言，服务的精细度越高，服务越细致，其复用性也就越强。但是随之而来的系统的复杂度也会越来越大，服务多，意味着系统必须同时维护大量不同的服务及其组合，反过来会降低复用的意义。此外，同等条件下，服务的开发成本相比传统的基于模块或类的开发方法要高。原因是，服务不仅要完整实现其业务功能和保证其自身的性能(这一点和传统开发方法一样)，而且还要符合SOA所要求的各项规定，以保证SOA架构的统一。因此，服务不是越多越好，服务的设计者必须准确把握服务的精细度，在保障总实现成本最低的同时，还要遵循SOA架构的标准和规范，从而真正发挥SOA架构的优势。
质量原则在SOA架构中，服务是最小设计单元。如果把SOA比喻为一座大厦，那么服务就是构建整座大厦的砖石。显然，服务必须满足一定的质量要求，才能真正被 SOA所用。这里的质量要求，不仅包括业务功能的要求，还应包括其它非功能性要求，如可用性、性能、伸缩性、安全性以及隐私策略等。在不同的上下文中，对服务质量的要求也不尽相同。因此，服务还应具备灵活适应各种不同服务宿主环境的能力，满足各种环境下对服务质量的要求，甚至可以根据不同的环境自动提供与之相适应的质量属性供其选择。
在服务上下文中，服务质量(QoS)可以看作为一种基于一组定量特性提供保证的机制。这些特性基于重要的功能性和非功能性服务质量属性来进行定义，其中包括实现和部署相关的问题以及其他的重要服务特性，例如：服务测量和计费、性能衡量(如响应时间)、安全需求、(事务)完整性、可靠性、伸缩性和可用性等。对于理解服务的整体行为使得其他应用程序可以与其进行绑定并使其作为商业过程的一部分而执行，这些特性是很必要的。
在Web服务环境中，支持服务质量(QoS)的关键元素包括可用性(服务持续对外提供的能力)、完整性(功能实现的程度)、性能(吞吐量和延迟)、可靠性(用每月或每年的事务失败数表示)、伸缩性和安全性(认证、授权、消息完