Event-driven messaging: Difference between revisions
Content deleted Content added
GreenC bot (talk | contribs) Move 1 url. Wayback Medic 2.5 per WP:URLREQ#ieee.org |
|||
| (32 intermediate revisions by 22 users not shown) | |||
| Line 1: | Line 1: | ||
{{Use dmy dates|date=October 2017}} |
|||
<!-- Do not use the "dated prod" template directly; the above line is generated by "subst:prod|reason" --> |
|||
| ⚫ | The '''event-driven messaging''' is a [[design pattern]] 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 (computer science)|polling]] based mechanism.<ref name='IIT'>Wajid Khattak, Vijay Narayanan.[http://www.informit.com/articles/article.aspx?p=1577450 Event-Driven Messaging][Online].Date accessed: 27 April 2010.</ref> |
||
{{orphan|date=March 2010}} |
|||
{{Wikify|date=March 2010}} |
|||
It's important to differentiate between event-driven and [[Message queue|message-driven (aka queue driven)]] services: Event-driven services (e.g. [[Amazon Simple Notification Service|AWS SNS]]) are decoupled from their consumers. Whereas queue / message driven services (e.g. [[Amazon Simple Queue Service|AWS SQS]]) are coupled with their consumers. <ref>{{Cite book |title=Domain-Driven Design with Java - A Practitioner's Guide |year=2022 |isbn=9781800564763}}</ref> |
|||
{{New unreviewed article|source=ArticleWizard|date=February 2010}} |
|||
| ⚫ | The ''' |
||
==Rationale== |
==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. 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 |
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.<ref>{{Cite web |title=A Complete Guide to Computer System Validation (CSV): What is it and why do we need it? |url=https://qbdgroup.com/en/a-complete-guide-to-computer-system-validation/ |access-date=2023-05-23 |website=QbD Group |language=en}}</ref> 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 |
In order to tackle this problem, the event-driven messaging design pattern suggests a [[Publish/subscribe|publisher-subscriber communication mechanism]] that ensures timely notification of event related data to the service consumer,<ref name='Mauro Comp'>Mauro. et al. [http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 Service Oriented Device Integration – An Analysis of SOA Design Patterns.] {{webarchive |url=https://web.archive.org/web/20110203194511/http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2010.336 |date=3 February 2011 }} [Online], pp.1–10, 2010 43rd Hawaii International Conference on System Sciences, 2010. Date accessed: 4 April 2010.</ref> thereby eliminating the inefficiencies linked with the traditional polling based communication mechanism. |
||
==Usage== |
==Usage== |
||
[[Image:SOA DP Event-Driven Messaging A.JPG|thumb|alt=Diagram A|Diagram A<br/> |
[[Image:SOA DP Event-Driven Messaging A.JPG|thumb|alt=Diagram A|Diagram A<br/>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.]] |
||
[[Image:SOA DP Event-Driven Messaging B.JPG|thumb|alt=Diagram B|Diagram B<br/>The event manager automatically notifies all the interested service consumers about the occurrence of a particular event the moment it actually happens.]] |
[[Image:SOA DP Event-Driven Messaging B.JPG|thumb|alt=Diagram B|Diagram B<br/>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 |
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.<ref name='Mauro'>Mauro et al. [http://home.in.tum.de/~sunyaev/papers/soda1v3.pdf Standardized Device Services – A Design Pattern for Service Oriented Integration of Medical Devices] [Online].Date accessed: 4 April 2010.</ref> This communication mechanism shares its roots with the [[Observer pattern]] applied traditionally within the [[Object-oriented design|object-oriented]] world.<ref name='Mauro'/> This design pattern also borrows some concepts from the [[Event Driven Architecture|Event-Driven Architecture]] as the fundamental rationale behind this design pattern is responding to events.<ref name='SOAWorldMag'>[[Thomas Erl]].[http://soa.sys-con.com/node/645271?page=0,2 Introducing SOA Design Patterns] {{Webarchive|url=https://web.archive.org/web/20100913104647/http://soa.sys-con.com/node/645271?page=0,2 |date=13 September 2010 }}[Online].Date accessed: 4 April 2010.</ref> |
||
The actual implementation of such a |
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 [[Enterprise service bus|ESB]] product should normally be able to provide such functionality. The application of this pattern helps to further decouple<ref name="CouplingTypes">[[Service Loose Coupling#Coupling types|Coupling Types]]</ref> the service consumers from the service providers and increases the overall reliability of a service composition. |
||
==Considerations== |
|||
The application of this pattern is dependent upon the existence of underlying platform extensions, which if not already present, would incur extra cost and therefore would impact the IT budget. It should also be noted that the publisher-subscriber model is based on [[asynchronous]] messaging, so the transmission of a message from the event manager can take place at any time, which could mean that if the event manager broadcasts an event notification message then it's not necessary that the service consumer would be online to receive it. Therefore, the application of this design pattern does not solve the unavailability problems. However, this could be addressed by further applying the Asynchronous Queuing<ref name='aq'>[http://soapatterns.org/asynchronous_queuing.php Asynchronous Queuing]</ref> and the Reliable Messaging<ref name='rm'>[http://soapatterns.org/reliable_messaging.php Reliable Messaging]</ref> design patterns that guarantee that a transmitted message is always received by the intended receiver along with acknowledgment messages. |
|||
The introduction of architectural extensions would affect the current service inventory architecture and the way service compositions are designed, therefore, also affecting the service composition architectures. |
|||
== References == |
== References == |
||
{{Reflist}} |
{{Reflist}} |
||
* Erl et al.,(2009).[ |
* [[Thomas Erl|Erl]] et al.,(2009).[https://www.amazon.com/dp/0136135161 SOA Design Patterns]. Prentice Hall. {{ISBN|0-13-613516-1}}. |
||
* Michael Stal.[https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1605179 Using Architectural Patterns and Blueprints for Service-Oriented Architecture][Online].Date accessed: 1 May 2010. |
|||
== External links == |
== External links == |
||
* [ |
* [https://patterns.arcitura.com/soa-patterns SOA Patterns] |
||
* [http://www.soaglossary.com/ SOA Terms Glossary] |
|||
* [http://www.soapatterns.org SOA Design Patterns] |
|||
[[Category:Service-oriented (business computing)]] |
[[Category:Service-oriented (business computing)]] |
||
Latest revision as of 03:35, 31 July 2024
The event-driven messaging is a design pattern 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]
It's important to differentiate between event-driven and message-driven (aka queue driven) services: Event-driven services (e.g. AWS SNS) are decoupled from their consumers. Whereas queue / message driven services (e.g. AWS SQS) are coupled with their consumers. [2]
Rationale
[edit]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.[3] 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,[4] thereby eliminating the inefficiencies linked with the traditional polling based communication mechanism.
Usage
[edit]
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.
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.[5] This communication mechanism shares its roots with the Observer pattern applied traditionally within the object-oriented world.[5] This design pattern also borrows some concepts from the Event-Driven Architecture as the fundamental rationale behind this design pattern is responding to events.[6]
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[7] the service consumers from the service providers and increases the overall reliability of a service composition.
References
[edit]- ^ Wajid Khattak, Vijay Narayanan.Event-Driven Messaging[Online].Date accessed: 27 April 2010.
- ^ Domain-Driven Design with Java - A Practitioner's Guide. 2022. ISBN 9781800564763.
- ^ "A Complete Guide to Computer System Validation (CSV): What is it and why do we need it?". QbD Group. Retrieved 23 May 2023.
- ^ 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.
- ^ a b Mauro et al. Standardized Device Services – A Design Pattern for Service Oriented Integration of Medical Devices [Online].Date accessed: 4 April 2010.
- ^ Thomas Erl.Introducing SOA Design Patterns Archived 13 September 2010 at the Wayback Machine[Online].Date accessed: 4 April 2010.
- ^ Coupling Types
- Erl et al.,(2009).SOA Design Patterns. Prentice Hall. ISBN 0-13-613516-1.
- Michael Stal.Using Architectural Patterns and Blueprints for Service-Oriented Architecture[Online].Date accessed: 1 May 2010.