SOA的核心主体是服务。所谓“服务（Service）” ，从业务角度而言，服务是一个可重复的经过标准封装的任务，例如: 检查帐号余额;开新帐户 等等…。SOA的目标是通过服务的流程化来实现业务的灵活性，所谓流程（Process）是由一系列相互关联的任务所组成，实现一个具体的业务功能。一个流程可以由一系列服务来实现。

服务就像一堆“元器件”，这些元器件通过封装形成标准服务，他们有相同的接口和语义表达规则。但服务要组装成一个流程和应用，还需要有效的“管理”，包括如何注册服务、如何发现服务、如何包装服务的安全性和可靠性，这些就是SOA治理。SOA治理乃是将SOA这一堆元器件，进行有效组装，形成一个“产品”的关键，否则它永远是一堆器件，而无法形成一个有机整体。

SOA治理的方法和体系，就是区别于一般组件开发的技术的重要区别和特征。

一个正确的框架，是指导我们开发和实施SOA架构的基础。由IBM提案，国际开放群组(The Open Group)提出了一个SOA架构的参考模型，这个架构框架目前是产业界最权威和严谨的SOA架构标准。The Open Group是一个非营利标准化组织，是一个厂商中立和技术中立的机构，致力于提出各种技术框架和理论结构，致力于促进全球市场的业务效率。The Open Group已有超过20年的标准制定与推广历史。在1996年，由X/Open与Open Software Foundation合并组成。The Open Group最有名是作为UNIX商标的认证机构。在过去，协会最出名的是其出版的Single UNIX Specification，它扩充了POSIX标准而且是UNIX的官方定义，其成员包括IT用户、供应商以及政府机构。

SOA基础实施是为整个SOA组件和框架提供一个可靠的运行环境，以及服务组件容器，它的核心组件是应用服务器等基础软件支撑设施，提供运行期完整、可靠的软件支撑。

企业服务总线是指由中间件基础设施产品技术实现的、通过事件驱动和基于XML消息引擎，为SOA提供的软件架构的构造物。企业服务总线ESB提供可靠消息传输、服务接入、协议转换、数据格式转换、基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。在SOA基础实现的方案上，应用的业务功能能够被发布、封装和提升（Promote）成为业务服务（Business Service）；业务服务的序列可以编排成为BPM的流程，而流程也可以被发布和提升为复合服务（Composited Service），业务服务还可以被外部的SOA系统再次编排和组合。ESB是实现SOA治理的重要支撑平台，是SOA解决方案的核心，从某种意义上说，如果没有ESB，就不能算作严格意义上的SOA。

关键服务实现，是SOA在各种业务服务组件的分类。一般来说，一个企业级的SOA架构通常包括：交互服务、流程服务、信息服务、伙伴服务、企业应用服务和接入服务。这些服务可能是一些服务组件，也可能是企业应用系统（如ERP）所暴露的服务接口等等。这些服务都可以接入ESB，进行集中统一管理。

开发工具和管理工具：提供完善的、可视化的服务开发和流程编排工具，涵盖服务的设计、开发、配置、部署、监控、重构等完整的SOA项目开发生命周期。

按照这个模型，许多SOA解决方案是只提供部分实现。这个行业中，许多国内的企业为了搭上SOA的便车，经常以偏概全，混绕概念。应该说真正按照SOA的思想和模型来构建整个企业的IT架构的案例是非常之少的。许多国外厂商的宣传案例，基本上是停留在部署应用服务器，开发了部分WebService组件，可以实现部分数据集成，这个层次而已，而这些WebService是部署在ESB平台之上的，就已经很不错了。实现了服务流程重组，实现SOA治理的案例就更是很少见到了。

国内有许多软件企业开发的系统，宣传是SOA架构的。基本上有几种情况，其一，有些开发组件和开发平台厂商，他们也自称中间件企业，基本上是提供一个工作流平台，许多还不支持BPEL的业务流程管理，只是传统的XPDL/WfMC工作流平台（Workflow不同于支持服务流程的Business Process），最常见的案例是OA办公审批，或者服务组件开发工具，而所谓的ESB产品大部分都是EAI的升级，可以与Webservice进行接口而已，就宣称这是ESB产品了，基本的服务注册、服务编排和安全管理都不具备。这些解决方案只是提供了许多WebService开发的组件，而不提供SOA治理的核心架构，相当于造了许多元器件，但还不能提供整机产品。

其二，许多宣称SOA架构的应用软件，基本上可以说是“支持”SOA，而不能称为“基于SOA”架构。因为支持SOA一般是指可以将其某些功能，封装为服务（WebService），可以在SOA架构之中进行管理，这比较容易达到。而“基于SOA”是指应用系统的业务功能都是封装为服务，通过ESB进行集中管理，业务实现是通过BPEL业务流程管理进行编排，用户交互是通过交互服务（如门户）进行管理，整个解决方案可以达到标准服务封装、服务复用、松耦合、服务编排与重组，并且基本符合TOG-SOA的架构模型。

按照这个标准，IT用户就可以了解到真正的SOA架构的框架模型，就可以识别是否是企业所需要的架构。

讲到这里，我们已经很清楚了，对于SOA的理解，有些学者或者咨询公司强调SOA不是一种技术，也不是软件，而是一种思想，一种架构风格。我认为这也是不完全准确的，这种观点认为SOA仅仅是思想和方法，将使得SOA成为一种不可知论，飘在空中，很难落地。

4.SOA如何落地

自从1996年Garnter的分析师首次提出SOA的概念，到今天，已经过去10多年了，在前几年这个概念并没有引起多大的注意，只是到这几年在技术上WebService的成熟，以及互联网的普及，SOA作为企业架构的主要技术，才逐渐占据了产业的主流。

因为商业策略的不同，有些企业提出SOA已经过时，有些企业还认为SOA还没有达到成熟的阶段等等这些论点。从商业概念炒作周期来看，我认为SOA正当喧嚣之后的理性期，是业界和IT用户真正抛弃“炒作”，踏踏实实发挥SOA的商业价值的时候了，SOA需要落地。

SOA将来真正推广到企业中应用，要落地，就不能离开几个基本的东西：支撑SOA的基础中间件平台、符合SOA架构的应用系统（如ERP等）、构建SOA的方法论。

4.1.架构方法论

方法和工具构成了工程技术域，要构建SOA架构的企业信息系统，确保业务和IT的真正匹配，首先必须从方法论入手。

许多企业的IT系统“孤岛”现象严重，本质上是缺乏足够有效的整体规划或者架构规划造成的。形象地说，构建企业IT大厦如同我们盖房子是一样的道理。我们许多企业建设信息系统时就采用了盖乡村民宅的做法。盖乡村民宅不需要严谨的规划，也没有复杂的地下设施建设（如自来水供水、排水、供气、地下停车场等），也没有需要建设污水处理、雨水收集等复杂的配套设施。而事实上，企业IT系统建设应该如城市建设，首先需要城市总体规划，然后根据功能区规划，设计和建设小区配套设施，“三通一平”实质就是构建建筑之间的公共基础设施，确保每栋建筑之间不是“孤岛”，然后每栋建筑还需详细的设计和工程施工。如果要消除信息孤岛，实现IT与业务的一致性，也需要有效的企业架构规划和设计。

4.2.基于SOA的应用系统

基于SOA的应用系统构建方法与传统软件架构方法有所不同。

基于服务的应用系统的本质特征是松耦合，以基本业务功能（服务封装）为系统的基本实现单元，然后通过服务编排（流程管理）来“组装”业务应用系统。相对于以往的应用系统，是面向技术组件，由系统程序实现业务流程，在复用、耦合方面都存在灵活性问题。

服务建模是第一步，也就是服务识别和颗粒度确定。服务识别是方法论的第一步，服务识别的主要任务，是确定在一定范围内（通常是企业范围，或若干业务场景范围内）可能成为服务的候选者列表，并确定服务的颗粒度，以及标识服务的接口。服务建模也就确定了应用系统架构的耦合程度。

服务封装阶段的主要任务是对服务进行规范性的描述，其中包括输入/输出消息等功能性属性，以及服务在业务层面的诸多属性。并决定服务以何种形式向外提供服务。服务可能是新开发的业务功能和业务对象的封装，也可能是遗留系统的服务封装，将遗留系统的软件资产以服务的形式进行封装，在新的架构上利用已有的资产。

服务治理就是将已经封装好的服务进行集中统一有效的管理。通过ESB基础设施，提供服务注册、存储、安全控制和版本管理等。服务注册阶段的主要任务是将服务注册到服务库。此时需要决定服务的命名、安全、性能、时间特性。

服务编排就是根据业务流程的需求，对服务进行组合和组装。服务组装是以实现业务流程为目的，通过对业务服务的组合和组装，实现更粗粒度的业务服务，实现最终的业务需求。

应用交付阶段主要任务是完成业务系统服务化组装和服务部署，实现业务按需交付。

基于SOA的应用系统是SOA架构的重要组成部分，也是SOA落地的地基。

4.3.支撑SOA的中间件平台

SOA方法论和基于SOA的应用系统要落地的支撑工具和技术基础就是中间件平台。这个在3.3.SOA的架构框架(Framework)之中已经阐述清楚了。

根据TOG-SOA模型，完整的SOA架构五大部分中，基础设施服务、企业服务总线、开发工具、管理工具等，都是中间件的基础平台。

交付服务之中的门户，也是需要支持JSR168和JSR286标准的Portlet容器和个性化交互以及终端适配的支撑平台。

业务流程管理需要支持BPEL规范的流程引擎和流程建模的工具，这个中间件平台用来支持服务的组合和服务流程编排，以满足业务重组的需求，来实现业务的灵活性。

SOA要落地的最后支撑平台就是满足SOA规范的中间件技术。