Talk:Event-driven architecture

EDA concept: got it! Now, how do I implement it?

I understand the terminology and the concepts. But what products, frameworks, libraries exist to implement EDA? If I use JMS and message-driven beans subscribing to specific topics, is it EDA?

• Answer: Using a messaging broker with a JMS topic per event type is a common implementation strategy for an event bus. However, point-to-point connection between emitters and consumers can lead to more scalable and flexible architectures. The point-to-point implementations are more complex and often require an eventing framework.

EDA vs EDP

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)

It's a technical subject. How stringent is the requirement to make it accessible to non-techies? How far do we have to go? Look at multivariable calculus. There's no way a non-mathematician is going to understand that. Yet it's all accurate and skillfully written.

This article at least uses a real world example of the car dealership's IT system, which could notice and respond to the event of a car's (or more precisely the car's database record in some system) changing from "for sale" to "sold." Continuing and extending that example in layman's terms could be a very successful way to make the article more accessible to a wider audience.

I don't think it needs copyediting, and I think it's tone and style are fine. I think what people are striving for is that it be re-written for a less technical audience. Petershank 23:40, 2 March 2007 (UTC)

Based on your comment, I would begin to agree that the {{confusing}} tag could be removed, but I still feel there's copyediting required. For example, the Simple event processing section does provide two examples but the sentence is written in an informal tone. --Sigma 7 17:47, 8 March 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. --JVersteeg 22:04, 11 February 2007 (UTC)

The problems are more likely related to the style or tone of the article. Based on other tags, the article may be a little confusing - while I can understand it, I'm not comfortable with how it's described (but I'm not sure how to correct it with references that I have). --Sigma 7 16:39, 15 February 2007 (UTC)

Relationship to Event-Driven Programming

There are certainly differences in scope (single process versus multiple physical nodes across the enterprise), but there are many shared concepts between the two. The syntax and mechanisms differ, but there are events in many languages, such as C#, that you can subscribe to. EDA takes that earlier model and expands upon it, and it would be useful to see that explained, which would also give a good introduction to the subject. —Preceding unsigned comment added by 64.91.76.251 (talk • contribs)

Event processing styles section is not clear

"Event processing styles" section needs to be more elaborative. I wanted to know about EDA and it is confusing to know the different between Simple Event Processing and Event Stream Processing. The explanation given says that both of them are meant for real-time flow but not depicting the difference. And, please explain what is a "complex event" before explain Complex Event Processing style. — Preceding unsigned comment added by Cuddaloredavinci (talk • contribs) 09:28, 18 July 2017 (UTC)