• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Correlation Architecture
 

Correlation Architecture

on

  • 1,747 views

 

Statistics

Views

Total Views
1,747
Views on SlideShare
1,741
Embed Views
6

Actions

Likes
0
Downloads
17
Comments
0

2 Embeds 6

http://www.linkedin.com 5
https://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Correlation Architecture Correlation Architecture Presentation Transcript

    • …Srinidhi Boray
    • • 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.
    • 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.
    • 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.
    • • 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.
    • 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.
    • • 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.
    • 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.
    • • 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
    • • 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
    • Event in Space Event in Time Field Events Event Sampling & Management Event Processing Event Decision Management Event(s)/ Response
    • 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