epts event processing technical society epts event processing technical society Tutorial v1.1 event processing technical society Courtesy of: Adrian Paschke (Freie Universitaet Berlin) Paul Vincent (TIBCO Software) Catherine Moxey (IBM) Alex Alves (Oracle) Themis Palpanas (University of Trento) Event Processing Architectures leading to an EPTS Reference Architecture Content by: members of the EPTS Reference Architecture Working Group
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
epts event processing technical society
eptsevent processing technical society
Tutorial v1.1
event processing technical society
Courtesy of: Adrian Paschke (Freie Universitaet Berlin)
Paul Vincent (TIBCO Software)
Catherine Moxey (IBM)
Alex Alves (Oracle)
Themis Palpanas (University of Trento)
Event Processing Architectures leading to an EPTS Reference Architecture
Content by: members of the
EPTS Reference Architecture Working Group
epts event processing technical society
Tutorial
• Event Processing is an increasingly important area in the field of IT
• Event Processing Architectures have evolved to
handle the needs of low-latency / high-throughput handle the needs of low-latency / high-throughput event processing
• Event Processing Architecture diagrams are used to describe the functions and component layouts of event processing systems
• Various providers and suppliers use their own architectural descriptions, and EPTS has collated and refined these into a candidate “reference” architecture
2
epts event processing technical society
Agenda
• Introduction to architectures, architecture methodologies, and event processing
• Member architectures and salient features
• Skeleton reference architecture from EPTS
3
• Skeleton reference architecture from EPTS Reference Architecture Working Group
• Summary and future work of the EPTS Reference Architecture Working Group
epts event processing technical society
Agenda
• Introduction to architectures, architecture methodologies, and event processing
• Member architectures and salient features
• Skeleton reference architecture from EPTS
4
• Skeleton reference architecture from EPTS Reference Architecture Working Group
• Summary and future work of the EPTS Reference Architecture Working Group
epts event processing technical society
Introduction to Event Processing
• Event-centric view of IT
• Events are
– Sent and Received
– Aggregated, Transformed into Data, Deleted
– Processed in queries, rules etc
– Cause actions like processes, service invocations, etc
About the EPTS Reference Architecture Working Group
• Started March, 2009
– 18 members, co-chairs are Adrian Paschke (RuleML) and Paul Vincent (TIBCO)
– July 09 added responsibilities from Metamodel Working Group
• Scope
– Define architecture patterns that are compatible with EPTS members’ Event Processing solutions and products.
– Define terminology and components regarding Event Processing in
7
– Define terminology and components regarding Event Processing in accordance with EPTS
– Identify and utilize best practices and methods for Technical Architecture descriptions and interchange
– Liaise with relevant standards bodies for EP metamodels and reference architectures
• Current work is focused on
– Discovery of existing Event Processing Architectures
• collected RAs from e.g. IBM, Oracle, Tibco, Streambase, Aleri, Microsoft…
– Definition of Terminology and Methodology for comparing and describing Event Processing Reference Architectures
epts event processing technical society
Relationship with the other EPTS Groups / Areas
• Application and Analysis – EPTS Use Case WG
• Value and ROI– EPTS Business Value WG
• Features and Components – EPTS Language WG
• Terminology – EPTS Glossary WG
• Architecture & Metamodels– EPTS Reference Architecture WG
epts event processing technical society
Reference Architecture and Reference Model
• Reference Architecture
A reference architecture models the abstract architectural elements in the domain independent of the technologies, protocols, and products that are used to implement the domain.
9
to implement the domain.
• Reference Model
A reference model describes the important concepts and relationships in the domain focusing on what distinguishes the elements of the domain.
epts event processing technical society
Motivation and Benefits• Motivation
– Event Processing is evolving from many existing technologies and creating or adapting different tools
– Potential adopters (stakeholders) may have problems understanding and adequately defining EP-based architectures and solutions.
• Benefits• Benefits
– a Reference Architecture aids efficient Event Processing solution development, by predefining customizable abstract frames of reference for specific stakeholder concerns and application domains.
• aids in reusability of successful EP architectures for frequently occurring EP design problems
• enables easier comparison of proposed EP solutions
– Underlying Reference Model defines / explains the terminology and components in Event Processing architectures
epts event processing technical society
ANSI/IEEE Std 1471 :: ISO/IEC 42010 Methodology
• Recommended Practice for Architectural
Description of Software-intensive Systems
– Now an ISO/IEC 42010:2007 standard
– Includes 6 elements
11
– Includes 6 elements
1. Architectural description
2. System stakeholders and their concerns
3. One or more architectural views
4. Viewpoints
5. A record of all known inconsistencies among the architectural description’s required constituents
6. A rationale for selection of the architecture
epts event processing technical society
ISO/IEC 42010:2007 Terminology (1)
• Architecture
– The fundamental organization of a system embodied in itscomponents, their relationships to each other, and to theenvironment, and the principles guiding ist design and evolution.
• Architectural Description
12
– A collection of products that document the architecture.
• System
– A collection of components organized to accomplish a specific function or set of functions.
• System Stakeholder
– A system stakeholder is an individual, team, ororganization (or classes thereof) with interests in, orconcerns relative to, a system
epts event processing technical society
ISO/IEC 42010:2007 Terminology (2)• View
– A representation of the whole system from the perspectiveof a related set of concerns.
• Viewpoint
– A specification of the conventions for constructing and using a view - a pattern or template which to developindividual views by establishing the purposes and audience
13
individual views by establishing the purposes and audiencefor a view and the techniques for its creation and analysis.
• Model
– A view may consist of one or more models and a model
may participate in one or more views.
– Each model is defined according to the methods
established in the corresponding viewpoint definition.
epts event processing technical society
Conceptual model of architectural description from IEEE Std 1471- 2000 (ISO/IEC 42010:2007 )
14
epts event processing technical society
Declaring a Viewpoint
• Each viewpoint is specified by:
– Viewpoint name
– The stakeholders addressed by the viewpoint
– The stakeholder concerns to be addressed by the viewpoint
– The viewpoint language, modeling techniques, or analytical methodsusedused
– The source, if any, of the viewpoint (e.g., author, literature citation)
• A viewpoint may also include:
– Any consistency or completeness checks associated with the underlying method to be applied to models within the view
– Any evaluation or analysis techniques to be applied to models withinthe view
– Any heuristics, patterns, or other guidelines which aid in the synthesis of an associated view or its models
15
epts event processing technical society
Architecture Views - Examples
• Domain Architecture
domain models represent domain requirement and logic
• e.g. process representation, use case analysis, free text
• Application Architecture
16
structural, logic architecture
– Functional Layering, e.g. functional multi-tier structure
– Functional Decomposition, e.g. Component Architecture, UML (class/activity/sequence)
• System Architecture
– Concrete implementation of an architecture in a target platform
epts event processing technical society
Example UML Architectural Views and Diagrams
UML defines 13 diagram models that describe 4+1 architectural views
4+1 architectural views model by Philippe Kruchten, IBM
IBM EP Architecture – mapping to methodologySystem: event processing system – event emitter, event bus, event handler
Environment: initial producers of events and their ultimate consumers
Stakeholders Concerns Architectural View
Event consumers – use events to get information, take action, detect problems, etc.
Receive correct events in consumable format, with relevant data
Event Handler (adapters, consumer-side EP services, orchestration), Event Processing Services, Repositories, Event Emitters. Publication, Subscription, Notification services to receive events
Event “Analysts” – create Means to specify the Event Instantiator, Event Processing Services, Event “Analysts” – create and understand event specifications and definitions, how events should be processed, etc.
Means to specify the events to be produced, the patterns to be identified, event enrichment etc.
Event Instantiator, Event Processing Services, Event Information Management and Query Services, Event Security Services, Event Registries. Event Repositories to do pattern-matching over time
Event System managers –manage and control the EP system
Security, Performance, Configurability
Event Security Services, Event Governance and related Security Services
Event System operators –operate the EP system
Abilities to monitor and configure system, diagnose and solve problems
Event Production: the source of events for event processing.
• Event Publication: As a part of event production, events may be published onto a communication mechanism (eg event bus) for use by event consumers (including participants in event processing). This is analagous to a "push" system for obtaining events.
• Event Retrieval: As a part of event production, events may be explicitly retrieved from some detection system. This is analagous to a "pull" system for obtaining events.
epts event processing technical society
Reference Architecture: Functional View / Runtime
Event Consumption: the process of using events from event publication and processing. Event processing itself can be an event consumer, although for the purposes of the reference architecture, event consumers are meant to indicate downstream consumers of events generated in event processing.
• Dashboard: a type of event consumer that displays events as they occur to some user community.
• Event Aggregation: combining events to provide new or useful information, such as trend
information and event statistics. Similar to event consolidation.
epts event processing technical society
Reference Architecture: Functional View / Runtime
Event Reaction: the process subsequent to event analysis and complex event detection to handle the results of analysis and detection.
• Event Assessment: the process by which an event is assessed for inclusion in some
process, incorporation in some other event, etc.
• Event Routing: the process by which an event is redirected to some process, computation
element, or other event sink.
• Event Prediction: where the reaction to some event processing is that some new event is
Event ReactionAssessment, Routing, Prediction,
Discovery, Learning
• Event Prediction: where the reaction to some event processing is that some new event is
predicted to occur.
• Event Discovery: where the reaction to some event processing is the disclosure of a new,
typically complex, event type.
• Note that event prediction is predicting some future event, usually of a known type, whereas event discovery is the uncovering of a new event type. See also event-based learning.
• Event-based Learning: the reaction to some event processing that uses new event
information to add to some, typically statistical-based, understanding of events.
• Note that event-based learning is a specialisation of general machine learning and predictive analytics.
epts event processing technical society
Reference Architecture: Functional View / Design timeand C
om
ple
x E
vent
Control, Rule, Query, RegEx.etc)
Modeling, (continuous) I
mprovem
ent
Covers the definition, modeling, improvement / maintenance of the artifactsused in event processing:
• event definitions, including event metadata and payloads,
• event and event object organisations and structures,
Event
and C
om
ple
x E
vent
(Pattern, Control, Rule, Query, RegEx.etc)
Definitio
n, M
odeling, (continuous) I
mprovem
ent
Design time
• event and event object organisations and structures,
• event processing transformations / queries / rules / procedures / flows / states / decisions / expressions (although these can sometimes be considered as administrative updates in some situations)
– Identify commonalities in proposed architectures
– Collect core and additional CEP system functions and components
• Member Reference Architecture Descriptions
– Using the EPTS-RA Methodology and Terminology
• Application of RA Descriptions to Use Cases
epts event processing technical society
Next Steps
• Generalize the EPTS Reference Architecture descriptions
– addressing important stakeholders and their views
– using rigorous RA methodology and terminology (+ glossary)
• Evaluate the EPTS-RA descriptions
– apply on selected EPTS use cases and compare to member experience
– compare with Best Practice Guidelines
• Review Logical Architecture requirements for Reference purposes
• Possible Outputs:
– EPTS-RA Description document
– EPTS-RA Design Patterns and Best Practice Guidelines document
– Wiley Book "Pattern Oriented Software Architecture: Architectures, Models and Patterns for Event Processing" (already in preparation)
– Input for Event Processing Metamodels and associated standards
epts event processing technical society
Summary
• Reference Architecture provides a common set of EP Functions that may be included in
– EP systems
– EP-related tools– EP-related tools
• Describes the mapping from Glossary of Terms to Implementation
• Provides the basis for EP agents, operators and languages
80
epts event processing technical society
Thank you !
81
Thank you !
Acknowledgment to the Event Processing Technical Society Reference Architecture working group: David Tucker (Event Zero), John Morrell (Coral8, Inc.), Baden Hughes (Event Zero), Dieter Gawlick (Oracle), Alex Alves (Oracle), Anand Srinivasan (Oracle), Shailendra Mishra (Oracle), Zbigniew Jerzak (TU Dresden), Hans-Arno Jacobsen (University Toronto), Albert Mavashev (Nastel Technologies Inc.), Simon Courtenage (University of Westminster), Catherine Moxey (IBM United Kingdom Limited), Richard Tibbetts (Streambase), Brian Connell (WestGlobal), Guy Sharon (IBM), Themis Palpanas (University of Trento)