The document discusses the evolution of event-driven architectures. It notes that while event-driven concepts have long existed, they became more prominent in control engineering applications involving sensors. Modern architectures like SOA and BPM benefit from incorporating event-driven design to better handle interdependencies between systems. Early frameworks like CORBA aimed to facilitate interoperability but had inherent limitations that newer approaches address.

1. …Srinidhi Boray

2. • Event driven is nothing new. It has existed ever
since computing began. But then the emphasis
was not architectural.
• As the technologies advanced; especially in the
control engineering where ‘sensors’ based
application is prevalent; Event driven design
became a paradigm.
• The ferocity of the competition in the market
has created a greater need for
interdependencies among the systems. Event
Driven Architectures, complementing SOA &
BPM ensures to achieve such a system.

3. 1989 – OMG was Born
• To facilitate interdependencies among the
businesses architectural frameworks were
sought; such as ‘Common Object Request Broker
Architecture’.
• The motive then was to promote object oriented programming and
distributed architecture to achieve greater functional
interdependencies.
• However, the functions still remained quite tightly coupled in
most cases.

4. 2001 – Model Driven Architecture Introduced
• Motive was to achieve
– a better holistic design,
– while promoting better use of strong
notation (UML)
– better ‘separation of concerns’
– Platform Independent Model
– Platform Specific Model
– model transformation and engineering
change management
• This addressed better design management, but the
inherent problems that were in CORBA did not go away.
Although some loose coupling occurred.

5. • As software architectures evolved, the designs moved
from hardware into software.
• Telecom is a classic example. The architecture that was
tightly coupled to the hardware gradually moved the
management functions embedded in the hardware into
the software.
• Almost all the embedded engineering is ‘event
dependent’. This means a paradigm shift in the
software architecture approach to incorporate the
functions migrated from the hardware.

6. During late 2000s
• SOA has taken center seat..
– SOA relies on
• Loose Coupling
• Coarse Grain
• This means the atomic structure of the
‘services’ is lot more larger than the object
oriented ‘function’
• Furthermore, the services are brought together
to instantiate business processes by another
component - ‘orchestration’.
• The design of the ‘orchestration’ layer creates a
greater need for an architecture that is ‘event
driven’ such that this layer is service/function
independent.

7. • To achieve a coherent model, the event driven design
paradigm requires being shifted from the level of services
into the orchestration component of the architecture
framework. This requires creating another layer called
‘Enterprise Service Bus’
• The ESB concept is a new approach to integration that can
provide the underpinnings for a loosely coupled, highly
distributed integration network that can scale beyond the
limits of a hub-and-spoke EAI broker.
Ref: David Chappell
• An ESB is a standards-based integration platform
that combines
•messaging
•web services
•data transformation and
•intelligent routing
to reliably connect and coordinate the interaction of
significant numbers of diverse applications across
extended enterprises with transactional integrity.

8. What are Services
• Services are request/response mechanisms.
• A service consumer makes a request and a service provides a response.
Essentially, a service consumer calls the service operation of a service and
the information flows through the service interface. Then the service
implementation processes the request and provides the information to the
service interface that responds.

9. • When Services do not act as requesters
but instead Events trigger a complex array of
interdependent business processes to respond
to a condition, the design paradigm shifts to :
Event Driven Architecture (EDA)
• In an EDA, a complex array of
business processes turns into a
non-hierarchical net-centric
structure

10. • While EDA is fundamentally different from SOA,
the two styles are not contradictory and, in fact,
they work together well.
• EDA is a request/response architecture
• Service consumers make requests of services
and wait for responses
• The idea of EDA is quot;fire and forget.quot; Systems are
constructed to respond to events that occur in
software or in the real world.
• Once an event has occurred, a cascading
process begins in reaction to the event.
Ref: Enterprise SOA: Designing IT for Business Innovation
By Dan Woods; Thomas Mattern

11. Event in Space Event in Time
Field Events
Event Sampling & Management
Event Processing
Event Decision Management
Event(s)/
Response

12. Sense / Interpret
Event in Space Event in Time
Field Events
Event Listener
Event Handler
Event
Sampling & Sequential
Management
Event Disseminator
Stream
Event Assimilator
Event
Processing Event Correlation Engine Complex
Business Activity Monitoring
Event Decision Rules Engine Event Data Base
Management
Interpret & Response
Event Controller Knowledge Management System
Logistics
Stochastic
Probabilistic Discreet Event
Pattern
Date Modeling Modeling
Event/s Aggregator
Response