Service-Oriented Architecture)，即面向服务的架构，这是最近一两年出现在各种技术期刊上最多的词汇了。现在有很多架构设计师和设计开发人员简单的把SOA和Web Services技术等同起来，认为SOA就是Web Service的一种实现。本质上来说，SOA体现的是一种新的系统架构，SOA的出现，将为整个企业级软件架构设计带来巨大的影响。

1. 什么是架构?什么是基于SOA的架构?

1.1 什么是架构

从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。

当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。

1.2 什么是基于SOA的架构

SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件(也就是service)组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。

利用基于SOA的系统构建方法，如图1中所示的一样，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务(services)。

图1

因此，SOA架构本质上来说体现了一种复合的概念:它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service开发提供了指导。

2. SOA架构设计师的角色

2.1 SOA架构设计师应该具备什么?

谈到SOA架构设计师的角色，我们首先要了解架构设计师应具有的能力。总体上来说，一个好的架构设计师不仅应该是一个成熟的，具有实际经验的并具有快速学习能力的人，而且他还应该具有良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时刻作出困难的决定，这就是一名架构设计师应该承担的责任。从角色上来看，SOA 架构师不仅会负责端到端的服务请求者和提供者的设计，并且会负责对系统中非功能服务请求的调研和表述。

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

2.2 什么是SOA架构设计师的职责?

那什么是企业级SOA架构设计师的具体角色呢?什么是SOA架构设计师与设计和开发人员之间的差别呢?相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生?也就是说架构设计师关注的应该是一些商业需求和服务级别(service-level)需求。所有的架构设计师的角色都包含了在构建一个系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别(service-level)需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。

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

3. 构建SOA架构时应该注意的问题

3.1 原有系统架构中的集成需求

当架构师基于SOA来构建一个企业级的系统架构的时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。我们都知道，面向服务的体系结构是当前及未来应用程序系统开发的重点，面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统;SOA可以通过利用当前系统已有的资源(开发人员、软件语言、硬件平台、数据库和应用程序)来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。因此，当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。

当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面:应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI(Electronic Data Interchange 电子数据交换)系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。

3.2 服务粒度的控制以及无状态服务的设计

当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方:首先是对于服务粒度的控制，另外就是对于无状态服务的设计。

服务粒度的控制

SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。 举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口给系统的外部用户，就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然面向服务的体系结构(SOA)并不强制要求一定要使用粗粒度的服务接口，但是建议使用它们作为外部集成的接口。通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。

无状态服务的设计

SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，我们最好把它定义成具体的业务流程(BPEL)。在服务的具体实现机制上，我们可以通过使用 EJB 组件来实现粗粒度的服务。我们通常会利用无状态的Session 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，但Web 服务客户不能访问其他类型的企业Bean，如有状态的Session Bean，实体Bean和消息驱动Bean。后一种选择(公开无状态 EJB 组件作为 Web 服务)有很多优势，基于已有的EJB组件，我们可以利用现有的业务逻辑和流程。在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。另外EJB容器会自动提供对并发的支持，作为无状态Session Bean实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何特定实例的请求。 由于EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发人员可以不需要编写安全代码以及事务处理代码。 性能问题对于Web服务来说一直都是一个问题，由于几乎所有 EJB 容器都提供了对无状态会话 Bean 群集的支持以及对无状态Session Bean 池与资源管理的支持，因此当负载增加时，可以向群集中增加机器，Web 服务请求可以定向到这些不同的服务器，同时由于无状态Session Bean 池改进了资源利用和内存管理，使 Web 服务能够有效地响应多个客户请求。由此我们可以看到，通过把 Web 服务模型化为 EJB 端点，可以使服务具有更强的可伸缩性，并增强了系统整体的可靠性。

1. SOA 为企业级架构设计带来的影响

1.1 SOA 的特点及其使用范围

SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是:

(a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同;

(b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定;

(c)无法完成服务(service)的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系;位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里;而协议无关性要求每一个服务都可以通过不同的协议来调用。通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。

1.2 SOA 架构的分层模型

接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。

560)this.style.width=560;" border=0>

在 SOA 系统中不同的功能模块可以被分为7层:第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。第2层就是组件层，在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型:(1)商业服务(business service) 或者是商业过程(business process)。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。(2)商业功能服务(business function service)， 这类服务会完成一些具体的商业操作，也会被更上层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。(3)技术功能服务(technical function service)，这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，第6层中的企业服务总线(ESB)提供了这个功能。第7层主要为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。

2. SOA 架构中的非功能性服务级别(service-level)需求

除了系统的业务需求，架构设计师还必须要保证构建出来的系统架构能够满足系统中的非功能性服务级别(service-level)需求以及服务质量(QoS)方面的需求。在项目初始及细化阶段，架构设计师应该与系统所有涉及方(Stakeholders)一起，为每一个服务级别需求定义其相关的衡量标准。构建出的系统架构必须要能满足以下几方面的服务水准要求:性能、可升级性、可靠性、可用性、可扩展性、可维护性、易管理性以及安全性。架构设计师在设计架构过程中需要平衡所有的这些服务级别需求。例如，如果服务级别需求中最重要的是系统性能，架构设计师很有可能不得不在一定程度上牺牲系统的可维护性及可扩展性，以确保满足系统性能上的要求。随着互联网的发展，新构建的系统对于服务级别需求也变得日益重要，现在基于互联网的企业系统的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成为企业系统的主要用户。

架构设计师的职责之一就是要尽可能地为提高系统设计人员和系统开发人员的工作效率考虑。在构建整个企业系统架构的过程中，需要充分重视各种服务级别需求，从而避免在系统开发和运行的时候出现重大问题。一个企业级系统中的服务级别需求往往是十分错综复杂的， SOA 架构设计师需要凭借丰富的专业经验和扎实的理论知识来分离和抽象系统中不同的服务级别需求，图3展示了这种分析的过程。

560)this.style.width=560;" border=0>

图3

经过 SOA 架构设计师分析和抽象的服务级别需求主要分为以下几类:

性能是指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等;

可升级性是指当系统负荷加大时，能够确保所需的服务质量，而不需要更改整个系统的架构;

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力;

可用性是指一个系统应确保一项服务或者资源永远都可以被访问到;

可扩展性是指在不影响现有系统功能的基础上，为系统填加新的功能或修改现有功能的能力;

可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护的能力;

可管理性是指管理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力;

安全性是指确保系统安全不会被危及的能力。

1) 性能

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

2) 可升级性

可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。

3) 可靠性

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，你的系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。

4) 可用性

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

5) 可扩展性

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

6) 可维护性

可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。同系统的可扩展性相同，当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。

7) 可管理性

可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时， SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framework)上。对于 SOA 架构设计师来说，可以选择的底层系统框架有很多，可以选用基于MQ, MessageBorker，WebSphere Application Server等产品来构建企业服务总线(Enterprise Service Bus)以支持企业的 SOA 系统架构，也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构建企业的ESB以支持 SOA 系统架构。具体选择哪种底层框架来实施 SOA 系统架构要根据每个系统各自的特点来决定，但这些底层的框架都已经提供了较高的系统可管理性。因此，分析并选择不同的产品或底层框架来实现企业系统架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构建 SOA 系统，中国 SOA 设计中心已经发表了一系列相关的文章，大家可以在DeveloperWorks中的 SOA 专栏看到它们。

8) 安全性

安全性是指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当 SOA 架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由Web Service实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。

3.结束语

本系列两部分介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时有哪些应该特别注意的地方并在最后简要介绍了在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度， SOA 是一种新的设计模式，方法学。因此， SOA 本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的 SOA 系统开发设计人员起到一定的帮助作用。