1 / 24

EDA/CEP is Hard Enough without Standards

Event Metamodel and Profile (EMP) Proposed RFP March 12,2008 Robert D Covington, CTO rcovington@rhysome.com 8425 woodfield crossing boulevard | suite 345 | indianapolis | in | 46240 | 317.252.2640 |. EDA/CEP is Hard Enough without Standards. I wonder where I can get an “Easy” Event Processor.

varana
Télécharger la présentation

EDA/CEP is Hard Enough without Standards

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Event Metamodel and Profile (EMP) Proposed RFPMarch 12,2008Robert D Covington, CTOrcovington@rhysome.com8425 woodfield crossing boulevard | suite 345 | indianapolis | in | 46240 | 317.252.2640 |

  2. EDA/CEP is Hard Enough without Standards I wonder where I can get an “Easy” Event Processor What you need is a Complex Event Processing solution with fully Immutable Event Objects and Distributed Tuple Management CEP Evangelist Business Analyst

  3. OMG’s Mission Since 1989 • Develop an architecture, using appropriate technology, for modeling & distributed application integration, guaranteeing: • Specifications are freely available • Implementations required for standardization • Member-controlled not-for-profit open to all vendors and customers • Primary focus on modeling standards not wire protocols, data structure or domain specific languages • DDS, CORBA popular exceptions • Model Driven Architectures • Enable business problems to be architected and described in a format that is independent of specific Domain Specific Languages, protocols, or message formats

  4. Who Are the OMG? Raytheon Samsung Sandia SAP Satyam Savvion Siemens SoftwareAG Unisys Visa W3C MITRE NASA Navy UWC & SWC NEC New York Life NIST Northrop Grumman Oracle Pega Systems Penn National PrismTech BEA Systems Borland Boeing Business RulesGroup CA Capgemini Credit Suisse CSC Daimler DND-Canada EDS Fujitsu GCHQ Harris Hewlett Packard Hitachi IBM IONA Kaiser-Permanente MetLife

  5. OMG is known for: • All created and cared for by OMG’s Members!

  6. Liaison Relationships

  7. What is a Metamodel Metadata modeling is a type of metamodeling used in software engineering and systems engineering for the analysis and construction of models applicable and useful some predefined class of problems. In data engineering and software engineering, the use of models is more and more recommended. This should be contrasted with the classical code-based development techniques. A model always conforms to a unique metamodel. One of the currently most active branch of Model Driven Engineering is the approach named model-driven architecture proposed by OMG[1]. This approach is based on the utilization of a language to write metamodels called the Meta Object Facility or MOF. Typical metamodels proposed by OMG are UML, SysML, SPEM or CWM. ISO has also published the standard metamodel ISO/IEC 24744. Source Wikipedia

  8. Motivation for an improved Modeling Standard • Event Driven Architectures and correlated Stream and Complex Event Processing Systems are a critical component of Business Architectures. • Certain aspects of modern Event Driven Architectures have made them difficult to model using existing modeling standards (UML/BPMN) • No standard exists for modeling Complex Event Processing concepts such as composite events, causal event modeling, event patterns, partially ordered sets of events, and event constraints. • Having a modeling notation to describe Business Problems that require Complex Event Processing principals is important. • A common ontology, vocabulary and metamodel does not exist for EDA. • The diversity in the CEP industry makes development of common language, integration protocols, reference architectures, common event objects difficult. Development of a standard modeling notation and vocabulary for describing CEP Business problems is a good first step towards standardization in the industry.

  9. Applicable OMG EDA Standards

  10. Applicable OMG EDA Standards (cont)

  11. Applicable OMG EDA Standards (cont)

  12. Applicable OASIS EDA Standards

  13. Applicable W3C Standards

  14. What do we mean by Event? The term “Event” is used to define both the definition of an event and an occurrences of the event A further breakdown of “Event” • Event Generator – actor – The object that generates the event • Event Detector – The method/object that detects events • Event Specification – The definition of the event • Event Occurrence/Instance – when the event occurs • Event Notification – when the event notification is distributed

  15. UML v2.0 State Definitions State • A state is a condition during the life of an object during which it satisfies some condition, performs some activity, or waits for some external event Event • An event is the specification of a significant occurrence. For a state machine, an event is the occurrence of a stimulus that can trigger a state transition Transition • A transition is a relationship between two states indicating that an object in the first state will, when a specified set of events and conditions are satisfied, perform certain actions and enter the second state. A transition has: • Transition Components • A source state • An event trigger • An action • A target state Action • An action is an executable, atomic (with reference to the state machine) computation. • Actions may include • operations, the creation or destruction of other objects, or the sending of signals to other objects (events). Substates • A substate is a state that is nested in another state. A state that has substates is called a composite state. A state that has no substates is called a simple state. Substates may be nested to any level.

  16. Event Processing Glossary from EPTS Event: Something that happens. Event (also event object, event message, event tuple): An object that represents, encodes or records an event, generally for the purpose of computer processing. Notes: Events are processed by computer systems by processing their representations as event objects. The same activity may be represented by more than one event object; each event object might record different attributes of the activity. In many event processing systems, for example simulation systems, events are immutable. A modification or transformation of an event must be achieved by creating a new event object and not by altering the original event. Deletion would entail removing an event from further processing. Initial compilation by David Luckham and Roy Schulte Source: http://complexevents.com/?p=195

  17. Objectives of RFP • Develop a UML profile for representing and clarifying semantics concerned with modeling Events Driven Architectures in UML. • Provide a UML metamodel to address the modeling needs for Complex Event Processing • Tighter definitions of “Events” and triggers for continuous event processing • CEP concepts such as Composite Events, causal relationships, Event patterns, Event broadcast, and Event constraints • Support for all of BPMN/BPEL’s event handling capabilities • Compiling a standard glossary of terms that is suitable for both CEP and other related domains. • Supporting the interchange of event models between tools using XMI.

  18. Mandatory Requirements • Required Metamodel and Profile • Submissions to this RFP shall provide a MOF metamodel and equivalent Profile extending UML for Event Modeling. The metamodel shall extend UML for Event Modeling as specified in other mandatory requirements specified in this RFP. • UML Compatibility • These metamodel and profile extensions shall not conflict with existing UML semantics for extended metaclasses. However, if the metamodel and profile extensions can extend, but do conflict with existing UML semantics, the decision to do so shall be justified. • UMPS, PRR, and RT Compatibility • Notation • Submissions shall specify icons for stereotype extensions to UML in order to extend the UML notation for Event modeling. • Glossary of Event Terms • Submissions shall provide a glossary of terms for Events that can be used to support interoperability among CEP applications.

  19. New/Moved Mandatory Requirements Event Classification • ODM “profile” for describing event ontology • Taxonomy out of scope Event Aggregation and Correlation • Submissions may specify how composite Events, causal relationships, Event patterns, Event Broadcast and Event constraints are modeled. Compatibility with Event Processing Styles • Submissions shall address the issue of compatibility with different approaches to Event Processing, including Simple Event Processing, Stream Processing, and Complex Event Processing (CEP), permitting the analysis of Event stream networks and the control of event stream responses. UPMS Agents • Submissions may provide specifications for modeling the use of Events by Agents, as defined in UPMS.

  20. Optional Requirements • BPMN/BPDM mappings • Alternative Notations • Submissions may provide non-UML2 notations for consideration although every effort should be taken to avoid this. • Mappings to Existing Platforms and Languages • Submissions may provide one or more mappings to existing platforms and languages as a proof-of-concept.

  21. Out of Scope/Future Scope • Event Calculus Mapping • QOS (Service Metrics, performance, etc.) • Event Source Discovery • Governance or Compliance • Security • Definition of data structures, wire protocols and messaging formats. • Implementation language • Event Taxonomy • Testing

  22. Example Event (CEP) Model Event lifecycle Event lifecycle Content Content Event Sources(technology, driver, etc) Event Sources/Destinations(IDL spec, pub-sub address, etc) Source: TIBCO BusinessEvents

  23. RFI and/or RFP Contributors • Aptsoft • Axway • CA • CellExchange • Collaborative Consulting • Cordys • Data Blueprint • EDS • IBM • MetLife • NIST • Oslo Software • Rhysome • Sandpiper Software • Tibco • WareLite Looking for more contributors!!

  24. Critical Path Items • Verify alignment with UPMS, PRR, UML-RT • CEP Vendor/End User Outreach • Event Processing Technical Society • OMG Complex Event Processing Session, March 13, 2008 • Would like participation from more CEP vendors. • Resume weekly calls the week of March 24 • RFP AB Vote planned for June 2008 meeting • Wiki: http://www.omgwiki.org/soaeda/doku.php

More Related