The document discusses staged event-driven architecture (SEDA), which decomposes complex, event-driven applications into stages connected by queues. This avoids high thread concurrency overhead and decouples event and thread scheduling from application logic. SEDA is implemented in Mule by dividing large flows into smaller flows connected by queues, using the queued-asynchronous processing strategy. This implements SEDA queues to decouple receiver threads from flow processing.

1. By Anirban Sen Chowdhary

2. SEDA is also known as staged event-driven architecture , is an approach
to software architecture that decomposes a complex, event-
driven application into a set of stages connected by queues.
This design avoids the high overhead associated with thread-based concurrency
models, and decouples event and thread scheduling from application logic.
Source :- Wikipedia

3. So, in simple words SEDA as a series of events sending messages between them.
One main reason to use this architecture, is that we can fragment the logic into
smaller pieces and can connect it and decouple each event, and is done mainly
for high performance and high control.

4. Advantage with SEDA :-
• Help to control on each event queue
• The service can be well-conditioned to load
• Preventing resources from being overcommitted when demand exceeds
service capacity.

5. A staged event-driven architecture basically contains the concept of queue:-

6. So, how can we implement SEDA in Mule ????

7. As already mentioned in the definition of SEDA that A complex big flow is
divided into multiple glow and the flows are connected to each other with a
queue .. So we will be developing a similar kind of flows here to implement a
simple example of SEDA architecture

8. Let’s consider we have a following flows implemented in Mule :-
As you can see both the flows are connected to each other with JMS queue

9. Now, if we look into our code we will find :-
You can see here, both the flows have processingStrategy="queued-asynchronous" and
both are connected by a JMS queue. You can also see that all the message processors in both
the flow are following SEDA ..

10. The reason I have processingStrategy="queued-asynchronous" in both the flow is, Mule uses a
queue to decouple the receiver thread from the rest of the flow. This means that once the receiver
places a message into a queue, it can immediately return and accept a new incoming message. This
specific type of queue implemented for the queued-asynchronous flow processing strategy is known
as a SEDA queue.

11. We can start our application and test it by hitting the url :-
http://localhost:8081/jms on the browser and we will the following in
our Mule console :-

12. So, you can see a simple example of implementing a SEDA in Mule by dividing the
flows and connecting them with a queue. But the important is the processing
strategy of the flows which should be queued-asynchronous
For more information on SEDA please visit Mule documentation :-
http://www.mulesoft.org/documentation/display/current/Flow+Processing+Strat
egies#FlowProcessingStrategies-TheQueued-
AsynchronousFlowProcessingStrategy

13. In my next slide I will bring some other techniques in Mule
implementation .
Hope you have enjoyed this simpler version.