Page History

Documentation Overview

The following diagrams and notes Following diagrams are my understanding of part of the ServiceMix architecture based on a study of the source code . Enjoy – PS[See Also: NMR Flows ]

– PS

Contents

• NMR flow types
  • st
  • seda
  • jms
  • jca

...

• There are a number of flow implementations . For example: STFlow, SedaFlow, JMSFlow, JCAFlowas shown in the following table
  

  Flow Name	Flow implementation Class
  st	org.servicemix.jbi.nmr.flow.st.STFlow
  seda	org.servicemix.jbi.nmr.flow.seda.SedaFlow
  cluster	org.servicemix.jbi.nmr.flow.jms.JMSFlow
  jms	org.servicemix.jbi.nmr.flow.jms.JMSFlow
  jca	org.servicemix.jbi.nmr.flow.jca.JCAFlow

goto top

Broker send sequence diagram

...

sequence diagram

• SedaQueue instances are lazilly lazily created as needed and referenced in a queueMap

...

JMSFlow

TODO

Uses JMS for message routing among a network of remote containers.

JMSFlow

...

classes and JMS Destinations

...

• There is one single Topic across all containers.
  • This Topic is created during JMSFlow init.
  • A ConsumerAdvisor configured for this Topic allows container to be "aware" of each other.
  • Special messages sent to this Topic broadcasting awareness of your components to other containers in the network.

• There is one Queue per container.
  • This is created during JMSFlow init.
  • This Queue is for sending response MEs to.

• There is one Queue per unique destination component.
  • This is created when a component is activated.
  • These Queues is for sending request MEs to.

• Outbound (request) messages get routed to a Queue for a named component (so are load balanced) and responses get sent back to the Queue for the originating container.

• The JMSFlow is a JMS MessageListener (ie it implements onMessage Method) for the Topic and all Queues

• The JMSFlow is also an ActiveMQ ConsumerAdvisoryEventListener for the Topic.
  • This means all JMSFlow instances will be aware of remote container startup/shutdown

goto top

Notification of remote component state changes

• The diagram shows a "local" and "remote" JMSFlow instance for clarity although they may be the same instance

• A container needs to be made aware when the state of a remote container's components changes.
  • JMSFlow uses an ActiveMQ ConsumerAdvisoryEvent to detect a change in status of a remote Consumer of the Topic
  • If remote Topic Consumer is activated - eg container started - information of all (local) components are re-broadcast to the Topic so the new container can learn about them
  • If remote Topic Consumer is deactivated - eg container shutdown - all (local) knowledge of the remote container's components is removed

• Conversely, a remote container needs to be made aware if there is some state change with any component of the local container.
  • The JMSFlow instance is a JMS MessageListener on the Topic
  • If a component state changes, a ComponentPacketEvent (which container component state information) is serialized and sent as a JMS ObjectMessage to the Topic.
  • All remote JMSFlows receive this message and adjust their knowledge of our component accordingly
  • If the component is becoming activated, then a Queue is created (for remote containers to send request MEs to)
  TODO add more notes

goto top

JMSFlow send ME sequence diagram

...

• The diagram shows a "local" and "remote" JMSFLow instance for clarity although they may be the same instance

• The ME is serialized and sent as a JMS ObjectMessage

• Requests are sent to a component Queue on some remote container
  • They are load balanced

• Responses are sent back to the container Queue of the conatiner that originated the request (because the sender may have done a synchronous send and is awaiting a response)

• The JMSFlow instance is a MessageListener for both Queues

• When the MessageListener's onMessage is triggered, the ObjectMessage content is deserialized. If the deserialized Object is a ME then it is routed to the appropriate component.

goto top

JCAFlow

The JCAFlow uses a JCA1.5 inbound resource adapters for message routing among a network of remote containers.

The resource adapters encapsulate JMS functionality.

goto top