面向服务的计算环境，为IBM所定义的随需应变计算环境奠定了现实基础。随需应变计算环境应具备以下特点，如图1-3所示。

　　图1-3 随需应变的计算环境应该具备的特点
 
　　（1）整合：将人、过程、应用和数据全面整合起来。

　　（2）虚拟化：将分布、异构的物理资源（服务器、存储设备等）整合起来，呈现为统一的逻辑对象，以安全和可管理的方式供使用。

　　（3）自主计算：如同生物体一样，系统具备一些高级生物系统的能力，包括自我诊断和修复问题，自动配置和调整以适应环境的变化，自动优化资源的使用效率、增强工作负荷的处理的能力，自我保护数据和信息的安全。

　　（4）开放标准：整个环境建立在开放的标准之上，保证系统的交互性。

　　1.2.4面向服务计算环境的现状

　　不同的服务计算环境，采用不同的技术和产品，这里主要结合IBM的产品和技术来介绍在J2EE平台上实现的服务计算环境。

　　主机通过增加对互联网技术和标准的支持，来创建主机上的面向服务计算环境。比如IBM的CICS 3.1，提供了SOAP和Web服务的支持，可以将主机上的应用以Web服务的方式提供出来，供消费者使用。

　　多年来，IT界的主要技术提供者，一直携手努力定义和推动Web服务的相关标准，并且在主要的几个计算平台上实现了高度兼容，包括.NET，J2EE和开源平台（如LAMPLinux，Apache，mySQL，PHP/Perl/Python）。

　　IBM以J2EE为基础，提供了全面的、强大的服务计算环境，如图1-4所示。

　　图1-4 IBM提供的服务计算环境
 
　　在这个计算环境中，它是服务的世界。其中，Access Services提供访问已有应用或遗留系统的能力，将已有系统中的功能和信息转化为服务，IBM提供了访问不同系统的适配器和相应的框架来帮助转化。Business App Services指那些通过新的计算平台J2EE（如IBM的WebSphere Application Server）来实现的新应用，它们所实现的功能和信息也都转化为服务提供出来。Partner Service指那些来自合作伙伴的服务，WebSphere Partner Gateway提供企业边界处不同安全等差异的转换。Information Service是那些跟信息（而不是活动）有关系的服务，比如将多个系统中异构的数据，聚合、转换为业务需要的统一整齐的业务数据对象来访问。Process Service是指把多个服务聚合成为一个服务流程对应业务过程的服务，这种复合服务通常是长时间运行的过程。Interaction Service是把人的活动，通过人机交互以服务的方式出现在整个业务过程中，作为Process Service中的一部分。

　　在面向服务计算环境中，企业服务总线处于非常重要的位置，它提供服务的中介，解耦服务请求者和服务提供者，是服务计算环境中的核心。ESB是过去消息中间件的发展，采用了”总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上的动态互联互通。

　　ESB的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

　　ESB所提供的基于标准的连接服务，将应用中实现的功能或者数据资源，转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是ESB借助于服务注册管理及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础。这使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。

　　所以，ESB采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOA解决方案是一个松散耦合、灵活的架构。

　　需要注意的是，ESB是一种架构模式，不能简单地等同于特定的技术或产品，但实现ESB确实需要各种产品在运行时和工具方面的支持。IBM有很好的产品支持，运行时支持包括WebSphere ESB和WebSphere Message Broker；工具支持有WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务、使用各种模式、转换消息和定义路由等。

　　1.2.5 面向服务的编程模型：服务组件架构（SCA）和服务数据对象（SDO）

　　为了促进面向服务应用的开发，IT公司联合起来，在2005年11月发布了服务组件架构（Service Component Architecture）和服务数据对象（Service Data Object）规范，这些公司包括IBM，BEA，Oracle，SAP等。

　　SCA的目标是大大地简化服务开发，直接采用Web服务和XML开发服务，使得程序员工作在底层技术上，需要应付各种异构环境下的具体实现细节。其中，SCA定义和规范了技术中立和实现透明的服务组件、服务及服务调用和组装；而SDO定义和规范了服务世界里的数据，这些数据对象拥有清晰定义的信息模型，独立于数据源和具体数据访问技术，使得服务访问数据和在服务之间交换数据更方便、有效。

　　很多公司已经在J2EE平台上支持了SCA/SDO，还提供了C++的版本。IBM WebSphere Process Server 6实现了SCA/SDO规范，提供了最新的SOA编程模型的支持，已经在很多实践中被广泛使用。

　　1.3 软件体系结构的演变和面向服务的设计原则

　　软件开发一直是一件很难的事情，因为我们要处理的问题越来越复杂，人们处理这种复杂性最主要的手段就是抽象。回顾历史，我们的抽象层次越来越高，反映在各个方面，从编程语言、平台、开发过程、工具到模式。尤其是模式，大量出现在那些结构上设计得很好的软件系统中，无论是微观层次上（对象、组件）稳定出现的结构范式，还是在宏观层面上出现的架构模式。使用哪些抽象手段来为问题域建模？如何定义组成部分之间的协作和结构关系？如何定义从外界所看到的系统结构和行为？是什么设计原则在指导我们的架构决策？有什么最佳实践和模式可供借鉴？所有这些，形成了不同设计风格和体系结构范式（Architecture Paradigm）。

　　通常，一种体系结构范式，包括设计原则，来自实践的结构式样、组成要素和关系，以及在整个开发生命周期中它们是如何被识别、描述和控制的。体系结构从过去单个应用包罗一切的客户/服务器的模式，逐渐演变到三层和多层结构的各种分布式计算模式。今天，人们开始谈论和实践面向服务、更加分布化的架构范式。

　　从抽象手段而言，SOA在原有方法的基础上，增加了服务、流程等元素。这些抽象手段之间的关系如图1-5所示。

　　如何利用这些抽象手段，将一个业务需求转化为流程、服务，进一步建模为服务组件，然后结合具体实现环境，在重用已有系统的功能和数据资源的基础上来实现？如图1-6所示是IBM总结的SOA架构概念模式。

　　SOA架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。那些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA架构来说同样是非常重要的。

　　结构上，服务总线是SOA的架构模式之一。

　　关于服务，一些常见和讨论的设计原则如下：

　　（1）无状态。以避免服务请求者依赖于服务提供者的状态。
　
　　（2）单一实例。避免功能冗余。

　　图1-5 SOA中的重要抽象手段

 
　　图1-6 SOA的概念架构模式
 
　　（3）明确定义的接口。服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。使用者依赖服务规约来调用服务，所以服务定义必须长时间稳定，一旦公布，不随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。

　　（4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。

　　（5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量比较大，但是服务之间的交互频度较低。

　　（6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术、当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

　　（7）重用能力。服务应该是可以重用的。

　　（8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，比如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，比如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS- Policy用于定义可配置的互操作语义，来描述特定服务的期望、控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。

　　1.4 软件工程的演变和面向服务体系结构

　　软件工程方法和过程伴随着软件实践不断发展。软件危机发生之后，从瀑布模型、原型方法等讲究过程、文档密集、控制较多的方法，逐渐发展到轻量级、敏捷和迭代的方法。这些方法更加人性化，避免因为过重的过程而扼杀人的主动性和创造性。这些方法更强调快速地交付对客户有价值的软件、直接的沟通、持续集成和持续质量保证。

　　SOA和当前软件工程过程的一个共同交叉点就是业务价值驱动（Business Centric），强调速度。SOA从软件的灵活性和重用能力入手，而敏捷过程则从软件交付效率出发。

　　SOA的架构特性，使得敏捷过程非常适合SOA项目的实施。在SOA架构中，服务的独立性，使得每个服务可以被单独地开发、测试和集成。一个企业中的IT系统，如果是基于SOA的计算环境，那么这个环境就是一个服务的生态系统，每开发一个服务，马上就可以独立部署，成为这个生态系统中的一部分。这样既很好地支持了持续集成、持续质量保证，又很好地使得这个服务马上产生业务价值，而不是苦等其他服务的到位。服务的特性，使得敏捷过程和SOA架构可以有一个很好的结合，让二者相得益彰。以我们与不同客户合作的实践，我们已经充分体会到这二者在实现过程中的风险控制、业务需求改变的适应能力方面相互配合的好处。比如我们在中远集运，从瀑布过程转向了迭代的开发过程，采用了敏捷方法的原则。

　　在韩国的项目里，我们的团队来自IBM中国，IBM韩国及韩国客户自己的工程师，分处汉城和北京两个地方，这些工程师怎样协作才能很快地交付高质量的系统而不相互牵扯？对于北京的工程师，北京的团队无法复制客户在汉城的已有系统，如何测试自己开发的服务？通过服务建模，系统被分解为若干相互独立的服务，我们将那些要重用已有系统来实现的服务交给汉城的队员，其他的交给北京的队员，并且要求每个服务开发人员提供一个简单的”伪”实现（Mock Service）。一开始，这些简单实现被部署在北京和汉城的测试环境中，然后各个服务开发小组开始各自独立地开发自己所负责的服务，而流程开发人员也在同一时间开始开发他的流程，不过所基于的服务是在那些简单实现之上，但是这些简单实现足以支持有意义的单元和集成测试。随后，一旦某个服务被实现，它就被部署到实际的环境中，通过调整ESB的服务中介配置，对此服务的请求被路由到真实实现。一旦真实实现有问题，还可以换回简单实现，以避免影响其他服务、流程的单元和集成测试。这种灵活性带来的随时开发、随时部署、随时集成和测试对于采用敏捷过程是非常有利的。

　　1.5 SOA技术概览

　　本节将讨论目前SOA体系架构中用到的主要技术和标准。

　　1.5.1 SOA的主要组件

　　在前面关于计算环境的讨论里，我们已经提到SOA计算环境的主要组件包括：服务运行时环境、服务总线、服务注册库、服务网关和流程引擎。通常，还会包括服务管理、业务活动监控（Business Activity Monitoring）和业务绩效管理（Business Performance Management，BPM）。另外，在服务建模、开发和编排服务等方面，我们需要相应的工具来支持。在分析、设计方面，我们需要基于服务的分析、设计方法，就是我们通常说的服务建模，包括服务的识别、定义和实现策略，其输出是一个服务模型（Service Model）。

　　1.5.2 SOA主要技术和标准

　　Web服务作为实现SOA中服务的最主要手段。我们首先来了解跟Web Service相关的标准，它们大多以”WS-“作为名字的前缀，所以统称WS-*。 Web服务最基本的协议包括UDDI，WSDL和SOAP，通过它们，我们可以提供直接而又简单的Web Service支持，如图1-7所示。

　　但是基本协议无法保证企业计算需要的安全性和可靠性，所以我们需要增加这方面的协议，比如WS-Security，WS-Reliability和WS-ReliableMessaging；对于复杂的业务场景，我们需要WS-BPEL和WS-CDL这样的语言来将多个服务编排成为业务流程；管理服务的协议如WS-Manageability，WSDM等。跟Web服务相关的标准，还在快速发展当中。目前在SOA产品和实践中，除了基本协议外，比较重要的还包括BPEL，WS-Security，WS-Policy和SCA/SDO。如表1-1所示给出了一个基本的总结，后面的章节会介绍重要的技术和标准。

　　图1-7 基本Web服务协议

 
　　表1-1 当前Web服务协议栈
 
　　1.5.3 SOA技术在工业界的支持现状

　　目前，Web的标准和技术在演变当中，不同的技术环境的支持力度也不同，但是前面提到的基本核心协议，都有很好的支持。关于Web服务协议的接受和支持程度，如图1-8所示。

　　图1-8 当前Web服务的接受情况
 
　　1.6 本章小结

　　本章介绍了SOA基本概念，并澄清了容易混淆的一些问题，然后概要地讨论了SOA的若干重要方面，包括面向服务的计算环境、编程模型、架构风格、工程方法等。还非常简要地介绍了SOA在工业界的支持概览，更多的细节请参看各个部分所附的参考链接，它们会给读者提供非常充分的信息和文档，供读者了解SOA相关技术和标准的发展细节。通过表1-2，读者也可以了解到工业界，包括厂家和标准化组织的参与情况。

　　关于作者

　　毛新生先生现任IBM中国开发中心Web 2.0首席架构师。此前他曾任IBM软件集团企业解决方案部大中华区和北亚地区首席架构师与IBM SOA中国设计中心技术主管，在企业级软件方面拥有广泛、扎实、深厚的理论功底和丰富的设计与项目实施经验。2006年，毛新生先生被授予“IBM资深技术主管”称号（STSM ，Senior Technical Staff Member），成为中国内地第一位获此殊荣的IBM技术人员，在全球也仅有1000多位IBM员工享有这样的荣誉。毛新生先生于2000年加入IBM，曾先后在北京大学和IBM中国研究院从事研发工作，以研究人员，开发经理和架构师的身份从事过信息检索，语音技术及其中间件，门户，普及计算，Linux，网格计算，Web Service和SOA等领域的很多工作。毛新生先生毕业于北京大学，拥有计算机专业硕士学位。如果您想找到更多关于毛新生先生的文章，您可以搜索 毛新生的BLOG。