Page History

...

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

– PS

...

sequence diagram

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

...

...

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
  allow
  • broadcasting awareness of
  you
  • 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
  request
  • response MEs to.

• There is one Queue per sender unique destination component.
  • This is created when a component is activated.
  • These
  Queue
  • Queues is for sending
  response
  • 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

...

Notification of remote component state changes

• TODO fix diagram

• I have shown The diagram shows a "local" and "remote" JMSFLow 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 lern learn about them
  • If remote Topic Consumer is deactivates 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 response request MEs to)

goto top

JMSFlow send ME sequence diagram

• I have shown 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 generic component Queue on the some remote container
  • They are load balanced

• Responses are sent back to a specific the container Queue for of the component conatiner that sent originated the request exchange (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 destination 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