我们定义了三个通道、四个组件。通过这样设计构成解决方案的组件，我们能让这些组件在其它集成解决方案中可以重用。集成流程不仅仅限于此示例。我们可能会在更复杂的集成中重用转换器、过滤器，甚至是服务催化器。唯一需要重构的是Spring Integration XML文件。有很多可能性。一个好的ESB应该做到：尽可能晚地重构流程设计和配置。
这里我们很容易就能想象到可以在什么地方采用该解决方案。下面是一些可能的补充。
对于某些审计工作流，使用jBPM（[12]）对系统增加支持。假设我们想在解决方案中添加业务流程管理（BPM），比如在消息传入时，以某种工作队列的分类存储该消息，以便编辑器进行核准。编辑过程可以处理得跟工作流引擎内部要求的一样。最终的博客内容核准后，编辑器把定稿发送到同样的电子邮件地址，带着某种关键字或识别出能用作相关ID的关键字。相关ID可用来让集成解决方案继续进行，主要表现在更新的条目。见[13]。
使用Spring Integration“组播”博客。当然，博客已经发布了。但还有一个问题，用旧的哲学问题来描述再合适不过了：“如果在woods中RSS订阅已经更新了，而没有人轮询到它，那博客算真正更新了吗？”呃，也许我只是讲了大概的意思！也可以通过Twitter传播博客标题，可以使用接收者列表模式（[16]）通知博客聚合器（[14]、[15]等）。
更新过滤器例子来验证某种真正授权的服务。也许能使用LDAP或Spring安全。
除了简单的电子邮件之外，多样化对发布的支持。FTP、 WebDav、文件系统（在源码中，电子邮件适配器的下面注释了一个简单的文件目录适配器配置）等都是可行的输入类型。更先进的例子则可以从移动客户端发送SMS消息。（当然，我不确定有多少人用他们的手机写博客。你永远也不会知道。不过只有一种方式能找到答案。）目前还没有对此的支持，但阅读了 Spring Integration的源码后会发现，很容易构建自己的适配器。你可以使用SMSLib[17]类似的库。
Spring Integration的不足之处Spring Integration是全新且强大的。你可以对其背后的SpringSource的价值及其自身的不断发展抱有信心。但这并不意味着它是完美的——它离完美还远着哩！应用集成不是一个新的领域，考虑解决方案和架构已经有数十年。应用集成的一些用法按惯例包含了重量级的适配器，比如那些与SAP集成的集成方法或JDEdwards OneWorld。Spring Integration不能直接支持这些具体情况。
尽管Spring Integration支持大量开箱即用的功能，但它对一些典型的适配器缺少支持，比如SFTP、HTTPS或AS2。目前，一些专有的解决方案能更好地支持这些需求。有些解决方案非常昂贵，所以你可以为Spring Integration试着改造第三方库、编写自己的适配器。如果你有兴趣，你会因为为Spring Integration编写适配器相当简单而感到惊喜。你要想开始创建解决方案，只需要看看jSch[18]、Jakarta Commons VFS[19]或Jakarta Commons Net [20]。
最终，Spring Integration可能并不是你现在最佳的解决方案。如果不是，请不要担心。你在本文中学到的东西也能应用在其他方案中。来吧，集成！
结论Spring Integration是一个干净、简练的EAI手段，也是很好的ESB产品替代者。现在的ESB方案沉重且很难引入到一些环境中。Spring Integration则是一个功能强大、低摩擦的替代方案，它能温和地解决一些最复杂的集成问题。