过程（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展示了这种分析的过程。 图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 系统开发设计人员起到一定的帮助作用。 参考资料
1. Patterns: Service-oriented 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. 面向服务的分析与设计原理一文研究了OOAD、EA 和 BPM 中的适当原理。
6. 企业服务总线解决方案剖析，第 1 部分 介绍了面向服务的体系结构(service-oriented architecture， SOA )和企业服务总线(Enterprise Service Bus，ESB)的基本知识，ESB的技术沿革，以及ESB与 SOA 之间的关系。
企业服务总线解决方案剖析，第 1 部分: 企业服务总线的基本概念
http://www.ibm.com/developerworks/cn/webservices/ws-esb1/
李珉, 高级软件工程师，技术经理, IBM 中国软件开发实验室 SOA设计中心
? ? ?
案，第 1 部分\，2003 年 12 月)作者 Rick Robinson。
Patterns: Implementing an SOA using an Enterprise Service 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 的理念，树立了 SOA 成功实施的范例，也为我们的队伍积累了经验，培养了人才。与此同时，我们还是 IBM 开发 SOA 的软件
Integration Framework -- 的主力军。该产品基于模型驱动的思想，旨在最大化地重用软件资产，它为 SOA 项目的实施提供了一整套源自成功实践的方法论，设计范式的出现将极大地方便 SOA 系统架构师、设计人员、开发人员快速地开发基于SOA的应用项目。
参与本系列撰写的主要技术人员包括：
毛新生 IBM 中国软件开发实验室 资深经理， SOA计中心中国区 首席架构师 李珉 IBM 中国软件开发实验室 SOA设计中心 高级软件工程师，技术经理 周志荣 IBM 中国软件开发实验室 SOA设计中心 软件工程师 张柯 IBM 中国软件开发实验室 SOA设计中心 软件工程师
金戈 IBM 中国软件开发实验室 SOA设计中心 资深软件工程师，技术经理
理解面向服务的体系结构中企业服务总线场景和解决方案，第 1 部分
企业服务总线中的工作角色
本文确定了一组最低功能，可以满足企业服务总线（Enterprise Service Bus，ESB）与面向服务的体系结构（service-oriented architecture，SOA）的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。
引言
最新的 IT 集成是使用 Web 服务技术实现面向服务的体系结构（SOA），有许多优秀的文章讲述了该技术的好处和相关的实践（请参见参考资料）。最近，企业服务总线（Enterprise Service Bus，ESB）的概念被表述为 SOA 基础架构的关键组件（请参见参考资料）。然而，有必要阐明 ESB 究竟是一个产品、技术、标准，还是别的什么。特别是，当前是否可以构建 ESB？如果这样，该如何构建？
本文将 ESB 描述为由中间件技术实现并支持 SOA 的一组基础架构功能。ESB 支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。为了达到此目的，需要将多种功能集中起来并加以分类。然而，并不是 ESB 能够传递值的每一种情形都需要所有的功能。
本文确定了一组最低功能，可以满足 ESB 与 SOA 的原则保持一致的基本需要。通过确定这些最低功能，您可以确定利用何种现有技术来实现支持 SOA 的 ESB。通过考虑特定情形下的需求如何确定对额外功能的需要，您可以选择最适合这种情形的实现技术。
在接下来的文章中，我将在 SOA 中定义一组 ESB 场景，以定义 ESB 或 SOA 实现的共同起点。而解决方案模式又为选择适当的实现技术提供了指南。 随着 ESB 解决方案的发展和成熟，它所需要的功能也在不断地发展。同样，可见的 ESB 产品的可用性和功能也日趋完善。因此，在本系列的最后一篇文章中，我将考虑 SOA 和 ESB 的发展路线，以指导 ESB 功能和技术的最初应用，并且阐述如何选择循序渐进的方法。
回页首
ESB 在 SOA 内的工作角色
? ? ?
利用显式的与实现无关的接口来定义服务。 利用强调位置透明性和可互操作性的通信协议。 封装可重用业务功能的服务的定义。
虽然我不打算深入讨论 SOA 的定义（请参见参考资料），但是在这里概括一下大部分对 SOA 的描述所适用的原则是很有用的：
图 1说明了这些原则。注意，虽然 Web 服务技术非常符合这些原则，但它并不是唯一符合这些原则的技术。