The WebSphere Business Integration 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 Business Integration Message Broker the execution model is referred
to as a "propagation and return" model.
- A WebSphere Business Integration 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. The broker calls the user-defined node
on its message processing function, using the cniEvaluate or
evaluate command. 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 your node is written in. The broker then invokes the user-defined
parser on one of its implementation functions. This instructs the parser to
start building the WebSphere Business Integration 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.