探讨EAI中的应用连接

<div class="postText">
IBM认为一个完整的EAI的解决方案应当包括五个方面：用户交互、应用连接、业务流程整合、构建整合和信息集成。<br />在这篇blog中来探讨下EAI的应用连接，IBM对于应用连接的定义：通过 HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据路由与数据格式转换，对于IBM的这个定义，非常的认可，在实际的EAI类的项目中，这也确实是个很实际的需要解决的问题，可能很多人仍然会认为EAI是一种炒作，好象也是没有什么做的成功的EAI项目，但EAI项目现在确实是存在的，而且在这块的技术、实施经验也是不断的成熟，EAI项目带来的意义更是不可否认，在这篇blog中将从应用连接所应对的应用场景、技术实现两个方面来探讨下：<br /><font size="4"><font style="BACKGROUND-COLOR: #ffffff"><font color="#ffa500"><strong><font color="#008000">应用连接所应对的应用场景</font></strong><br /></font></font></font>在EAI项目中，通常都会有这样的需求，那就是A应用需要主动的发送某些数据给B、C或C或C、D应用，要做到的效果就是不论B、C或C或C、D应用是否启动，在这些应用启动后数据都必须100%的送到，在送到时需要让A应用得到通知，在未送到的情况下也要让A应用知道未送到的原因，而如果超出时间仍然未送到的话则要告诉A应用发送给某应用的数据失败了。<br />这个应用场景更为形象的描述的话可以类比实际生活中的送信的过程，尽管应用连接的需求的复杂程度远超过送信的过程，如果大家能想起更加吻合的场景的话，请回复一下，多谢。<br /><font color="#008000" size="4"><strong>应用连接的技术实现</strong></font><br />应用连接的技术实现的发展过程和阶段非常的明显，在最早各大厂商开始炒作EAI时，对于应用连接这块全部是号称用MQ就可以直接实现的，为什么会想到用MQ呢，这是因为在应用连接所应对的应用场景中非常重要和典型的需求就是“保证信息能够及时和准确传递”，这正是MQ的强项，自然MQ就当仁不让的成为了应用连接技术实现的首选，当然，这确实是应用连接技术实现中的一个重要的选择，即使在现在MQ也仍然是应用连接技术实现中核心的产品，但仅仅基于MQ是无法实现应用连接中的应用需求的，MQ仅仅能保证消息及时、准确的传递，但它对于应用连接中重要的应用级别的生命周期、应用级别上的消息的100%到达的需求都是无法实现的，但是基于MQ是可以实现这些的，而且MQ对于扮演两点之间的消息的可靠的到达上还是起到了很大的作用的，近一两年来EAI开始从炒作进入做实事的阶段，大厂商们也开始推广新的产品来实现应用连接，象IBM的MB、BEA的Service Bus，这都是开始从应用层面考虑对于应用连接的实现的，但是否基于这些产品就真的可以实现呢，仍然是存在着巨大的疑问的，而数据传输时采用怎么样的数据标准是纯粹的应用领域的需求，中间件产品能否很好的支持这个也是一个非常重要的问题。<br />根据IBM对于应用连接的定义，可以看出，上面的技术实现的描述只是探讨了对于通过 HUB 或总线架构，实现应用与应用之间的连接，完成相关的数据路由，但对于数据转换这块还没探讨，数据到了接收的应用后，如何转换为符合该应用的数据结构呢，这是数据转换所需要做的事情，数据转换这块目前发展的已经较为成熟了，各种图形化的非常好用的数据转换工具已经出现。<br />根据这样的技术实现的描述，可以看到在应用连接的技术实现上应用级别的数据传输这块仍然是EAI领域的一个产品的争夺点，而如何实现好数据传输这块则需要依据丰富的EAI类项目的经验才行。
</div>

我记得原来WebMethods的产品中是不带消息中间件的吧？现在有了？

ESB的四个特征：

1. 使用消息中间件的异步消息传递。
2. 使用 XML 作为数据格式。
3. 用XSLT做数据格式转换。
4. 基于消息的路由。

至少这个Sonic的观点。好像很少有人提到Sonic啊。

你说的第一条不够全面, 不一定要依赖消息中间件来将应用服务事件暴露在ESB上. 也可以是基于File,Db,FTP等的适配器,或者是webservice.

不矛盾啊。应用接适配器，适配器接MOM。