Component Matrix

ServiceMix defines several types of components:

• JBI SE : standard JBI Service Engine
• JBI BC : standard JBI Binding Component
• LW SE : LightWeight Service Engine
• LW BC : LightWeight Binding Component

Lightweight components are components that can be configured using activation specs in the servicemix.xml configuration file.
Standard JBI components can be deployed at run-time and accept service units deployments. These components may in addition provide a way to configure them in a lightweight fashion.
Note that the servicemix-lwcontainer is a standard JBI component which is able to deploy lightweight components so that you can add / remove lightweight components at run-time.

A component can act as two different roles with respects to JBI MessageExchanges. In a given exchange, the originator component is said to be the consumer and the target component is said to be the provider.

The JBI spec defines service invocation as an instance of an interaction between a service consumer and a service provider. The following are the four service invocation patterns are required to be supported by any JBI implementation:

• One-Way: consumer issues a request to provider with no error (fault) path provided.

• Reliable One-Way: consumer issues a request to provider. Provider may respond with a fault if it fails to
  process request.

• Request-Response: consumer issues a request to provider, with expectation of response. Provider may
  respond with a fault if it fails to process request.

• Request Optional-Response: consumer issues a request to provider, which may result in a response.
  Consumer and provider both have the option of generating a fault in response to a message received during
  the interaction.

The WSDL 2.0 Extensions spec defines a Message Exchange Pattern (MEP) as: "the sequence and cardinality of abstract messages listed in an operation." JBI uses this concept to define interactions between two nodes: the consumer node, and the provider node. The pattern is defined in terms of message type (normal or fault), and message direction. MEPs always reflect the provider's point of view. For example, in a request-response interaction, the MEP is in-out, which reflects the flow of messages as seen by the provider. From the consumer's perspective, the direction of message flow is reversed, but the MEP used by the NMR in its interactions with the consumer will always reflect the provider's perspective. This is a conventional practice when dealing with WSDL MEPs.

Below is a matrix of ServiceMix components and the JBI MEPs supported by each.