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.
- 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.