Browse Prior Art Database

Governance of entities used in Event Driven Architecture Disclosure Number: IPCOM000235704D
Publication Date: 2014-Mar-21

Publishing Venue

The Prior Art Database


Context : In event driven architecture (EDA), event producers publish events to event agent and event consumers consume events from those agents. As event producers have no prior knowledge of the event consumers, this asynchronous interaction in EDA promotes loose coupling. In EDA, the responsibility of receiving, processing and routing events is handled by an event agent. We have developed a solution for governance of entities used in EDA. Traditional SOA gov- ernance solutions recommend governing service consumers and service providers. However, in EDA, it is important to govern event producers, event consumers, events and the event agent. Method: We have designed a model based solution for discovery and governance of entities used in EDA. Results: Developed solution promotes discovery, reuse and run-time look up of entities used in EDA. As a proof-of-concept we have developed a prototype implementation in order to assess the feasibility of this solution.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 12% of the total text.

Page 01 of 21

Governance of entities used in Event Driven Architecture


Governance models for service oriented architecture focus on the governance of service consumer and service provider. These governance models cannot be used as-is, with much success, to govern the EDA entities. In EDA based solutions, event agent[2] plays a significant role in capturing, translating and routing events between event producers and event consumers. This makes it important to govern event agent along with both event consumers and event producers. One might
argue that governing producers and consumers in EDA is no different from governing these entities in a traditional SOA. However, in EDA, both the event producers and event consumers are loosely coupled. They produce and consume events through the event agent. Hence, service level definitions, service level agreements and corresponding policies between these entities must be established and enforced via the event agent.

In short, two service level agreements, one between event agent and event consumer and other between event agent and event producer must be defined and enforced. In-spite of this conspicuous difference between SOA governance and EDA governance, not

much work has been carried out in the realm of governance for EDA entities. The objective of this article is to present a solution for governance of entities used in EDA. In order to achieve this objective, we have developed a model and a set of lifecycles for discovery and governance of such entities. E

ective EDA Governance

1) Visibility - ability to account for all the EDA entities available for use.

2) Reusability - ability to discover visible EDA entities thereby promoting reuse.

3) Traceability - ability to track when, where and who is using these EDA entities.

4) Enforcement - ability to enforce policies associated with generated events at run-time.

5) Monitoring - Ability to measure the availability of EDA entities and report on their adherence to service level agreement associated with these entities.

Visibility, reusability and traceability of EDA entities are achieved by using service repository and registry. Policies associated with the generated events can be enforced at run-time by an event agent. It is up to an event agent to retrieve these policies from service registry and repository and ensure that event consumers adhere to these policies by enforcing them at run-time. There are several products designed to monitor and report on run-time performance of entities.

These products may need changes to accommodate for EDA entities. This article focuses on the EDA governance aspects associated with the service registry and repository.


The EDA governance business class model represents the EDA entities, their metadata and the relationships between these entities in context of EDA. We begin by providing a brief overview of these entities and their relationships identified in this class