OpenESB and ServiceMix in Comparison
This article compares the open source Enterprise Service Bus products in terms of components, tool support and performance. The comparison should give the reader decision guidance for choosing a suitable ESB product.
Both products implement the Java Business Integration specification and provide integration based on open standards. Apart from that both ESBs are based on different approaches. This article deals with the particular characteristics.
1. OpenESB / Glassfish ESB
Open Enterprise Service Bus in short OpenESB is developed by an
open source community under the direction of Sun Microsystems.
OpenESB is strongly linked with the Netbeans IDE and the Glassfish
Application Server. Glassfish ESB is an Open ESB distribution
containing the runtime and some essential components. With a
single download you get everything you need for developing,
installing and running integration solutions supported by
Glassfish ESB is well tested and according to our expierence more stable as the OpenESB bundled together with the Netbeans All distribution bundle.
1.1. Tool support
The Netbeans IDE provides numerous integrated functions for development and administration. The Composite Application Service Assembly (CASA) editor provides a graphical overview of integration applications which are called Service Assemblies. Using the CASA editor service endpoints can be configured and connected by drag and drop. Figure 1 shows an application in the CASA Editor.
To control the lifecycle of JBI components and service assemblies there is the JBI manager which is integrated into the server manager. The screenshot in figure 2 shows the JBI manager as well as the installed Components and service assemblies.
Netbeans also supports the developer in creating service units. A service unit for file access or XSLT transformation can be created in a separate project. As the OpenESB uses intensively WSDL descriptions, the WSDL and schema editors are very helpful. Figure 3 shows a WSDL document in tree view.
The schema editor shown in figure 4 provides several views for the comfortable editing of XML schema.
Numerous dialogues help the developer work with WSDL documents. The buildin validator for WSDL documents finds numerous errors and violations of rules of the Basic Profile of the WS-I organisation. XPath and XSLT are key technologies which are often used in ESB solutions. The XPath editor allows developers with only basic XML knowledge to create even complex XPath expressions using drag and drop. As figure 5 shows.
Netbeans uses the build tool Ant in the background. Glassfish and OpenESB can be accosted by Ant. Therefore the development environment is replaceable. So Eclipse can also be used for OpenESB development.
Numerous free JBI components are available for OpenESB. Among usual components used for FTP, HTTP, BPEL, etc. also connectors to mainframes as for example CICS, MQSeries or IMS, or an SAP system adaptor are available. Service engines for Data Integration ETL, Workflow or Complex Event Processing CEP can be obtained from the OpenESB page. Some components as for example the Quartz Scheduler are providing Netbeans plugins for configuration. The majority of components of the OpenESB are using WSDL for describing the endpoints. Often the whole configuration is stored in a WSDL binding. Describing endpoints using WSDL needs some time. This also applies to components communicating with endpoints within the bus. The effort of the creation of the WSDL description for the OpenESB components is balanced by by the tool support of Netbeans. WSDL documents can often be generated. The description of endpoints using WSDL is the main difference between OpenESB and ServiceMix. At least this is the difference most noticeable by development. This difference is completely based on the components. The bus is standardized by JBI and is acting equally in both products.
1.3. The BPEL Service Engine
To connect binding components and service engines using OpenESB, the Business Process Execution Language is needed. Without BPEL is is not possible to connect two components, if they are supporting different message exchange patterns like In-Only and In-Out. Using BPEL everything can work together, because BPEL supports synchronous ans asynchronous invokations. The usage of OpenESB implies therefore the usage of BPEL.
1.4. Runtime environment
Glassfish application server is the default runtime environment for OpenESB. In addition to Glassfish OpenESB can be integrated in other JEE application server as IBM Websphere or BEA respectively Oracle Weblogic. The Application Server then provides features as clustering or transactions. The Java EE service engine provides access to EJB and Web applications which are running at the application server. Those who want to run OpenESB without an application server can use OpenESB for Java SE distribution. There are only installation guidelines for Unix for this distribution and in addition it isn't evident which OpenESB version is contained. Those who want to abandon an application server are probably better advised to use ServiceMix.
Due to transmitting messages in main memory and an efficiently processing of XML the OpenESB offers a good performance. A simple composite application with SOAP adaptor and an XSLT transformation processed 25.000 messages a minute in our tests with a Dual Core processor and Windows XP. Therefore the performance basically depends on processing speed of the backend system or complex XSLT transformations.
2. Apache ServiceMix
ServiceMix is the JBI implementation of the Apache Software Foundation. For the carriage of messages on the bus Java Messaging Service in short JMS is used. The used implementation of JMS is Apache ActiveMQ. Every time a message of a component is sent through ServiceMix's Bus it is transmitted through the JMS infrastructure. The message queues which have been created especially for this can be monitored with a Java Management Extensions JMX Console. By using JMS for message exchange the bus is getting its Quality of Service characteristics as: message persistence or support of transactions. Therefore ServiceMix can continue doing its work where it as been interrupted. ServiceMix uses the Apache XBean project for configuration. XBean features a in-depth integration of the Spring Framework. The whole configuration is done by the Spring XML format. Even Service Units are configured with XBeans. Some components also offer the possibility to exchange some components by using XBeans. For example you can engage a file filter implemented in java into the File Component. Therewith Java can be used in this ServiceMix Component. This offers a lot more possibilities than a "common" configuration.
2.1. Tool Support
ServiceMix is a typical Apache project which can be administrated by command line or Maven2. Plugins for Maven2 are also the only ones bundled with ServiceMix. Those who aren't familiar with Maven2 will need some time for familiarization. Afterwards you can manage your service assemblies and their dependencies to service units very comfortable with Maven2. There is also no need for an administration tool for components and service assemblies, because the desired activities can be done quickly by deleting or copying files.
The ServiceMix distribution already contains numerous binding components and service engines. following connectors are provided:
|bean||Java POJOs (Simple Java Class)|
|Drools||Router or Services can be realised with rules of the Drools Rule Engine|
|EiP||Enterprise Integration Patterns taken from the book of Hohpe und Woolf e.g. filter, splitter, conent-based router, pipeline, content enricher|
|saxon||XSLT engine for transformations|
|Scripting||Services can be created with nearly any scripting language as Ruby, Perl or Groovy. Linked by JSR-223 Scripting for the Java Platform|
|Validation||Schema validation with XML schema or Relax NG (ServiceMix 3.3 or newer)|
ServiceMix is distributed with more components as the OpenESB Netbeans or Glassfish distribution. Altogether there are more Components available for the OpenESB as for ServiceMix. The JBI specification promises the exchangeability of integration components between the several ESB: In Practise this doesn't work smoothly, but it surely will change in future.
2.3. Orchestration and Routing
Contrary to OpenESB BPEL is not needed for orchestration and
routing. The ServiceMix distribution doesn't even contain a BPEL
engine. If BPEL support is desired for ServiceMix, a BPEL engine
like Apache ODE can be installed as JBI component.
There are several alternatives for routing in ServiceMix. The simplest solution is the Enterprise Integration Patterns service engine. It offers besides others an XPath splitter, an aggregator, a routingslip and a content based router. A more powerful option is the Camel SE. Apache Camel is an open source integration framework. Routing rules can be created using a Java based Domain Specific Language (DSL) or using a Spring configuration. Besides this, ServiceMix offers a SE for the Drools Business Rule Management System . And of course you can use BPEL.
2.4. Runtime Environment
ServiceMix is modest in resource consumption. During development ServiceMix can be ran immediately in a Java VM without an application server. It's even possible to run ServiceMix out of a JUnit Test or to run ServiceMix embedded in other applications. An integration of ServiceMix into Geronimo, JBoss, Tomcat or other servers is also possible.
ServiceMix can also process more than 10000 messages per minute. The performance doesn't suffer considerably even when the messages are persisted by ActiveMQ and Apache Derby data base. If the performance doesn't suffice, for example due to complex XSLT Transformations, ServiceMix can be clustered. Therefore ServiceMix and the service assembly has to be installed on several computers. Using mulitcast they find each other and distribute the load across multiple computers.
In face of the JBI specification OpenESB and ServiceMix are quite different. None of them is better or worse. Those who want to use WSDL for describing services, appreciate a good tool support and want to use an application server will decide in favor of OpenESB. Those who want to keep their XML interfaces flexible; considering messages as documents which are changing; using already Maven2 and not want to use an application server will decide in favor of ServiceMix.
|Number of Components||++||+|
|Implementation of Enterprise Integration Patterns||+ (using BPEL)||++|
|Documentation||Numerous Tutorials and Examples||Detailed Reference|
|Bus||In-Memory||JMS, Persistent or In-Memory|
|Orchestration||BPEL||EIP, Camel, BPEL|
|Message Persistence||BPEL and JDBC||JMS and JDBC|
|License||CDDL v1.0||Apache License Version 2.0|