THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
The following diagrams and notes are my understanding of part of the ServiceMix architecture based on a study of the source code
– PS 
| Warning |
|---|
ServiceMix code is currently evolving faster than I can keep up with it . Therefore, so some of ths the information in this document may be already be out-of-date. Diagram comments indicate what version of the code was studied. |
...
- 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
| Info |
|---|
The 'cluster' flow (present in ServiceMix version 1.x) is now just a synonym for 'jms' flow type |
...
Uses JMS for message routing among a network of remote containers.
| Info |
|---|
...
"remote" just means separate. In fact, it makes no difference if the JMSFlow containers are on the same or separate machines. |
JMSFLow classes and JMS Destinations
...
- 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 activated - eg container started Information - information of all (local) components are re-broadcast to the Topic so the new container can lern about them
- If remote Topic Consumer is deactivates - eg container shutdown All - 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. JMSFlow 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 remove 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 MEs to)
...
- Responses are sent back to a specific Queue for the component that sent the request exchange (because the sender may have done a synchronous send and is awaiting a response)
- The JMSFlow 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 component.
...