架构设计师与SOA

1、架构设计师与SOA， 第 1 部分强 王 (shilir), IBM中国软件开发实验室 - SOA Design CenterSOA(Service-Oriented Architecture)，即面向服务的架构，这是最近一两年出现在各种技术期刊上最多的词汇了。现在有很多架构设计师和设计开发人员简单的把SOA和Web Services技术等同起来，认为SOA就是Web Service的一种实现。本质上来说，SOA体现的是一种新的系统架构，SOA的出现，将为整个企业级软件架构设计带来巨大的影响。本系列两部分文章将根据作者自己的理解来帮助大家分析和了解什么是SOA架构，SOA将怎样对企业系统架构设

2、计带来积极的影响，什么是SOA架构设计师的角色，以及SOA架构师在设计SOA系统架构时有哪些应该特别注意的地方。1. 什么是架构？什么是基于SOA的架构？11 什么是架构从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠

3、性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。12 什么是基于SOA的架构SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提

4、供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。利用基于SOA的系统构建方法，如图1中所示的一样，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务（services）。图1因此，SOA架构本质上来说体现了一种复合的概念：它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service

5、开发提供了指导。2. SOA架构设计师的角色21 SOA架构设计师应该具备什么？谈到SOA架构设计师的角色，我们首先要了解架构设计师应具有的能力。总体上来说，一个好的架构设计师不仅应该是一个成熟的，具有实际经验的并具有快速学习能力的人，而且他还应该具有良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时刻作出困难的决定，这就是一名架构设计师应该承担的责任。从角色上来看，SOA 架构师不仅会负责端到端的服务请求者和提供者的设计，并且会负责对系统中非功能服务请求的调研和表述。 对于任何一名经验丰富的架构设计师来说，不论他是采用基于传统的架构设计方法（基于J2EE架构或者.NET

6、架构）还是采用基于SOA的架构设计方法来构建一个企业级的系统架构，具有相关商业领域的知识对于架构设计师来说都是必不可少的，架构设计师往往可以通过实际的工作经验积累以及接受相关的专项培训来获得这些商业领域的知识。除了具有相关商业领域的知识以外，一名合格的架构设计师必须具有较广泛的技术背景，这可能包括软硬件，通信，安全等各个方面的知识。但这并不是意味着要成为一名架构设计师就必须熟悉每一门具体技术的细节，架构设计师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术的特点以及优缺点，只有这样架构设计师才能在特定的应用场景下正确地选择各种技术来设计企业整体架构。22 什么是SOA架构设计师的职责？

7、那什么是企业级SOA架构设计师的具体角色呢？什么是SOA架构设计师与设计和开发人员之间的差别呢？相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生？也就是说架构设计师关注的应该是一些商业需求和服务级别（service-level）需求。所有的架构设计师的角色都包含了在构建一个

8、系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别（service-level）需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。作为SOA架构设计师必须要能够领导整个

9、开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。3. 构建SOA架构时应该注意的问题31 原有系统架构中的集成需求当架构师基于SOA来构建一个企业级的系统架构的

10、时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。我们都知道，面向服务的体系结构是当前及未来应用程序系统开发的重点，面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统；SOA可以通过利用当前系统已有的资源（开发人员、软件语言、硬件平台、数据库和应用程序）来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发

11、的成本和风险。因此，当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都

12、有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI（Electronic Data Interchange 电子数据交换）系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续

13、得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。32 服务粒度的控制以及无状态服务的设计当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方：首先是对于服务粒度的控制，另外就是对于无状态服务的设计。服务粒度的控制 SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口

14、的具体的内部操作。 举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口给系统的外部用户，就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证了服务请求者将以一致的方式

15、使用系统中所暴露出的服务。虽然面向服务的体系结构（SOA）并不强制要求一定要使用粗粒度的服务接口，但是建议使用它们作为外部集成的接口。通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。无状态服务的设计 SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，我们最好把它定义成具体的业务流程（BPEL）。在服务的具体实现机制上，我们可以通过使用 EJB 组件来实现粗粒度的服务。我们通常会利用无状态的Sessio

16、n Bean来实现具体的服务，如果基于Web Service技术，我们就可以将无状态的Session Bean暴露为外部用户可以调用的到的Web服务，也就是把传统的Session Facade模型转化为了 EJB 的Web服务端点，这样，我们就可以向 Web 服务客户提供粗粒度的服务。如果我们要在 J2EE的环境下（基于WebSphere）构建Web服务，Web 服务客户可以通过两种方式访问 J2EE 应用程序。客户可以访问用 JAX-RPC API 创建的 Web 服务（使用 Servlet 来实现）；Web 服务客户也可以通过 EJB的服务端点接口访问无状态的Session Bean，但W

17、eb 服务客户不能访问其他类型的企业Bean，如有状态的Session Bean，实体Bean和消息驱动Bean。后一种选择（公开无状态 EJB 组件作为 Web 服务）有很多优势，基于已有的EJB组件，我们可以利用现有的业务逻辑和流程。在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。另外EJB容器会自动提供对并发的支持，作为无状态Session Bean实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何

18、特定实例的请求。 由于EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发人员可以不需要编写安全代码以及事务处理代码。 性能问题对于Web服务来说一直都是一个问题，由于几乎所有 EJB 容器都提供了对无状态会话 Bean 群集的支持以及对无状态Session Bean 池与资源管理的支持，因此当负载增加时，可以向群集中增加机器，Web 服务请求可以定向到这些不同的服务器，同时由于无状态Session Bean 池改进了资源利用和内存管理，使 Web 服务能够有效地响应多个客户请求。由此我们可以看到，通过把 Web 服务模型化为 EJB 端点，可以使服务具有更

19、强的可伸缩性，并增强了系统整体的可靠性。4. 结束语本文简要介绍了有关架构设计师以及SOA架构的知识，分析了SOA架构师在设计SOA系统架构时有哪些应该特别注意的地方。本文的第二部分将向您介绍在构建基于SOA架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度，SOA是一种新的设计模式，方法学。因此，SOA本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的SOA系统开发设计人员起到一定的帮助作用。参考资料 1. Patterns: Service-oriented

20、Architecture and Web Services红皮书，SG24-6303-00，2004 年 4 月，作者Mark Endrei 等。 2. DeveloperWorks 的SOA 和 Web 服务专区有大量专题文章以及关于开发 Web 服务应用程序的入门级、中级和高级教程。 3. 有关随需应变商务的更多信息，请参阅 Developer resources for an on demand world Web site 4. Web 服务项目角色 描述了 Web 服务开发项目中所涉及到的各种不同的工作角色，包括各自的目标，任务以及彼此之间是如何协作的。 5. 面向服务的分析与设计原

21、理一文研究了OOAD、EA 和 BPM 中的适当原理。 6. 企业服务总线解决方案剖析，第 1 部分 介绍了面向服务的体系结构(service-oriented architecture，SOA)和企业服务总线(Enterprise Service Bus，ESB)的基本知识，ESB的技术沿革，以及ESB与SOA之间的关系。 关于作者王 强,IBM软件工程师，工作在IBM中国软件开发实验室 - SOA Design Center，从事Incubator及SOA，Grid项目的工作，对J2EE架构、SOA架构、MDA/MDD以及网格计算等技术有较深入的研究。联系方式：wangq 架构设计师与 S

22、OA ， 第 2 部分本系列的第 1 部分 介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时有哪些应该特别注意的地方。本文将延续第一部分的内容，向您介绍了 SOA 为企业级架构设计带来的影响，以及在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。1 SOA 为企业级架构设计带来的影响11 SOA 的特点及其使用范围SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区

23、别于Intranet环境的几个特点主要是：(a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同；(b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定；(c)无法完成服务（service）的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系；位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪

24、一个服务，但并不需要知道所调用服务的物理位置在哪里；而协议无关性要求每一个服务都可以通过不同的协议来调用。通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。12 SOA 架构的分层模型接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。在 SOA 系统中不同的功能模块可以被分为7层：第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。第2层就是组件层，

25、在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型：(1)商业服务（business service） 或者是商业过程（business process）。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。(2)商业功能服务（business function service）， 这类服务会完成一些具体的商业操作，也会被更上

26、层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。(3)技术功能服务（technical function service），这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，第6层中的企业服务总线（ESB）提供了这个功能。第7层主要为整个 SOA 系

27、统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。2 SOA 架构中的非功能性服务级别（service-level）需求除了系统的业务需求，架构设计师还必须要保证构建出来的系统架构能够满足系统中的非功能性服务级别（service-level）需求以及服务质量（QoS）方面的需求。在项目初始及细化阶段，架构设计师应该与系统所有涉及方（Stakeholders）一起，为每一个服务级别需求定义其相关的衡量标准。构建出的系统架构必须要能满足以下几方面的服务水准要求：性能、可升级性、可靠性、可用性、可扩展性、可维护性、易管理性以及安全性。架构设计师在设计架构过程中需要平衡所有的这些服务级

28、别需求。例如，如果服务级别需求中最重要的是系统性能，架构设计师很有可能不得不在一定程度上牺牲系统的可维护性及可扩展性，以确保满足系统性能上的要求。随着互联网的发展，新构建的系统对于服务级别需求也变得日益重要，现在基于互联网的企业系统的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成为企业系统的主要用户。 架构设计师的职责之一就是要尽可能地为提高系统设计人员和系统开发人员的工作效率考虑。在构建整个企业系统架构的过程中，需要充分重视各种服务级别需求，从而避免在系统开发和运行的时候出现重大问题。一个企业级系统中的服务级别需求往往是十分错综复杂的， SOA 架构设计师需要凭借丰富的专业经验和扎

29、实的理论知识来分离和抽象系统中不同的服务级别需求，图3展示了这种分析的过程。 图3经过 SOA 架构设计师分析和抽象的服务级别需求主要分为以下几类：· 性能是指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等； · 可升级性是指当系统负荷加大时，能够确保所需的服务质量，而不需要更改整个系统的架构； · 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力； · 可用性是指一个系统应确保一项服务或者资源永远都可以被访问到； · 可扩展性是指在不影响现有系统功能的基础上，为系统填加新的功能或修改现有

30、功能的能力； · 可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护的能力； · 可管理性是指管理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力； · 安全性是指确保系统安全不会被危及的能力。 1) 性能 我们通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能；另外，我们也可以通过系统能够处理的交易量（每秒）来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不

31、是系统设计开发人员应该关注的事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于 SOA 的架构中使用了很多Web Service来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换

32、。这样做可以在一定程度上提高系统的整体性能。2) 可升级性 可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂

33、直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。3) 可靠性 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，你的系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠

34、性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。4) 可用性 可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可

35、用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持；第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的 SOA 系统架构中的关键性业

36、务能具有较高的可用性。5) 可扩展性 可扩展性是指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素：低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系；服务本身是通过统一的接口定义（可以是WSDL）语言

37、来描述具体的服务内容，并且很好地封装了底层的具体实现。在这里我们也可以从一个方面看到基于 SOA 来构架企业系统能为我们带来的好处。6) 可维护性 可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。同系统的可扩展性相同，当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素：低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系

38、统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口（可以是WSDL）、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。7) 可管理性 可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求（QoS）的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架

39、构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时， SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架（Framework）上。对于 SOA 架构设计师来说，可以选择的底层系统框架有很多，可以选用基于MQ, MessageBorker，WebSphere Application Server等产品来构建企业服务总线（Enterprise Service Bus）以支持企业的 SOA 系统架构，也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构建企业的ES

40、B以支持 SOA 系统架构。具体选择哪种底层框架来实施 SOA 系统架构要根据每个系统各自的特点来决定，但这些底层的框架都已经提供了较高的系统可管理性。因此，分析并选择不同的产品或底层框架来实现企业系统架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构建 SOA 系统，中国 SOA 设计中心已经发表了一系列相关的文章，大家可以在DeveloperWorks中的 SOA 专栏看到它们。8) 安全性 安全性是指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-S

41、ervice)攻击。这就要求当 SOA 架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由Web Service实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。3结束语本系列两部分介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时

42、有哪些应该特别注意的地方并在最后简要介绍了在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度， SOA 是一种新的设计模式，方法学。因此， SOA 本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的 SOA 系统开发设计人员起到一定的帮助作用。参考资料 1. Patterns: Service-oriented Architecture and Web Services红皮书，SG24-6303-00，2004 年 4 月，作者Mark End

43、rei 等。 2. DeveloperWorks 的 SOA 和 Web 服务专区有大量专题文章以及关于开发 Web 服务应用程序的入门级、中级和高级教程。 3. 有关随需应变商务的更多信息，请参阅 Developer resources for an on demand world Web site 4. Web 服务项目角色 描述了 Web 服务开发项目中所涉及到的各种不同的工作角色，包括各自的目标，任务以及彼此之间是如何协作的。 5. 面向服务的分析与设计原理一文研究了OOAD、EA 和 BPM 中的适当原理。 6. 企业服务总线解决方案剖析，第 1 部分 介绍了面向服务的体系结构(se

44、rvice-oriented architecture， SOA )和企业服务总线(Enterprise Service Bus，ESB)的基本知识，ESB的技术沿革，以及ESB与 SOA 之间的关系。企业服务总线解决方案剖析，第 1 部分: 企业服务总线的基本概念李珉, 高级软件工程师，技术经理, IBM 中国软件开发实验室 SOA设计中心· 案，第 1 部分"(developerWorks，2003 年 12 月)作者 Rick Robinson。 · Patterns: Implementing an SOA using an Enterprise Serv

45、ice Bus，SG24-6346-00，作者 Martin Keen 等。 · Enterprise service bus - making SOA real作者 Beth Hutchison， Peter Lambros， Rob Phippen， Marc-Thoms Schimdt 关于作者IBM中国软件开发实验室SOA设计中心 是IBM全球四个SOA设计中心中最大的一个，成立一年多来，已经取得了可喜的成就。我们已经在全球范围内成功地实施了多个 SOA 应用项目，为多个行业的客户成功地提供了 SOA 解决方案。我们正在实施的 SOA 项目涵盖了很多的重要行业，包括零售业、航

46、运业、电力、银行、保险等等。通过这些不断增长的成功案例，我们不仅深入地推广了 SOA 的理念，树立了 SOA 成功实施的范例，也为我们的队伍积累了经验，培养了人才。与此同时，我们还是 IBM 开发 SOA 的软件平台 - SOA Integration Framework - 的主力军。该产品基于模型驱动的思想，旨在最大化地重用软件资产，它为 SOA 项目的实施提供了一整套源自成功实践的方法论，设计范式和工具集。它的出现将极大地方便 SOA 系统架构师、设计人员、开发人员快速地开发基于SOA的应用项目。参与本系列撰写的主要技术人员包括：毛新生 IBM 中国软件开发实验室 资深经理， SOA计中

47、心中国区 首席架构师李珉 IBM 中国软件开发实验室 SOA设计中心 高级软件工程师，技术经理周志荣 IBM 中国软件开发实验室 SOA设计中心 软件工程师张柯 IBM 中国软件开发实验室 SOA设计中心 软件工程师金戈 IBM 中国软件开发实验室 SOA设计中心 资深软件工程师，技术经理 理解面向服务的体系结构中企业服务总线场景和解决方案，第 1 部分企业服务总线中的工作角色本文确定了一组最低功能，可以满足企业服务总线（Enterprise Service Bus，ESB）与面向服务的体系结构（service-oriented architecture，SOA）的原则保持一致的基本需要。通过

48、确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。引言最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件（请参见参考资料）。然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？本文将 ESB 描述为由中间件技

49、术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能。本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA 实现的共同起点。而解决

50、方案模式又为选择适当的实现技术提供了指南。随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法。回页首ESB 在 SOA 内的工作角色虽然我不打算深入讨论 SOA 的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的：· 利用显式的与实现无关的接口来定义服务。 · 利用强调位置透明性和可互操作性的通信协议。 · 封装可重用

51、业务功能的服务的定义。 图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。图 1: SOA 的原则为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置

52、和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。本文剩余部分将讨论 ESB 在 SOA 中的角色，包括它提供的除了基本的路由和传输以外的功能，如下面的ESB 功能模型部分中所述。ESB 结构ESB 有时被描述为分布式基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被描述为中心辐射型（hub-and-

53、spoke）。然而，这并不是真正的差别。正在研究两个不同的问题：控制的集中和基础架构的分布。ESB 和中心辐射型（hub-and-spoke）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。图 2展示了这一点。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是 ESB 设计的一个重要方面。另外的一种能力也是非常重要的，就

54、是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。图 2: 分布式 ESB 基础架构的集中控制我还应该定位在 SOA 基础架构中 ESB 与其他组件之间的关系，特别是与 Service Directory、Business Service Choreography、以及 Business-to-Business (B2B) Gateway 这些组件之间的关系。由于上述 SOA 原则对这些组件并没有严格的要求，所以我们可以将它们视为可选组件。图 3展示的 SOA 说明了这些组件之间的关系。图 3: SOA 中的 ESB 角色ESB 需要某种形式的服务路由目录

55、（service routing directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（business service directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。Business Service Choreographer 的作用是通过若干业务服务来组合业务流程；因此，它将通过 ESB 调

56、用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能（如合作伙伴

57、关系管理），这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。ESB 的功能模型表 1对现有文献中确定的一些 ESB 功能进行了总结和分类（请参见参考资料）。虽然有一些功能非常基础，但是其他的功能（如自动化功能或智能化功能）代表着向按需操作环境转变的重要步骤。重要的是认识到，当前的大多数场景只需要部分类别中的部分功能。ESB 实现所需的最低功能将在下面支持 SOA 的最低功能的 ESB 实现部分中进行探讨。表 1：在现有的文献中定义的 ESB 功能通信 服务交互 · 路由 · 寻址 · 通信技术、协议和标准（例如 IBM® WebSph

58、ere® MQ、HTTP 和 HTTPS） · 发布/订阅 · 响应/请求 · Fire-and-Forget，事件 · 同步和异步消息传递 · 服务接口定义（例如，Web 服务描述语言（Web Services Description Language，WSDL） · 支持替代服务实现 · 通信和集成所需的服务消息传递模型（例如 SOAP 或企业应用程序集成 (EAI) 中间件模型） · 服务目录和发现 集成 服务质量 · 数据库 · 服务聚合 · 遗留系统和应用程序适配器

59、 · EAI 中间件的连接性 · 服务映射 · 协议转换 · 应用程序服务器环境（例如 J2EE 和 .NET） · 服务调用的语言接口（例如 Java 和 C/C+/C#） · 事务（原子事务、补偿、Web 服务事务（WS-Transaction） · 各种确定的传递范例（例如 Web 服务可靠消息传递（WS-ReliableMessaging）或对 EAI 中间件的支持） 安全性 服务级别 · 身份验证 · 授权 · 不可抵赖性 · 机密性 · 安全标准（例如 Kerberos 和 Web 服务安全性（WS-Security） · 性能 · 吞吐量 · 可用性 · 其他可以