Mule Application Architecture

The first building block in a typical flow is a Message Source, which receives messages from one or more external sources, thus triggering a flow instance. Each time it receives another message, the message source triggers another flow instance.

Sometimes the message source immediately places the incoming message into a queue. This allows the message source to close the receiver thread it used to accept the message, and immediately open another thread to accept another incoming message. The message just placed into the queue, whiere it waits until it reaches the top of the queue and can be processed through the rest of the flow. Since the message is processed sequentially by two distinct threads (with an intervening wait inside the queue), start-to-finish transaction processing is typically not possible. For an elegant work-around, see Advanced Use Case, below.

Sometimes, a message source can accept incoming messages from multiple transport channels. For instance, you can embed both an HTTP endpoint and a Servlet endpoint within a building block known as a Composite Scope. Whichever endpoint receives a message effectively becomes the message source for that particular message flow instance. Alternatively, you can populate a composite scope to receive both IMAP and POP3 mail.

Under certain conditions, flows do not need to be triggered by message sources. For instance, a Flow Reference Component can trigger a private, child flow, which can execute synchronously or asnchronously, be resuable, or not, and inherit the exception strategy used by the parent flow, or not. For details, see Child Flows, below. Similarly, the Async Scope can trigger a child flow that executes asynchronously, (i.e., in parallel with the parent flow).

Typically, these are pre-packaged execution units that process messages in various ways. Except for message sources, all the building blocks in a flow qualify as Message Processors. In contrast to the Mule Services they have largely supplanted, message processors offer the following advantages:

You can assemble message processors into application (i.e., main flow) sequences in two distinct ways:

Message processors fall into a number of convenient categories, as the following table indicates:

After you have arranged the various Message Processors in your flow into proper sequence, you may need to configure these Message Processors using one or both of the available options:

Mule provides several ways to combine multiple Message Processors into functional Processing Blocks.

For instance, the Composite Source Scope allows you to embed into a single Message Source two or more inbound endpoints, each one listening to a different transport channel. Whenever one of these listeners receives an incoming message, it triggers a flow instance and starts the message through the message processing sequence.

Other building blocks known as Scopes provide multiple ways to combine Message Processors into convenient functional groupings that make your XML code much easier to read, implement parallel processing, or create reusable sequences of building blocks.

As previously mentioned, Endpoints implement transport channels that facilitate the insertion or extraction of data from Flows. Endpoints serve a diverse variety of roles, depending on how they are configured. For example, they can, as previously mentioned, serve as Inbound or Outbound conduits. They can implement one-way or request-response exchange patterns. And, in certain situations, you can embed other types of Message Processors, such as Transformers, into Endpoints.

A processing strategy determines how Mule executes the sequence of Message Processors in your Mule application. For example, when the message source is configured for the request-response exchange pattern, Mule sets the processing strategy to synchronous, thus ensuring that the entire sequence of message processors executes, and the client that sent the message receives a response. To accomplish this synchronous processing, the entire flow is executed on a single processing thread.

By contrast, when the flow is configured for a one-way, non-transactional exchange pattern (i.e., no response to the original message sender is required, and it isn’t necessary to verify that all steps in the flow have been completed), Mule sets the processing strategy to Queued Asynchronous, which has the potential to raise flow throughput. Under this processing strategy, the Inbound Endpoint places the incoming message into the queue as soon as it is received, then closes the receiver thread. When the message reaches the top of the queue, it resumes processing, but this time on a different thread. By implication, this sort of processing does not qualify as transactional end-to-end, because the transfer from one thread to the next means that the processing can not be rolled back if an exception is thrown.

An exception strategy determines how Mule responds if and when an error occurs during the course of message processing. In the simplest case, the error is simply logged to a file.

You can configure an exception strategy to respond in a variety of ways to a variety of conditions. For example, if an exception is thrown after a message has been transformed, you can set Mule to commit the message as it existed after being transformed, but immediately before the error occurred, so that the message can not inadvertently be processed twice.

For details, see: Error Handling

Subflows inherit both the processing strategy and exception strategy of the parent flow.

Subflows provide a number of potential advantages. First, they can isolate logical processessing blocks, making the underlying XML code much easier to read. Next, they can be reused, so a developer can write a particular block of code just once, then reference the same subflow repeatedly from within the same application.

Although a subflow operates synchronously, it can spawn an asynchronous child flow of its own, which runs in parallel with the main flow (or the parent subflow itself), until the parent subflow and then the main flow complete.

A special type of child flow operates synchronously, as a Subflow does, but unlike a Subflow, this type of synchronous child flow uses its own, rather than the parent flow’s, exception strategy. This can be useful when the message processing events inside the child flow are either much more or much less crucial than the rest of the events in the main flow. In either case, you can set the exception strategy used by the synchronous child flow to perform very differently from the exception strategy you configured for the main flow.