TechDays 2010 Portugal - Event Driven Architectures - 16x9
âąAls PPTX, PDF herunterladenâą
3 gefĂ€llt mirâą2,098 views
This document discusses event-driven architecture (EDA) and how it compares to service-oriented architecture (SOA). EDA uses messaging to facilitate loose coupling between asynchronous and independent components. It is well-suited for unpredictable environments that must react to many real-time events. SOA focuses on synchronous request-response between components. The document provides examples of how to implement EDA using messaging and event processing engines, and recommends when to use EDA versus SOA based on factors like independence of process steps. Resources for further reading on EDA, SOA patterns, and related topics are also included.
Empfohlen
Empfohlen
Weitere Àhnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ăhnlich wie TechDays 2010 Portugal - Event Driven Architectures - 16x9
Ăhnlich wie TechDays 2010 Portugal - Event Driven Architectures - 16x9 (20)
Mehr von Nuno Godinho
Mehr von Nuno Godinho (12)
KĂŒrzlich hochgeladen
KĂŒrzlich hochgeladen (20)
TechDays 2010 Portugal - Event Driven Architectures - 16x9
- 1. Event-Driven Architecture Como, Quando e PorquĂȘ? ARC316 NunoGodinho Partner & CTO @ ITech4All nuno.godinho@itech4all.com @NunoGodinho
- 2. Session abstract Session title
- 3. Speaker Bio and Photo Speaker Name
- 4. Nuno Filipe Godinho Partner & CTO @ ITech4all Mail: Nuno.Godinho@itech4all.com Nuno.Godinho@sapo.pt Blogs: http://pontonetpt.com/blogs/nunogodinho http://xamlpt.com/blogs/nunogodinho http://weblogs.asp.net/nunogodinho http://msmvps.org/blogs/nunogodinho Twitter: @NunoGodinho About Me
- 5. Introduction Event Driven Architecture SOA vs EDA How to Implement Resources Q&A Agenda
- 6. Introduction
- 7. SOA is a synchronous RPC (mostly over Web services) EDA is SOA The best of EDA and SOA is combined in SOA 2.0 Introduction Common Thoughts about SOA and EDA
- 8. Moving towards on-Demand Business. Why? Organizations tend to change their structure frequently Parts of the business process are outsourced to External Partners Departments and business units are seen now as service providers Focus not only internally on the organization, but they are seeking for external markets to offer their services Introduction Trend Change
- 9. Moving towards on-Demand Business. Why? Everything is moving toward on-demand business where service providers react to impulses from the environment. Loose coupling between application components Introduction Trend Change
- 10. Linking application to simplify and automate a process, while avoiding changes to existing applications Introduction Sample Painpoint : EAI â Enterprise Application Integration
- 11. File Tranfer Import and Export Files Common Issues: Various Formats Needs Translation Manually Loaded Introduction How to Solve this painpoint?
- 12. Shared Databases Making integration on the Database Level Several Applications share the same Database Common Issues: Data is tightly coupled to multiple applications Incremental or partial updates are impossible Introduction How to Solve this painpoint?
- 13. Web Services Providing Services to automate the integration Common Issues: Requires services to be available at invocation Results in multiple call stacks Resource consuming Yet another Remote Procedure Call (RPC, COM, Corba, DCOM, ...) Introduction How to Solve this painpoint?
- 14. Messaging Using Messaging mechanisms Basics: Defined data format Asynchronous Operations Minimized Coupling Fault Tolerance Data Freshness Introduction How to Solve this painpoint?
- 15. Messaging Defined data format Contract between Producer and Consumer Internal formats remain private Integration is maintained at the edge of the application, to prevent internal changes to impact the interface Introduction How to Solve this painpoint?
- 16. Messaging Asynchronous Operations Processes run on their own context Source process continues No need for the service to be always available Introduction How to Solve this painpoint?
- 17. Messaging Minimized Coupling Additive Model reducing the changes needed to existing systems Reduces dependencies Increases service reuse Enable Isolated Service Testing Introduction How to Solve this painpoint?
- 18. Messaging Fault Tolerance Durable Messaging Improved recoverability Compensating Actions to handle partial failures Introduction How to Solve this painpoint?
- 19. Messaging Data Freshness Favors small data transfer Minimized data exchange latency Introduction How to Solve this painpoint?
- 20. Events Represent a change in state Self-Contained Pure and complete representation of an Event No references to other data sources Reduces dependencies, Loosens coupling Uniquely indentified Enabled idempotent handling events Improves tracebility of related processing Allows correlation with related events Introduction How to Solve this painpoint?
- 21. Events Time relevant, not time sensitive Sourced using messaging Observable Published events can be observed by multiple subscribers Event stream Processing Introduction How to Solve this painpoint?
- 22. Event Types Execution Lifecycle Management Business Introduction How to Solve this painpoint?
- 24. Architecture pattern that orchestrates behavior around: Production Detection Consumption of events as well as the responses they invoke. A 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 Event Driven Architecture What is EDA?
- 25. Suited for Asynchronous, unpredictable environments Extremely Loosely Coupled Inversion of communication Event Driven Architecture What is EDA?
- 26. 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â Event Driven Architecture Why do we need EDA?
- 27. Concerns events that are directly related to specific, measurable changes of condition Event Driven Architecture Simple Event Processing
- 28. Both ordinary and notable events happen Event Driven Architecture Stream Event Processing
- 29. Allows patterns of simple and ordinary events to be considered to infer that a complex event has occurred Event Driven Architecture Complex Event Processing
- 30. SOA-2: Event-Driven Service Oriented Architecture Event Driven Architecture What is Complex Event Processing? Event Stream Processing Complex Event Processing time 1 2 3 4 5 6 7 8 9 Event pattern of significance where prompt detection and action can have materially impact
- 35. Event Driven Architecture Event Processing Engine
- 36. Event Generator Event Channel Event Processing Engine Downstream Activity Event Driven Architecture Event Flow Layers
- 37. SOA-2: Event-Driven Service Oriented Architecture Event-driven Process Automating the basic process OTHER SERVICES OTHER SERVICES OTHER SERVICES Investment manager wants order management system integrated with trading desk ECN ORDER MANAGEMENT SYSTEM BROKER TRADINGDESK EXCHANGE TRADER
- 38. SOA-2: Event-Driven Service Oriented Architecture Event-driven Processes Operational improvement OTHER SERVICES OTHER SERVICES COMPLIANCEENGINE OTHER SERVICES TRADINGDESK President wants compliance engine to monitor trading activities to eliminate cash liability during market swings INBOUNDTRANSFORMATION OUTBOUNDTRANSFORMATION ? ECN ORDER MANAGEMENT SYSTEM BROKER EXCHANGE TRADER FUND MANAGER
- 39. SOA-2: Event-Driven Service Oriented Architecture Event-driven Processes Keeping up with regulations OTHER SERVICES COMPLIANCE ENGINE LOGGING SERVICE OTHER SERVICES OTHER SERVICES TRADINGDESK DB Board wants trades logged for Sarbanes-Oxley and integrated with company-wide risk management INBOUNDTRANSFORMATION OUTBOUNDTRANSFORMATION TOCORPORATERISK MGT ? ECN ORDER MANAGEMENT SYSTEM BROKER EXCHANGE TRADER FUND MANAGER
- 40. SOA vs EDA
- 41. SOA vs EDA SOA Core Services
- 42. SOA provides an organizing and delivery paradigm that derives greater value by reusing existing software solutions rather than duplicating capabilities SOA establishes services as the mechanism by which needs and capabilities are brought together SOA standardizes the necessary interfaces and behavior to support interaction SOA vs EDA What is SOA? Service S Capabilities performed by one for another to achieve a desired outcome Oriented O When capabilities are self-contained and independent to enable a collection of services to be linked together to solve a business problem Architecture A The fundamental organization of a system embodied in its capabilities, their interactions, and the environment
- 43. SOA vs EDA Service Oriented Architecture Applications are composed in design-time Linear flow between services Predictable behavior Request/Response is common, and often overused Event Driven Architecture Applications are composed at run-time Asynchronous components Reactive behavior
- 44. Support strong cohesion in the business processes, situations where all process steps are under one control Commonly applied to: Verticalinteraction 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 SOA vs EDA When to use SOA?
- 45. Support independency between business process steps Commonly applied 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 SOA vs EDA When to use EDA?
- 46. SOA vs EDA Visualization
- 47. How to Implement
- 48. 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) How to Implement
- 49. 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. How to Implement
- 50. Preparatory steps: Model business requirements into functions at the granularity level of the desired autonomy. Outline the application landscape to identify all affected systems. Map the application landscape to the business function model. 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). Basis for the decoupled service boundaries How to Implement Scenarios where SOA and EDA can easily co-exist
- 51. Resources
- 52. Enterprise Integration Patterns (GregorHohpe and Bobby Woolf ) Patterns for Enterprise Architecture (Martin Fowler) SOA Patterns (ArnonRotem-Gal-Oz, Eric Bruno, UdiDahan) Resources Books
- 53. 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) Resources Books
Hinweis der Redaktion
- 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
- Notable event happens, Initiating downstream action(s). Simple event processing is commonly used to drive the real-time flow of workâtaking lag time and cost out of a business.
- Ordinary events are screened for notability and streamed to information subscribersCommonly used to drive the real-time flow of information in and around the enterprise, which enables in-time decision making
- Complex event processing evaluates a confluence of events and then takes action. The events (notable or ordinary) may cross event types and occur over a long period of time. The event correlation may be causal, temporal, or spatial. CEP is commonly used to detect and respond to business anomalies, threats, and opportunities.
- Event Metadata. A good event-driven architecture has a strong metadata architecture. Event metadata includes event specifications and event processing rules. Event specifications must be made available to event generators, event format transformers, event processing engines, and subscribers. While no standards currently exist for event definition and processing notation, it is only a matter of time.Event Processing. The cores of event processing are the engine and the event occurrence data. Simple event engines are often homegrown. Complex event engines should be acquired from a CEP engine provider. Event occurrence data is typically persisted and retained for audit and trend analysis.Event Tooling. Event development tools are required to define event specifications and processing rules, and to manage subscriptions. Event management tools provide administration and monitoring of the event processing infrastructure, monitoring of event flows, and visibility into event generation and processing statistics.Enterprise Integration. An enterprise integration backbone plays a large role in event-driven architecture. Some of the required integration services are: event preprocessing (filters, routes, and transformations), event channel transport, service invocation, business process invocation, publication and subscription, and enterprise information access.Sources and Targets. These are the resources of the enterpriseâapplications, services, business processes, data stores, people, and automated agentsâthat generate events and/or perform an event-driven action.
- The third layer, the event processing engine, is the logical location where the event is identified and the appropriate reaction is selected to be executed. Multiple reactions can be chosen by the engine for the same event. For example, the processing engine can decide to forward the event to other event processors. On the other hand it could choose to invoke a downstream activity like invoking a part of a business process, such as reserving some seats in the VIP area of a party, or send an email to the original requestor to tell him or her that everything went horribly wrong and he or she will get their money back. The primary tool for processing events on the Azure platform is the worker role; it continuously polls a queue for new events and responds to them by executing custom code. Every queuing mechanism discussed in the previous paragraph supports the queue-peek-lock mechanism to ensure that when a message is read from the queue, it does not really get removed from the queue. Until the processor has finished his work and explicitly removes it from the queue, the message will only go invisible for some time. If the processor fails to remove the message within an allotted time frame it will reappear as this indicates that the processor has failed to handle the message. This mechanism provides some sort of retry mechanism to make the processing a bit more resilient to the challenges that the cloud presents us. The .Net Service Bus provides another feature that is vital for the implementation of an event process layer, routers. A Router is a publish/subscribe message distribution primitive that allows to push events to subscribers. Routers can be configured through policies, just like queues, to distribute the events they receive to all or one of the subscribers, meaning they can be used to forward messages from one or multiple publishers to one or multiple subscribers. The real beauty however is the fact that queues and routers can subscribe and read from each other, allowing the composition of these primitives in a customized event processing engine, as shown in the example below. They are especially powerful when combined together with worker roles that take care of any complex routing, filtering logic or correlation of events.
- EVENT GENERATORS. 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. 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 eventfor 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 EVENT-DRIVEN 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.
- The circles at the top of the picture denote decoupling points (events), the linking pins between loosely coupled systems. At these decoupling points components can be connected and disconnected without any change of the connected systems (peers). All data exchange between the domains takes place only at this point and not at the lower levels.Within a reuse domain (see figure 1) a finer grained EDA may be implemented. The more fine-grained EDA, the more flexible the IT-systems are, but also to smaller the reuse domains will be.
- BPEL, however, has a procedural nature and runtime implementations need a controlling BPEL-engine. This isnot a problem in case of SOA, but to achieve the aimed loose coupling of EDA it is. Good support for EDA wouldrather be a declarative model than a procedural model.