Burton says Mule ESB needs more SOA capability |
 |
By Rich Seeley, News Writer
27 Feb 2008 | SearchSOA.com |
|
|
The open source enterprise service bus (ESB) from MuleSource Inc. is well suited for straightforward integration projects, but it is not ready for multi-component service-oriented architecture (SOA) implementations, according to an "In-depth Product Profile" published this week by Burton Group Inc.
|
|
|
|
|
To effectively adopt Mule, teams should contain Java-centric and middleware-savvy development experts.
Chris Haddad
Report Author, Burton Group Inc.
|
|
|
|
|
|
|
|
|
|
While the 16-page report, "Mule ESB: A Polished-Metal Ride", sees Mule as a middle of the road option, it also lists "bottom-line assessment constraints," including that it is best used where "deployment of other service-oriented architecture infrastructure components is minimal."
Asked for the reason behind this caveat, Chris Haddad, the author of the report, explained, "Infrastructure products created by other vendors currently don't integrate directly with Mule ESB. For example, Web service management, XML gateway and registry products do not yet directly integrate with Mule. An organization will be required to front-end Mule with the complementary product using a proxy pattern or perform custom integration. The situation leads us to conclude that it is easiest to chose and deploy Mule ESB when integration with other vendor's infrastructure components is not required."
One of the themes throughout the report is that the Mule ESB will take some programming effort, but that if SOA developers are willing to do the work, it offers benefits.
"An organization will still gain benefit by deploying Mule, but it may be harder to address service monitoring, administration, contract management, and security policies in a holistic fashion," Haddad said. He added that MuleSource is addressing these issues by building out their own infrastructure stack.
As the report's title suggests, the Mule ESB is not the luxury BMW type product, but it isn't a dune buggy either. Haddad offered a definition of the "polished metal ride" simile of the title, which indicates the middle of the road status of the Mule ESB. "Polished-metal" is a step up from "bare-metal," he explained. "Ride" refers to the feel. A dune buggy would be bare metal, a race car polished metal and a luxury sports car full metal.
It's like you want a Ferrari, but what you can afford is a Toyota Corolla, and it gets you around town just fine.
"The product is a 'good enough,' no frills option that is not cluttered with superfluous features," Haddad writes in the report. "Mule will appeal to organizations looking for a basic, streamlined ESB without a lot of bells and whistles."
The strength of the Mule ESB is its "open source heritage" and the community that supports it, the Burton report states. The best implementation of it is "as a lightweight mediation component where protocol bridging, routing, and transformations are used to loosely couple service consumers and providers."
Haddad also praises it because its "pluggable architecture and extension frameworks enable the solution to be customized and extended to fit within any environment." Mule's embrace of the Common Public Attribution License (CPAL) version 1.0 makes distribution and customization friendly, he added.
That fact that it is not a walk in the park for coders is one of the key weaknesses Burton finds in the Mule ESB.
"Mule's development and management tooling is primitive and a work in progress," Haddad writes. "Developers can expect to build services by hand coding XML configuration files and extending Mule's base classes. To effectively adopt Mule, teams should contain Java-centric and middleware-savvy development experts."
Burton sees MuleSource as having a "limited window of opportunity" to become a player amidst what it calls the "Java super platform vendors" – IBM, Oracle Corp. and BEA Systems Inc., now being acquired by Oracle. It also faces competition from the other commercial open source vendors led by the JBoss division of Red Hat Inc., Sun Microsystems Inc. and Iona Technologies Inc., which has recently been put up for sale.
To meet that competition, MuleSource will need to develop a graphical model-driven developer workbench, a declarative framework and a full-featured repository, Haddad said. The company has the resources to do this, but not much time, he concludes.
|
|
|
|
