说说系统集成发展史

原创

回顾系统整合方案的发展历史，我们可以看到系统整合大致经历了三个阶段：点对点连接、过渡时期的集中式、总线式

 

点对点：

应用之间的连接拓扑大多数情况下是点对点的，硬编码的，所使用的协议是非标准的，功能的提供者和使用者之间是紧耦合的，功能的粒度通常较细，数据的表示也不统一；

 

集中式：

Enterprise Application Integration"，即企业应用整合

随着集成复杂度的增长，和实践经验的总结，开始出现一些从好的实践中总结出来的集成模式，如消息中枢（Message Backbone）、应用集成中心（Application Integration Hub），这些模式或多或少地尝试提供一个集成基础设施来简化应用之间日趋复杂的连接拓扑，提供异构数据和功能访问方式之间的转换。Enterprise Application Integration"，即企业应用整合 狭义的，仅指企业内部不同应用系统之间的互连，往往使用如CORBA和COM等的消息中间件进行分布式，跨平台的程序交互，因此，这一时期的EAI是有限的部件级的重用。(很不幸的是，这个时期的架构没有统一的标准，因此，各个厂商都有各自不同的EAI解决方案，你会看到各种各样的中间件平台。如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之间周旋，来实现合理的互联方式，你不得不考虑各种复杂的可能性。因此，你所见过的大多数传统EAI解决方案都比较笨重。)

 

（这种很像一个Hub模式基础架构，还存在如下问题：首先，整个架构的性能低下，每个交易都经过中央Hub的中转，Hub的负担会很重，速度会随着参与者的增多而愈来愈慢；其次，这样的系统会很脆弱，一旦Hub出错，整个系统都会瘫痪；最后，这样的架构会破坏了开放性原则，参与者运行在一个相对封闭的环境中，扩展起来十分麻烦。因此，这也不是理想的架构。）

 

 

总线式：

EAI集成具有更为广义的内涵，它已经被扩展到业务整合(Business Integration)的范畴，将应用集成进一步拓展到业务流程整合的级别。不仅实现异构系统的互联互通，消息传输，转换，

 

此时被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑，因为不管有怎样的应用底层实现，只要是SOA架构中的服务，它就一定是基于标准的。这些服务通过松耦合的SOA架构，为其它应用服务。对于服务的使用者，不用关心服务的提供者是基于什么开发技术、在哪个位置、什么硬件平台提供的服务，这个服务使用的过程完全是松散和透明的。服务能够良好的重用，快速的组装或编排出新的业务应用、业务流程。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26101821/viewspace-723247/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26101821/viewspace-723247/