Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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
titleST Flow
borderStylesolid

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
titleSeda Flow
borderStylesolid

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
titleJMS Flow
borderStylesolid

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
langxml
<sm:container flowNames="seda">
  ...
</sm:container>

...

Code Block
langxml
<sm:container flowNames="jms?jmsURL=tcp://localhost:61616">
  ...
</sm:container>

You can defined define several flows by using a comma separated list.

Code Block
langxml
<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
langxml
<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>

See also: How Stuff Works