Is ServiceMix the Right ESB for Me?

So you've read How to Evaluate an ESB and you're ready to select one. Now the question becomes, 'Is ServiceMix the right one for me?' Here's some basic information to get your decision-making process started.

Open Source & Open Standards

How do Open Source ESBs compare to commercial ESBs?

In general, they are both viable solutions. To be more specific, hopefully the rest of this page will give you some idea.

Note that both community and commercial Support are available for ServiceMix.

Is ServiceMix based on Open Standards? Is that important?

Yes, and yes.

ServiceMix implements the Java Business Integration or JBI specification (see What is JBI?). This means that standard JBI components can be run in ServiceMix, along with services that use them. Likewise, JBI components or services developed for ServiceMix can be used in any other JBI-compliant ESB.

Additionally, while not a standard per se, ServiceMix lets you use Spring beans as services, which may help you get started quickly. The same Spring beans could be used both in ServiceMix and in other Spring environments (such as, say, in a unit test, or in another application requiring the same logic).

Beyond the above, the message format used internally on the bus is XML-based (with optional binary attachments, etc.), and ServiceMix supports a variety of WS-* specifications for messages going into and out of the bus. More on those later. ServiceMix also uses the standard JMX management and monitoring API.

The bottom line is that you should be able to deploy standards-based services, using standards-based ESB functionality, exchanging standards-based messages. This means your code and configurations should be portable across products, it should be easy to integrate with other environments, and it should be easy to find tools to support development, testing, monitoring, and tuning.

Basic Architecture

JBI: Normalized Messages, Service Engines, Binding Components, oh my!

Let's look at the picture from the Front Page:

In the middle, there's the bus. The messages on the bus are JBI Normalized Messages, which are XML-based with optional binary attachments, header values, etc. (for more detail see What is JBI?).

On the bottom are binding components. These are JBI components (like plugins) that have the capability to convert incoming messages from some protocol (like SOAP over HTTP, REST over JMS, SNMP, some custom binary junk, etc.) into Normalized Messages, and put those messages onto the bus. Or take a Normalized Message from the bus, and send it out using some other protocol. Or both.

On the top are service engines. These are JBI components (again, like plugins) that can do interesting things with Normalized Messages. Like perform some custom message routing, or transform the message via XSLT, or run a BPEL process, or invoke a method on an EJB and return the result as another Normalized Message.

So when you deploy an application, it will probably include things like:

• Some POJOs, Spring Beans, or other components with service logic
• Configuration files to activate certain service engines (e.g. to convert Normalized Messages into method calls on your beans above)
• Configuration files to activate certain binding components (e.g. to connect your services to the SOAP-over-HTTP protocol on a certain URL)
• Any additional routing rules, perhaps using a routing service engine, if it can't be deduced (e.g. by comparing the format of a Normalized Message to the WSDL describing the services) or needs additional customization

Note that JBI has a specific format for applications – Service Units in a Service Assembly, so your application could be deployed to another JBI-compliant ESB (assuming the needed JBI Binding Components and JBI Service Engines had also been deployed).

WSDL? Did you say WSDL?

So a JBI service is typically described by a WSDL. This does not mean that SOAP is involved on the bus, though – note that an XML message (for example, a NormalizedMessage) can be compliant with a WSDL without any of the SOAP envelope, headers, or additional overhead.

In some cases, you may deploy a service with an associated WSDL. In other cases, the WSDL may be generated for you (for instance, if you deploy a POJO as a service using the JSR-181 service engine). But the easiest way to make sure a NormalizedMessage gets to a particular service on the bus is to make sure the message complies with the WSDL for that service. Otherwise, you have various routing options to use.

If it happens that you are using SOAP for messages going into and out of the bus, what typically happens is that the binding component will strip off the SOAP envelope, use the body of the SOAP message as the Normalized Message XML, use any SOAP attachments as attachments on the Normalized Message, and use any SOAP headers as headers on the Normalized Message. Then the Normalized Message is sent on the bus to the appropriate Service Engines, etc. Finally, the reverse procedure applies for replies or messages going out of the bus via a SOAP binding component.

How does ServiceMix handle messages on the bus?

The two most common modes are SEDA and JMS flows. For messages that are non-persistent, ServiceMix uses an efficient in-memory system known as the SEDA flow to convey messages on the bus. For messages that are persistent, ServiceMix uses JMS messages with an underlying ActiveMQ broker. You may also choose to force the use of the JMS flow, for example to connect multiple ServiceMix instances.

Message Capabilities

Does ServiceMix support SOAP?

Messages on the bus do not use SOAP. But ServiceMix includes binding components that support SOAP-over-HTTP and SOAP-over-JMS, as well as the CXF binding component that supports SOAP over HTTP and JMS, all of which include SOAP 1.1 and SOAP 1.2 support, MIME attachments, etc.

What WS-* specifications does ServiceMix Support?

Most of the WS-* specification support can be found in the binding components included with ServiceMix – for HTTP, JMS, or CXF (which supports both HTTP and JMS). Of the three, CXF has the most extensive WS-* support.

Does ServiceMix support plain XML messages?

Yes, the binding components can accept plain XML as well as SOAP – the Normalized Message is created directly from that XML. As with any other Normalized Message, routing and transformations can be applied (more on that in a moment).

Does ServiceMix support other (non-XML, binary, etc.) protocols?

ServiceMix can support any protocol so long as a binding component is available to convert protocol messages to or from Normalized Messages. For custom protocols, you may need to write a bit of code for the binding component, but that is not particularly complex (outside of whatever the protocol processing requires).

Mediation

What routing options does ServiceMix provide?

Many.

1. Standard JBI routing, for example, a binding component specifies a particular service engine to dispatch to, or the bus matches the Normalized Message XML content to a service's WSDL
2. Content-based routing using XPath expressions on the Normalized Message XML content
3. Rules-driven routing using the Drools service engine
4. Script-driven routing using the Scripting service engine
5. Java code can perform routing using the ServiceMix POJO Support
6. You can drop in a JBI-compliant BPEL service engine (such as Ode to perform routing (among other things)

What transformation options does ServiceMix provide?

Many of the same options as in the routing answer above. For example, messages can be transformed with XPath/XSLT, or via a script like Groovy, or via a Java class, or BPEL, etc.

Which options allow a declarative approach for routing/transformation?

Pretty much everything except the Java code approach. Otherwise, the script or configuration typically exists in files outside your Java code, but inside your JBI Service Unit. In other words, it is declarative, but not necessarily editable at runtime without redeploying the service.

Specifically:

• JBI routing, when configuration is needed, is configured in an XML file in the Service Unit
• XPath/XSLT routing and transformation uses an entry in the XML file and a separate XSLT file in the Service Unit
• Drools rules are typically defined in an XML file bundled in the Service Unit
• Script-driven routing and transformation can use scripts in the XML file in the Service Unit
• BPEL process definitions are packaged in the Service Unit

Orchestration

What orchestration options are available?

Is the answer you're looking for BPEL? It is not distributed with ServiceMix, but thanks to the JBI standards, you can drop in a JBI component for a BPEL engine, such as Apache Ode (literally – download the Ode or other JBI component to servicemix/install). So we generally consider BPEL to be a supported orchestration option.

Other options include using Scripting languages such as Groovy, which in addition to routing and transformation, can save state across requests and therefore perform at least some orchestration (though the state is not maintained across server restarts).

You could also write custom Java code to perform orchestration.

Are transactions supported?

There is no built-in support for "business transactions" (such as WS-TX BusinessActivity). ServiceMix can preserve SOAP headers as Normalized Message headers, so individual services might react to them, but we don't really claim support.

It is possible to use transactional delivery on the bus, either encompassing a single message delivery or a flow involving a series of components and response messages. See, for example, the JMS and JCA Flows, as well as the page on Transactions. However, to be honest, this is not the easiest to configure and the documentation is liable to give you a headache.

Security

Performance

Testing

Complex Services

Publication / Discovery

Policies