This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have been closely observing the Service Oriented Integration space in Java world and hence we have been dealing with the following frameworks:
Amongst them, the first three are related to Java Business Integration (JBI) in some way and open source. The extend to which these three frameworks support JBI are varied, and let me explain a bit on that.
ServiceMix http://servicemix.apache.org Compared to Mule, the major difference for ServiceMix is its architectural design, which is fundamentally based on the Java Business Integration (JBI) standard.
Mule http://mule.codehaus.org/display/MULE/Overview Mule and JBI have some overlap in the problems they solve but under the covers they do it in different ways. JBI is XML and WSDL centric where as Mule makes no assumptions about the message type. JBI uses a notion of Message Exchanges and a Normalized Message to communicate between components, where as Mule use a "POJO / Endpoint" architecture. JBI is a service container whereas mule is more of a ubiquitous messaging fabric that goes beyond integration to provide a solutions for translating, monitoring, routing and orchestrating all type of information around the organization.
As you have already noticed, the book is on JBI and an open source implementation for that. JBI as a technology and as an API is relatively new, but is very promising on SOA and integration point of view. There are no other books available on JBI at present. Moreover, we wanted to create a book for developers. This means, readers need to understand JBI API, then use an implementation and try out things at code level. Obviously we can use Mule or ServiceMix for that. Now, as we discussed above, ServiceMix is built from the ground up on JBI principles, patterns and abstractions rather than tacking JBI onto the side of a quite different model. This is the main reason why we chose ServiceMix.