Enterprise Integration Patterns and HTTP (SOAP/REST)

Question

Hi went through Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.

http://www.eaipatterns.com/toc.html I also went through Camel and Mule's compliance with these integration patterns -

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

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

I see that both Mule and Camel allow applications to be deployed and accessed via webservices like SOAP or REST, SOAP being more RPC style. They allow massive integration support using opensource utilities like CXF and Jersey. In fact Mule also supports RMI endpoints - which will give remote method invokation capability as well which is a well-accepted form of Integration. I understands ESBs are built around a Message Bus with additional support for other protocols however ESBs only comply to EIP and EIP is not just ESBs.

Question is why SOAP/REST or their transport protocol not considered as "Integration Styles" and which is Enterprise Integration so "Message Oriented"?

I am a novice compared to the great minds which designed these patterns but trying to understand the lopsided message-y nature of Integration patterns. I admit it isn't quite the QnA format of stack overflow but will request Mods to keep it alive for a while so that people can share their opinions.

Answer 1

As for SOAP, it would put it under the Integration Style "Remote Procedure Invocation", since it's pretty much what SOAP implements in reality (I won't consider the SOAP over JMS hybrids here with a potential to mix RPC with Messaging..).

REST is, interface wise, very different from SOAP in that it's resource driven instead of service driven. I would non the less group it under the "RPC" style since it's just another format of syncrhonous RPC calls.

I would, however, not put too much effort in theory of what EIP integration style a specific message pattern implements.

Look at a specific scenario at hands instead and use the EIP to model your specific integration.

I've seen integrations of file transfers that in realtiy implemented RPC patterns or SOAP services that in reality implemented messaging (although I don't really recommend do this).

A concrete example: consider the usage of a dedicated file upload service, which happends to be built using SOAP technolgy, which uploads a CSV file to a file area on a server, from where it's picked up by some other system. I would call this file based integration on a high level.

Another example is that Messaging systems sometimes are implemented using a shared database. Still the integration style using them is messaging, not "Shared Database".

Think about how your integration should work on a high level, then apply the various protocols to do the grunt work.