Page History

...

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.

...