集成的需要
创建商业应用很不容易,创建一个独立的、大型的应用来完成一个企业的所有业务处理更是不可能的，即使是重量级的ERP开发商，如SAP、Oracle、Peoplesoft等，只是实现了典型企业所需的部分业务功能。ERP系统是目前企业中最常见的集成系统之一，从这一点也很容易发现创建商业应用的艰辛。
其次，把业务功能分散到多个应用中，这为企业提供了很大的灵活性，可以选择“最好”的财会开发包、“最好”的客户关系管理系统以及“最好”的订单处理系统来满足自己的需要。IT组织通常对那种“一站式”的企业应用并不感兴趣，况且企业的需求名目繁多，要想提供这样一个“无所不能”的应用也不太可能。
集成面临的挑战
企业集成要求公司策略大幅调整。商业应用一般会强调某个特定的功能领域，如客户关系管理（Customer Relationship Management，CRM）、账单管理、金融管理等。然而根据Conway定律“设计系统的组织会根据组织的通信结构来得出设计”，企业很多的IT小组就是依据这些功能领域组建的。成功的企业集成不但要在多个计算机系统之间建立通信，还要在业务单位和IT部门之间建立通信。在一个集成的企业应用中，特定的应用不再由小组控制，因为每个应用已经成为整个集成应用和服务流的一部分。
由于集成的覆盖面很广，通常会对商业应用产生深远影响。一旦把最重要的业务功能加入到一个集成方案中，这个解决方案能否正确地履行功能对商业应用至关重要。如果集成方案失败，或者表现不正常，有可能使企业丢失订单、支付有误，引起客户的不满，因而损失几百万美元。
开发集成解决方案最大的限制在于，集成开发人员对所集成的各个应用只有有限的控制。在大多数情况下，这些应用都是“遗留”系统或者是封装好的应用，不会因为要连接到集成方案而作出修改。这就迫使集成开发人员不得不修补应用存在的缺陷，增加新的特性，或者弥补它们之间存在的差异。如果能在应用端点内部实现部分解决方案会更容易一些，但是出于政治或技术上的原因，这通常是做不到的。
尽管对集成解决方案存在着广泛的需求，但是这个领域内的标准还很少。XML、XSL和Web服务的出现是集成解决方案向标准化迈进的重要标志。但是，对Web运用模式解决集成问题服务的大肆宣传也给市场带来了新的格局，这又造成关于标准的新的“扩展”和“实现”到处泛滥。XML不是万能的，XML表示的业务语义在不同的上下文有不同的含义，要弥补这些语义不同需要付出诸多努力，这是一项非常困难而耗时的任务，因为它涉及到重大的商业和技术决策。
开发一个EAI解决方案本身就是一项艰难的任务，运行和维护这样的解决方案可能会更加困难。在此会混合大量不同的技术，再加上EAI解决方案的分布特性，因此，要完成复杂任务的部署、监控和故障排除需要各种各样的技能。在大多数情况下，这些技能是由不同的人掌握的，甚至并非IT行业内部的人。
集成模式有何帮助
如何实现企业集成，没有简单的答案。有人说集成很容易，这些人要么是难得的天才（至少比我们这些人更聪明），要么就是少有的白痴（这还是乐观的说法），也有可能他们想让你相信集成很简单，以便向你兜售他们的产品而从中获利。
集成模式是经过长时间的摸索，通过尝试与失败，从无数架构师经验中获得的。所谓“21天集成速成”是不可能的，模式并不是可以复制粘贴的示例代码，也不是塑膜包装的组件，而是一些宝贵的建议，描述了针对一些频繁出现的问题有哪些解决方案。如果使用得当，集成模式有助于填补集成的高层目标与具体系统实现之间的鸿沟。
集成世界
集成（integration）就是连接计算机系统、公司或人。
在许多集成项目中，我们反复地遇到以下六种类型的集成：
- 信息门户·数据复制
- 共享的业务功能
- 面向服务的体系结构
- 分布式的业务过程
- 企业到企业（B2B）的集成
松耦合
松耦合有一个基本的核心，就是在协作双方（组件、应用、服务、程序、用户）交换信息时要减少对对方做出的假设。双方对对方及公共协议做出的假设越多，通信的效率就越高，但是这种解决方案往往无法忍受服务的中断或变化，因为通信双方被紧密耦合在了一起。
许多集成方法的目标是把远程数据交换打包，从而采用本地方法调用同样的语义，以简化远程通信。基于这种策略，远程过程调用（RPC）或远程方法调用（Remote Method Invocation，RMI）得以出现，许多流行的框架和平台都已经提供了对此的支持，包括CORBA、Microsoft DCOM、.NET Remoting、Java RMI以及最近出现的RPC风格的Web服务。这种方法的好处体现在两个方面。第一，应用开发人员对同步方法调用的形式非常熟悉，所以，为什么不充分利用已知的知识呢？第二，对本地方法调用和远程方法调用均采用相同的语法，这样可以延迟到部署时再决定哪些组件要在本地运行而哪些应该远程运行，从而减少应用开发人员的负担。
远程调用面临的问题：
- 编程语言的限制
- 一个跨网络的调用往往比本地调用慢好几个数量级
- 网络的不可靠性
- 远程调用是需要同步处理还是异步处理
- 怎样才能保证是与正确的一方通信，如何防止窃听
- 第三方或商业伙伴的被调方法的方法签名改变了怎么办
集成方式
应用耦合——应该尽量减少所集成应用之间的依赖性，使每个应用的变化不会对其他应用造成影响。紧耦合的应用会对其他应用如何运行做出大量的假设。当应用发生变化，这些假设条件不再成立时，应用之间的集成就会中止。因此，集成应用的接口应该足够特定，可以提供所需的功能，但同时也要有足够的一般性，允许应用根据需要修改。
技术选择——不同的集成技术需要不同的专门软件和硬件，数量也不同。这些工具可能价格不菲，且一旦采用可能很难再采用其他开发商的产品，还可能增加开发人员的学习曲线。但是从另一方面看，从头开始构建集成解决方案常常要比最初的设想付出更多的努力，做出重复性的工作。
数据格式——所集成的应用必须协商好所交换数据的格式。为了使用统一的数据格式而修改已有的应用可能会很困难，甚至不可能。而采用中间转换器就可以把仍然使用不同数据格式的应用连接起来。与之相关的问题是数据格式的演化及其可扩展性一—数据格式如何随时间改变，以及这些改变会对应用造成怎样的影响。
数据的时间特性——当某个应用决定共享一些数据，同时其他应用拥有这些数据时，集成要尽可能缩短共享的时间。采用频繁交换少量数据的方式可以满足这一需求。但是，把一个大的数据集划分为小的数据块传送会降低系统效率。数据共享造成的延迟会影响集成设计。理想的情况是，接收方的应用在共享数据准备好时，能够立即得到通知。共享的时间越长，应用之间不同步的几率就越大，集成就会变得更复杂。
数据或功能——许多集成解决方案不但允许应用共享数据，还能共享功能，因为共享功能可以在应用之间提供更好的抽象。尽管调用远程应用中的功能与调用本地功能看上去一样，但其工作方式截然不同，这对集成工作的表现有很大的影响。
远程通信——计算机处理一般是同步的，也就是说，进程会等待子进程执行完毕后再执行。但是，调用远程子进程要比调用本地子进程慢得多，因此进程可能不希望等待子进程完成；相反地，可能希望采用异步方式调用子进程，也就是说，启动子进程后继续完成自己的处理。异步特性可以提高解决方案的效率，但是这种解决方案的设计、开发和调试更为复杂。
可靠性——与本地函数调用相比，远程连接不仅慢，而且更不可靠。当一个进程调用同一应用内部的子进程时，能够确保子进程是可用的。但是当进行远程通信时，则没有肯定的把握；远程应用可能根本没有运行，或者网络出现了临时故障。可靠的异步通信能够保证源应用继续处理其他工作，并相信远程应用以后总会运行。
应用集成的选择
- 文件传输——让每个应用生成共享数据文件，供其他应用使用，并使用其他应用生成的共享数据文件。
- 共享数据库——让应用把要共享的数据存储在一个公共数据库中。
- 远程过程调用——让每个应用公开提供自己的一些过程，使它们能够被远程调用，应用通过调用这些过程来执行操作并交换数据。
- 消息传递——让每个应用连接到一个公共的消息传递系统上，并通过消息来交换数据和调用行为。
文件传输
文件是一种通用的存储机制，各种企业操作系统都提供了这种机制，而且得到了所有企业语言的支持。最简单的方法莫过于使用文件来集成应用。
优点：
- 集成人员不必了解应用的内部细节
- 不再需要额外的处理工具现集成软件包
缺点：
- 开发人员必须自己完成大量的处理工作，包括格式转换、锁定机制、惟一性，多版本，时效性等
- 一致性问题，采用文件传输最明显的问题是很少完成更新，因此系统很可能不同步
共享数据库
基于SQL的关系数据库得到了广泛使用，因此更适合作为共享数据库。几乎所有应用开发平台都支持SQL，而且往往配备有完善的开发工具，因此就没有必要再为多种文件格式操心。由于所有的应用都会使用SQL，开发人员也不必再去掌握另一门技术。
优点：
- 一致性，数据库的事务管理系统能非常妥善地管理好数据的一致性
开发人员不用做大量的工作，包括格式转换、锁定机制、惟一性、多版本、时效性等
缺点：
- 统一的数据库模式不可能满足多个应用的需求
- 性能瓶颈，多个应用同时访问应用数据导致冲突和锁，更严重的可能导致死锁
- 封装性，共享数据很难对具体的业务进行封装，数据模式的修改导致连锁反应
远程过程调用
远程过程调用运用封装原则来集成应用。如果某个应用需要其他应用拥有的一些信息，它可以直接请求那个应用。如果某个应用需要修改另一个应用的信息，可以调用那个应用提供的函数。采用这种方式，每个应用都能维护自己数据的完整性。此外，各应用可以修改内部数据的格式，而不会影响其他应用。
优点：
- 封装性，通过方法把数据封装起来，就能更好地解决语义不一致问题
- 耦合性，可以不需要大的共享数据结构，从而有助于减少应用的耦合
缺点：
- 转换接口太多，每个应用都必须与其“相邻”应用协商接口
- 性能，远程过程调用和本地过程调用在性能和可靠性方面存在显著的差异，需要开发人员了解
- 多个应用协调处理复杂，从而导致应用间的耦合性
消息传递
利用文件传输和共享数据库，应用能够共享它们的数据，但不能共享功能。远程过程调用使应用能够共享功能，但是这会让应用紧耦合。集成的难点在于，要让不同的系统尽可能及时地协作，而且无论从应用执行还是应用开发来看，都不会使所集成的系统变得不可靠。
文件传输使得能够很好地保持应用的解耦合，但是在时间特性方面要付出代价。系统不能保持彼此的同步。协作行为太过缓慢。共享数据库能按照响应方式把数据集中在一起，但是也要付出代价，这样会把所有应用与数据库耦合。同样无法处理协作行为。
面对这些问题，远程过程调用看起来是一种更好的选择。但是把单个应用的模型扩展到应用集成中，会产生很多其他的缺陷。这些缺陷都是由分布式开发造成的。尽管远程过程调用看起来像本地调用，但是表现完全不同。远程调用更慢，而且更容易失败。当多个应用跨企业通信时，我们不希望一个应用的失败引发所有其他应用也失败。而且，不希望在假设调用速度很快的前提下设计系统，另外不想让每个应用都知道其他应用的细节，甚至只是接口方面的细节。
我们真正需要的有些类似于文件传输，大量的小数据包能迅速地产生，并且方便地传送，当有新的数据包到达时，接收应用会自动得到通知。数据传输需要一种重传机制，以确保传送的成功。存储数据的任何磁盘结构或数据库细节要对应用隐藏，这样一来，与共享数据库不同，存储模式和细节可以很容易地修改，从而反映企业不断变化的需求。类似于远程过程调用，一个应用可以向另一个应用发送一个数据包，从而调用其他应用的相应操作，不过这里不那么容易失败。要让发送者不必等待接收者，尤其是必须要重传数据时，应该采用异步传输。
异步消息传递从根本上是为了解决分布式系统面临的实际问题。发送一个消息时，不需要通信双方同时在线或者都准备好。而且，采用异步通信方式有助于开发人员认识到，与远程应用协作会更慢，促使他们设计出高内聚（把大量操作本地化）和低耦合（有选择地执行远程操作）的组件。
优点：
- 消息传递系统同样能保持文件传输的解耦合性，消息能在传送中得到转换，发送者与接收者都不用了解具体的转换
- 通过频繁发送小消息，应用不仅能共享数据，还可以在操作上相互协作
- 不像远程过程调用那么快，但是在处理消息以及返回响应时，调用者不需要等待
缺点：
- 尽管频繁的消息传递能减少文件传输遇到的许多不一致问题，但是并没有完全根除，如果系统未能同时更新，也会带来一些滞后问题
- 大多数开发人员没有学过异步设计，因此取而代之，会采用许多不同的规则和技术，掌握异步仍然有一定的学习曲线。另外，在这种环境中，测试和调试也更加困难
一旦决定使用消息传递方法集成系统，还要考虑许多新的问题以及相应的做法。
- 如何传输数据包？
发送者通过一个连接发送者和接收者的消息通道来发送一个消息，从而向接收者发送数据。 - 如何确定消息的发送地址？
如果发送者不知道消息发送到哪里，它可以把数据发送给一个消息路由器，由它把数据转发给适当的接收者。 - 怎样确定需要使用的数据格式？
如果发送者和接收者不能达成一致的数据格式，发送者可以把数据直接发送给消息转换器，由它把数据转换成接收者的格式，并进一步将数据转发给接收者。 - 如果你是一位应用开发人员，该如何把自己的应用与消息传递系统连接？
想要使用消息传递的应用必须采用消息端点来完成具体的发送和接收。
网友评论