Following up from last weeks post on my first impressions of Mule Summit in San Francisco, I wanted to cover the major areas covered at the conference a little deeper. I will try not to regurgitate their marketing pitch, but offer my insight on why a certain feature would be beneficial of better than another solution.
The
Mule Summit presentations are available and can be accessed with username: Summit2010, password Summit2010.
Mule 3.0 PreviewMateo Amenta, Mulesource ESB Product Manager presented a preview of new features in Mule 3.0. The main objective of Mule 3.0 offered by Mateo was "simplification". I can certainly appreciate that. I have worked with the current 2.0 version and while I can say it is no more complicated than say working with Spring or any other XML driven configuration, it can a bit daunting to the novice. I am much more a fan of "convention over configuration", but that's another topic entirely and that is not the type of simplification Mule had in mind for 3.0 of their ESB product.
One area of simplification introduced in Mule ESB 3.0 relates to "Web Middleware", which was explained as light weight, cloud oriented and distributed. This is a new definition of the traditional ESB which was typically a central hub, usually running on "big iron" from a legacy vendor provider. The traditional ESB software suite usually consisted of numerous packages and modules that required extensive "carnal" knowledge of install, configure and develop against. Been there, done that.
One thing I like about Mule is you can just take the pieces you want and install, configure and deploy. You can start with the Community Edition (CE) and upgrade when you are ready. You can add HA or Mule MQ when and if you need it later. You don't need to buy the whole stack.
Another simplification feature touted in Mule was using
Java Domain Specific Languages (DSL) and XML Views. They didn't actually show how DSL was implemented in Mule, but they did demo some use of XML views. It does indeed reduce the verboseness of Mule XML configuration. I googled around XML Views and in and of themselves (outside of Mule) look intriguing.
Another feature added to Mule 3.0 was support for annotations, specifically support for
Google Guice. Reading over the specifics of Guice on Google's site does strongly suggest it would offer a more lightweith alternative to dependency injection (DI) using Spring. Guice might also offer supplement to lcfg.
Web Transports in MuleMule 3.0 will support Ajax transports and JSON and JAXB data bindings. This supports the movement towards HTTP clients as a common integration point to an organization's data services. Also to be supported is RESTPack integration using JAXRS, ATOM and RSS.
jBPM TransportOne of the non-core benefits of an open source ESB is support for long running processes/state engines that can handle business processes and choreography. I don't know much about jBPM, but what I gleamed from the brief overview at the Mule Summit and my own Googling, it seems promising.
Other Transport Honorable Mentions...XMPP - The chat protocol
WS-Security, SAML (single sign on) 1.1b via CXF
wss4j 1.5.8
Mule MQOne thing that really perked me up during the conference was the talk on Mule MQ. This is Mulesoft's message queue offering which complete obviously with IBM Websphere MQ and open source equivalent Active MQ. One claim by the Mulesoft guys is that Mule MQ is "Independently benchmarked as the fastest messaging product on the market."
They listed some bif financial houses that use Mule MQ and FX transactions. Which on the surface anyway would seem to be impressive since financial transactions are very demanding in terms of availability, robustness and reliability.
The Mule MQ Enterprise Manager looked pretty cool. It seemed to give much more monitoring information than what I am used to seeing from IBM MQ Explorer. For troubleshooting and diagnostics, it seems like it would be very useful.
The performance statistics presented were a comparison with Active MQ. Queue performance was about 2x for Mule MQ versus Active MQ. I would like to do a similar comparison with IBM MQ. I am hoping to get a hold of their test setup so I can compare with IBM MQ. Topics were even faster with publish and subscribe being about 4 times faster than Active MQ.
Another possible financial benefit of Mule MQ is that is is not licensed based on number of processors. I don't know how that compares with IBM's licensing for Websphere MQ but it would be something to look into further.
High Availability for MuleFor a messaging system, high availability is crucial. Specifically, any enterprise level messaging system must provide failover and uninterrupted processing of in-flight messages. Mule ESB 2.2 supports active-passive failover using shared state of cluster transport and cluster service.
Mule ESB also supports active/active HA. From what I could gather, it accomplishes this using SEDA (staged event-driven architecture) shared state, in memory queues. In Mule, this equates to the VM transport which is their internal, native transport mechanism. There was also talk of some kind of partnership with
Gigaspaces to achieve HA. I will look more into this.
A configuration that was presented being used at CIGNA, was an active/active (2 node) cluster of 2 Mule ESB instances running on one host with one MQ instance. This configuration is repeated on another host:
F5 Big IPHost 1 Host 2Mule 1 Mule 1Mule 2 Mule 2MQ MQThis setup is somewhat similar to configurations that I am familar with using IBM Websphere Message Broker and IBM MQ where you can have multiple broker instances shared on a single MQ instance and have a cluster of brokers.
GluOne surprise development from the Mule Summit which also got me excited was Glu. In particular, was the fact that Glu is a new open source project that can be used stand alone outside of Mule ESB. From their slide deck, here is how they describe Glu: "Framework to simply build integration resources"
Glu is RESTful providing a common interface for all HTTP enabled clients (Java, JS, Groovy, Ruby, Python, Perl, PHP, etc). From the looks of the sample code, it looks very "convention over configuration" like. The claims of ease of use and a common store for RESTful components causes me to want to investigate this more. It seems kind of too good to be true, but I am willing to see how far it goes in matching claims.
