The WebSphere Message Broker execution
model is the system used to execute message flows through a series of nodes.
When an execution group is initialized, the appropriate LILs are made available
to the runtime. The Execution Group runtime process starts, and spawns a dedicated
configuration thread. In the message flow execution environment, the message
flow is thread-safe. You can concurrently run message flows on many threads,
without having to consider serialization issues. Any user-defined nodes that you implement should not compromise
this threading model. Note the following points:
- An input message sent to a message flow is only processed by the thread
that received it. No thread or context switching takes place during message
processing
- Data structures accessed by message flows are only visible to a single
thread, and these data structures exist only for the lifetime of the message
being processed.
- A single instance of a message flow is shared between all the threads
in the message flow thread pool. This is related to the behavior of a message
flow node in that it does not have state.
- The memory requirements of an Execution Group are not unduly affected
by running message flows on more OS threads.
- The message flow execution environment is conceptually similar to procedural
programming. Nodes that you insert into a message flow are like subroutines
called using a function call interface. However, rather than a "call-return"
interface, in which parameters are passed in the form of input message data,
in WebSphere Message Broker the execution model is referred
to as a "propagation and return" model.
- A WebSphere Message Broker message flow is inherently
thread-safe, and message flows can be run concurrently on more than one thread
If, for example, you are using a user-defined node to process messages, and you are also
using a user-defined parser
to parse the incoming messages, both the node and parser will contain implementation
functions. The broker calls these implementation functions, or callbacks,
when certain events occur.
When an input message is received into the broker at that input node, it
is sent to the user-defined node.
- For C nodes, the broker calls the cniEvaluate function
for the user-defined node.
See cniCreateNodeContext for information on
the cniEvaluate function.
- For Java nodes, the broker calls the evaluate method
that is implemented by the user-defined node.
If the node wants to query the message to decide
what to do with it, it calls a C utility function or a Java method, as appropriate
for the language in which the node is written. The broker then invokes the user-defined parser
on one of its implementation functions. This instructs the parser to start
building the WebSphere Message Broker parse tree. The parser
starts building the tree by invoking utility functions that create elements
in the parse tree. The parser can be called multiple times by the broker,
rather than just once.