Microsoft TechDays 2010 Portugal – Event-Driven Architectures: Why, When and How?

   During TechDays 2010 in Portugal I did a session about “Event-Driven Architectures: Why, When and How?”. This was a level 300 session and we looked at real situations where we could make use of the EDA Approach. The purpose of this session was to show Why we need another approach other then SOA, and When is EDA a better approach than SO. To finalize we looked at How we can implement EDA, as well the components that this approach uses, and their product mapping.

   So the session was based on the following:

  • Introduction
    • Common Thoughts about SOA and EDA
      • SOA is just a Synchronous RPC (mostly over Web Services)
      • EDA is SOA
        • No. EDA is not SOA. “Event-driven architecture can complement service-oriented architecture (SOA) because services can be activated by triggers fired on incoming events. This paradigm is particularly useful whenever the sink does not provide any self-contained executive” according to Wikipedia.
      • The Best of EDA and SOA is combined in SOA 2.0
        • That’s right. SOA 2.0 is also known and Event-Driven SOA. “the ability to create high-level business events from numerous low-level system events. Events are created by filtering real-time data (from middleware, applications, databases, and Web services, for example) and infusing it with defining detail such as dependencies or causal relationships discovered by correlating other events.” according to Wikipedia.
    • Why do we need this?
      • Basically due to a Trend Change that move to a more On-Demand Business, due to:
        • The several organization structure changes
        • Outsourced processes to External Partners
        • Departments and Business Units are now seen as Service Providers
        • Loose Coupling of application components
      • Example of this is EAI. Ways to achieve this? 
        • File Transfer
          • Problems
            • Various non-Standard Formats.
            • Translation is needed from one to another format
            • Manually Loaded
        • Shared Databases
          • Problems
            • Data is tightly coupled to multiple applications
            • Impossible to make incremental or partial updates
        • Web Services
          • Problems
            • Requires services to be available at invocation
            • Results in multiple call stacks
            • Resource consuming
            • Yet another Remote Procedure Call (RPC, COM, Corba, DCOM, ...)
        • Messaging
          • Benefits
            • Defined data format
            • Asynchronous Operations
            • Minimized Coupling
            • Fault Tolerance
            • Data Freshness
          • Problems
            • Almost Impossible to make “reactive” applications
        • Events
          • Benefits
            • Represent a change in state
            • Self-Contained
            • Uniquely indentified
            • Time relevant, not time sensitive
            • Sourced using messaging
            • Observable
          • Event Types
            • Execution
            • Lifecycle
            • Management
            • Business
  • Event Driven Architecture
    • What is EDA?
      • Architecture pattern that orchestrates behavior around:
        • Production
        • Detection
        • Consumption of events as well as the responses they invoke.
      • Method for building enterprise systems in which events flow between decoupled components and services
      • A maintainable, sustainable and extensible model for building complex, distributed applications
      • Suited for Asynchronous, unpredictable environments
      • Extremely Loosely Coupled
      • Inversion of communication
        • In contrast to the direct communication frequently used in a composite SOA, or other architectures, communications is done asynchronously through publishing events
    • Why do we need EDA?
      • Companies must manage and react to a large number events every day in real time
        • Real time trade settlement systems
        • Flight reservation system
        • Streaming stock data
        • Real time vehicle location for transportation companies
        • Stock Exchange Market systems
      • System designers normally must support both events and Services
      • Systems must be “Business Oriented”
    • Types of EDA?
      • Simple Event Processing
        • Commonly used to drive the real-time flow of work—taking lag time and cost out of a business
      • Event Stream Processing
        • Commonly used to drive the real-time flow of information in and around the enterprise, which enables in-time decision making
      • Complex Event Processing
        • Commonly used to detect and respond to business anomalies, threats, and opportunities.
    • Implementation Components

                 

    • Event Flow Layers
      • Event Generator
        • Every event is generated from a source. The source might be an application, data store, service, business process, transmitter, sensor, or collaboration tool (IM, email). An ordinary event may be evaluated for notability by an event preprocessor (router, filter), resulting in the generation of a new notable event.
        • Because of the variety of event generators, not all events will be generated in the required format for event processing. In those cases, the events need to be transformed to the required (enterprise standard) format prior to being deposited in the event channel.
      • Event Channel
        • The event channel, typically a messaging backbone, transports standard formatted events between event generators, event processing engines, and downstream subscribers.
      • Event Processing Engine
        • In the event processing layer, upon receipt, events are evaluated against event processing rules, and actions are initiated. The event processing rules and actions are defined in accordance to the needs of the interested parties, not of the event generators.
        • The actions include invoking a service, initiating a business process, publishing the event out to a subscription hub, directly notifying humans or systems, generating a new event, and/or capturing the event for historical purposes.
        • Events are processed by engines. A simple engine processes each event occurrence independently.
        • A complex engine processes new event occurrences in context of prior and future events.
      • Downstream Activity
        • A single event, or event correlation, may initiate numerous downstream activities. The invocation of the activity might be a push by the event processing engine (service invocation, business process initiation, notification) or a pull by subscribers of event publications.
        • Subscribers might be humans, applications, active business processes, data warehouses, performance dashboards, and/or automated agents.
        • Events should be published in the standard event format. Transformation to subscriber-specific formats is typically done by an enterprise integration backbone.
  • SOA vs EDA
    • SOA
      • Applications are composed in design-time
      • Linear flow between services
      • Predictable behavior
      • Request/Response is common, and often overused
    • EDA
      • Applications are composed at run-time
      • Asynchronous components
      • Reactive behavior
    • What do SOA applies to?
      • Vertical interaction between the hierarchical layers of functional decomposition
      • Functional request-and-reply processes such as man-machine dialogues; the user waits for an answer
      • Processes with a transactional nature which require commit and rollback facilities
      • Data enrichment in a message to be published to bring the message to its full content in a formal format
    • What do EDA applies to?
      • Horizontal communication between tiers in a process chain
      • Workflow type of processes
      • Processes that cross recognizable functional organization borders, external (B2B) as well as internal
    • Conclusion
      • There’s no SOA vs EDA, they really work very well together and complete one another
  • How to Implement
    • Using Web service technologies today, and additional SOAP-aware message queuing infrastructure.
    • Current ESB infrastructures provide a way of message queuing combined with Web service technologies.
    • SOA and EDA implementations must be regarded in the context of Business Process Management (BPM)
    • Modern BPM-tools are based on BPEL (Business Process Execution Language)
      • Current BPEL implementation focuses strongly on the command-and-control model, the orchestration of services, and so on SOA
      • Beside orchestration BPEL - to a certain extend - also supports workflow, a kind of choreography, which goes in the direction of EDA
      • BPEL has a procedural nature
      • EDA would rather be a declarative model.
    • Preparation Steps:
      • 1. Model business requirements into functions at the granularity level of the desired autonomy.
      • 2. Outline the application landscape to identify all affected systems.
      • 3. Map the application landscape to the business function model.
      • 4. Identify applications that cross functional borders as potential "agility bottlenecks" (assign a special high priority to those applications that are required to cross external organization borders).
        • Basics for the decoupled service boundaries
  • Resources
    • Books
      • Enterprise Integration Patterns (Gregor Hohpe and Bobby Woolf)
      • Patterns for Enterprise Architecture (Martin Fowler)
      • SOA Patterns (Arnon Rotem-Gal-Oz, Eric Bruno, Udi Dahan)
      • Event Processing: Designing IT Systems for Agile Companies (K. Chandy , W. Schulte)
      • Event-Driven Architecture: How SOA Enables the Real-Time Enterprise (Hugh Taylor, Angela Yochem, Les Phillips, Frank Martinez)
      • SOA Design Patterns (The Prentice Hall Service-Oriented Computing Series from Thomas Erl)
    • Sites

You can find this presentation here and on SlideShare:

TechDays 2010 Portugal - Event Driven Architectures - 16x9
View more presentations from Nuno.Godinho.

I would enjoy very much to ear your thoughts about this presentation.

Digg This

No Comments