The Component Flow Stage
In a completely asynchronous message flow in Mule, every message is handled by three distinct stages while it passes through a service. Each stage corresponds to a single thread and this is all controlled by the Staged Event Driven Architecture (SEDA) that Mule implements.
The inbound flow stage handles the message up until the message can be handed over to the component. The second stage is then known as the Component Flow Stage. Inside this stage, the following can occur:
1 – If any Envelope Interceptors are configured, the before() methods of these interceptors are invoked. Interceptors are invoked in the order in which they are declared in your configuration file. They also act in sequence; i.e., the result of interceptor #1 is passed to interceptor #2 and so on.
2 – If any standard interceptors are configured, the intercept() methods of these classes are invoked.
3 – If there is a component configured for this service, Mule uses the Entry Point Resolver mechanism to figure out which method should be called. By default, the legacy entry point mechanism is invoked but this may be changed.
4 – If there is a component and if a method was chosen by the previous step, this is invoked. The return value of the method is wrapped up into another MuleMessage
5 – If any Envelope Interceptors are configured, the after() methods of these interceptors are invoked.
6 – The resultant MuleMessage (if any!) is then handed over to the Outbound Flow Stage.
Note that this stage operates in an independent thread from the Inbound Flow Stage only if the message flow is asynchronous. If synchronous, then it does not make sense to have multiple threads which will block and wait for one another so one thread governs the entire message flow in that case.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: component, entry point resolver, Envelope Interceptor, interceptor, MuleMessage, threading
October 15th, 2009 at 10:02 AM
[...] The Component F … 10/08 [...]