The execution model is the system used
to execute message flows through a series of nodes.
When an execution group is initialized, the appropriate loadable
implementation library (LIL) files are made available to the runtime environment.
The execution group runtime process starts, and creates a dedicated configuration
thread. In the message flow execution environment, the message flow is thread-safe.
You can run message flows concurrently on many operating system threads, without
having to consider serialization issues. Do not compromise this threading
model in your implementation of user-defined nodes. Consider the following
points:
- An input message sent to a message flow is processed only by the thread
that received it. No thread or context switching takes place during message
processing.
- A single instance of a user-defined extension might be invoked on several
threads concurrently.
- The memory requirements of an execution group are not unduly affected
by running message flows on more operating system threads.
- The message flow execution environment is conceptually similar to procedural
programming. Nodes that you insert into a message flow are similar to 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,
the execution model is referred to as a propagation-and-return model.
- A message flow is inherently thread-safe, and message flows can be run
concurrently on more than one thread.
As an example, consider a message flow in which you use both user-defined
nodes and parsers. You use a user-defined node to process messages, and a
user-defined parser to parse messages; both the node and parser contain implementation
functions. The broker calls the implementation functions, or callback functions,
when certain events occur:
- When an input message is received by the message flow and is propagated
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 user-defined node wants to query the message to decide what to
do with it, the node calls a C utility function or a Java method, as appropriate
for the language in which the node is written.
The broker invokes the user-defined parser on one of its implementation
functions, for example cpiParseFirstChild. This function
instructs the parser to build the parse tree. The parser builds the tree by
invoking utility functions that create elements in the parse tree, for example cpiCreateElement.
The parser can be called many times by the broker.