我阅读了Gregor Hohpe和Bobby Woolf的《企业集成模式》。
http://www.eaipatterns.com/toc.html我还研究了Camel和Mule对这些集成模式的遵从性-
http://www.mulesoft.org/documentation/display/current/Understanding +企业+集成模式+使用+ 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格式，但会要求mod将其保留一段时间，以便人们可以分享他们的意见。
至于SOAP，它将把它置于集成风格"远程过程调用"之下，因为它实际上与SOAP实现的非常相似(这里我不会考虑SOAP over JMS的混合，因为它可能将RPC与消息传递混合在一起…)。
在接口方面，REST与SOAP非常不同，因为它是资源驱动的，而不是服务驱动的。我宁愿把它归为"RPC"样式，因为它只是另一种格式的同步RPC调用。但是，我不会在理论上花费太多精力来讨论特定消息模式实现的EIP集成样式。
查看手头的特定场景，并使用EIP为您的特定集成建模。
我看到过文件传输的集成实际上实现了RPC模式，或者SOAP服务实际上实现了消息传递(尽管我不建议这样做)。
一个具体的例子:考虑使用专用的文件上传服务，该服务碰巧是使用SOAP技术构建的，它将CSV文件上传到服务器上的文件区域，然后由其他系统从中获取。我将把这种基于文件的高级集成称为
另一个例子是消息传递系统有时是使用共享数据库实现的。使用它们的集成风格仍然是消息传递，而不是"共享数据库"。
考虑您的集成应该如何在高层次上工作，然后应用各种协议来完成基本工作。