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.
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.
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.
Depends on what you mean, I guess. There are a lot of Spring-related features, and Spring is clearly not an OASIS standard, but we hardly think of it as proprietary. You can simply ignore these features and choose not to, for example, use Spring Beans as services if you'd prefer not to.
Different JBI service engines included with ServiceMix may let you develop services, routing logic, transformation logic, etc. in a variety of formats. Just to give a few examples: Drools rules, XSLT transformations, OSWorkflow workflows, Groovy scripts, or JavaBeans (POJOs). While you might not normally be able to deploy say a Groovy script in another ESB, you could always deploy the servicemix-script JBI component to another JBI-compliant ESB and then your Groovy script would be deployable there too.
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:
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).
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.
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.
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.
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.
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).
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).
The main approach would be XSLT transformation on the Normalized Message XML content.
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.
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.
Finally, while it's not full-fledged orchestration, Camel is integrated with ServiceMix and supports many Enterprise Integration Patterns that might otherwise require an orchestration engine to implement.
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.
So to begin with, there are several ways for a client to authenticate on a request to a binding component. For HTTP binding components, this may include HTTP Basic, Client Certs, etc. SOAP over HTTP and JMS can use WS-Security to authenticate.
Then, there are several ways to validate the client's authentication request. ServiceMix uses JAAS for this, so you can hook up a JAAS LoginModule supporting properties files, a user database, an LDAP or ActiveDirectory server, or any other user data repository. Once authenticated, a Subject is populated on the JBI Normalized Message, so authorization can be performed down the line.
Note that with a somewhat more complex JAAS configuration, you may provide additional features such as a lockout after a certain number of login failures, denial-of-service prevention, login auditing, etc.
Finally, to control authorization, ServiceMix uses an XML file that defines which users/groups/etc. can access which services (or which operations on a service). The standard implementation is not very flexible (there's one XML file for the whole server and it cannot be reloaded at runtime), but it is pluggable, so alternatives are possible.
One option that has been discussed, for example, is to expose the JBI Subject to Spring to allow Spring security to act on service invocations. Another option would be to support annotations on the service WSDL. Of course, these have not been implemented at present.
For messages in or out of the bus, WS-Security provides the encryption and digital signature options. For messages within the bus, there are no particular features along these lines.
Logins may be audited using a JAAS module, as mentioned above.
It is also possible to audit message traffic – one option would be to use the EIP WireTap to send each message to both an auditing service and the usual destination (or similarly, the Static Recipient List pattern). Another (if using the JMS Flow) would be to configure a virtual destination in ActiveMQ and audit copies of the message traffic.
Yes. Multiple ServiceMix instances can communicate via JMS using ActiveMQ.
As far as how to use a cluster, one way is to use the JMS or JCA flows to ensure that services deployed on a cluster are aware of each other and requests can be load-balanced across nodes in a cluster. That is harder to set up but effective without more manual intervention. An alternative is to manually define JMS endpoints and corresponding routing between machines in the cluster for cases where you need to send requests to a separate machine in the cluster, and otherwise always allow the local copy of a service to handle any request on a clustered machine. That is not as complex to set up, but requires manual configuration for every communication path between cluster nodes. In either case, you can deploy services to multiple cluster nodes and put them behind a load balancer.
Yes, when using the SEDA (default), JMS, or JCA flows. The optional Straight Through flow eliminates any queuing.
Yes, using the lightweight Cache component – you can specify a caching strategy/size and message header values or a message body XPath to use as the cache key.
However, note that lightweight components are generally deprecated; this one doesn't happen to have a (JBI component) replacement available yet.
It depends. On things like the protocols, routing, transformations, and orchestration being used, the flow being used, whether ServiceMix is clustered, how long the actual services take to execute, and so on.
Note that in many cases (depending on the protocols in use) you can run load tests against the deployed services, and use that as a guide to hardware sizing.
There have been two previous efforts to create an Eclipse-based GUI for things like this, but neither appears to be up to date. Our hope is that the Eclipse SOA Tools Project will provide a quality GUI for JBI/ServiceMix development.
There is a Web console available with which you can deploy JBI components, services, review endpoints WSDLs and flows, etc. It is built-in to the Web app distribution of ServiceMix, or available as an add-on to the standalone distribution of ServiceMix.
Also, stay tuned for more news in this area.
There are Maven plugins to package a Maven project or module as a JBI Service Unit or Service Assembly. There are also more options in case you're building a custom JBI service engine or binding component.
If you're starting a new Maven project, there are also archetypes available for many types of JBI and ServiceMix modules.
For starters, if your services are Java Beans or Spring Beans, you can probably unit test them without ever deploying them to an ESB. So you might have a Service Unit module, with an xbean.xml file for when the service is packaged for deployment, and perhaps a separate spring-test.xml that configures the service and any needed stubs or whatever for unit testing purposes.
It should be possible to have Maven start ServiceMix, deploy a service assembly to it, run integration tests against the deployed services, and then shut it down again. (This statement deliberately left vague.)
Or, you can start ServiceMix as part of a JUnit test, deploy various JBI components and Service Assemblies, and then run the bulk of the tests against that embedded ServiceMix instance. Here's a sample ServiceMix config file that does that.
Depending on the protocols used by the services, you might also be able to use third-party tools like soapUI, JMeter, or various commercial tools to test the services when they are deployed to ServiceMix.
Sure. Each Normalized Message will typically correspond to the WSDL for a given service, and there's nothing preventing different services from using different WSDL versions. Just make sure your messages comply with the WSDL for the service they're going to.
This is defined by JBI. For a Service Unit, states can be:
For some more insight into state transitions, see the JBI ServiceUnitManager JavaDoc.
However, not all services will necessarily see the initialized state – it depends on the JBI component hosting the service and what it exposes to its services.
So long as existing operations are not changed, the service should continue to accept all Normalized Messages that it previously would have.
If new operations are added, then they will become available when the new WSDL takes effect (e.g. when the Service Unit with the WSDL is redeployed).
Of course, you would want to coordinate changes to routing, transformation, or orchestration that depend on changes to the service's WSDL. (This is easiest for anything deployed in the same Service Assembly as the service in question.)