Open-Source ESBs in Action
is a comprehensive look at the leading Enterprise Service Bus open-source products and how they are applied in the enterprise. Tijs Rademakers and Jos Dirksen offer a book overview and insights into its contents, including:
* ESBs covered in their research
* Why they chose Mule and ServiceMix as their leading examples
* The advantages and disadvantages of using technology neutral and JBI-based ESBs
* Which ESB is better for legacy system integration?
* What are some compelling reasons to ditch commercial ESBs in favour of Mule or ServiceMix?
Playback time: 10'11"
(Click here if you can't see the video
Tijs Rademakers is a software architect with more than six years of experience in designing and developing Java and EE applications. He works for Atos Origin, a large European system integrator, where he is responsible for SOA and BPM services and knowledge development. Tijs has designed and implemented large process- and application-integration solutions, primarily focused on open standards.
Jos Dirksen has been working with Java and J2EE applications for more than six years as a software architect. The last couple of years, his focus topics have been open source, security, and quality. He has worked with various open source and commercial integration solutions, mostly in the government and the healthcare areas.
The title should be "Open-Source ESBs in Action".
damn..hit Post instead of Preview..... As I was saying, The book is about Mule and ServiceMix and not OpenESB
You're right . . . it's fixed.
I went though the Table of contents , but I did not find that much of information about Apache Synapse , though it is also an open source ESB. Any reason ?
I went though the Table of contents , but I did not find that much of information about Apache Synapse , though it is also an open source ESB. Any reason?
Synapse was featured very prominently in earlier versions of the book but was removed, probably because of the overboarding complexity. As reviewer from early on I was not too happy about that but can understand that the book needs to be accessible and simply must not exceed a certain page count or complexity to remain accessible to certain target groups.
you can download a sample chapter,
which states the reasons.
We actually do talk about Apache Synapse in chapter 5. We explain the architecture of Synapse and we show an example of how to implement validation in Apache Synapse.
In an earlier version of the book Apache Synapse was the second ESB that we discussed, with lots of examples. But eventually we realized that discussing a Java based ESB like Mule and a web service based ESB like Apache Synpase is too much for one book. So we decided to go for a custom architecture ESB, Mule, and a JBI based ESB, ServiceMix. We still like Apache Synapse very much though :-)
Author of Open Source ESBs in Action
A new book by Jeff Davis covers Synapse in a lot of detail, and also mixes in things like jBPM, complex event processing (Esper), rules, and more. It has examples for Tuscany, ServiceMix and some more.
The book info can be found here: http://www.manning.com/davis/
With Jeff's book and the Open Source ESB's In Action you have every major ESB covered.
We are implementing mule in our company these days and this book, along with mule in action, has been a great help. I would highly recommend this book to anyone interested in Mule or servicemix
...but as you mention, the book was started over a year ago and at that point Mule & ServiceMix were probably the most mature products available. I'd argue the point that OpenESB (and the forthcoming commercially supported GlassFish ESB) are at least their equal.
You make a valid point about what commercial products offer over-and-above open source ESBs - the most important of which is support.
GlassFish ESB gives the best of both worlds - built on open source with a high community involvement and commercially supported from a large player like Sun. You're also getting tooling (notably lacking in other open source ESBs) and an industry leading application server in GlassFish.
We evaluated a couple of ESB including the very slow and very expensive Process Server (slow and expensive) but only OpenESB with the recent commercial support offering came close to satisfying most of our requirements (BTW. I have been a very active Mule user in the past).
If only SCA integration was on the roadmap.........
I am interested in the last comment on SCA. Do folks believe this is anything more than another vendor driven standard to ensure that they can retain high-prices for their products by adding mystique ... what is it that attracts folks to SCA?
One can of course argue that the use of open standards like JBI or SCA (although SCA is not yet a standard yet) in integration products is benificial. One of the good things is that standardization prevents us from learning new architectures time and time again. But of course a standard comes with complexity and sometimes lack of flexibility. But I really can't understand your comment about adding mystique by supporting an open standard. An open standard is open to everyone, so you can read the specification etc. If a product implements its own proprietary standard, then it's adding mystique.
Yup, I worded it badly and maybe I am geting skeptical in my ol' age :) But when I see IBM and others defining a new "standard" I ask myself do I need it and is it for me or is it for them?
My badly worded question was meant to pose: are the benefits of SCA worth all the hype? However, making the question more concrete and relevant to this thread, do folks here think that those involved in Mulesource, ServixMix, OpenESB, etc should spend effort following SCA or just innovate and ignore it?
Good question! I think the real benefit of SCA is the standardization of the service component model. ServiceMix and OpenESB already support JBI and there has been a lot of debate about combining JBI and SCA already. I did a technical talk at JavaOne this year about how to combine JBI and SCA with an example implementation of ServiceMix and Tuscany (http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5870&yr=2008&track=soa
For Mule, the support for SCA has also been investigated and it's been pretty quite since then (http://www.mulesource.org/display/SCA/Home
). I think the chance we'll see support for SCA with ServiceMix or OpenESB is higher than with Mule.
is one of the most complete OSS SCA implementation out there. It is currently hosted at Codehaus, and recently had the 0.6.5 release. Fabric3 currently supports implementation types for,
And bindings for
3. Oracle AQ
On top of the Java programming model and SCA assembly model, Fabric3 fully supports SCA policies. It also has a number of additional value adds including JPA support, host integration with a number of JEE servers etc. Another key value add for Fabric3 is heterogeneous federated provisioning of service infrastructures based on policies.
We have been suing Fabric3 at Vocalink
for a number of high profile, mission critical, high volume transaction processing systems in the finance sector.
This is an interview
on the value proposition of SCA.
Lead Technologist: VocaLink
Founding Member: Fabric3
Hi AD, do you mean WebSphere Process Server? Which requirements did OpenESB meet that other ESBs including WebSphere Process Server didn't meet? I've been working with WebSphere Process Server quite extensively, and on of the nice things is that it does support SCA, and provides nice tool support for this (although it doesn't yet follow the SCA 1.0 specification). If you really want SCA support, there is Apache Tuscany. What's missing in Apache Tuscany to your opinion?
The Problem with Websphere Process Server is that it is very slow and very expensive (if you add the WID cost too)
I agree on the expenses. The performance of WebSphere Process Server can of course be improved with clustering and/or addtional hardware power. But then the expenses grow and grow :-)
What I find striking is that open source BPM products like jBPM offer similar functionality with more flexibility. Of course jBPM is focused on jPDL and less on WS-BPEL (although there is an implementation available) and WPS also supports SCA as an open standard, so support for open standards is the downside. I've worked with both products(jBPM and WPS), but I really like the flexibility and the ease of development of jBPM.
We are absolutely seeing great progress in the OpenESB project and the start of the GlassFish ESB with support from SUN is nice. But what about for example routing support in GlassFish ESB. I saw there is a Camel SE added to OpenESB, but I didn't see this component in the supported list of GlassFish ESB. Will Camel SE eventually be supported? Are there other routing capabilities in GlassFish ESB, besides the BPEL SE?
Glad to hear you like the way OpenESB / GlassFish ESB is going. Hope to see some examples of its use on your website http://www.esbinaction.com/
in the future.
As for Camel-SE - it won't be supported in the upcoming GlassFish ESB release, it will definitely be supported at some stage, probably in the first GlassFish ESB update release. However I would think for the majority of people it is definitely usable at the moment, after all, most of the work is done in Camel, not in the SE.
As for other means of routing outside of BPEL - well, if you need content-based routing you could do this now in the Camel-SE, you could also do it in an EJB using the JavaEE-SE, and even in the upcoming POJO-SE. If you want simple proxying, you can connect BC to BC with no SE inbetween or use the XSLT-SE.
Lots of options.
You will definitely see examples about OpenESB / GlassFish ESB appearing on out website in the near future. If people are willing to participate in providing examples for OpenESB or any other open source ESB, please let me know.
The Camel SE is definitely an enhancement to the component stack. I've used the Camel SE provided by ServiceMix, and it works great.
About the components that can be used for routing, I don't find he JavaEE-SE and POJO-SE real options for implementing routing functionality. Of course you can implement routing functionality in plain Java, but I would expect some specific routing functionality provided by the ESB framework. And of course you can connect a BC to another BC, but that's not what routing is about in most cases. To exaggerate a little bit: in the first version of GlassFish ESB you'll have to implement your routing functionality in BPEL or in plain Java. Is the support for specific routing functionality (for example the Hohpe and Woolf routing patterns) overrated to your opinion?
Great article guys, I haven't looked into the book but will certainly read through it with interest.
I'm currently implementing a FIX broker solution using and well-known FIX vendor integrated with an Oracle (formally Weblogic) Aqualogic instance. I'm particularly interested in options for a suitable FIX Implementation and transport layer as we've experienced issues with poor JMS consumption rates from remote queues. Apart from using FIX itself as the internal transport protocol...can you recommend any others that would realize +8000 msg/sec capacities?
I would also like your opinion on near-realtime log file replication...I've seen FIX and JMX implementations into a C#.net thick client but again...am shopping around.
I had been practicing Judo for quite sometime now. It has helped