Middleware is in the Open, Finally
- By Alan Radding
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.
The Big Idea
NOT FAIR, NOR MIDDLING
- The open-source community, which has focused on development tools (such
as Eclipse) for the past several years, finally has turned its attention to
- Recently, a consortium of proprietary middleware product vendors launched
the Synapse initiative to create open-source middleware for SOA development
- In what has to be the same as sleeping with the enemy, JBoss jumped into
bed with Microsoft in September.
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.
With ServiceMix, you have to depend on the ServiceMix client proxy. To me, that is not fully JBI compliant.
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
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.
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
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
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.
We’re excited about JBI. It brings application integration to the next level. With JBI, we’re starting to get true middleware.
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
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,"
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 the road with mobile
By Paul Korzeniowski
By John K. Waters
new open-source portal
By John K. Waters