1. Event Metamodel and Profile (EMP) Proposed RFP Updated Sept 26, 2007 P.J. Hinton, Software Engineer 8425 woodfield crossing boulevard | suite 345 | indianapolis | in | 46240 | 317.252.2636 |

2. Page 2 Talk Organization EMP RFP Timeline: Where Have We Been? Where Are We Going? Motivation: Why is this necessary? RFP Contents: What’s in the RFP Now? Open Issues: What Needs to be Done? Participation: Who’s Contributed? How you can get involved.

3. Page 3 A Brief History of EMP RFP Creation Effort Winter 2006-7: EDA RFI responses collected and summarized. 2007 Spring Technical Meeting: RFI response summary submitted by Bob Covington. Mid-summer 2007: RFP supervision effort transferred to P.J. Hinton. Weekly teleconferences begin. Late Summer 2007: Formal RFP submission moved to Winter 2007 OMG Technical Meeting to increase participation and improve the document’s quality.

4. Page 4 Proposed Schedule Approx Day Event or ActivityActual Date Issuance recommendation of RFP by TF June 2007 Approval of RFP by Architecture Board Review by TC (“Four week rule”) November 12, 2007 0TC votes to issue RFP December 14, 2007 60LOI to submit to RFP due February 12, 2008 120Initial submissions due April 12, 2008 134Voter registration closes April 26, 2008 141Initial submission presentations May 3, 2008 Preliminary evaluation by TF June 2008 240Revised submissions due August 10, 2008 261Revised submission presentations August 31, 2008 Final evaluation and selection by TF Recommendation to AB and TC September 2008 Approval by Architecture Board Review by TC (“Four week rule”) October 2008 330TC votes to recommend specifications November 8, 2008 360BOD votes to adopt specifications December 8, 2008

5. Page 5 Motivation for this proposed RFP 1.Events are a critical component of Business Architectures. 2.Currently adopted standards, such as UML, are not sufficient for modeling events in business or IT systems, or the interactions between agents and services. 3.No standard exists for modeling Complex Event Processing concepts. 4.A common ontology, defining EDA domain terminology and related conceptual knowledge, is required to support interoperability among CEP systems.

6. Page 6 Events in Complex Event Processing In CEP, an Event is the record of an occurrence. 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.

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

8. Page 8 Is UML Enough for CEP? UML Events may have: Parameters Guards Actions Their Shortcomings Parameter syntax is awkward for conveying the form of an event and its relativity, both of which may be very complicated. In CEP, a event processing engine is responsible for managing constraints and executing actions. UML binds these things to events with guards and actions. This existence of this issue has been known for some time. A 1999 paper by Medvidovic et al. wrote: Finally, our extensive study of relating UML and (Architecture Description Languages) using (the constraint of UML through stereotypes) has shown that certain ADL features for modeling architectural semantics cannot be easily (or at all) represented in UML. An example is Rapide’s event causality. Source: Medvidovic, N., Egyed, A., and Rosenblum, D. "Round-Trip Software Engineering Using UML: From Architecture to Design and Back," Proceedings of the 2nd Workshop on Object-Oriented Reengineering (WOOR'99) co-located with ESEC/FSE'99, Toulouse, France, September 1999, pp. 1-8.

9. Page 9 Scope of RFP Contents of RFP Responses Event Ontology: Reasonably unify different uses of events. Clarified UML Semantics: What can we do with UML as is? Metamodel Extensions: What do we need to add to UML to make CEP modeling easier? Interchange via XMI: What is needed to make event models interchangeable between CEP applications. Constraints Complement standards from OMG and other standards bodies, most notably UPMS. Factor in industry consensus and academic research Desired Results EDA development and adoption is accelerated EDA design decoupled from evolving implementations Straightforward generation of platform specific formats

10. Page 10 Overview of EMP RFP Requirements

11. Page 11 Mandatory Requirements 1.Provide a MOF metamodel and equivalent Profile extending UML for Event Modeling as specified in other mandatory requirements specified in this RFP. 2.Metamodel and profile extensions can extend, but not conflict with, existing UML semantics for extended metaclasses. 3.Specify icons for stereotype extensions to UML in order to extend the UML notation for Event modeling. 4.Notations must specify icons for stereotype extensions to UML 5.Specify one or more ontology components representing business and IT vocabulary for events, event types, and event-related processing. Use cases and documentation describing coverage and providing examples are also required. 6.Express the intent of Event models rather than any specific means by which that intent may be realized by some runtime platform. 7.Be compatible with existing event driven implementations from OMG, excluding CORBA Pull Consumer Interface 8.Be compatible 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 Optional Requirements 1.Specifications for modeling the interaction with Agents 2.Modeling the interaction with Request/Reply Systems 3.Support for CORBA Pull consumer interface 4.Compatible with existing Event Implementations from OASIS, and W3C 5.Support for: 1.Changing metadata in the Event Source 2.Out of order Events 3.Event Persistence

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 Open Issues 1.Incorporate improvements suggested by reviewer Peter Rivett. 2.Bring more participants on board. 3.Narrow and refine RFP scope, perhaps downgrade some requirements to optional material. 4.Review standards listed in proposal and verify their relevance. 5.For referenced standards that remain, provide the following: Brief summary Relevance to this standard creation effort Strengths Weaknesses

15. Page 15 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

16. Page 16 Applicable OMG Standards (cont) Notification Service An extension to the existing OMG Event Service, adding to it: transmitting events in the form of a data structure; event subscription; discovery; QoS; and an optional event type repository. Adopted Standard Production Rules Representation (PRR) Production Rules Representation - Specification for Condition - Action rule sets extensible to ECA (Reaction) rules. RFP Semantics of Business Vocabulary and Rules (SBVR) Business language statements of terms, facts and business constraints, usually defined in relation to business events. Adopted Standard (Finalization) SysMLThe OMG systems Modeling Language (OMG SysML™) is a general-purpose graphical modeling language for specifying, analyzing, designing, and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities Adopted Standard UML Profile and Metamodel for Services (UPMS) UML profile for modeling servicesRFP Business Process Definition Metamodel (BPDM) A metamodel for all different types of processes, primarily aimed at BPMN modeled processes but capable of extension to EDA processes. Adopted Standard

17. Page 17 Applicable OMG Standards (cont) UML Profile for EDOC UML Profile for Enterprise Distributed Object Computing UML Profile for Schedulability, Performance and Time Specifies a UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems Ontology Definition Metamodel (ODM) ODM is applicable to knowledge representation, conceptual modeling, formal taxonomy development and ontology definition, and enables the use of a variety of enterprise models as starting points for ontology development through mappings to UML and MOF. Knowledge Discovery Metamodel (KDM) This specification defines a meta-model for representing information related to existing software assets and their operational environments Meta Object Facility 2 (MOF2) MOF is an extensible model driven integration framework for defining, manipulating and integrating metadata and data in a platform independent manner. MOF-based standards are in use for integrating tools, applications and data. MOF VersioningThe problem being addressed by this Specification is to manage the co-existence of multiple versions of metadata in a Meta Object Facility

18. Page 18 Applicable OASIS Standards Common Alerting Protocol The Common Alerting Protocol (CAP), a data interchange standard for alerting and event notification applications, currently in version 1.1. CAP functions both as a standalone protocol and as a payload for EDXL messages. Approved Standard WS-BaseNotificationWS-Notification is a family of related specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. Approved Standard WS-BrokeredNotificationWS-Notification is a family of related specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. Approved Standard WSDM Management Of Web Services (MOWS) Defining a Web services architecture to manage distributed resourcesApproved Standard WSDM Management Using Web Services (MUWS) Defining a Web services architecture to manage distributed resourcesApproved Standard WS-TopicsWS-Notification is a family of related specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. Approved Standard

19. Page 19 Applicable W3C Standards Document Object Model Level 2 Events Specification Design of a generic event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event Recommendation Document Object Model Level 3 Events Specification Design of a generic event system which allows registration of event handlers, describes event flow through a tree structure, and provides basic contextual information for each event Draft Ubiquitous Web Applications Activity Proposal The Ubiquitous Web Applications Working Group seeks to simplify the creation of distributed Web applications involving a wide diversity of devices. Chartered Group WS-EventingThis specification defines a protocol for one Web service to register interest with another Web service (called an "event source") in receiving messages about events. Draft Xforms XForms is an XML application that represents the next generation of forms for the Web. Recommendation XHTML Events Module This specification defines the XHTML Event Module, a module that provides XML languages with the ability to represent in syntax the semantics of the Document Object Model (DOM) Level 2 event interfaces Draft XML Events 2An Events Syntax for XMLDraft XML State Chart XML (SCXML) State Machine Notation for Control AbstractionDraft

20. Page 20 RFI and RFP Contributors Aptsoft BEA CA CellExchange Collaborative Consulting Cordys Data Blueprint EDS IBM MetLife NIST Oslo Software Rhysome Sandpiper Software Tibco WareLite Your participation is welcome!

21. Page 21 Collaboration Channels OMG Hosted Mailing List: Subscribe by sending message to request@omg.org. Posting address is eda- rfp@omg.org.request@omg.orgeda- rfp@omg.org Weekly Teleconference: Currently meets on Thursdays at 11 am Eastern Daylight Time (GMT – 4). Dial-in information is distributed via reminders on mailing list. OMG DokuWiki Site: Status updates and updated drafts posted here http://www.omgwiki.org/soaeda/doku.php?id=start http://www.omgwiki.org/soaeda/doku.php?id=start