Talk:Event-driven architecture

I don't think Event Driven Programming is necessarily the same as Event Driven Architecture - unless you believe that IT architecture is not a valid discipline. Architecture defines the framework and concepts, while programming realises and implements them. I don't think a preemptive redirect on the Event Driven Architecture page is appropriate, this article should be restored as a standalone article. Peter Campbell Talk! 23:41, 1 August 2006 (UTC)

(Also posted on User talk:JulesH)

I'm not sure that I agree. Yes, design and implementation are two seperate concepts. But really, that's the point. The implementation is just a concrete example of the design (or any design), and as such I think we should look to merge the articles. Antgel 02:43, 16 January 2007 (UTC)

Okay, talking to myself, but having read http://en.wikipedia.org/wiki/User_talk:JulesH#Redirect_on_Event_Driven_Architecture_page apparently there was a merge effort which didn't reach consensus. Seeing as the article is in need of copy-edit, perhaps we should look again at a merge? Antgel 02:48, 16 January 2007 (UTC)

Event-Driven Architecture

YouMal 16:05, 11 August 2006 (UTC)To understand event-driven architecture, one must start with this general rule: Processes are triggered by events and processes invoke operations. Operations in turn can generate events, which will trigger other processes.

In an event-driven architecture, events are used to reduce complexity in processes. The processing for an event needs to be "atomic" even if the process is a long-running one. If operations in the current process for handling the event are entry-points to other processes, we will rightly expect the atomicity to include the other processes as well. Ensuring the atomicity of the whole chain of processing can become quite complex.

To reduce complexity in an event-driven design, the operations in a process will be limited to only those operations that are critical for handling the event. Any other processing that is identified as non-critical or as a by-product of the original processing are catered for in the original process as an operation that just records an event. The latter event will then be processed independently from the original process. With such a design, atomicity of the original process only has to include the recording of the events that will trigger the other sub-processes, and not the processing of the sub-processes.

Let us take an example to illustrate this. If someone triggers an inter-account funds transfer at an ATM, we expect the process to include a debit operation followed by a credit operation. There are also additional operations that need to take place for handling such an event: accounting entries and recording of performance indicators are good examples. If you look closely at what are the critical parts for handling the event (in this case, it is what needs to occur online to give a result to the customer), you will agree that only the debit and credit operations are important. The rest are by-products that can just be recorded as events in the current processing.

Such an approach dramatically reduces complexity, and draws even more benefits because it allows for asynchronous processing of the events produced as by-products. The asynchronous processing and event persistence allows for the events to be processed at a later time when dependent resources permit, which may not be the case when the original process was running.

It is important to realize that atomicity in event-driven architectures does not necessarily exhibit the ACID properties we generally expect of atomic transactions. Event-driven designs tend to promote long-running transactions. This imposes compensation processes to be made available when there are failures. Here again, the compensation process will be fired (asynchronously) as part of the recording of a failed event.

The next thing that comes to mind is how to guarantee that the processing of an event has completed (and is therefore atomic). The design I would propose is to notify the event source when the processing completes. The event source does not need to be notified of successful completion of all the individual operations making up the process; only notification of the end of the process is important. Such a design reduces complexity dramatically.

Let us take an example to illustrate this. When you send a letter by post and you want to be guaranteed of its delivery, you ask for a delivery receipt to be sent to you. You do not need to be aware of all the intermediate steps (post-offices and postmen) that were involved to deliver the letter. When you get the receipt, you get a guarantee that your letter was delivered. It can also happen that you do not get the delivery receipt after an expected period. This is a sign that your letter may not have reached its destination. In such cases, you typically re-send a copy of the same letter. This approach must surely ring bells for communications people.

By making a process notify its event source of its completion, you guarantee the completeness of all steps in the process. If, after an expected time, which will become a sort of SLA, you do not get the notification, then you generate an event which will be for the process you want to run when an expiry time has been reached. In some cases, the process for the expired-time event can be just a replay of the process because you want the same processing to occur. In other cases, a compensation process could fire if your requirement is to cancel the effects of the previous process wherever it may have gone wrong.

Since processes can be replayed in an event-driven design (to cater for completion notification failures), the operations inside the processes must be made idempotent. Idempotent operation requirement and notification of completeness requirement also apply to compensation processes because these processes have the same requirement for atomicity as any other process.

In an event-driven design, care must be taken to properly segment the processes with the corresponding events, and to properly evaluate the impact of the latency in integrity establishment (due to the asynchronicity of compensation processes). The benefits of reduced complexity in processes and enhanced scalability via asynchronicity make event-driven architecture a very attractive solution to complex integration and system design problems.

Last but not least, event-driven architecture can provide a very effective and low-cost solution to disaster recovery. Since it is understood that all processes must be triggered by events, it follows that if we have the events, we can just replay them and get back to a state with full integrity. If we have properly designed our operations to be idempotent (as mentioned above), then replay of events can occur at any point in time independently of the time the failure occurred and independently of the system which failed. This has a dramatic simplification effect on recovery procedures. It is based on the same principle as the transaction log in database systems.

To conclude, event-driven architectures can solve very complex process design and integration problems while at the same time provide for reliable and simplified disaster recovery.

Author: Youri MALLECK-AHMED mailto:youri.malleckahmed@mcb.co.mu

This article needs to be more general

This article needs to bring out the ideas, and not go so deeply into language-dependent jargon. I would expect to see at least a passing mention of agent-oriented systems, and a more detailed discussion of blackboards, and so forth. Trishm 11:31, 24 January 2007 (UTC)

There is no way in the world a non-techie is going to understand this. We need to get some of the basic concepts down first, including what "traditional" software does.Trishm 06:03, 5 February 2007 (UTC)

Copyedit notice?

I just read through the article and didn't notice any weird grammar or spelling. I'm not a native English speaker but feel pretty confident the "copyedit" notice can be removed.