Event-driven messaging

Last updated

The event-driven messaging is a design pattern, applied within the service-orientation design paradigm to enable the service consumers, which are interested in events that occur within the periphery of a service provider, to get notifications about these events as and when they occur without resorting to the traditional inefficient polling based mechanism. [1]

Contents

Rationale

The interaction between a service consumer and a service provider is normally initiated by the service consumer as it needs to respond to an event that occurs within the boundary of the service consumer itself, e.g. requiring some data from an external resource (i.e. the service provider) in order to perform a calculation whose results need to be relayed back to a user interface in response to an action performed by the user. [2] However, there are situations where the service consumer needs to wait for the occurrence of an event within the boundary of the service provider itself. Under these circumstances, the service consumer somehow needs to be informed of the event as and when it happens. One way is to program the service consumer to poll the service provider with regular intervals so that it can check if the event happened or not. This approach not only manifests inefficiency but also behavioral unpredictability. Inefficiency because the service consumer and the service provider are engaged in unproductive interactions and unreliable because it might be that the event actually happened more than once before the service consumer could poll the service provider, thereby missing the previous events and their related data. Apart from these problems, such a technique also introduces latency as the interval with which the service consumer performs the polling is fixed and, therefore, it would only fetch the event data at that time and not when the event actually occurred. This whole scenario deteriorates even further if multiple service consumers are dependent on a particular service provider.

In order to tackle this problem, the event-driven messaging design pattern suggests a publisher-subscriber communication mechanism that ensures timely notification of event related data to the service consumer, [3] thereby eliminating the inefficiencies linked with the traditional polling based communication mechanism.

Usage

Diagram A To find out if a particular event has occurred or not, the service consumer polls the service provider with regular intervals, which results in inefficient service interactions. SOA DP Event-Driven Messaging A.JPG
Diagram A
To find out if a particular event has occurred or not, the service consumer polls the service provider with regular intervals, which results in inefficient service interactions.
Diagram B The event manager automatically notifies all the interested service consumers about the occurrence of a particular event the moment it actually happens. SOA DP Event-Driven Messaging B.JPG
Diagram B
The event manager automatically notifies all the interested service consumers about the occurrence of a particular event the moment it actually happens.

The application of the event-driven messaging design pattern requires an event manager with whom the service provider registers its events. The service consumers then register their interest in few or all of the advertised events. Upon the occurrence of an event, the service provider informs the event manager that then notifies all the registered service consumers instantly. [4] This communication mechanism shares its roots with the Observer pattern applied traditionally within the object-oriented world. [4] This design pattern also borrows some concepts from the Event-Driven Architecture as the fundamental rationale behind this design pattern is responding to events. [5]

The actual implementation of such a publisher–subscriber-based communication mechanism requires architectural extensions in order to provide such a complex message tracking and forwarding mechanism. A mature ESB product should normally be able to provide such functionality. The application of this pattern helps to further decouple [6] the service consumers from the service providers and increases the overall reliability of a service composition.

Related Research Articles

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

In computing and systems design, a loosely coupled system is one

  1. in which components are weakly associated with each other, and thus changes in one component least affect existence or performance of another component.
  2. in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

In software architecture, a messaging pattern is an architectural pattern which describes how two different parts of an application, or different systems connect and communicate with each other. There are many aspects to the concept of messaging which can be divided in the following categories: hardware device messaging and software data exchange. Despite the difference in the context, both categories exhibit common traits for data exchange.

A service delivery platform (SDP) is a set of components that provides a service(s) delivery architecture for a type of service delivered to consumer, whether it be a customer or other system. Although it is commonly used in the context of telecommunications, it can apply to any system that provides a service. Although the TM Forum (TMF) is working on defining specifications in this area, there is no standard definition of SDP in industry and different players define its components, breadth, and depth in slightly different ways.

Event-driven architecture (EDA) is a software architecture paradigm concerning the production and detection of events.

The OASIS Reference Model for Service Oriented Architecture (SOA-RM) is an abstract framework for understanding significant entities and relationships between them within a service-oriented environment, and for the development of consistent standards or specifications supporting that environment. It is based on unifying concepts of SOA and may be used by architects developing specific service oriented architectures or in training and explaining SOA.

Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Service-orientation design principles are proposed principles for developing the solution logic of services within service-oriented architectures (SOA).

In the domain of the service-orientation design paradigm, the Enterprise Inventory is a design pattern by Thomas Erl that answers the question, "How can services be delivered to maximize recomposition?"; the application of this pattern results in a standardized enterprise-wide service inventory that fosters repeated service composition.

Within the service-orientation design paradigm, Service Refactoring is a design pattern, which is applied to an existing service so that either the service logic or its implementation can be changed without affecting the service consumers.

The standardized service contract is a software design principle applied within the service-orientation design paradigm to guarantee that service contracts within a service inventory adhere to the same set of design standards. This facilitates standardized service contracts across the service inventory.

Service abstraction is a design principle that is applied within the service-orientation design paradigm so that the information published in a service contract is limited to what is required to effectively utilize the service The service contract should not contain any superfluous information that is not required for its invocation. Also that the information should be limited to the serviced contract only, no other document or medium should be made available to the service consumers other than the service contract that contains additional service related information.

Service statelessness is a design principle that is applied within the service-orientation design paradigm, in order to design scalable services by separating them from their state data whenever possible. This results in reduction of the resources consumed by a service as the actual state data management is delegated to an external component or to an architectural extension. By reducing resource consumption, the service can handle more requests in a reliable manner.

In computing, service composability is a design principle, applied within the service-orientation design paradigm, that encourages the design of services that can be reused in multiple solutions that are themselves made up of composed services. The ability to recompose the service is ideally independent of the size and complexity of the service composition.

Domain Inventory is a design pattern, applied within the service-orientation design paradigm, whose application enables creating pools of services, which correspond to different segments of the enterprise, instead of creating a single enterprise-wide pool of services. This design pattern is usually applied when it is not possible to create a single inventory of services for whole of the enterprise by following the same design standards across the different segments of the enterprise. The Domain Inventory Design pattern by Thomas Erl asks, "How can services be delivered to maximize recomposition when enterprise-wide standardization is not possible?" and is discussed as part of this podcast.

Service normalization is a design pattern, applied within the service-orientation design paradigm, whose application ensures that services that are part of the same service inventory do not contain any redundant functionality. This design pattern emphasizes on creating normalized services, much like creating normalized tables in a database where all the attributes in a table only relate to the entity described by the table and any attributes that do not directly relate to the entity are either put into a new table or in an existing table that better fits the context of that attribute.

Service layer is an architectural pattern, applied within the service-orientation design paradigm, which aims to organize the services, within a service inventory, into a set of logical layers. Services that are categorized into a particular layer share functionality. This helps to reduce the conceptual overhead related to managing the service inventory, as the services belonging to the same layer address a smaller set of activities.

Canonical Protocol is a design pattern, applied within the service-orientation design paradigm, which attempts to make services, within a service inventory, interoperable with each other by standardizing the communication protocols used by the services. This eliminates the need for bridging communication protocols when services use different communication protocols.

In software engineering, Canonical Schema is a design pattern, applied within the service-orientation design paradigm, which aims to reduce the need for performing data model transformation when services exchange messages that reference the same data model.

Entity abstraction is a design pattern, applied within the service-orientation design paradigm which provides guidelines for designing reusable services whose functional contexts are based on business entities.

References

  1. ↑ Wajid Khattak, Vijay Narayanan.Event-Driven Messaging[Online].Date accessed: 27 April 2010.
  2. ↑ "A Complete Guide to Computer System Validation (CSV): What is it and why do we need it?". QbD Group. Retrieved 23 May 2023.
  3. ↑ Mauro. et al. Service Oriented Device Integration – An Analysis of SOA Design Patterns. Archived 3 February 2011 at the Wayback Machine [Online], pp.1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.
  4. 1 2 Mauro et al. Standardized Device Services – A Design Pattern for Service Oriented Integration of Medical Devices [Online].Date accessed: 4 April 2010.
  5. ↑ Thomas Erl.Introducing SOA Design Patterns Archived 13 September 2010 at the Wayback Machine [Online].Date accessed: 4 April 2010.
  6. ↑ Coupling Types
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.