应用集成标准
2022年10月23日
第一章 应用集成的背景
据IDC统计，在过去的10年中，全球企业在信息系统上一共投资18万亿美元。巨大的投资为企业建立了众多的信息系统，以帮助企业进行内外部业务的处理和管理工作。根据METAGroup的统计，一家典型的大型企业平均拥有49个应用系统，33％的IT预算是花在传统的集成上，通过零星的“点对点”连接，使众多的“信息孤岛”联系起来，以便让不同的系统之间交换信息。根据摩根斯坦利公司对大企业CIO的调查，在这些主管企业信息化人士所关心的问题中，如何将众多的企业应用系统集成起来并进行数据统一管理，是他们最为关注的热点。
如今不少企业至少包含三个以上软件系统，比如OA、ERP、CRM、HR、BI以及财务软件，但这些软件的数据格式、数据库类别、操作系统、应用系统等都不尽一样，位置分散相互独立，甚至一些企业在同一个集团下的财务、办公、销售、生产等系统也各自独立。
孤立的信息系统无法有效地提供跨部门、跨系统的综合性的信息，诸如：某个主要的订单的状况怎样？谁是我的最重要的客户？这个季度的任务能否完成？等等。孤立的信息系统也无法实现实时的信息存取和对业务流程的透视，无法实现对客户、供应商、项目、订单、资产等的全面掌控，无法实现企业价值链的全面的、彻底的透视和控制。
应用集成，最关键的问题是这些异构系统之间成为多个应用孤岛和数据孤岛，难于共享数据和资源，相互之间不能互为数据备份，数据的完整性和可用性差，企业决策者无法集中看到所有关键数据，难于及时掌控各种准确有效数据，因而大大提高了企业营运成本，减弱了企业市场快速响应力，也大为降低了企业综合竞争力。一些企业老旧IT系统甚至"陷于不义"，产生自相矛盾、过时错误的数据信息，使企业在错误时间错误地点做出了错误的决策，贻害不浅。
企业虽然一直面临着削减成本和最大限度地利用现有技术的难题，但是与此同时，他们还必须不断地努力，以期更好地服务客户，更快地响应企业战略重点，从而赢得更大的竞争力。从信息的整合再到功能与流程的整合，从企业内部的应用整合到跨企业边界的整合，企业整合的需求不断地变化和丰富。
在已经上了信息化的企业，想做应用集成改造，是必须谨慎从事的。系统的增加、替换甚至是放弃，都是一件关系到上上下下、方方面面的大事。改造是有成本的，更是有风险的，搞不好影响到经营业务，甚至会成为公司发展的分水岭。
因此面对日益繁复庞杂的IT系统，企业该如何来科学有效地统筹管理？如何将不同时期的不同新旧系统进行整合，简化管理和操作流程，消除信息孤岛（包括应用孤岛和数据孤岛），降低IT系统总体拥有成本，提高业务服务水平，发挥最大的效益，并创造优异的灵活性来适应未来的业务变化，是每个中小企业都必须解决的重要而迫切话题。
第二章 应用集成的发展历程
EAI（Enterprise Application Integration, EAI）技术的发展经历了从不成熟到逐渐成熟的坎坷历程，回顾EAI技术的发展过程， EAI技术的演变经历了十多年的时间，产生了几代从不成熟到逐渐成熟的EAI技术，为企业带来不断增长的商业价值。
20世纪60年代到70年代期间，企业应用大多是用来替代重复性劳动的一些简单设计。当时并没有考虑到企业数据的集成，惟一的目标就是用计算机代替一些孤立的、体力性质的工作环节。
20世纪80年代，企业规模开始扩大，企业业务和数据日趋复杂，一些公司开始意识到应用集成的价值和必要性，很多公司的技术人员试图在企业系统整体概念的指导下对已经存在的应用进行重新设计，以便将它们集成在一起。此时，点到点(Point-to-Point)的集成技术开始出现，在各个应用系统之间通过各自不同的接口进行点到点的简单连接，实现信息和数据的共享。点到点的应用集成也被称为第0代EAI技术。
20世纪80年代末和90年代初，随着企业规模的进一步扩大，应用系统不断增加，简单的点到点连接已经很难满足不断增长的应用集成要求，企业迫切需要新的集成方法：可以少写代码，无须巨额花费，就可以将各种旧的应用系统和新的系统集成起来。第1代EAI技术的出现在一定程度上解决了这些问题，它采用CORBA/DCOM、MOM(消息中间件)等技术，实现了对企业信息的集成，促进了企业的进一步发展。
20世纪90年代中后期，企业业务的迅速发展以及与电子商务的结合对应用集成解决方案提出了更高的要求，局限于信息集成的第1代EAI集成技术很难实现企业业务流程的自动处理、管理和监控，基于业务流程管理/集成(BPM/BPI)的第2代EAI集成技术成为更加合适的集成选择方案。第2代EAI集成技术通过实现对企业业务流程的全面分析管理，可以满足企业与客户、合作伙伴之间的业务需求，实现端到端的业务流程，顺畅企业内外的数据流、信息流和业务流。第2代EAI集成技术是当前集成技术发展的主流。
目前，EAI技术正向第3代集成技术演变：即根据不同行业特点，选择适合应用集成技术，推出基于行业的预建构集成包，预先解决行业共性的问题，从而缩短EAI项目开发周期。
第三章 应用集成的定义
企业应用集成(Enterprise Application Integration, EAI) 是完成在组织内、外的各种异构系统，应用和数据源之间共享和交换信息和协作的途径、方法论、标准和技术。企业应用集成所连接的应用包括各种电子商务系统，企业资源规划系统，客户关系管理系统，供应链管理系统，办公自动化系统，数据库系统，数据仓库等等。
第四章 应用集成的层次
应用集成可以分为三个层次。每个层次的目的和内容不尽相同。
· 业务集成
企业搞集成的目的并不是简单追求管理手段和技术的先进性，而是根据企业管理的目标。比如通过“钢性”的信息系统将管理模式输出到多个同类型的制造或者经营部门，做到作业标准化、工作模式化（业务标准统一），实现管理的简单复制。
其实，我们所用的不同系统都是用来解决管理的某些层面的问题，或者说处理某些层面的问题比较专业。比如要把从采购、制造到销售等企业内部价值链过程用一套系统联接起来，将物流、资金流、信息流统一起来，这便有了ERP(企业资源计划)。而PDM(产品数据管理软件)解决的是设计研发的问题，OA（办公自动化软件）解决的是办公的问题。
当企业同时拥有ERP、PDM、OA等系统的时候，这就有了集成的需求。这些集成的本质是业务集成。正如案例中谈到的，同样是物料，“设计部门认为蓝色漆和绿色漆编码肯定应该不一样，但是在财务人员看来是相同的因为价格相同；而财务人员认为金属漆与普通漆价格相差很大，编码肯定应该不同，但是设计人员认为两者差别不大。”其本质是两者关注的业务点不一样，一个是工艺，另一个是成本。解决业务集成，重在实现管理口径的一致性，这是信息交换和共享的基础。说白了，就是用相同的语言说话。
业务集成通常会实现业务逻辑在多个信息系统之间的流转。技术实现并不是唯一有效的这手段，通过规范管理要素是更好的选择，即统一业务逻辑。再看上面的例子中，可以增加物料的附属信息，使之同时包含颜色、价格等多个独立属性，并在不同的系统引用这些属性以达成不同的管理目的。这样一来，物料编码的粗细程度就不会成为主要矛盾。
· 数据集成
数据集成是解决信息系统底层的数据同步性、时效性问题，其目的是解决数据来源的唯一性、真实性、时点性（数据是动态的，不同时点的数据有不同的状态）。
为了完成业务过程集成，必须首先解决数据和数据库的集成问题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型。这三步完成以后，数据才能在数据库系统中分布和共享。
数据集成是业务集成的技术基础，但对这种技术实现精度的要求可高可低，其衡量标准是紧急程度和代价的多少。比如，给手机冲值要求金额实时到帐，不然会出现一卡反复冲值或者出现冲值后仍然不能使用的情况。而拨打手机的计费并不是实时到帐，而是数十小时甚至是月底才批量性结转的，因为如果实时处理，基站和计费系统的负荷会不堪重负。
由于有更高的技术细节，数据集成是一件复杂的事情。最近这几年有越来越多的客户对这一块技术方案、实现技巧、切换方法感兴趣，而可以提供咨询和解决方案的顾问较少。究其原因，同时对技术和业务有深入理解的顾问很少。所以，这是一个又难又重要的领域。
数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。构件数据仓库是为企业决策者做出战略决策，提供信息，这些用户访问数据仓库的工具有：报表和查询工具、应用程序开发工具、执行信息系统工具、联机分析处理工具、数据挖掘工具。数据仓库解决方案常用来实现企业决策信息的挖掘和提取。
· 企业集成
最上层的企业集成。对于枣矿集团这种大型的集团企业，由于二级子公司业务的独立性、产业的多样性和历史的因素，各子公司使用不同信息系统的现象相当普遍。
集团的信息部门总是在系统整合与分散之间左右为难。枣矿集团也有这样的困惑：整合意味放弃前期的系统投入，也意味着切换失败的管理和技术风险，不整合又可能意味着集团管理的乏力。
是否进行企业集成，评判标准与业务集成不同，主要看产业关联度和管理关联度。对于子公司之间产业相同或者产业关联度很高，可以用一套系统整合集中管理，提高集团子公司的业务协同，就应该在资金允许，准备充分的情况下对企业集成，彻底整合。但如果集团公司是以投资管理为重点，子公司之间是非相关产业多元化性质的，就没有必要做业务运营层面的系统集成。顶多是通过集团管控、合并报表、公文流转等系统应用来集成部分二级公司的数据。切忌用一套系统来管理多元化集团企业成员。前几年，国内有多个这种性质的集团企业，花了很多钱来统一系统平台，结果几年都不能实现，无功而返，还耽误了集团的管控进程。正确的做法是，集团收集二级单位的汇总管理信息，通过逐级上报软件和分析系统做管理决策。
我们已经知道企业应用集成的三个层次，在具体的企业中如何用于行动呢？我们说评估、规划是应用集成的前提。
首先进行公司业务定位、管理模式、管理基础、系统现状的评估。判断集成的风险，特别关注人的因素（包括观点、能力、执行力等）、钱的因素（资金保障）、时间因素（集成实现和系统切换的时间点）。
其次是发动业务和管理层，规划集成的目标、范围，明确重点和难点，找到管理上、技术上的解决方案。特别是实现的策略、步骤和过渡、切换方法。提交一两套方案供公司高层决策。
企业应用集成是为了提高管理效益，而不是仅仅追求技术的先进性，只有把握集成的度，分层次考虑，才能提高集成的效益。
除此以外，近几年，还有其他的一些提法：
· B2Bi
B2Bi(BusinesstoBusinessintegration)是一个企业与另一个企业的应用系统之间的整合，以实现企业同供应商、经销商等合作伙伴之间更加紧密的协作关系。
· B2Ci
B2Ci(BusinesstoCustomerintegration)是指企业内部系统(主要是ERP系统)和企业的Web应用之间的整合。一个企业如要进行电子商务，就必须将Web应用同后台的财务、库存管理模块等实现充分的信息交流和打通，否则传统的作业方式无法满足电子商务的实际需要。
枣矿集团完整的EAI解决方案应当包含以下五个方面：
用户交互：实现应用用户界面统一的接入与安全机制。
应用连接：通过SOA(面向服务架构)，具体实现可以参考基于微服务分布式应用架构。实现应用与应用之间的连接，完成相关的数据路由与数据格式转换。为两个应用系统中的数据和程序提供接近实时的集成。在一些B2B集成中，它可以用来实现CRM系统与企业后端应用和Web的集成，构建充分利用多个业务系统资源的电子商务网站。
业务流程整合：实现业务流程管理，包括工作流管理和自动化流程两个方面。对业务过程进行集成的时候，企业必须在各种业务系统中定义、授权和管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过程集成，包括业务管理、进程模拟以及综合任务、流程、组织和进出信息的工作流，还包括业务处理中每一步都需要的工具。
构建整合：这个层面包含两个分，一部分是构建与现有应用兼容的新应用，另一部分是对现有资源进行升级改造以适应新环境的需要。
数据集成：实现数据集成，在异构的数据源之间实现数据层的直接整合。
通过以上集成，EAI使得企业众多信息系统都与一个由中间件组成的底层基础平台相连接，各种“应用孤岛”、“信息孤岛”通过各自的“适配器”（可以理解成一个转接口）连接到一个总线上，然后再通过一个消息队列或服务调用实现各个应用之间的交流。就像几个只会讲各自母语的人遇到了一个“万能翻译”一样，不同的信息系统之间终于可以流畅对话了。这样，EAI使得企业内部的应用系统能够通信顺畅。系统之间借助EAI实现良好的沟通，可以极大地减少以往通过手工处理导致的资源消耗（打印成本、人力成本、时间成本），为企业创造了价值。在这基础上，它还可促进一个企业与另一个企业的应用系统的整合，以实现企业同供应商、经销商等合作伙伴之间更加紧密的协作关系。
第五章 应用集成的主要技术
企业应用集成使用的主要技术包括：
· RMI
远程方法调用（Remote Method Invocation，RMI）是用Java在JDK1.1 中实现的，它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言，其巨大的威力就体现在它强大的开发分布式应用系统的能力 上，而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信，实现远程对象之间的无缝远程调用。
RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。JRMP是专为Java的远程对象制定的协议。因此，Java RMI具有Java的"Write Once,Run Anywhere"的优点，是分布式应用系统的百分之百纯Java解决方案。用Java RMI开发的应用系统可以部署在任何支持JRE（Java Run Environment Java，运行环境）的平台上。但由于JRMP是专为Java对象制定的，因此，RMI对于用非Java语言开发的应用系统的支持不足。不能与用非Java语言书写的对象进行通信。
Java Remote Method Invocation ( RMI -- Java远程方法调用)允许您使用Java编写分布式对象。
RMI可利用标准Java本机方法接口JNI与现有的和原有的系统相连接。RMI还可利用标准JDBC包与现有的关系数据库连接。RMI/JNI和RMI/JDBC相结合，可帮助您利用RMI与目前使用非Java语言的现有服务器进行通信，而且在您需要时可扩展Java在这些服务器上的使用。RMI可帮助您在扩展使用时充分利用Java的强大功能。
RMI（远程方法调用）的组成
一个正常工作的RMI系统由下面几个部分组成：
² 远程服务的接口定义
² 远程服务接口的具体实现
² 桩（Stub）和框架（Skeleton）文件
² 一个运行远程服务的服务器
² 一个RMI命名服务，它允许客户端去发现这个远程服务
² 类文件的提供者（一个HTTP或者FTP服务器）
² 一个需要这个远程服务的客户端程序
RMI（远程方法调用）的工作原理
RMI系统结构，在客户端和服务器端都有几层结构。
方法调用从客户对象经占位程序（Stub)、远程引用层(Remote Reference Layer)和传输层（Transport Layer）向下，传递给主机，然后再次经传 输层，向上穿过远程调用层和骨干网（Skeleton），到达服务器对象。 占位程序扮演着远程服务器对象的代理的角色，使该对象可被客户激活。 远程引用层处理语义、管理单一或多重对象的通信，决定调用是应发往一个服务器还是多个。传输层管理实际的连接，并且追追踪可以接受方法调用的远程对象。服 务器端的骨干网完成对服务器对象实际的方法调用，并获取返回值。返回值向下经远程引用层、服务器端的传输层传递回客户端，再向上经传输层和远程调用层返 回。最后，占位程序获得返回值。
· RPC（Remote Procedure Call Protocol）
RPC 远程过程调用协议，通过网络从远程计算机上请求调用某种服务。
常用分布式服务框架RPC框架： Dubbo,Spring Cloud。
基础架构：
· COM
COM是Microsoft组件对象模型（Component Object Model）的简称。
COM是一个说明如何建立可动态交替更新组件的规范。它提供了客户和组件为保证能够互操作应该遵循的标准。该标准对于组件架构的重要性同其他任何一个具有可交替更新部分的系统是一样的。举个例子，如果没有国家标准（GB），那么各个厂家所生产的零件及产品将不能实现互换性。各个厂家各自为政，若电机上的螺栓坏了，就要买原来厂家生产的螺栓，相当不方便。我们所熟悉的超文本格式语言（HTML），实际上也是一种趋向于标准化的语言。没有标准，任何东西都将不能一起工作。
COM规范就是一套为组件架构设置标准的文档。
COM组件由以Win 32动态连接库（DLL）或可执行文件（EXE）形式发布的可执行代码所组成。遵循COM规范编写出来的组件将能够满足对组件架构的所有要求。
COM组件可以动态的插入或卸出应用
COM组件必须是动态链接的
COM组件必须隐藏（封装）其内部实现细节
COM组件必须将其实现的语言隐藏
COM组件必须以二进制的形式发布
COM组件必须可以在不妨碍已有用户的情况下被升级
COM组件可以透明的在网络上被重新分配位置
COM组件按照一种标准的方式来宣布它们的存在
· DCOM
Microsoft的分布式COM（DCOM）扩展了组件对象模型技术（COM）,使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通讯。使用DCOM，你的应用程序就可以在位置上达到分布性，从而满足你的客户和应用的需求。
· XML
XML 代表Extensible Markup Language（eXtensible Markup Language的缩写，意为可扩展的标记语言）。XML是一套定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语 言，即定义了用于定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。
XML主要具有以下几个特点：
① 简洁有效
XML是一个精简的SGML，它将SGML的丰富功能与HTML的易用性结合到Web应用种，它保留了SGML的可扩展功能，这使得XML从根本上有区别于HTML。并且XML种还包括可扩展格式语言XSL（Extensible Style Language）和可扩展链接语言XLL（Extensible Linking Language）使得XML的显示和解析更加方便快捷。
② 易学易用
XML对SGML进行了精简，它抛弃了SGML中不常用的部分，方便用户编写Web页面同时也给设计人员实现XML浏览器降低了困难。
③ 开放的国际化标准
XML是W3C正式批准的，它完全可用于Web和工具的开发。XML具有标准的名域说明方法，支持文档对象模型标准、可扩展类型语言标准、可扩展链接语言标准和XML指针语言标准。使用XML可以在不同的计算机系统间交换信息，而且还可以跨越国界和超越不同文化疆界交换信息。
④ 高效可扩充
XML支持复用文档片断，使用者可以发明和使用自己的标签，也可以与他人共享，可延伸性大。在XML中，可定义一组无限量的标准，可以有效地进行XML文件的扩充。
· JSON
JSON(JavaScript Object Notation, JS 对象简谱) 是一种轻量级的数据交换格式。它基于 ECMAScript (欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。
· JMS
Sun Java™ System Message Queue (Message Queue) 可以提供可靠的异步消息传送，能够将企业中的分布式应用程序和组件集成在一起。在不同平台和操作系统上运行的进程可以通过连接到该服务来彼此进行交互。
Message Queue 是一种基于标准的消息传送解决方案，它实现了 Java™ 消息服务 (JMS) 开放标准。此外，Message Queue 还提供了大规模企业部署所需的互操作性、安全性、可伸缩性、可用性、易管理性以及其他功能。
图 ：消息服务体系结构
· WEB Service
Web Service 是一种新的web应用程序方式，他们是自包含、自描述、模块化的应用，可以发布、定位、通过web调用。Web Service可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后，其他Web Service应用程序可以发现并调用它部署的服务。
它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。
web广泛用到的技术：
· TCP/IP：通用网络协议，被各种设备使用
· HTML：通用用户界面，可以使用HTML标签显示数据
· Java：写一次可以在任何地方运行的通用编程语言
· XML ：通用数据表达语言，在web上传送机构化数据的容易方法
他们的特点是其开放性，跨平台性，开放性正是Web services的基础。
Web服务的优势
为什么说Web服务是互联网发展的趋势呢？除了本地服务的缺点以外，还有这么几点：
* 平台无关。不管你使用什么平台，都可以使用Web服务。
* 编程语言无关。只要遵守相关协议，就可以使用任意编程语言，向其他网站要求Web服务。这大大增加了web服务的适用性，降低了对程序员的要求。
* 对于Web服务提供者来说，部署、升级和维护Web服务都非常单纯，不需要考虑客户端兼容问题，而且一次性就能完成。
* 对于Web服务使用者来说，可以轻易实现多种数据、多种服务的聚合（mashup），因此能够做出一些以前根本无法想像的事情。
· ESB
ESB（Enterprise Service Bus，即企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。
企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息协议接口(例如IBM的WebSphere MQ、Tibco的Rendezvous和Sonic Software的SoniCMQ)。ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。
企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service -Oriented Architecture， SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型，其中的软件架构是以一种定义清晰的层次化结构相互耦合，其中，一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。
ESB(SOA架构)是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：
· 面向服务的架构 -分布式的应用由可重用的服务组成
· 面向消息的架构 - 应用之间通过ESB发送和接受消息
· 事件驱动的架构 - 应用之间异步地产生和接收消息
新构建应用系统集成必须参照SOA面向服务架构进行设计和开发。
· SOA
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能模块（称为服务）通过这些服务之间定义良好的接口和约定联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务应用，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。
然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。
Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个业务应用系统如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括新进供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的信息数据传递应该在任何 SOA 中都起着重要的作用。
第六章 应用集成的实现方式
· 定制连接，两两互连
最早期的系统应用集成，用户只着眼于解决眼前的一个系统和另外一个系统的互连互通，并不考虑这个系统的合理性和可扩展性。这种集成并不采用什么专门的EAI技术，只是使用硬编码来实现系统之间的点对点连接。这种方式，在有些特定情况下（比如很小规模的集成系统）可能会得到相对较高的性能，因为一切都是为特定情况定制开发的。但集成规模稍一复杂，这种方式代码量大，不可靠，无法维护等缺点就会显露无疑。
桥接的技术也是为两个特定系统专门定制通讯链路来转换这两个系统的接口，协议以及数据格式等差异。
缺点：
全部使用专门为两个特定系统定制的连接，在企业系统众多的情况下连接急剧增加，难以开发，后期维护更加困难 。
由于这些专用连接完全互相独立，其只能满足系统两两互连通讯的需求，无法实现涉及多个应用系统的复杂业务流程。
· 中心——辐条（hub-spoke）式体系结构
由于两两互连方式具有上述明显缺陷，中心——辐条式的解决方案应运而生。该方式提供一个应用集成中心（hub），这个中心具有自己的连接协议，所有需要集成的系统（spoke）都和该中心相连。原来用户每集成一个系统，都要考虑改系统和其他所有系统的点对点连接的协议，数据结构的转换，而在中心——辐条结构下，用户只需要考虑系统和集成中心的点对点连接上转换。这样，原来n个系统之间的nx(n-1)/2个点对点连接减少为n个连接。
一般集成中心和各个系统的连接及相应的转换使用集成中心中所谓适配器来完成。同时，这种方式也使的集中管理以及流程集成成为可能。另外，体系结构中开始出现集中式的资源中心（Repository）。资源中心将原来分散的各种资源（适配器，组件，运行信息等）集中管理起来，这为用户设计，开发，部署和维护管理EAI系统提供了很大的便利。
缺点：
集中式的结构容易造成效率瓶颈，同时存在单点失效的问题。
· ESB & BPM & BAM
随着IT技术的发展，企业应用集成的需求急剧增加，上述朴素的中心——辐条式结构已不能很好的满足这些需求，企业服务总线（Enterprise Service Bus）的体系结构逐渐浮出水面。这种体系结构继承了中心——辐条（hub-spoke）式体系结构将各个系统点对点连接转化为多个系统对中心的连接的理念。但在这种体系结构中，集成中心被扩展成可以分布在多个物理节点上的总线，从而有效解决了中心——辐条模式的单点失效和效率问题。
然而，ESB技术并不仅仅是简单的将集成中心被扩展成总线。企业服务总线本身提供各种消息路由，数据转换等各种EAI模式的支持。这种总线一般以成熟的消息中间件作为其物理消息传递背板，保证消息在分布式环境下可靠高效的传输。同时，企业服务总线作为应用集成系统的基础框架，大多数采用面向组件的技术，这实际上是SOA的雏形。
另外，ESB体系机构中往往包含商业流程管理（BPM）和商业活动监控（BAM）模块的实现。BPM作为ESB的消费者，可以将总线上的各个服务（或组件，适配器等）按照用户需要的商业逻辑组装起来，使这些服务按照业务逻辑顺序执行，从而实现用户完整的业务功能。而BAM提供对整个ESB，ESB上的服务和BPM的运行状态进行监控和管理。
· SOA & ESB/BPM/BAM
面向服务的体系架构（Service Oriented Architecture）是目前EAI领域最先进的体系结构。实际上，SOA的提出在很大程度上就是为了更好的满足企业应用集成的需求。SOA强调复用和松偶合，注重接口及其标准化描述，这些都为企业应用集成规划了非常好的框架体系结构。除了具有前面ESB结构的优点之外，基于SOA的应用集成系统具有更好的可扩展性和灵活性，用户可以在对已有系统影响最小的情况下开发应用新的业务模块（服务）或修改已有模块，从而快速满足业务需求的变化。
本质上说，SOA架构对应用集成的基本要求有以下几点：
SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用。这是对服务提供者本身的要求。
服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关。这是从服务消费者的角度应该看到（了解）的服务提供者的样子。
灵活的架构-服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明。这是对服务消费者消费服务提供者提供的服务的方式的要求。基于SOA架构的EAI产品一般使用企业服务总线（ESB）来满足（实现）这一要求。
可以看到，SOA的体系结构一般来说也需要企业服务总线的支撑，只是它对总线上的服务和总线本身的作用和位置有着更加明确的要求。
好的符合SOA的EAI系统也同样整合了对BPM和BAM的支持。这里特别要指出的是，在符合SOA的EAI系统中对BPM的支持具有更多优点。在传统ESB系统中，BPM往往是厂家相关的专门模块，这一模块存在于ESB之上并且是不可替换的。而在符合SOA的EAI系统中，BPM模块也作为一种服务（编排服务）其本质上和其他服务没有差别，这使得用户选择多种服务编排方式（即不同的BPM实现）成为可能。
· 分布式SOA
分布式SOA基础架构可以帮助用户摆脱紧耦合的方式，以较少的投资开始SOA建设，用户只配置需要的功能，并根据需要以渐进的方式扩大整合的规模。分布式SOA可以在运行环境中动态配置，也就是说用户的业务无需中断。在分布式SOA基础架构里，具备今天SOA所涉及的全部元素。在这个架构里，为了使各种服务能够重用以前的或者是现在的各种应用，实现各种服务元素的共享，首先要把这些元素互联、互通，消除信息孤岛，不管是基于主机、CORBA还是基于Java，统一对其进行封装，就像原来不同的网络协议被TCP/IP封装一样。 分布式SOA基础架构分为三层，最底层是对不同应用进行SOA封装，使其成为标准；第二层提供中间层服务；第三层是基于业务需求定义传递参数和返回值 。枣矿集团PaaS平台为分布式SOA提供技术支撑。
分布式SOA架构完全可以替代EAI，如果用户已经建立了EAI，可以将其纳入分布式SOA架构这个体系之内，加上端点，加上封装，就可以进入SOA网络。以某省网通公司为例，如果对BSS、OSS和MSS系统进行EAI建设，投资是1500万。而如果采用分布式SOA架构，较传统方式（Socket和数据库）预计能够节省80%的投资。
· 枣矿云
枣矿集团新业务应用系统集成必须基于枣矿PaaS平台来构建，业务数据整合和分析必须构建在枣矿大数据平台（数据分析引擎）之上，充分利用枣矿云的计算、存储和网络资源，减少重复投入，降低软硬件成本。
第七章 总结
然而要保障多种IT系统的兼容互通、成功整合，企业还必须要建立强有力的执行政策，避免执行标准时出现经常性或不必要的偏移。如果有不可避免的例外情况发生，在可行的情况下，政策应该确保应用软件的升级以支持整个架构的标准化，而不是各行其政各行其是，让企业各种软件系统充分融合，不是苟合，不能搞成"四不象"，变成"1+1＜2"，这不是企业应用集成的目的。
当今，应用集成已经成了企业适应竞争、应对挑战的一种战略，一种招数，一种资源的互补，一种力量的凝聚！