title: Enterprise Integration Patterns and HTTP (SOAP/REST)
body: <p>Hi went through Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf.</p>
  
  <p><a href="http://www.eaipatterns.com/toc.html" rel="nofollow">http://www.eaipatterns.com/toc.html</a>
  I also went through Camel and Mule's compliance with these integration patterns -</p>
  
  <p><a href="http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule" rel="nofollow">http://www.mulesoft.org/documentation/display/current/Understanding+Enterprise+Integration+Patterns+Using+Mule</a></p>
  
  <p><a href="http://camel.apache.org/enterprise-integration-patterns.html" rel="nofollow">http://camel.apache.org/enterprise-integration-patterns.html</a></p>
  
  <p>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.</p>
  
  <p>Question is why SOAP/REST or their transport protocol not considered as "Integration Styles" and which is Enterprise Integration so "Message Oriented"? </p>
  
  <p>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.</p>