THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
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 easier 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 routing, 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).
What does ServiceMix use to 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 use the JMS flow, for example to connect multiple ServiceMix instances.