导语：
SOA作为一种面向服务的架构，是一种软件架构设计的模型和方法论。从业务角度来看，一切以最大化“服务”的价值为 出发点，SOA利用企业现有的各种软件体系，重新整合并构建起一套新的软件架构。这套软件架构能够随着业务的变化，随 时灵活地结合现有服务，组成新软件，共同服务于整个企业的业务体系。简单的理解，我们可以把SOA看作是模块化的组 件，每个模块都可以实现独立功能，而不同模块之间的结合则可以提供不同的服务，模块之间的接口遵循统一标准，可以实现 低成本的重构和重组。在SOA的技术框架下，可以把杂乱无章的庞大系统整合成一个全面有序的系统，从而增加企业在业务 发展过程中应用系统的灵活性，实现最大的IT资产利用率。
一、SOA详细定义
面向服务的体系结构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接 口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构 建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方 面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种 形式的更改时，它们就显得非常脆弱。
对松耦合系统的需要来源于业务应用程序需要，根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能 够灵活地适应环境变化的业务为按需业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已 经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构，它已经出现很长时间了，其定义的概念与 SOA 相似。然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXML）为基础的。
在SOA架构风格中，服务是最核心的抽象手段，业务被划分（组件化）为一系列粗粒度的业务服务和业务流程。业务服务相 对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个"服务"定义了一个与业务功 能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标（Key Performance Indicator，KPI）等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平 台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不 依赖于特定技术的中立特性，通过服务注册库（Service Registry）加上企业服务总线（Enterprise Service Bus）来支持动态 查询、定位、路由和中介（Mediation）的能力，使得服务之间的交互是动态的，位置是透明的。技术和位置的透明性，使得 服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性；另一点是当某个服务的内 部结构和实现逐渐发生改变时，不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连 的，因而当发生变化时，某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改，这样的系统架构就 很脆弱了。
二、SOA架构的优点
SOA的主要优点概括为：IT能够更好更快地提供业务价值（Business Centric）、快速应变能力（Flexibility）、重用 （Reusability）
也可以细分为以下几个方面：
①服务之间通过简单、精确定义的接口进行通信，不涉及底层编程接口和通信模型。
②粗粒度性：粗粒度服务提供一项特定的业务功能，采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够了。
③松耦合性：松耦合性要求SOA架构中的不同服务之间应该保持一种松耦合 的关系，也就是应该保持一种相对独立无依赖的 关系。这样的好处有两点，首先是具有灵活性，其次当组成整个应用程序的服务内部结构和实现逐步地发生变化时， 系统可以继续地独立存在。而紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个 应用程序进行某种形式的更改时 这种结构就显得非常脆弱。
④位置透明性：位置透明性要求SOA系统中的所有服务对于其调用者来说都是位置透明的，也就是说，每个服务的调用者只需 要知道想要调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪。
⑤协议无关性：协议无关性要求每一个服务都可以通过不同的协议来调用。
另外，在许多传统的IT系统的内在部分采用的是硬连接，这种结构很难让企 业快速响应市场的变化，而SOA能够重复利用企 业现有的资源，可以减轻企业运营成本，提升资源的使用效率，并且减轻企业维护人员的工作量，减少潜在的风险 以及管理 费用。在业务方面和IT方面带来许多优势：
①服务给精确的业务流程带来灵活性；
②使用服务来改善客户服务，而不必担心底层复杂的IT基础架构；
③可以迅速创建新的业务流程和复杂的应用程序，以适应市场变化；
④借助安全、易管理的集成环境，成为响应能力更强的IT组织；
⑤通过使用预装的、可重复使用的服务构建模块，缩短开发和部署周期；
⑥通过使用服务来降低复杂性和维护成本；
⑦是增强而不是替换现有的IT系统。
三，SOA架构详解
3.1. 如何形象理解SOA
事实上，SOA的思想我国很早就有了，印刷术的发展过程其思想就完整体现了SOA的核心含义。
印刷的内容――文字，在秦始皇统一六国之前，各国的文字是不统一的，据说许多常用的文字有十几种写法和读音，妨碍了各 国之间的文化交流，就象SOA之前，各种软件平台、各种开发工具和各种接口的组件之间，没有统一的标准，对软件系统之 间的整合造成巨大的困难。
因此，伟大的始皇帝统一了六国文字，“书同文、车同轨”就是通过标准解决“复用”和“互操作”等问题。这也为大规模的印刷和文 明发展提供了一个良好的基础，这种“统一封装”的文字，对文化交流起到了一个“互操作”的标准作用。
SOA的形象解析
在没有印刷术之前，书籍要依赖于手工抄写，这样效率当然是非常低下，而且质量也不能获得一致性的保证，也就是书籍还 无法“复用”。中国人首先发明了刻版印刷 术，就是将书籍刻成一块一块的凸字版，然后就可以大规模进行印刷了，当印刷出来 的书籍脱销时，下次还可以继续使用，大大提高了效率，这就是“复用”，软件 通过组件的封装，也可以达到重复和在不同场合 多次使用的“复用”效果。
刻版印刷术有个很大的问题就是文字之间是紧耦合的，同样一个字，在另一部书之中是不能“复用”的，必须重新雕刻，也就是 说刻版印刷是没有“编排”特性的。就如软件技术中微软VB开发的Com+组件就只能在Windows环境之中使用，它不能与Java开 发的EJB组件进行复用和编排，因为他们与开发环境和运行环境是紧耦合的，要在UNIX环 境下使用，必须重新开发（相当于 重新“刻版”）。活字印刷就是通过文字与版面之间的松耦合，通过“排版”来实现一部书的印刷版面的，这种松耦合就大大提高 了文字的字模之间的复用和编排效率。我们标准封装的“服务”就类似一个一个的字模，通过服务编排（“排版”）来实现业务流程。
统一文字和活字印刷促进了人类文明进步，而SOA促进全球IT架构和应用的革命。
3.2. SOA的核心要素
要准确全面理解SOA，首先必须理解SOA的核心要素：
SOA的核心要素
SOA的目标就是实现灵活可变的IT系统。要达到灵活性，通过三个途径来解决：标准化封装、复用、松耦合可编排。
互操作(标准化封装)、复用、松耦合等SOA技术的内在机制，也是中间件技术和产品的本质特征。
标准化封装（互操作性）
传统软件架构，因为封装的技术和平台依赖性，一直没有彻底解决互操作问题。互联网前所未有的开放性意味着各节点可能 采用不同的组件、平台技术，对技术细节进 行了私有化的约束，构件模型和架构没有统一标准，从而导致架构平台自身在组件描述、发布、发现、调用、互操作协议及数据传输等方面呈现出巨大的异构性。各种不良技术约束的结果是软件系统跨互 联网进行交互变得困难重重，最终导致了跨企业/部门的业务集成和重组难以灵活快速的进行。
在软件的互操作方面，传统中间件只是实现了访问互操作，即通过标准化的API实现了同类系统之间的调用互操作，而连接互 操作还是依赖于特定的访问协议，如JAVA使用RMI，CORBA使用IIOP等。而SOA通过标准的、支持Internet、与操作系统无 关的SOAP协议实现了连接互操作。而且，服务的封装是采用XML协议，具有自解析和自定义的特性，这样，基于SOA的中间 件还可以实现语义互操作。
SOA要实现互操作，就是通过一系列的标准族，来实现访问、连接和语义等各种层面的互操作。
软件复用
软件复用，即软件的重用，也叫再用，是指同一事物不作修改或稍加改动就多次重复使用。从软件复用技术的发展来看，就 是不断提升抽象级别，扩大复用范围。最早 的复用技术是子程序，人们发明子程序，就可以在不同系统之间进行复用了。但 是，子程序是最原始的复用，因为这种复用范围是一个可执行程序内复用，静态开发 期复用，如果子程序修改，意味着所有 调用这个子程序的系统必须重新编译、测试和发布。
SOA的复用
为了解决这个问题，人们发明了组件（或者叫控件），如MS操作系统下的DLL组件。组件将复用提升了一个层次，因为组件可以在一个系统内复用（同一种操作系统），而且是动态、运行期复用。这样组件可以单独发展，组件与组件调用者之间的耦合度降低。
为解决分布式网络计算之间的组件复用，人们发明了企业对象组件，如（Com+,.NET,EJB等)，或者叫分布式组件。通过远程对象代理，来实现企业网络内复用，不同系统之间复用。
传统架构的核心是组件对象的管理。但分布式组件也是严重依赖其计算环境，由于构件实现和运行支撑技术之间存在着较大的 异构性，不同技术设计和实现的构件之间无法直接组装式复用。
而现代SOA的重要特征就是以服务为核心，如WebService,SCA/SDO等。通过服务，或者服务组件来实现更高层次的复用、 解耦和互操作，即SOA架构中间件。
因为服务是通过标准封装，服务组件之间的组装、编排和重组，来实现服务的复用。而且这种复用，可以在不同企业之间，全球复用，达到复用的最高级别，并且是动态可配置的复用。
耦合关系
SOA架构在松耦合解耦过程也发展到了最后的境界。传统软件将软件之中核心三部分网络连接、数据转换、业务逻辑全部耦 合在一个整体之中，形成“铁板一块”的软件， “牵一发而动全身”，软件就难以适应变化。分布式对象技术将连接逻辑进行分 离，消息中间件将连接逻辑进行异步处理，增加了更大的灵活性。消息代理和一些分 布式对象中间件将数据转换也进行了分 离。而SOA架构，通过服务的封装，实现了业务逻辑与网络连接、数据转换等进行完全的解耦。
SOA不断解耦的过程
总之，从科学哲学的角度来看，SOA是一个不断解构的过程，传统软件强调系统性，耦合度过高，所以需要松耦合（解耦）；SOA也是一个组件粒度的平衡，集成电路趋势是集成度越来越高，软件发展的趋势是相反的过程；SOA是架构，更是 方法，反映了人们对哲学思想的追求的原动力。
按照这个特性，SOA基本上来说与WebService并不是同一个概念，SOA并不一定需要WebService实现，理论上可以在其他技 术体系下，实现SOA。但事实上，到目前为止，能够实现SOA架构风格的技术就是WebService，因为它的特性和厂商的支持 力度，使得WebService成为了实现SOA实现技术的事实标准。也正因为WebService技术的成熟，才使得已经提出10多年了的 SOA思想和概念，得以能够实现落地，成为一种可以使用的技术。这也就是回答了SOA和WebService的关系。
3.3. SOA的架构框架
(Framework) SOA的核心主体是服务。所谓“服务（Service）” ，从业务角度而言，服务是一个可重复的经过标准封装的任务，例如: 检查帐 号余额;开新帐户等等…SOA的目标是通过服务的流程化来实现业务的灵活性，所谓流程（Process）是由一系列相互关联 的任务所组成，实现一个具体的业务功能。一个流程可以由一系列服务来实现。
SOA治理
服务就像一堆“元器件”，这些元器件通过封装形成标准服务，他们有相同的接口和语义表达规则。但服务要组装成一个流程和 应用，还需要有效的“管理”，包括如何注册服务、如何发现服务、如何包装服务的安全性和可靠性，这些就是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用户、供应商以及政府机构。The Open Group在中国的创始会员为金蝶集团，金蝶集团负责 成立了中国分会。TOG在1993年提出的The Open Group Architecture Framework (TOGAF) 架构框架，是一套行之有效的企 业架构。历经15年9个版本发展，支持开放、标准的SOA参考架构，已被80％的福布斯( Forbes)全球排名前50的公司使用。
这个SOA参考模型为：
SOA标准模型
根据这个模型，完整的SOA架构由五大部分组成，分别是：基础设施服务、企业服务总线、关键服务组件、开发工具、管理 工具等。
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业务流程管理进行编排，用户交互是通过交互服务（如门户）进行管理，整个解决方案可以达到标准服务封装、服务复用、松耦合、服务编排与重组，并且基本符合TOGSOA的架构模型。
按照这个标准，IT用户就可以了解到真正的SOA架构的框架模型，就可以识别是否是企业所需要的架构。
讲到这里，我们已经很清楚了，对于SOA的理解，有些学者或者咨询公司强调SOA不是一种技术，也不是软件，而是一种思想，一种架构风格。我认为这也是不完全准确的，这种观点认为SOA仅仅是思想和方法，将使得SOA成为一种不可知论，飘 在空中，很难落地。
四、SOA商业化实际运用
SOA将来真正推广到企业中应用，要落地，就不能离开几个基本的东西：支撑SOA的基础中间件平台、符合SOA架构的应用 系统（如ERP等）、构建SOA的方法论。
SOA落地途径
4.1. 架构方法论
方法和工具构成了工程技术域，要构建SOA架构的企业信息系统，确保业务和IT的真正匹配，首先必须从方法论入手。
许多企业的IT系统“孤岛”现象严重，本质上是缺乏足够有效的整体规划或者架构规划造成的。形象地说，构建企业IT大厦如同 我们盖房子是一样的道理。我们许多企业建设信息系统时就采用了盖乡村民宅的做法。盖乡村民宅不需要严谨的规划，也没有 复杂的地下设施建设（如自来水供水、排水、供气、地下停车场等），也没有需要建设污水处理、雨水收集等复杂的配套设 施。而事实上，企业IT系统建设应该如城市建设，首先需要城市总体规划，然后根据功能区规划，设计和建设小区配套设 施，“三通一平”实质就是构建建筑之间的公共基础设施，确保每栋建筑之间不是“孤岛”，然后每栋建筑还需详细的设计和工程 施工。如果要消除信息孤岛，实现IT与业务的一致性，也需要有效的企业架构规划和设计。
为什么需要架构规划
透过现象看本质，SOA代表着一种面向服务的IT架构风格，SOA的技术本质和出发点，在于IT架构。而IT架构，是组织的企业 架构的重要组成部分，它和组织的战略架构、业务架构一起，形成一个自上而下、紧密联系、相辅相成的有机整体。SOA代 表着一种正在蓬勃兴起的革命性IT架构理念，和传统技术体系区别的关键特征之一就在于SOA是战略导向和业务驱动的。而国 际和国内的各方面经验都告诉我们，对于一个组织而言，捕获战略、梳理业务和IT的最有效的措施就是架构。
企业架构(Enterprise Architecture，EA)，是从多个角度对组织的构件层次描述的规划蓝图，从各个层面反映组织的愿景、战 略、业务、服务、人员、技术和产品及其相互之间的关系，辅以其管控和演进的规则。
一个企业架构内容包括业务架构（Business Architecture）、应用架构（Application Architecture）、信息架构（Information Architecture）、技术架构（Technology Architecture）等。
真正可以落地的SOA建设，必须且只能从架构出发。没有架构，"SOA"将变成一盘无法真正解决各种运营问题的技术和产品的大杂烩。优良的架构填补了业务需求与实际信息系统以及基础设施设计之间难以逾越的鸿沟。
在所有的架构开发方法（ADM- Architecture Development Methods）之中，开放群组TOG的TOGAF是目前最权威和最有影响力的一种。The Open Group于1993年开始应客户要求制定系统架构的标准，在1995年发表The Open Group Architecture Framework (TOGAF) 架构框架。TOGAF的基础是美国国防部的信息管理技术架构(Technical Architecture for Information Management: TAFIM)。TOAGF是一个架构框架，简而言之，TOGAF是一种协助开发、验收、运行、使用和维护架构的工具，它是基于一个迭代(Iterative)的过程模型，支持最佳实践和一套可重用的现有架构资产。它可设计、评估并建立组织的正确架构。TOGAF的关键是架构开发方法ADM：一个可靠的，行之有效的方法，以发展能够满足商务需求的企业架构。而2008 年发布的TOGAF 9.0是符合SOA架构开发的最新版本。TOGAF所提出的“无边界信息流（Boundaryless Information Flow）”理 念和愿景，是解决目前企业信息化孤岛问题的最有效方式。
TOGAF架构内容
4.2. 基于SOA的应用系统
基于SOA的应用系统构建方法与传统软件架构方法有所不同。
首先基于SOA的应用系统建模和管理的组件层次是服务：
面向服务的工程
基于服务的应用系统的本质特征是松耦合，以基本业务功能（服务封装）为系统的基本实现单元，然后通过服务编排（流程管理）来“组装”业务应用系统。相对于以往的应用系统，是面向技术组件，由系统程序实现业务流程，在复用、耦合方面都存在灵活性问题。
软件工程和系统设计的演进过程基于SOA的应用系统构建过程是：
基于SOA的应用构建过程
服务建模是第一步，也就是服务识别和颗粒度确定。服务识别是方法论的第一步，服务识别的主要任务，是确定在一定范围内（通常是企业范围，或若干业务场景范围内）可能成为服务的候选者列表，并确定服务的颗粒度，以及标识服务的接口。服务建模也就确定了应用系统架构的耦合程度。
服务封装阶段的主要任务是对服务进行规范性的描述，其中包括输入/输出消息等功能性属性，以及服务在业务层面的诸多属性。并决定服务以何种形式向外提供服务。服务可能是新开发的业务功能和业务对象的封装，也可能是遗留系统的服务封装，将遗留系统的软件资产以服务的形式进行封装，在新的架构上利用已有的资产。
服务治理就是将已经封装好的服务进行集中统一有效的管理。通过ESB基础设施，提供服务注册、存储、安全控制和版本管理等。服务注册阶段的主要任务是将服务注册到服务库。此时需要决定服务的命名、安全、性能、时间特性。
服务编排就是根据业务流程的需求，对服务进行组合和组装。服务组装是以实现业务流程为目的，通过对业务服务的组合和组装，实现更粗粒度的业务服务，实现最终的业务需求。
应用交付阶段主要任务是完成业务系统服务化组装和服务部署，实现业务按需交付。
基于SOA的应用系统是SOA架构的重要组成部分，也是SOA落地的地基。
4.3. 支撑SOA的中间件平台
SOA方法论和基于SOA的应用系统要落地的支撑工具和技术基础就是中间件平台。这个在3.3.SOA的架构框架(Framework)之中已经阐述清楚了。
根据TOG-SOA模型，完整的SOA架构五大部分中，基础设施服务、企业服务总线、开发工具、管理工具等，都是中间件的基础平台。
交付服务之中的门户，也是需要支持JSR168和JSR286标准的Portlet容器和个性化交互以及终端适配的支撑平台。
业务流程管理需要支持BPEL规范的流程引擎和流程建模的工具，这个中间件平台用来支持服务的组合和服务流程编排，以满 足业务重组的需求，来实现业务的灵活性。
SOA要落地的最后支撑平台就是满足SOA规范的中间件技术
https://mp.weixin.qq.com/s/ry9IoJNYtsUb3k_hTb2pqA
