The word Enterprise Service Bus means something different, when looking at ESB solutions in .NET and Java Open Source space.
In Java Space the ESB is responsible for message validation and routing. The ESB also maps application specific data models to a common domain model in order to have one domain language within the services. It also implements adapters that abstract different protocols and applications.
For the execution of the business process ESBs are bundeled with BPE servers that execute business process desciptions mostly based on BPEL (Business Process Execution Language).
In the .NET world the business process is at the heart of the ESB. In case of the three implementations mentioned here, it is implemented in code. The process there is implemented as a saga, that is used to store all necesarry data to execute the process. These implementations only implement asynchronous communication using Message Queues. All of them support MSMQ, but there are also other options.
Adapters and alike are not available so it is up to the implementor of the process to adapt the ESB to application specific protocols and data structures
So if you talk to somebody about a ESB you have to be careful if he is a .NET or a Java Guy
That is an interesting difference - allthough you have to agree that the JAVA world has the one and only correct insight into the topic. A bus is about transforming and routing messages - not about exectuing business processes.
ReplyDeleteThat might be good in theory, but the question is how well do these models fit in what we see out there.
ReplyDeleteNormally customers really don't care about about transforming and routing. They just want to get their jobs done. So its all about execution of business processes.
Just getting the job done, is what the .NET implementations are really good at, maybe without some of the bells and whistles you find in the implementations in the Java world.
In the end I guess its about needs of the customer