ServiceMix allows for different message dispatch policies within the Normalized Message Router (NMR) Broker.
There are four basic types, that have different characteristics and are suited to different usage cases.They are as follows:
Straight-through (ST) Flow
Straight-through flow. A MessageExchange is routed straight to it's destination with no staging or buffering. A straight through flow is best suited for the cases where the ServiceMix JBIContainer JBI container is deployed with simple flows (no state) or embedded, or where latency needs to be as low as possible.
Panel |
---|
borderColor | #ccc |
---|
title | ST Flow |
---|
borderStyle | solid |
---|
|
![](/confluence/download/attachments/39155/stflow.jpg?version=1&modificationDate=1171443075000&api=v2)
|
Seda Flow
The SedaFlow Seda flow introduces a simple event staging between the internal processes in the NMR Broker. A Seda flow (, which is the default ) flow used by most components, is suited for general deployment, as the . The additional staging is well suited buffering exchanges between heavily routed to components (where state may be being used) for example.
Panel |
---|
borderColor | #ccc |
---|
title | Seda Flow |
---|
borderStyle | solid |
---|
|
![](/confluence/download/attachments/39155/sedaflow.jpg?version=1&modificationDate=1171443075000&api=v2)
|
JMS Flow
A JMS Flow flow is used for cases where you need collaboration between more than one ServiceMix JBIContainer (for JBI container. For example, an application that needs to have fail-over or scalability).
Component capability or an application that needs to balance its endpoints among several machines would need to have one or more JBI containers working in concert.
When JBI containers are deployed in a cluster, component deployment happens in the same way as a normal SericeMix JBI container (both for POJO and archive Component deployment) , but all the containers in the cluster are notified of a deployment, and the JMS Flow will handle flow handles automatic routing ( and failover ) of MessageExchange(s) between the container instances.
A Message Queue is used for each JBI endpoint, so multiple instances of the same named Component will have requests load balanced across them.
Panel |
---|
borderColor | #ccc |
---|
title | JMS Flow |
---|
borderStyle | solid |
---|
|
![](/confluence/download/attachments/39155/clusterflow.jpg?version=1&modificationDate=1171443075000&api=v2)
|
JCA Flow
The JCA Flow flow is very similar to the JMS Flow, in that it allow flow. It allows users to cluster ServiceMix containers together.
The main difference is that it uses JCA to provide support for XA transactions when sending and receiving
JBI exchanges. You can find more informations on transactions here.
Configuring flows
Flows are In versions of ServiceMix prior to 3.3 Flows were configured on the JBI container by usually using the flowNames attribute on the main sm:container
element.
Code Block |
---|
|
<sm:container flowNames="seda">
...
</sm:container>
|
...
Code Block |
---|
|
<sm:container flowNames="jms?jmsURL=tcp://localhost:61616">
...
</sm:container>
|
You can defined define several flows by using a comma separated list.
Code Block |
---|
|
<sm:container flowNames="seda,jms?jmsURL=tcp://localhost:61616">
...
</sm:container>
|
For more complex configurationsconfiguration, you can define the flow explicitelyexplicitly. This method is also the recommend method for configuring flows in ServiceMix 3.3 and later.
Code Block |
---|
|
<sm:container>
<sm:flows>
<sm:sedaFlow />
<sm:jcaFlow bootstrapContext="#bootstrapContext"
connectionManager="#connectionManager"
jmsURL="vm://localhost" />
<sm:jmsFlow jmsURL="tcp://localhost:61616" />
</sm:flows>
</sm:container>
|
...