What is evident in process control systems or tasks like train or plane traffic control, ticket reservation, etc., is a revelation in business information systems. Funny, that it took half a century of experience to recognize the need to work in real-time and process the input stream of events. The appearance of the EDA was the first step toward useful results.
In 2006, Gartner organized an analytical group that worked on Event-driven architecture, EDA. The term EDA was proposed by Gartner analyst Roy W. Schulte three years earlier in The Growing Role of Events in Enterprise Applications.
It is regrettable to note that creating even complex corporate information systems for a long time resembled the collection of jigsaw puzzles using the “scientific poke” method rather than design. To be convinced of this, it is enough to compare the design culture that has developed in IT with classical design schools in the field of aircraft, ships, and bridges. The far from a simple process of assembling this very mosaic is burdened not only by the lack of a general prototype scheme but also by the incompleteness of the set of fragments from which the system is built.
However, the set of parts for assembly is constantly expanding. With the advent of business process modeling (BPM) and the introduction of event-driven architecture, it finally takes on the features of completeness. The approaches implemented in BPM and EDA introduce a natural order. They allow you to first build a model and then combine individual fragments into a single system adapted to the conditions of the external environment.
Any enterprise exists in the real world filled with events. It cannot fail to work out the input stream of events from the surrounding world, but even with the most advanced information systems, this happens implicitly, mainly at the level of managerial personnel. So, implementing EDA ideas marks the beginning of the migration of event processing functions from people to automated systems.
Up to a point, SOA and EDA went hand in hand in the minds of analysts, but then the event-driven architecture fell out of favor and was forgotten. Maybe the concept was too revolutionary, or perhaps the idea of Complex event processing (CEP) diverted the primary attention, but due to the delay in the introduction of technologies such as RFID, it went into the shadows, taking EDA with it. But something else is essential for us to:
Firstly, unlike SOA, EDA is an architecture, i.e., a particular approach to building an enterprise information system;
second, the concept of event-driven architecture explains why interest in the enterprise service bus (ESB) is now outstripping interest in SOA.
I’ll start with why SOA is not architecture. SOA was architecture at the time of its inception, as long as it was associated with such a picture. But the idea of pre-registering services in the registry and discovering them during execution didn’t work.
But EDA is an architecture, i.e., a pattern that describes the interaction between software components, each of which has a specific role: one piece generates a message, the other intercepts and processes it, if necessary, calling third components for this. Generally speaking, this is what integration environments have always done.
The next subtlety is that to build a service-oriented architecture, and the Enterprise service solution is generally not needed. Applications themselves can provide services. The ESB was positioned as a service development tool for legacy applications. But if such an application somehow develops, then you can pull out programming interfaces from it and wrap them with services without the help of ESB. And suppose the application is already entirely inherited and no one understands how it functions inside itself. In that case, it will not be possible to “pull out” services from it using ESB. But to build an event-driven architecture and integration environment is necessary. Events must be intercepted, transformed, routed, etc.
Thus, EDA puts everything in its place. Let’s analyze the most common myths about integration. We will give just a few of them:
Myth №1: Enterprise architecture can prevent the need for integration. Reality: no enterprise can afford to rewrite all existing applications from scratch, so organizations, one way or another, will have to work with a set of disparate systems
Myth №2: Packaged application suites will eliminate the need for integration. Reality: the introduction of such applications will increase the demand for integration; new systems will have to be integrated with existing applications
Myth № 3: Application servers will allow you to abandon the use of integration environments. Reality: Application server vendors, seeing the need for integration and business process management tools, have included ESB and BPMS in their solutions.
That’s what’s important!
The industry is ready for EDA support. Many vendors are already shipping or preparing to send the necessary middleware and development tools tailored to the new architecture’s specifics.
Existing messaging and Web services-oriented middleware are acceptable for the most basic applications. Known J2EE-based application servers can be used, but it is more likely that further development of servers will aim to be more adapted to event handling.
Specialized integration brokers can implement more complex “event” applications that use content-aware event routing and business process controls. Such tools will appear no earlier than 2006.
The most complex forms of event applications will require the use of complex event processing (CEP) techniques, if you need professional advice, this is the right place to ask your questions. The famous theorist of this trend is David Luckham, whose work can be found in the Extreme Technologies section of this issue of the journal. In addition, several start-up companies are now engaged in such activities.
Modern operating systems and network and systems management tools use separate elements of CEP. Still, their development in the coming years will be associated with the provision of event-based applications. The need to support such applications will determine the development of modeling tools.
The standardization process is already underway. Generally accepted standards for EDA do not yet exist, but it is hoped that they will appear within a few years.
