1. Event Metamodel and Profile (EMP) Proposed RFP (ad/07-11-01) Updated December 11, 2007 P.J. Hinton, Software Engineer 8425 woodfield crossing boulevard | suite 345 | indianapolis | in | 46240 | 317.252.2640 |

2. Page 2 Talk Organization Changes made to the RFP since September meeting (ad/07-08-01) RFP Objectives Motivation RFP Scope Response requirements (mandatory, optional, for discussion) Reasons for postponing issuance Proposed Schedule Acknowledgements

3. Page 3 What’s Changed Since September Meeting? 1.Several major revisions made based on detailed review by Pete Rivett. 2.Narrowed and refined RFP scope. 3.Removed citations of standards that were of limited relevance to event modeling. 4.Moved several requirements from mandatory to optional. 5.Increased items to be discussed. 6.Streamlined evaluation criteria.

4. Page 4 Objectives for this proposed RFP Clarify semantics concerned with modeling Events using a UML Profile Establish Event modeling best practices for UML by incorporating constraints from the UML Profile and Metamodel for Services (UPMS). Provide a UML metamodel to address the modeling needs of the Event Processing community. Enable Event model interchange between tools via XMI.

5. Page 5 Events in Complex Event Processing In CEP, an Event is an observation of state. An Event has three aspects: 1.Form: What does the event report about the occurrence? 2.Significance: What does the event represent? 3.Relativity: How are events related to one another? Types of relationships between events 1.Time: “receiver lifted” precedes “number dialed” 2.Causality: “window shatters” event happened because “projectile strikes window” 3.Aggregation: “account overdrawn” event consists of “check received”, “withdrawal attempt”, “subzero balance computed” and “fee assessed” events. Source: David Luckham, The Power of Events, Addison-Wesley, 2002.

6. Page 6 Events in UML Source: Unified Modeling Language: Superstructure, Version 2.1.1, OMG Document number 2007-02-05

7. Page 7 Existing Modeling Standards: Enough for CEP? There are many standards that model event concepts.  UML provides “pins”  BPDM deals with changes of state. These standards treat Events as actions or process invocations. In CEP Events are observations of state, there is a need for a common and standardized modeling entity. UML needs a first-class entity for modeling Events.

8. Page 8 Scope of RFP Develop a UML profile for representing Events in ways that are useful to event processing applications. Provide a UML 2.1 metamodel extension that treats Events as first-class entities, or provide a standalone metamodel for events that could replace UML 2 metamodel concepts related to events. 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.

9. Page 9 Mandatory Requirements 1.Required Metamodel and Profile Submissions to this RFP shall provide a UML metamodel and equivalent UML Profile. The metamodel shall extend UML for Event Modeling as specified in other mandatory requirements specified in this RFP. A mapping between the UML metamodel and UML profile shall be provided. 2.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. 3.Notation Submissions shall specify icons for stereotype extensions to UML in order to extend the UML notation for Event modeling. 4.Glossary of Event Terms Submissions shall provide a glossary of terms for Events that can be used to support interoperability among CEP applications.

10. Page 10 Optional Requirements 1.Alternative Notations Submissions may provide non-UML2 notations. 2.Mappings to Existing Platforms and Languages Submissions may provide one or more mappings to existing platforms and languages as a proof-of-concept. 3.UPMS Agents Submissions may provide specifications for modeling the use of Events by Agents, as defined in UPMS. 4.Event Aggregation and Correlation Submissions may specify how composite Events, causal relationships, Event patterns, and Event constraints are modeled.

11. Page 11 Items to be Discussed 1.Incorporating Academic Research Work Specifications shall address the incorporation of existing University Research and the Event Processing Technical Society [EPTS], in such areas as terminology, use cases and reference architectures. 2.Non-normative Use of Existing UML Constructs Submissions shall address the non-normative use of existing UML constructs to model CEP concepts such as composite events, causal event modeling, event patterns, and event constraints. 3.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.

12. Page 12 Evaluation Criteria 1.Preference will be given to submissions that express the intent of Event models rather than any specific means by which that intent may be realized by some runtime platform. 2.Submissions that establish UML as the foundation for event modeling and extend (i.e., define a new capability of) UML will be preferred. 3.Completeness of the mapping and the use of OMG MDA principles and related work such as MOF QVT and IMM (for XML Schemas). 4.Ability to translate from one platform to another using the event profile as an intermediate form. 5.Clarity of the proposed specification for the purpose of implementing conforming tools for modeling Events and ease of reviewing for correctness. 6.The precision, completeness, compactness, and clarity of the event metamodel. 7.The ability to easily draw notation elements by hand and use them in collaborative modeling sessions.

13. Page 13 Out of Scope/Future Scope 1.BPMN and BPEL mapping 2.Event Calculus Mapping 3.QOS (Service Metrics, performance, etc.) 4.Event Source Discovery 5.Governance or Compliance 6.Security 7.Definition of data structures, wire protocols and messaging formats. 8.Implementation language 9.Testing

14. Page 14 Reasons for Postponing Issuance to March 1.Alignment with UPMS -- The EMP RFP aims to dovetail with the standardization efforts for the UML Profile and Metamodel for Services (UPMS), especially within the scope of Agents. The current fragmentation within the UPMS effort has delayed the adoption of this standard. 2.CEP Vendor Outreach -- Additional time will allow us to enlarge the pool of active participants in a submission team, especially CEP vendors who may not be fully aware of OMG’s efforts in this space.

15. Page 15 Proposed Schedule Approx Day Event or ActivityActual Date Approval of RFP by Architecture Board Review by TC (“Four week rule”) February 11, 2008 0TC votes to issue RFP March 14, 2007 60LOI to submit to RFP due May 13, 2008 120Initial submissions due July 12, 2008 134Voter registration closes July 26, 2008 141Initial submission presentations August 2, 2008 Preliminary evaluation by TF September 2008 240Revised submissions due November 9, 2008 261Revised submission presentations November 30, 2008 Final evaluation and selection by TF Recommendation to AB and TC December 2008 Approval by Architecture Board Review by TC (“Four week rule”) January 2009 330TC votes to recommend specifications February 7, 2009 360BOD votes to adopt specifications March 9, 2009

16. Page 16 Acknowledging RFI and RFP Contributors Aptsoft Axway BEA CA CellExchange Collaborative Consulting Cordys Data Blueprint EDS IBM MetLife NIST Oslo Software Rhysome Sandpiper Software Tibco WareLite

17. Page 17 Applicable OMG Standards Unified Modeling Language (UML) A specification defining a graphical language for visualizing, specifying, constructing, and documenting the artifacts of distributed object systems. Adopted Standard Business Process Modelling Notation (BPMN) A process diagram specification designed for use by the people who design and manage business processes. BPMN also provides a formal mapping to an execution language of BPM Systems (BPEL4WS). Adopted Standard Enterprise Collaboration Architecture (ECA) The Events profile, which describes a set of UML extensions that may be used on their own, or in combination with the other EDOC elements, to model event driven systems. Adopted Standard Event Service Specification Defines two roles for objects: the supplier role and the consumer role. produce event data and consumers process event data. Event data are communicated between suppliers and consumers by issuing standard CORBA requests Adopted Standard Event-driven architecture for SOA Developing modeling standards for the interaction of Event Driven Architectures and Service Oriented Architectures RFI Management of Event Domains Specifies an architecture and interfaces for managing event domainsAdopted Standard Notification / JMS Interworking The interworking involves several aspects such as: event message mapping; QoS mapping; event and message filtering; automatic federation between Notification Service channel concept and topic/queue concepts; and transaction support. Adopted Standard