2

您好通过了 Gregor Hohpe 和 Bobby Woolf 的企业集成模式。

http://www.eaipatterns.com/toc.html 我还了解了 Camel 和 Mule 对这些集成模式的遵守情况——

http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule

http://camel.apache.org/enterprise-integration-patterns.html

我看到 Mule 和 Camel 都允许通过 SOAP 或 REST 等 Web 服务部署和访问应用程序，SOAP 更像 RPC 风格。它们允许使用 CXF 和 Jersey 等开源实用程序进行大规模集成支持。事实上，Mule 还支持 RMI 端点——这也将提供远程方法调用能力，这是一种被广泛接受的集成形式。我了解 ESB 是围绕消息总线构建的，并额外支持其他协议，但是 ESB 仅符合 EIP，而 EIP 不仅仅是 ESB。

问题是为什么 SOAP/REST 或它们的传输协议不被视为“集成样式”，而企业集成又为何如此“面向消息”？

与设计这些模式但试图理解集成模式不平衡的信息本质的伟大思想相比，我是一个新手。我承认这不是堆栈溢出的 QnA 格式，但会要求 Mods 将其保持一段时间，以便人们可以分享他们的意见。

4

1 回答 1

1

至于 SOAP，它将把它放在集成样式“远程过程调用”下，因为它几乎是 SOAP 在现实中实现的（我不会考虑这里的 SOAP over JMS 混合体，它有可能将 RPC 与消息传递混合......） .

REST 在接口方面与 SOAP 非常不同，因为它是资源驱动的，而不是服务驱动的。我会将它归为“RPC”样式，因为它只是同步 RPC 调用的另一种格式。

但是，对于特定消息模式实现的 EIP 集成样式，我不会在理论上投入太多精力。

而是查看手头的特定场景，并使用 EIP 为您的特定集成建模。

我已经看到了文件传输的集成，它们在现实中实现了 RPC 模式或 SOAP 服务，在现实中实现了消息传递（尽管我真的不建议这样做）。

一个具体的例子：考虑一个专门的文件上传服务的使用，它碰巧是使用 SOAP 技术构建的，它将一个 CSV 文件上传到服务器上的文件区域，从那里它被其他一些系统拾取。我会在高层次上称这个基于文件的集成。

另一个例子是消息系统有时是使用共享数据库实现的。使用它们的集成方式仍然是消息传递，而不是“共享数据库”。

考虑一下您的集成应该如何在高层次上工作，然后应用各种协议来完成繁重的工作。

于 2013-03-04T15:57:34.210 回答