In-Depth

Middleware is in the Open, Finally

• By Alan Radding
• November 1, 2005

Maybe you can view it as some sort of perverse testament to the robustness of today's open-application environment, but application development and deployment has gotten very complicated. There are too many message protocols, data formats, component types, services and such for developers to manage in their heads, or on paper.

"Basically, I need to create assemblies of different components, and I need to do it in an open-source environment," says Mansour Raad, senior software architect at ESRI, a GIS systems company. Given the diversity of protocols and component types, what he needs is an enterprise service bus-something that will let him loosely couple disparate components independent of the underlying protocols. In short, he needs open-source middleware.

Open-source middleware demand
Raad isn't the only one. As open-source development expands and SOA gains traction, many more developers are looking to open-source middleware to expedite their development of increasingly complex applications. Those apps consist of diverse components and are aimed at facilitating the deployment of distributed apps across a variety of messaging infrastructures.

The open-source community, which has focused on development tools (such as Eclipse) for several years, finally has turned its attention to the middleware problem. Products such as Mule, which have quietly chugged along for several years, are finally attracting widespread attention. New middleware products including ServiceMix and ObjectWeb also are gaining traction.

Most recently, a consortium of proprietary middleware product vendors launched the Synapse initiative to create open-source middleware for SOA development and deployment. "Synapse is important because SOA is very complicated," says Robin Bloor, an analyst at Hurwitz and Associates, an IT research firm. "With SOA, you are trying to link a lot of heterogeneous stuff. Synapse will allow this to happen on the middleware level."

Until this recent flurry of activity, however, middleware for the open-source community mainly meant application servers, and open-source application servers usually meant JBoss. Today there are more open-source applications servers, such as JOnAS and ObjectWeb, although JBoss still dominates.

Open-source application server
At the base of any middleware stack, open source or proprietary, is the application server. An application server is considered middleware because its job is to connect things, particularly an application to its various clients. To do this, the application server makes transparent as much of the infrastructure as possible. With an application server in place, developers don't have to worry about differences in operating systems, backend databases and the host of other interfaces that would bog them down in myriad nitty-gritty details.

The difference between open-source application servers and conventional proprietary application servers from vendors including IBM and BEA Systems comes down to cost. Proprietary app servers can easily run into six figures, notes Pierre Fricke, director of product management for JBoss. Open-source application servers are free, with the creators relying on the sale of additional services and support for revenue. At this time, proprietary application servers also have more advanced enterprise features than their open-source counterparts, although the open-source communities are catching up.

The boss is in the house
JBoss is well established as the leading open-source application server, and according to BZ Research, the JBoss application server is the choice of 34.8 percent of enterprises that use application server technology, making it the most widely used application server in the industry. Its open-source pricing, no doubt, is what makes it so popular.

NLG, a cruise and travel wholesaler, deployed its first JBoss application server in 2003. At the time, it was deploying a new J2EE application to support a risky new venture. Given the already high risk, the company didn't want to further increase its exposure by licensing a costly proprietary application server when a suitable open-source alternative was readily available.

"We looked at proprietary application servers and EAI packages, but we didn't need that level of functionality," says Jamie Cash, VP of technology for NLG. "JBoss supports JMS, and that is all we needed." The company does custom development and integration with a handful of trading partners. Since its initial JBoss deployment, it implemented other JBoss application servers.

Today, its open-source development portfolio contains tools such as Ant, the Eclipse Java IDE; Cruise Control for automatic builds; CVS for version control; and Hibernate for run-time object/relational mapping. The company continues to use Oracle for its database, but is starting to explore the use of MySQL, an open-source relational database that debuted in its newest version this fall.

In what has to fall under the category of sleeping with the enemy, JBoss jumped into bed with Microsoft in September. The companies announced they would work together to boost the performance of JBoss products running on Windows. Analysts interpreted the arrangement as everything from an effort to co-op open-source, to co-opting JBoss, to a shared motivation to weaken IBM. Application developers shouldn't care what the motivation is as long as it improves the performance of their Java and open-source applications without compromising the open-source nature of the technology.

Enter the dragon
The open-source development community, like its proprietary counterpart, is looking to expand the middleware stack. JBoss announced its JBoss Enterprise Middleware System, its version of the open-source middleware stack, at the end of 2004. At that time, the stack consisted of the JBoss Application Server; Hibernate; Tomcat, the leading Web servlet engine in use; its JBoss jBPM, open-source workflow engine; the JBoss IDE based on Eclipse; JBoss Cache; JGroups, a toolkit for reliable multicast communications; and JBoss Portal, a content management system.

Since the initial JEMS announcement, JBoss introduced new portal functionality and says it will introduce messaging capabilities in 2006. "Our goal is to get to a JBoss enterprise service bus," Fricke says. That will require more than just Java messaging, however. JBoss will have to start handling data transformation and provide support for Web services and SOA.

Mule muscle
Across the industry, open-source communities are boosting the capabilities of their products. Open-source products like middleware typically are developed as projects of various communities. Apache is one of the largest communities, as is Eclipse.

SymphonySoft's Mule is another long-established, open-source middleware product that is ramping up some new initiatives. The developers describe Mule as a lightweight, messaging framework- lightweight meaning it does not consume much system resources. Mule acts like a highly distributable object broker that handles interactions with other applications, using a variety of communications technologies, including JMS, HTTP, e-mail and XML-RPC.

The object of Mule, according to creator Ross Mason, is to "free the developer from worrying about the underlying protocols and just concentrate on the business functionality."

Mule manages all the interactions between application components, whether they are local or over the Internet, and is agnostic to the underlying transport in use. It also performs transformations, orchestrates events around different services, cleanly takes care of error handling and exceptions, and can be used in conjunction with existing frameworks such as Spring, Plexus and Picocontainer.

Essentially, Mule is an ESB, especially when combined with a popular framework such as Spring. Early this fall, the organization released Mule 1.1, which adds a number of the latest sexy features, including JBI integration and BPEL-support, along with new EJB and RMI features and improved SOAP features.

The Java Business Integration support means the Mule transports, components and transformer can be used inside any JBI-compliant container, and that Mule components can interact with JBI containers using the new JBI bindings. The Business Process Execution Language for Web services capability consists of integration with FiveSight's PXE WSBPEL execution engine.

"Mule has made my life really easy," says ESRI's Raad. "Mule does not force me to implement a specific interface definition. I can take a Java object, SOAP, or anything else and just hook it into the bus," he explains.

Although the new JBI capability is getting a lot of attention, Raad is less thrilled with that. "JBI is trying to standardize things so it forces a specific interface definition," Raad notes. "Mule is so simple. I can take POJOs [plain old Java objects] and just plug them into the Mule bus," he adds.

ESRI uses SOAP on the front end. With Mule, Raad can connect a POJO to the front end without writing any code. "I just configure Mule, and SOAP will be enabled automatically."

When he has to scale the system, all he has to do is add another application server, pop it on the network, and through Mule configurations, redirect the JMS queue to the new machine, Raad says. "I have instant scalability without programming. Mule does it all for me," he says. Otherwise, he would be stuck writing JMS and SOAP and writing to multiple interfaces. At ESRI, Raad also uses Spring in conjunction with Mule.

Open-source ESBs on the move
Mule is one open-source ESB, but there are others, such as ObjectWeb and ServiceMix. They are on the move as well.

In late September, ObjectWeb, a nonprofit international consortium of companies, introduced Petals, what it refers to as the next-generation, open-source middleware. Petals is built around JSR208, the JBI specification, and will include the JOnAS application server and Iona Technologies' Celtix in the framework, creating an ObjectWeb ESB. According to the announcement, the Petals services platform will provide a clustered implementation of a JBI container as a core element for building lightweight open-source ESB products that leverage existing components from ObjectWeb's ESB initiative. Petals will be distributed, enabling the integration of JBI containers running on different JVMs extending across the organization.

"With Petals, all the features of JBI are designed to be clustered," says Francois Letellier, member of the ObjectWeb executive committee. In addition, "you can have the JBI containers on different JVMs, but manage them as one because the transport layer is inside the container," he adds.

Petals targets integration with JOnAS and with Celtix, a Java ESB core. It also is able to glue JOnAS server instances natively by processing JOnAS-hosted J2EE applications as service engines in Petals. JOnAS Web Services and Java Connector Architecture implementations will be used as binding components, according to ObjectWeb.

ServiceMix is another open-source ESB. It includes an SOA toolkit built ground-up on JBI specification semantics and APIs. Like Mule, ServiceMix is lightweight and supports Spring. It can run at the edge of the network (inside a client or server), as a standalone ESB provider, or as a service within another ESB.

ServiceMix also is integrated into Apache Geronimo, which allows developers to deploy JBI components and services directly into Geronimo. In addition, ServiceMix is integrated with JBoss.

Raad looked at both ServiceMix and Mule and opted for Mule, in large part because of how each supported JBI. "With ServiceMix, you have to depend on the ServiceMix client proxy. To me, that is not fully JBI compliant," he says.

SOA and Synapse
In August, four proprietary middleware vendors who had been on the periphery of the open-source movement formed a consortium called Synapse to take open-source middleware to what many consider an immediate level. The goal is to deliver an open-source implementation of a Web service mediation framework, along with components to use in developing and deploying SOA infrastructures.

As a mediation framework, Synapse will handle transformation and routing between two or more Web services. It will provide for the loose coupling of services (components) by providing some intelligence in the middle that will do whatever is required in the way of transformation to ensure the services successfully communicate with each other.

Synapse is being developed under the Apache Software Foundation umbrella, giving it an instant high profile and high level of importance. "Getting Synapse into the Apache incubator is no small feat," says Michael Goulde, an analyst at Forrester Research. Under the Apache umbrella, he expects Synapse to evolve quickly. The four middleware vendors-Blue Titan, Infravio, Iona and Sonic Software-make for an interesting quartet. At one level, they are competitors. For instance, Sonic already has a well-established proprietary ESB on the market. But Sonic recognizes that parts of the application development and deployment stack are being commoditized anyway, so it will benefit everybody if it is done in a shared way.

Blue Titan focuses on managing and scaling SOA deployments. At the core of Synapse will be Infravio's X-Broker Web services management suite. IONA established its reputation as a component broker. However, it recently donated its Celtix ESB to the open-source community.

Knowledgeable industry observers expect big things from this odd mix. Synapse is important for SOA development, according to Bloor, because it preempts competing products, allowing the open-source community to move ahead with a single standard for SOA middleware. "If there weren't Synapse, we'd be faced with competing architectures," he notes. But with Synapse: "Development and deployment will be clearly interrelated. It will allow a single standard for Web services," he explains.

Synapse, however, is just middleware. It does one piece of the job. In an SOA world, systems need to identify services, register services, then let the services talk to each other. "Synapse brings the integration, letting the services talk to each other," says Bloor. But, he adds, "it is the Registry that is key."

With Synapse as the latest addition to the open-source ESB middleware stack, developers have a growing set of open-source middleware options. Now all that's needed are customers ready to deploy open-source services-based applications. Who knows? Maybe they will come when those apps are ready.

JBI provides music to listeners
JSR 208 addresses the needs of the SOA because it defines the basic service-oriented integration bus and component architecture for services by standardizing the common message routing architecture, plug-in interfaces for service engines and bindings, and a mechanism (Composite Service Description) to combine multiple services into a single executable and auditable unit of work.

"We're excited about JBI. It brings application integration to the next level. With JBI, we're starting to get true middleware," says Tom Keen, CTO, Integrated Software Specialists. By true middleware, he means something that enables business integration and business orchestration, not just lower-level technical integration.

To get to JBI, ISS, a custom development shop, uses Mule. "We selected Mule because our customers wanted to leverage their existing technology investments and skills while they transitioned to a service- and event-driven architecture at their own pace," says Guillermo Tantachuco, ISS' software architect. Mule provided for multiple transport mechanisms and easily integrated with Web services.

However, the promise of JBI is what is really forcing the open-source middleware communities to move forward. "We're seeing the communities trying to respond to the new JBI spec, to JSR 208. The ESB has inadequacies. As we move to the next level of integration, we'll see true orchestration and true event-based systems, not just Web services," says Keen.

On ADTmag.com
On the road with mobile middleware
By Paul Korzeniowski

Vendors embrace open source
By John K. Waters

JBoss releases new open-source portal
By John K. Waters