JavaOne 2008 struggles to retain its importance. Read my full report at:

http://www.theserverside.com/news/thread.tss?thread_id=49332

-Frank

I'll be giving a keynote talk on SOA Development In The Real World at TIBCO's user conference next week. This will be based on the work PushToTest did to surface the developer productivity and performance differences between TIBCO, BEA, Oracle, and IBM platforms for SOA development. All of the research is available under a free open-source license at http://soakit.pushtotest.com.

If you are attending TUCON then please let me know and I will be glad to meet with you personally.

-Frank

Mule makes an open-source Enterprise Service Bus (ESB) and SOA development platform. Held at the Hilton Hotel in San Francisco over 2 days, Mulecon attracted approximately 400 delegates, including Mule staff. I was very glad to go as the conference let me talk to several Mule ESB users. I had to do a fair amount of begging to get an invitation since PushToTest is the author of the SOA Knowledge Kit, a TIBCO commissioned comparison of commercial SOA/ESB development platforms. (PushToTest will be an exhibitor at TUCON later this month, and I might be in their keynote session.) Maybe someday I will be appointed an ambassador to something. :-)

The presentations varied between Mule staff talking about Mule and the product roadmap and customers talking about their use of Mule. The Mule staff seemed to be singing from the same songbook: Mule claims 13,000 deployments of Mule ESB, Mule 2.0 is not compatible with 1.4 but the migration should not be too difficult as the concepts are the same, Mule Enterprise Edition, Saturn and Mule HQ releases coming late this year.

A Room Full of Architects

It did not take long for me to realize that Mulecon delegates are mostly software architects. Typical questions I heard goes like this:

"Your company inherits a big bank and needs to decide between JMS and Advanced Message Queue Protocol (AMQP) for a universal protocol for your bank. Which would you pick?"

and

"How do you empirically come to a model that will let you uncover the performance characteristics and measurements?"

These are the kinds of discussions that make my wife immediately yawn and roll her eyes! Geeks, there's a lot of 'em in this room.

ESB, Grid, AMQP Approaches

Conversations about hub-and-spoke, virtual circuits, and bus architecture seem to be over. Just about everyone I met expects a heterogeneous architecture where parts of a system are hub-and-spoke and others are bus-based. Easy service interfaces now exist between each type of architecture using daemons and local brokers. Jahan Moreh, VP of Engineering at U1, had a very basic message "Provided the underlying products are good you won't have a problem."

Jahan was more sanguine about guaranteed deliver and performance. In essence "performance and guaranteed delivery are in conflict." Choose one but don't expect both. I very much want to do primary research to determine a standards way to profile performance in a guaranteed delivery setting. Hopefully one of our customers will commission a PushToTest study. (hint, hint.)

I learn about AMQP at Mulecon. AMQP is a protocol-level standards initiative to provide a messaging infrastructure. Jahan told me "AMQP tries to do something very important but may not be attainable. Because they are at the protocol level they may wind up being extensions on the side. I would bet on the JMS side."

POJOs Rule, But Where Is BPM?

Eugene Ciurana of LeapFrog gave a talk about LeapFrog's use of Mule. I just saw Eugene at TheServerSide.com Java Symposium in Las Vegas last week. Boy does Eugene get around!

LeapFrog is marketing a child's toy that features downloadable content – not bad for products that must cost less than a few dollars to manufacture! The backend system to support this effort uses ESB technology to provide flexibility to LeapFrog's software developers and reliability in operating the service and applications.

Many of the question-and-answer sessions at Mulecon include a question on Business Process Management (BPM) such as: "What are you doing for BPM in your architecture?" Eugene took one of these.

This question echoes what I had learned in Las Vegas: Java architects and developers are frustrated looking for Business Process Management (BPM) standards and tools. Brian Sletten's talk at TSSJS was titled "Avoiding ESBs" but could have been better described as "I'm sick and tired of waiting for vendors to give me a decent Business Process Management (BPM) platform!"

At Mulecon, Rory dela Pax of Biogen Idec, told me that "Mule is good at doing some workflow. But, all of us are struggling with BPM. We do a separation of skills strategy rather than overloading the ESB with these tasks."

Over the years I have seen most of the platform vendors try to provide the Java development community with set of products, best practices, framework, and code to implement applications that deliver business flows. I am specifically remembering the failures of JBI, JEMs, BPEL, SCA, and WS-*. None have come together to offer a standard. I sense a lot of anger and disappointment at all the failed attempts. Mostly disappointment from me.

Eugene answered the BPM question by telling the delegates that LeapFrog pushes all of its development to Plain Old Java Objects (POJOs.) They actively separate every application from each other. LeapFrog then uses Mule routers to define the inputs and outputs. Eugene said "We are not doing any transactional data at Leapfrog. Our support is for the toy devices." He added that Leapfrog has a separate side of the IT house for Oracle tools and BPEL.

Mule and Clustering

Rory dela Pax of Biogen Idec gave a brief talk on their migration from BEA WebLogic Integration (WLI) to Mule. The migration came about like many companies adopting an open-source project: A developer mentioned it during a water break conversation. The environment was ripe: Biogen Idec found WLI to be "a bit on the heavy side, unstable, and has not scaled well." They were also leery of the rumors of the Oracle buy-out since late 2006. They found that Mule has a one-for-one match in capabilities, plus they see Mule as lightweight, stable, and scalable.

I can understand lightweight and stable, but the scalability claim seemed to need some proof. Rory tells me they achieve scalability by using WebLogic Server (WLS) 8.1 SP6's clustering. They deploy their Mule application as a WAR file in a cluster of JVMs in WLS. There are no separate JVMs in their environment. I imagine the gaul the WLI product manager must feel at being swapped out. :-)

Still, there is a lot that Biogen Idec needs to learn about clustering. They still need to define the best way to cluster. Rory told the delegates "We don't know how to do that." They would like to define clustering methods in environments where message sizes grow larger. Right now their application uses simple verb+link combinations. The incoming request is to approve an invoice and the response contains a link to bring the user's browser into the application.

Rory told me some of the downsides to using this WLS clustering approach. For example, they use Quartz as a scheduler. In this WLS clustering set-up changing the Quartz schedules means redeploying the application to the cluster.

Moving Up To Mule 2.0

Mule 1.4 uses DTDs to define pretty much everything – settings, configuration, deployments. Mule 2.0 delivers XML Schema based configuration that leverages Spring's "Extensible XML Authoring." The result is less cumbersome class names because of namespace support. They are updating their Eclipse support to provide auto-completion and context-specific help. Mule 2.0 features transport-specific endpoints and connectors and now everything is done through typed properties. There is a lot of extensibility because each module/transport comes with its own schema. Mule 2.0 lets you implemtn your own schema too.

Some additional changes in Mule 2.0: CXF supercedes XFire (XFire is still available,) there is a new expression evaluator framework, streaming improvements, auto-transformation, and lots of bug fixes. Plus, Mule 2.0 has 30% more unit tests over 1.4. Mule uses Spring to implement Beans. Mule uses session and entity (data) beans inside the Mule container or through proxies to external data services.

Mulecon left me a few questions:

1. How important was the Spring-based approach to building services to Mule's popularity and success?
2. Is anyone, I mean anyone on Earth, using OpenESB from Sun? None of the Mule users had any experience with it.
3. How are Mule and Mule users testing Mule for scalability and performance? Mule 2 provides hundreds of unit tests but apparently no performance tests, at least none that I could find.
4. What are the tradeoffs of an ESB versus Gigispaces, Tangosol and other grid environments?

Mulecon impressed me with its quality presentations and delegates. I will keep it in mind when PushToTest does its first user conference, PTTCon, or PushCon, of TestCon, or who knows!?

-Frank