1 / 15

Talk Organization

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 |. Talk Organization. Changes made to the RFP since September meeting (ad/07-08-01)

lois-gaines
Download Presentation

Talk Organization

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 RFP (ad/07-11-01)Updated December 11, 2007P.J. Hinton, Software Engineer8425 woodfield crossing boulevard | suite 345 | indianapolis | in | 46240 | 317.252.2640 |

  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. What’s Changed Since September Meeting? • Several major revisions made based on detailed review by Pete Rivett. • Narrowed and refined RFP scope. • Removed citations of standards that were of limited relevance to event modeling. • Moved several requirements from mandatory to optional. • Increased items to be discussed. • Streamlined evaluation criteria.

  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. Events in Complex Event Processing • In CEP, an Eventis an observation of state. • An Event has three aspects: • Form: What does the event report about the occurrence? • Significance: What does the event represent? • Relativity: How are events related to one another? • Types of relationships between events • Time: “receiver lifted” precedes “number dialed” • Causality: “window shatters” event happened because “projectile strikes window” • 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. 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.

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

  8. Mandatory Requirements • 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. • 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. • 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.

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

  10. Items to be Discussed • 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. • 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. • 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.

  11. Evaluation Criteria • 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. • Submissions that establish UML as the foundation for event modeling and extend (i.e., define a new capability of) UML will be preferred. • Completeness of the mapping and the use of OMG MDA principles and related work such as MOF QVT and IMM (for XML Schemas). • Ability to translate from one platform to another using the event profile as an intermediate form. • Clarity of the proposed specification for the purpose of implementing conforming tools for modeling Events and ease of reviewing for correctness. • The precision, completeness, compactness, and clarity of the event metamodel. • The ability to easily draw notation elements by hand and use them in collaborative modeling sessions.

  12. Out of Scope/Future Scope • BPMN and BPEL mapping • 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 • Testing

  13. Reasons for Postponing Issuance to March • 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. • 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.

  14. Proposed Schedule

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

More Related