这一节将详细讨论，今天各个企业应用怎样进行集成、或者怎样没有集成。还包括对今天很多组织中很流行的集成方式：偶然架构的讨论。
在过去二十年以来，无数分布式计算模型一一登场：包括 DCE、CORBA、DCOM、MOM、 EAI Broker、J2EE、Web Services、.NET。 然而，迹象表明，不管采用何种技术，只有很少数企业的应用时很好连通的。按照来自 Gartner 公司的一个研究报告[1]，这个数字少于10%。
关于应用的连通性，其他的统计数结果更令人吃惊，— 只有 15% 的应用的集成采用了正式的集成中间件。其余则使用 ETL 和批量文件传输技术，其主要以手工编写的脚本和其他定制方案为基础。关于 ETL 和批量文件传输的更多信息，以及他们相关的问题，我们在第9章讨论。
Gartner 15% 统计值提供一个关于当今的集成状态的一个令人深思的数据。那么其他85% 的应用是如何连接的呢? 一种在今天的企业中普遍存在的情形，我将其称为是“偶然架构”。所谓偶然架构就是没有人公开宣布创造的；相反，是多年积累的一种“就事论事”的解决方案。在一个偶然架构中，公司的应用被永远锁定在一个不灵活的刚性基础架构之上。然后他们又被视为是信息“地牢”，因为集成基础设施不能适应新的业务需求。 (图 2-1)
大多数集成尝试都从某个深思熟虑的设计开始，但是经过一段时间后，其他的部分好像都各就各位地“集成”了，但是手工编写的代码却早已飘移出原来的内容之外。经过逐渐进行的螺栓和补丁，所谓整合的系统已经失去了其原来的设计完整性，尤其是如果系统是被很多的人来维护的，而他们对最初的设计意图可能没有很好地沟通。事实上，这种“就事论事”的方法将完全失去集成的一致性，因为工程师总将是“只是做一点点修改”作为解决问题的权益之计。最后甚至对找出那些地方做了修改都变得非常困难，更不要说要理解这些结果导致了那些方面的副作用影响。在一个部署系统中，这可能会对你的业务造成损失惨重的悲惨结果。
对集成遵守标准能够为你创建一个针对所期望功能的基线来遵从。如果基础设施是专有的， 不基于标准的，那么随时间变化保持计划的设计和指导原则就变成棘手问题。虽然也可以构造专有的平台并且变通规则，但是这通常又导致更加“多样性”的后果，结果更加锁定于其上。然而，你应该记住的是简单地遵守标准并不必然地阻止你构建一个偶然架构。
图表 2‑1 偶然架构将永远使公司的应用成为“信息发射井”
在偶然架构背后的技术是各不相同的。图 2-1中的实线、虚线和点划线表示了连接应用的不同技术。这些技术可能包括 FTP 文件传输、直接的socket连接 、专有的MOM、以及有时是 CORBA 或其他类型的远程过程调用(RPC) 机制。某些定向的点对点解决方案可能已经使用了XML信封定义，或者基于SOAP或者其他什么机制的技术，来为集成的应用之间承载数据。
图中间的集成Broker表示了在部门级的层次连接应用的一个岛屿。然而这并不意味着它能够连接任何事物。集成Broker通常只是结交给基础设施中的某一块，因此资金丰富的项目可能会取得适度的成功，但是它们再也不能与其它所承诺的部分进行很好的集成。
偶见架构表现为得到一个刚性的，不能对集成提供一致的、持久的基础设施。它不能如其应该达到的效果那样很好地解决你的组织性的问题。要改变偶然架构一直以来就是个挑战，因为点对点的解决方案的数量不断在增长。这通常也意谓着应用之间的互相依赖性是紧密耦合的。使应用中的数据的表现的修改意谓着你还必须修改共享该数据的其他所有应用。这就限制你快速地改变你的业务流程，以适应变化了的或者新的业务机会。这些紧密耦合的、硬连接的接口不仅仅是偶然架构的问题。因为控制流、业务应用之间的通信的编排被硬编码进应用本身之中，这进一步导致了复杂化。这些都增加了系统之间的紧密耦合和脆弱性，使变更业务流程更加困难，并且导致了厂商所定。
偶然架构的先天技术不足队组织中的人力协调问题具有推波助澜的作用。不管问题是紧密耦合的接口还是硬编码的流程编排，要想回头或者对其进行较大的翻新改造简直是一件恐怖的事情。这经常需要安排大量的会议，和属于不同项目的不同的开发组的人们开会，就紧紧对要做什么以及何时做这类的问题达成一致。如果应用，以及他们分属的开发项目组，分别处于不同的地理位置和时间区，应用改变所需的协调问题则会变得更加困难。
有时某些应用程序被视为“遗留”系统，对他们你是不愿意或不能够对其进行多少修改，因为它们已经进入维护模式。我们通常说，“遗留系统”的一个定义就是那些你昨天刚安装的系统。即使你对自己开发的应用具有完全的访问和源代码的控制权，当开发人员继续进行其他项目或离开公司的时候，对其进行修改也是非常困难的。我们将会在第 4 章中看到， ESB 大大地减少了随时间变化，修改数据模式和格式所带来的影响。
即使你已经对跟踪和修改应用数据及其接口建立了良好的公司实践，偶然架构仍然还有其他缺点。使用不同的连接技术意谓着安全模型可能是混杂的，所以没有确定的方式来建立和执行公司级的安全策略。 对插入新的应用没有一致的 API可以依赖，而且没有基础来在棋上构建公司关于集成的最佳实践。最近与一些领导的专家进行了交流，总结了偶然架构的下列各项问题:
应用之间的通信或许能得益于异步的消息的可靠性。如果一个大型业务流程中的某两个应用之间的通信连接失败，整个业务流程可能会事务性地返回或者重启。我们将会在第5章学到更多有关松散耦合的、异步的可靠消息的更多内容。
不管你是否你已经有了一个预先的性能规划并且试图分析一个现有的性能问题，由于偶然架构的许许多多的子系统和他们各自的运行特征，这个工作是极其困难的。通常的做法是采用混杂的、“投入资源到其中，直到它能正确运行”式的解决方法，这将造成磁盘、处理器、内存等上面的过度开支。
没有哪个单一方法能够提供充分的诊断和报告能力。 意外架构需要很多具有很高能力的维护人员围着所有有缺陷得生产系统转，这将导致整体拥有成本 (TCO)的急剧上升。各部分实现的方式差异越大，在其失效时需要用来解决它们的问题的专家经验就越宽。另外，建立一个基线来描述期望的正确行为也是一个挑战。
没有任何方式能够保证这个泥潭中的所有组建都能够满足你的关于可接受的冗余、弹性和容错度的定义。这意谓着要为依赖于后段系统的新功能定义可达到的服务级别协议 (SLAs) 是很困难的。
如果你的系统携带又能够收费的帐单数据 ( 比如电信)，那么账单数据的利息就可以被丢失在偶然架构之中。因此，你可能会损失收入并且还一点都不知道。
没有一致的方法来监控和管理一个偶然架构。假定你的整合应用系统必须运行 24/7 ，而且你的职员负责关注运行监控工具，并且做出纠正。这些工具将不会以相同的方式工作，那么在无数不同的小方案的基础上进行培训 ( 和再培训) 将是非常昂贵的事情。简单地安装企业级的运行管理工具并不能自动地将自省能力提供给集成基础设施，并且偶然架构通常并不能提供所有可能需要的控制点。
总而言之，偶然架构表现为一种刚性的、高成本的基础设施，并且不能满足你的组织变更的需要，还要承受以下缺点的痛苦：
- 紧密耦合的、易碎的、对变更不灵活的
- 因为多个点对点解决方案导致的昂贵的维护负担
- 修改一个应用程序可能影响其他很多应用
- 路由逻辑是硬编码到应用程序之中的
- 没有通用的安全模型；安全是混杂的
- 没有通用的 API(通常)
- 没有通用的通信协议
- 没有建立和构建最佳实践的通用基础
- 难以支持异步处理
- 不可靠
- 没有对应用和集成组件的健康监控和部署管理
如你所知，偶然架构的创建已经有些年头了，要替换和解决它并不是一蹴而就的事情。随着继承项目的需求的增加，解决方案应该更加柔性的、简单、以及运行便宜，而不是其他什么东西。偶然架构给了你的那些敏捷的竞争者得到好处，而你却不能够在一个合理的时间范围内实现新的业务机会。
你需要一个内聚的架构，面向实践、标准来解决着大量的问题。ESB 提供了架构和基础设施，并且使你能够逐个项目的基础上采用它。采用 ESB 并不是全有或全无，推倒重来式的方式。而是，你可以渐进式地采用它，同时还能利用你的现有资产-包括偶然架构和集成Broker，以一种“留下而分层”的方式。
2.2.3 ETL，批量传输，和 FTP
提取、转换、和载入 (ETL) 技术，比如 FTP 文件传输和每夜批处理式的集成在今天仍然是最流行的方法。
这通常涉及到将位于各个应用中的数据打包然后上传这样的操作。问题是有很大的可能在应用间的数据失去同步。一个失败的打包上传的处理程序可能要花上一天的时间。在京及和业务全球化的情况下，系统以24/7 的方式运行，再也没有了“夜晚”的概念，那你得批处理又该在何时执行呢？
其他问题也可能与每夜的批处理相关。因为批处理的反应期问题，在分析关键业务数据的时候，最好的情形是24 小时轮转时间。这一延迟可能严重地阻碍你对随时变化的业务事件进行反应的能力。
有时，一次跨越多个面向批处理系统的端对端处理处理甚至会花费一整个星期才能完成。处理从源头到目标的数据的总体潜伏反应期完全阻止了收集具有意义的，反应目前业务情形的数据的洞察力。比如，在供应链的场景中，这将导致你永远不知道你的库存的真实状态。
第 9 章将会呈现一个通过FTP进行成批传输的技术和业务意义的案例研究，并且会研究ESB如何能帮助你逃脱偶然架构的困境。
2.2.4 集成Broker
集线器-和-插头的集成Broker，或者EAI Broker，提供了偶然架构的替代。集成Broker是从上世纪90年代出现在，现在已经被植入到MOM主干或应用服务器平台之中。
集成Broker市场的一些公司包括:
- SeeBeyond
- IBM
- webMethods
- TIBCO
- Ascential (Mercator)
- BEA (more recently)
- Vitria
集成Broker能够使用一个集线器-和-插头架构帮助偶然架构提供应用之间的集中路由。此外，他们还允许使用业务程序管理 (BPM) 软件将业务流程从下层的集成代码中分离出来。到此为止，所有的都是好消息。
然而，对集成Broker方式也有缺点。一个集线器-和- 插头拓扑不允许对局部集成域之上进行局部控制。构建在一个集线器-和-插头拓扑之上的BPM 不能够建立跨越部门和业务单位的业务流程极其编排。 集成Broker也可能受限于下面的MOM不能越过物理的LAN网段和防火墙的能力限制。
有许多公司已经在其集成策略中采用了集线器-和-插头的集成Broker解决方案。 这些技术具有较高的成本，并且成功也值得怀疑。1990 年代后期的昂贵集成Broker项目已经取得了名义上的成功，但是将组织置于专有的集成域的井中。一项Forrester在2001 年十二月发布的研究报告[2] 展示了下列各项统计:
- 集成项目平均 20+ 个月才完成
- 少于 35% 的项目能够准时和在预算内完成
- 35% 的软件维护预算被花费在维护点对点应用连接之上
- 在 2003 年， 全球 3500 家企业平均期望花费六百四十万美元到集成项目上
这项研究还是在EAI 在它的最尖峰的时候进行的，而且几乎没有迹象表明这一数字在那时候起之后得到了改善。注意一年六百四十万美元是公司会在集成项目上花费的平均数的一个预测。当于这些公司的领导们交流这些问题的时候，我进行了一个一般性的求证。
照今天的预算标准来看，EAI Broker项目是很昂贵的。集成软件费用很贵的，通常单独对于软件许可费用，每个项目的价格范围就在从 $250,000 到一百万美元不等。这还不算一起的咨询服务组件，而这个组件的价格往往是软件许可费用的5到12倍。
集成Broker高昂的启动成本又被另一事实所进一步恶化，即从一个项目中学到的知识不能很好地转移到下一个项目。由于传统的 EAI Broker技术的专有特性，通常具有很陡峭的学习曲线，对于每个项目来说，有时候实6个月。要试图弥补这个负担的通常方式是聘请事前对专有技术经过培训的特别的顾问。当然，高特殊性=高价格。这是高昂咨询费用的一个重要组成部分( 另一个大的组成是技术安装、配置、部署、和管理的复杂性)。并且一旦项目完成，顾问就不见了。
集成项目的实现时间普遍是在 6-18 月之间。这意谓着。根据事前针对短期设定的标准、以及项目资金，实施时间吃掉了项目原本想要利用的策略性窗囗。
集成Broker的专有性质，以及高昂的咨询费用通常导致供应商锁定和重启后续项目的巨大成本。这意谓即便对于成功的项目，增长和伸展也是令人恐惧的。而且在你对你的供应商或者实现心生不满的时候，你也得面对到底是就目前的情况继续走下去，还是选择完全重新开始，雇用更多的咨询顾问或者投入另一个新的学习曲线之间左右为难。因为所有这些，一些IT组织通常留下了一些难以再集成到其他项目的“集成孤岛”。总而言之，集成Broker已经证明是偶然架构里面的老套技术，而并非它的解决方案。
当我们更详细地讨论集成Broker的时候，我们将看到导致这里所列的问题的技术屏障。另外，许许多多的非技术因素也导致了对采用ESB的需求的增长。
[1] [2]来自 Gartner 公司的统计,"集成Broker，应用服务器和 APSs,"10/2002.
[2] [3]来自 Forrester 研究的统计学,"减少集成费用,"12/2001.