There are a few myths about Synapse and the WSO2 ESB I'd like to address. Its amazing they still come up.
Not an ESB?
The first and oldest myth is that Synapse is not an ESB. This dates back to the initial creation of the project - before there was even any code! Dave Chappell was at Sonic at the time and he said "This project is related to ESB , but it is not in itself an ESB".
Well, firstly, since at that time Sonic was the ESB leader, he would say that! Secondly, this was purely theoretical - no code had been written at that point. While I love the internet's ability to archive everything for years, to quote this several years later (like the ServiceMix guys do here: http://servicemix.apache.org/how-does-servicemix-compare-to-synapse.html) is disingenuous to say the least.
The fact is that Synapse - both as a pure Apache project and when packaged as the runtime engine of the WSO2 ESB is an ESB. Rather than argue about the definition of an ESB, it would be simpler to describe a few of the many usecases it is in production for:
* Getting the latest trades from a legacy financial system and reporting them to third-parties to meet regulatory requirements.
* Linking an SAP/R3 system with a .NET-based Point-of-Sale (POS) system in 40+ retails stores to distribute the latest price updates.
* Integrating between BMC Remedy, Salesforce and Peoplesoft.
* Providing a full SOA bus for a telecom operator linking to provide a common fabric for payment services, SMS top up and other integrations.
* Lightweight Service Orchestration (what we call Service Chaining) - providing simple non-persistent flows across multiple services.
* Integrating FIX messaging to existing systems.
* etc etc
In addition, the beauty of the Synapse ESB (and WSO2 ESB) is that it can also provide very high performance lightweight routing, load-balancing, failover and security management, so it is often used for high throughput scenarios as well - for example at eBay where it handles well over 1bn request/response interactions/day.
Synapse (and WSO2 ESB) only support SOAP or translate every message into SOAP
This is also a complete myth. The WSO2 ESB has a very effective model for dealing with content that only parses the content as needed. This model is based on the concept of a message formatter and builder. These objects handle the internal representation of content and are very flexible. For example, the normal approach to handling non-XML data is to keep it as a binary stream. In addition, a new transport in the WSO2 ESB (the Passthru transport) supports even higher performance routing of messages where the message body is simply passed from one HTTP endpoint to the next, while still supporting useful functions like header-based routing, authentication and authorization, logging, throttling and cacheing.
For XML data, we have an internal model that unifies SOAP and non-SOAP. What this means is that for non-SOAP payloads, there are two extra objects in memory that represent the envelope and body. This makes it very easy (and performant) to handle scenarios like taking the SOAP body and publishing it (without the SOAP wrapper) onto a JMS queue.
Because the XML object model we use (Apache Axiom) supports streaming (via StAX), the message is only built into a tree if a mediator such as the XSLT transform requests it.
I think this is where the mistaken belief lies. This is a bit like Heisenberg's Uncertainty Principle! The act of observing a quantum level action affects the action. Similarly, if you examine the message, then if you ask for it as SOAP, we will build it into a SOAP message and give it to you. Of course that doesn't mean it was a SOAP message until you asked for it as SOAP. If you were to ask for the message as pure XML then you would get it as a pure XML element. In both cases it remains as a binary stream until the point you ask for the message. If you simply route the message out to another system, it will not have been converted to or from anything: Synapse will simply stream the message through and out to the target.
I hope that this clears up these two myths!
Not an ESB?
The first and oldest myth is that Synapse is not an ESB. This dates back to the initial creation of the project - before there was even any code! Dave Chappell was at Sonic at the time and he said "This project is related to ESB , but it is not in itself an ESB".
Well, firstly, since at that time Sonic was the ESB leader, he would say that! Secondly, this was purely theoretical - no code had been written at that point. While I love the internet's ability to archive everything for years, to quote this several years later (like the ServiceMix guys do here: http://servicemix.apache.org/how-does-servicemix-compare-to-synapse.html) is disingenuous to say the least.
The fact is that Synapse - both as a pure Apache project and when packaged as the runtime engine of the WSO2 ESB is an ESB. Rather than argue about the definition of an ESB, it would be simpler to describe a few of the many usecases it is in production for:
* Getting the latest trades from a legacy financial system and reporting them to third-parties to meet regulatory requirements.
* Linking an SAP/R3 system with a .NET-based Point-of-Sale (POS) system in 40+ retails stores to distribute the latest price updates.
* Integrating between BMC Remedy, Salesforce and Peoplesoft.
* Providing a full SOA bus for a telecom operator linking to provide a common fabric for payment services, SMS top up and other integrations.
* Lightweight Service Orchestration (what we call Service Chaining) - providing simple non-persistent flows across multiple services.
* Integrating FIX messaging to existing systems.
* etc etc
In addition, the beauty of the Synapse ESB (and WSO2 ESB) is that it can also provide very high performance lightweight routing, load-balancing, failover and security management, so it is often used for high throughput scenarios as well - for example at eBay where it handles well over 1bn request/response interactions/day.
Synapse (and WSO2 ESB) only support SOAP or translate every message into SOAP
This is also a complete myth. The WSO2 ESB has a very effective model for dealing with content that only parses the content as needed. This model is based on the concept of a message formatter and builder. These objects handle the internal representation of content and are very flexible. For example, the normal approach to handling non-XML data is to keep it as a binary stream. In addition, a new transport in the WSO2 ESB (the Passthru transport) supports even higher performance routing of messages where the message body is simply passed from one HTTP endpoint to the next, while still supporting useful functions like header-based routing, authentication and authorization, logging, throttling and cacheing.
For XML data, we have an internal model that unifies SOAP and non-SOAP. What this means is that for non-SOAP payloads, there are two extra objects in memory that represent the envelope and body. This makes it very easy (and performant) to handle scenarios like taking the SOAP body and publishing it (without the SOAP wrapper) onto a JMS queue.
Because the XML object model we use (Apache Axiom) supports streaming (via StAX), the message is only built into a tree if a mediator such as the XSLT transform requests it.
I think this is where the mistaken belief lies. This is a bit like Heisenberg's Uncertainty Principle! The act of observing a quantum level action affects the action. Similarly, if you examine the message, then if you ask for it as SOAP, we will build it into a SOAP message and give it to you. Of course that doesn't mean it was a SOAP message until you asked for it as SOAP. If you were to ask for the message as pure XML then you would get it as a pure XML element. In both cases it remains as a binary stream until the point you ask for the message. If you simply route the message out to another system, it will not have been converted to or from anything: Synapse will simply stream the message through and out to the target.
I hope that this clears up these two myths!
Besides the fact what I think of the WSO2 ESB, I think what you just described is typical behavior of companies or people perceiving the success of WSO2 as threat for their own. Instead of showing why their product/project is to be seen as superior to another, they start spreading myths and lies about their competition. I think that is quite childish. It actually can have an effect opposite of the intention. Anyway, if one is wondering if the WSO2 ESB really is an ESB: read the documentation. I know it is. I have also worked with so-called ESBs of other vendors, and if their products are considered ESBs, then the WSO2 ESB is the ultimate ESB.
ReplyDeleteThanks Peter.
ReplyDeleteThere is also a nice followup from Hiranya here:
http://techfeast-hiranya.blogspot.co.uk/2012/09/busting-synapse-and-wso2-esb-myths.html
I really love the Heisenberg analogy. Absolutely the right way to handle this and think about it. In fact it actually makes you rethink the uncertainty principle and wonder if that's what's going on there. Is nature transporting around information and when we observe it we ask for it in one form or another and nature complies by giving us what appears as duality.
ReplyDelete