探讨EAI中的应用连接

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

评论

11 楼 Sayor 2006-10-13  

其实在ESB这个领域应该说有两种不同类型的产品, 一种是面向服务的另外一种是面向消息的也就是你说的MOM. Sonic 和 Fiorano 的产品就是基于MOM的实现. 这类ESB系统的优点就是消息传递的质量和异步的消息传递.
但是却也有很多的缺陷.

另一类的ESB的实现则是基于服务的实现, 代表厂商有BEA,IBM,ORACLE等.

这里有篇文章比较了两类产品,可以参考一下: http://www.capeclear.com/technology/messaging.shtml

10 楼 BirdGu 2006-10-13  

Sayor 写道

BirdGu 写道

Sayor 写道

BirdGu 写道

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

ESB的四个特征：

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

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

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

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

没有说你说的不对, 只是除了MOM之外还有接在其他地方的适配器.

我理解ESB中，MOM和适配器的作用与地位是不一样的。MOM就是总线，适配器是插在总线上的。

9 楼 Sayor 2006-10-13  

BirdGu 写道

Sayor 写道

BirdGu 写道

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

ESB的四个特征：

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

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

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

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

没有说你说的不对, 只是除了MOM之外还有接在其他地方的适配器.

8 楼 BirdGu 2006-10-13  

Sayor 写道

BirdGu 写道

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

ESB的四个特征：

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

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

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

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

7 楼 Sayor 2006-10-13  

BirdGu 写道

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

ESB的四个特征：

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

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

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

6 楼 BirdGu 2006-10-13  

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

ESB的四个特征：

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

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

5 楼 Sayor 2006-10-13  

BlueDavy 写道

<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>

lz所说的应用级别的数据传输是否指得是获取某一应用的数据而进行的数据传输? 而非SERVICE BUS或者data hub内的数据传输?

4 楼 stone 2006-10-13  

对于soa的架构，我认为他本身就是eai的产物。soa中的s就是eai的工作。

3 楼 stone 2006-10-13  

我觉得应用连接应该从连接的角度和应用的层面进行划分，
在进行EAI的过程中，对于分层的架构，可以从业务层面和数据层面进行连接。
1。业务层面
比如lotus这样的应用，他本身对外暴露了一些接口供外界调用，如果这些接口满足eai的需求，那OK，使用这些接口就可以了。
还有一些标准的组件，比如ejb和com等，本身比较独立，同样如果他们提供的功能满足需求，那为什么不直接使用它们呢？

2。数据层面

对数据层面的连接，这是没有办法的办法，同样也是业界中最普遍的实施eai的方法和手段，应用没有提供服务给你,:(

在数据层面的连接上，可以采用类似mq的机制，结合数据库的触发器和扩展的业务逻辑，实现数据交换，实施eai。

2 楼 kj23 2006-10-12  

我曾学习过webmethods，一个比较成熟的EAI产品，则是采用了Broker中心文件发布订阅机制，采用xml或行业文件标准来进行数据传输。

1 楼 jerry.li 2006-10-12  

相比IBM，Webmethods 提供的方案好像更简洁。