Your SlideShare is downloading. ×
mars/2013-02-05                                                    RFP Template: ab/08-08-01                  Object Manag...
mars/2013-02-05                                                       RFP Template: ab/08-08-011.0       Introduction1.1  ...
mars/2013-02-05                                                   RFP Template: ab/08-08-011.3       Conventions          ...
mars/2013-02-05                                                     RFP Template: ab/08-08-016.0       Specific Requiremen...
mars/2013-02-05                                                      RFP Template: ab/08-08-01          extending the API ...
mars/2013-02-05                                                     RFP Template: ab/08-08-016.3       Relationship to oth...
mars/2013-02-05                                                       RFP Template: ab/08-08-01          Proposals shall a...
mars/2013-02-05                                                     RFP Template: ab/08-08-01          Proposals shall sup...
mars/2013-02-05                                                        RFP Template: ab/08-08-016.8       Evaluation Crite...
mars/2013-02-05                                                       RFP Template: ab/08-08-01          Appendix A       ...
mars/2013-02-05                                                         RFP Template: ab/08-08-01                  [CCM] C...
mars/2013-02-05                                                      RFP Template: ab/08-08-01                  [MDAc] “MD...
mars/2013-02-05                                                     RFP Template: ab/08-08-01                  [UMLC] UML ...
mars/2013-02-05                                                        RFP Template: ab/08-08-01          Metamodel - A mo...
mars/2013-02-05                                                     RFP Template: ab/08-08-01          Technology Committe...
Upcoming SlideShare
Loading in...5
×

Draft Request For Proposal Unified Component Model for Distributed, Real-Time and Embedded Systems

3,580

Published on

Draft Request For Proposal
Unified Component Model for Distributed, Real-Time
and Embedded Systems

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,580
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Draft Request For Proposal Unified Component Model for Distributed, Real-Time and Embedded Systems"

  1. 1. mars/2013-02-05 RFP Template: ab/08-08-01 Object Management Group 140 Kendrick Street Building A Suite 300 Needham, MA 02494 USA Telephone: +1-781-444-0404 Facsimile: +1-781-444-0320 Draft Request For Proposal Unified Component Model for Distributed, Real-Time and Embedded Systems OMG Document: mars/2013-02-05 Author: Johnny Willemsen, Remedy IT (jwillemsen@remedy.nl) Letters of Intent due: 1 December 2013 Submissions due: 13 February 2014 Objective of this RFP The objective of this RFP is to solicit proposals for a new component model standard targeted for general purpose distributed, real-time and embedded (DRE) applications. Proposals must address evolutionary improvements and simplifications to the existing lightweight profile of the OMG CORBA Component Model (CCM) standard in order to take full advantage of the Generic Interaction Support (GIS) connector concept. The new standard, termed the Unified Component Model (UCM) through exploratory work done to date, shall be messaging middleware agnostic and independent of the OMG CORBA standard. For further details see Chapter 6 of this document.OMG RFP 18. Feb. 2013 1
  2. 2. mars/2013-02-05 RFP Template: ab/08-08-011.0 Introduction1.1 Goals of OMG The Object Management Group (OMG) is the worlds largest software consortium with an international membership of vendors, developers, and end users. Established in 1989, its mission is to help computer users solve enterprise integration problems by supplying open, vendor-neutral portability, interoperability and reusability specifications based on Model Driven Architecture (MDA). MDA defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform, and provides a set of guidelines for structuring specifications expressed as models. OMG has established numerous widely used standards such as OMG IDL[IDL], CORBA[CORBA], Realtime CORBA [CORBA], GIOP/IIOP[CORBA], UML[UML], MOF[MOF], XMI[XMI] and CWM[CWM] to name a few significant ones.1.2 Organization of this document The remainder of this document is organized as follows: Chapter 2 - Architectural Context - background information on OMG’s Model Driven Architecture. Chapter 3 - Adoption Process - background information on the OMG specification adoption process. Chapter 4 - Instructions for Submitters - explanation of how to make a submission to this RFP. Chapter 5 - General Requirements on Proposals - requirements and evaluation criteria that apply to all proposals submitted to OMG. Chapter 6 - Specific Requirements on Proposals - problem statement, scope of proposals sought, requirements and optional features, issues to be discussed, evaluation criteria, and timetable that apply specifically to this RFP. Appendix A – References and Glossary Specific to this RFP Appendix B – General References and GlossaryOMG RFP 18. Feb. 2013 2
  3. 3. mars/2013-02-05 RFP Template: ab/08-08-011.3 Conventions The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in RFC 2119 [RFC2119].1.4 Contact Information Questions related to the OMG’s technology adoption process may be directed to omg-process@omg.org. General questions about this RFP may be sent to responses@omg.org. OMG documents (and information about the OMG in general) can be obtained from the OMG’s web site (http://www.omg.org/). OMG documents may also be obtained by contacting OMG at documents@omg.org. Templates for RFPs (like this document) and other standard OMG documents can be found at the OMG Template Downloads Page at http://www.omg.org/technology/template_download.htm2.0 Architectural Context <RFP writers shall not change this section>3.0 Adoption Process <RFP writers shall not change this section>4.0 Instructions for Submitters <RFP writers shall not change this section>5.0 General Requirements on Proposals <RFP writers shall not change this section>OMG RFP 18. Feb. 2013 3
  4. 4. mars/2013-02-05 RFP Template: ab/08-08-016.0 Specific Requirements on Proposals6.1 Problem Statement Part 3 of the OMG CORBA standard is the CORBA Component Model (CCM). CCM specifies a component model based upon IDL and CORBA messaging middleware as defined in Parts 1 and 2 of the CORBA specification. CCM includes a large feature set targeted at both information technology (IT) enterprise architectures and applications, as well as distributed, real-time and embedded (DRE) operational technology (OT) architectures and applications. In recent years, application of and extensions to CCM have been confined primarily to the OT space. For DRE applications, its large integrated feature set and execution environment footprint can become a burden in resource constrained domains. This problem is exacerbated for OT applications that use alternative messaging middleware solutions such as the OMG Data Distribution Service (DDS), either supplemental to or in place of CORBA. CCM has been extended initially through standards like Quality of Service for CCM (QoS4CCM) which extend the API of the CCM standard. In order to fit better into a DRE environment the CCM specification has been extended with a Lightweight CCM (LwCCM) profile. The LwCCM profile disables the IT enterprise features of CCM, to optimize for OT applications. This leads to a greatly reduced set of APIs that have to be supported by a LwCCM product compared to a full CCM implementation, and reduced execution environment footprint and overhead. Per the introduction of the Data Distribution Service for CCM (DDS4CCM) specification, the CCM standard was extended through the generic connector concept to support both DDS as well as any CORBA alternative middleware as a means of implementing communication between components. The DDS4CCM connector concept was more recently incorporated into the CCM standard itself as Generic Interaction Support (GIS). GIS introduces a way to extend the feature set of a CCM implementation without extending the API definition of the LwCCM core each time. DDS4CCM connectors expose a set of extended ports to business components that implement a publish-subscribe information exchange pattern. The two normative DDS4CCM DDS_Event and DDS_State connectors internally communicate with DDS, although the middleware and programming language agnostic IDL-defined APIs can accommodate alternative middleware implementations that support publish-subscribe. The recently adopted AMI4CCM specification reuses the GIS connector concept as well, to add asynchronous method invocation (AMI) to CCM withoutOMG RFP 18. Feb. 2013 4
  5. 5. mars/2013-02-05 RFP Template: ab/08-08-01 extending the API definition of the CCM core. AMI4CCM supplemented the publish-subscribe pattern connector capability introduced by DDS4CCM with a complementary request-reply information exchange pattern. A prime concern raised about CCM in embedded applications is that its mandatory dependency on CORBA can lead to unwanted memory and storage footprint, particularly when alternative middleware implementations are used. The hard to use IDL to C++ language mapping has also led to a lot of issues for users. The robotics community within the OMG has defined its own Robotics Technology Component (RTC) standard to resolve these concerns. Some CCM implementations have defined their own custom language mappings to circumvent these problems. With the recent adoption of the IDL to C++11 language mapping we have a new language mapping that makes CCM application code independent of CORBA middleware and the CORBA name space for C++ users. In order to address the problems outlined in this document, the first step in the realization of a new Unified Component Model for distributed, real-time and embedded applications (UCM4DRE) is removal of the mandatory dependency on CORBA from the CCM core. Relative to LwCCM, new UCM solutions must be simpler, lighter weight, middleware agnostic, and they should incorporate the GIS connector concept from the CCM specification. Moreover, proposals should address an evolutionary approach toward leveraging LwCCM and its related suite of comprehensive standards to the maximum practical extent, in order to provide a clean transition path toward UCM for LwCCM implementations and use cases that already exist. To this end, UCM must provide generic interaction support through extended ports for both publish- subscribe and request-reply patterns of information exchange, allowing support for CORBA, DDS and other middleware solutions to be delivered through new middleware independent connector types.6.2 Scope of Proposals Sought This RFP searches for proposals that define a simplified, evolutionary version of the current combined suite of CCM/LwCCM, QoS4CCM, DDS4CCM and AMI4CCM standards targeting general purpose distributed, real-time and embedded (DRE) applications. New middleware agnostic UCM solutions should not offer a completely different or new component model, but should instead leverage the current suite of OMG component oriented standards to the maximum practical extent.OMG RFP 18. Feb. 2013 5
  6. 6. mars/2013-02-05 RFP Template: ab/08-08-016.3 Relationship to other OMG Specifications and activities6.3.1 Relationship to OMG specifications CORBA v3.3 - formal/2012-11-12, formal/2012-11-14, formal/2012-11-16 DDS for CCM (DDS4CCM) – formal/2012-02-01 Asynchronous Method Invocation for CORBA Component Model (AMI4CCM) – ptc/2012-07-08 Quality of Service for CCM (QOSCCM) – formal/2008-10-12 Data Distribution Service (DDS) – formal/2007-01-01 Deployment and Configuration of Component-based Distributed Applications (DEPL) – formal/2006-04-02 IDL to C++11 (CPP11) – formal/2013-02-046.3.2 Relationship to other OMG Documents and work in progress IDL 3.5 (IDL35) – mars/2011-09-086.4 Related non-OMG Activities, Documents and Standards6.5 Mandatory Requirements Proposals shall be independent of any particular middleware standard. Proposals shall not have CORBA as a mandatory dependency for the new Unified Component Model (UCM) standard. Proposals shall use IDL, CCM Generic Interaction Support (GIS) connector concepts, and GIS extensions to the IDL grammar for the specification of UCM components, ports, template modules, connectors, mirror ports, interfaces, and other supporting types in IDL. Proposals shall support UCM component inheritance compliant with the IDL specification. However, proposals do not have to offer support for component inheritance from an IDL interface, per the IDL “supports” keyword. Proposals shall support local connection between components and connectors that does not go through any middleware layer, with the connection established at launch time via a DEPL compliant deployment framework.OMG RFP 18. Feb. 2013 6
  7. 7. mars/2013-02-05 RFP Template: ab/08-08-01 Proposals shall address standardized component and connector life cycle state model with appropriate callback operations compatible with a DEPL deployment framework. Proposals shall offer support for UCM GIS extended port types that implement a middleware agnostic publish-subscribe information exchange pattern. Goal is to leverage the DDS4CCM specification to the maximum practical extent. Proposals shall support the definition of publish-subscribe pattern extended port types via user-defined IDL “struct” or “union” type definitions using the mechanism of GIS template module instantiation. Proposals shall offer support for UCM GIS extended port types that implement a middleware agnostic request-reply information exchange pattern. Goal is to leverage the AMI4CCM specification for this definition. Proposals shall support the definition of request-reply pattern extended port types via user-defined IDL “interface” type definitions using the mechanism of GIS template module instantiation. Proposals shall provide the ability to implement component executors in a way that they are source code compatible between UCM implementations. Proposals shall address the interface of a UCM component implementation framework (CIF) to a deployment framework that is compliant with the OMG Deployment and Configuration of Component-based Distributed Applications (DEPL) specification. Proposals shall provide the ability to define component attributes with initial component configuration values settable via a DEPL compliant deployment framework. Proposals shall provide support for scheduling timers (sporadic and recurring) with application supplied event handlers, using at least monotonic and system time. Proposals shall provide support for a simple, lightweight CIF session container that encapsulates a flexible event queue/dispatch and threading model. The container provides the execution environment for UCM application components. Proposals shall provide a user extensible, event driven programming model, that supports both thread pools as well as a single-threaded/non re-entrant threading model as the default.OMG RFP 18. Feb. 2013 7
  8. 8. mars/2013-02-05 RFP Template: ab/08-08-01 Proposals shall support the concept of service connectors which are connectors that have only one instance within a container. Proposals shall offer request-reply connector types that support both synchronous and asynchronous method invocation from a client/request side perspective. Proposals shall offer request-reply connector types that support both synchronous and asynchronous invocation handling from a service/reply side perspective. Proposals shall support the DDS4CCM standard defined DDS connectors for State and Event communication patterns. Proposals shall support a simple, optional and key-less factory/home capability for dynamic/run-time component instantiation and destruction life cycle management of application components. Proposals shall address reconfiguration and redeployment options for modification of a UCM domain at run-time. Proposals shall not specify language bindings to specific programming languages such as C/C++/C++11/Java, but shall instead leverage standard IDL Language mappings. Proposals shall address the implementation of a UCM request-reply connector using CORBA.6.6 Optional Requirements Proposals may address the implementation of a UCM request-reply connector using DDS. Proposals may address the implementation of a UCM publish-subscribe connector equivalent of a LwCCM event connector, which offers a UCM alternative to the current built-in CCM event support.6.7 Issues to be discussed Proposal shall discuss how CCM components can be migrated to a UCM environment. These issues will be considered during submission evaluation. They should not be part of the proposed normative specification. (Place them in Part I of the submission.)OMG RFP 18. Feb. 2013 8
  9. 9. mars/2013-02-05 RFP Template: ab/08-08-016.8 Evaluation Criteria6.9 Other information unique to this RFP6.10 RFP TimetableThe timetable for this RFP is given below. Note that the TF or its parent TC may, incertain circumstances, extend deadlines while the RFP is running, or may elect to havemore than one Revised Submission step. The latest timetable can always be found at theOMG Work In Progress page at http://www.omg.org/schedules under the item identifiedby the name of this RFP. Note that “<month>” and “<approximate month>” is the nameof the month spelled out; e.g., January. Event or Activity Actual Date Preparation of RFP by TF RFP placed on OMG document server “Four week rule” Approval of RFP by Architecture Board Review by TC TC votes to issue RFP September 2013 LOI to submit to RFP due December 1, 2013 Initial Submissions due and placed on February 13, 2014 OMG document server (“Four week rule”) Voter registration closes April 1, 2014 Initial Submission presentations March 17, 2014 Preliminary evaluation by TF Revised Submissions due and placed on November 5, 2014 OMG document server (“Four week rule”) Revised Submission presentations December 8, 2014 Final evaluation and selection by TF Recommendation to AB and TC Approval by Architecture Board Review by TC TC votes to recommend specification December 2014 BoD votes to adopt specification March 2015OMG RFP 18. Feb. 2013 9
  10. 10. mars/2013-02-05 RFP Template: ab/08-08-01 Appendix A References and Glossary Specific to this RFP A.1 References Specific to this RFP The following documents are referenced in this document: • [CORBA] CORBA v3.3, formal/2012-11-12, formal/2012-11-14, formal/2012-11-16 • [DDS4CCM] DDS for CCM, formal/2012-02-01 • [AMI4CCM] Asynchronous Method Invocation for CORBA Component Model, ptc/2012-07-08 • [QOS4CCM] Quality of Service for CCM, formal/2008-10-12 • [DDS] Data Distribution Service, formal/2007-01-01 • [DEPL] Deployment and Configuration of Component-based Distributed Applications, formal/2006-04-02 • [CPP11] IDL to C++11, formal/2013-02-04 • [IDL35] IDL 3.5, mars/2011-09-08 A.2 Glossary Specific to this RFP Generic Interaction Support (GIS) – The generic connector concept as defined in the CCM specification coming from DDS4CCM. Appendix B General Reference and Glossary B.1 General References The following documents are referenced in this document: [ATC] Air Traffic Control Specification, http://www.omg.org/technology/documents/formal/air_traffic_control.htm [BCQ] OMG Board of Directors Business Committee Questionnaire, http://doc.omg.org/bc/07-08-06OMG RFP 18. Feb. 2013 10
  11. 11. mars/2013-02-05 RFP Template: ab/08-08-01 [CCM] CORBA Core Components Specification, http://www.omg.org/technology/documents/formal/components.htm [CORBA] Common Object Request Broker Architecture (CORBA/IIOP), http://www.omg.org/technology/documents/formal/corba_iiop.htm [CSIV2] [CORBA] Chapter 26 [CWM] Common Warehouse Metamodel Specification, http://www.omg.org/technology/documents/formal/cwm.htm [DAIS] Data Acquisition from Industrial Systems, http://www.omg.org/technology/documents/formal/dais.htm [EDOC] UML Profile for EDOC Specification, http://www.omg.org/techprocess/meetings/schedule/UML_Profile_for_EDO C_FTF.html [EJB] “Enterprise JavaBeans™”, http://java.sun.com/products/ejb/docs.html [FORMS] “ISO PAS Compatible Submission Template”. http://www.omg.org/cgi-bin/doc?pas/2003-08-02 [GE] Gene Expression, http://www.omg.org/technology/documents/formal/gene_expression.htm [GLS] General Ledger Specification , http://www.omg.org/technology/documents/formal/gen_ledger.htm [Guide] The OMG Hitchhikers Guide,, http://www.omg.org/cgi-bin/doc?hh [IDL] ISO/IEC 14750 also see [CORBA] Chapter 3. [IDLC++] IDL to C++ Language Mapping, http://www.omg.org/technology/documents/formal/c++.htm [Inventory] Inventory of Files for a Submission/Revision/Finalization, http://doc.omg.org/smsc/2007-09-05 [MDAa] OMG Architecture Board, "Model Driven Architecture - A Technical Perspective”, http://www.omg.org/mda/papers.htm [MDAb] “Developing in OMGs Model Driven Architecture (MDA),” http://www.omg.org/docs/omg/01-12-01.pdfOMG RFP 18. Feb. 2013 11
  12. 12. mars/2013-02-05 RFP Template: ab/08-08-01 [MDAc] “MDA Guide” (http://www.omg.org/docs/omg/03-06-01.pdf) [MDAd] “MDA "The Architecture of Choice for a Changing World™"”, http://www.omg.org/mda [MOF] Meta Object Facility Specification, http://www.omg.org/technology/documents/formal/mof.htm [MQS] “MQSeries Primer”, http://www.redbooks.ibm.com/redpapers/pdfs/redp0021.pdf [NS] Naming Service, http://www.omg.org/technology/documents/formal/naming_service.htm [OMA] “Object Management Architecture™”, http://www.omg.org/oma/ [OTS] Transaction Service, http://www.omg.org/technology/documents/formal/transaction_service.htm [P&P] Policies and Procedures of the OMG Technical Process, http://www.omg.org/cgi-bin/doc?pp [PIDS] Personal Identification Service, http://www.omg.org/technology/documents/formal/person_identification_se rvice.htm [RAD] Resource Access Decision Facility, http://www.omg.org/technology/documents/formal/resource_access_decisio n.htm [RFC2119] IETF Best Practices: Key words for use in RFCs to Indicate Requirement Levels, (http://www.ietf.org/rfc/rfc2119.txt). [RM-ODP] ISO/IEC 10746 [SEC] CORBA Security Service, http://www.omg.org/technology/documents/formal/security_service.htm [TOS] Trading Object Service, http://www.omg.org/technology/documents/formal/trading_object_service.h tm [UML] Unified Modeling Language Specification, http://www.omg.org/technology/documents/formal/uml.htmOMG RFP 18. Feb. 2013 12
  13. 13. mars/2013-02-05 RFP Template: ab/08-08-01 [UMLC] UML Profile for CORBA, http://www.omg.org/technology/documents/formal/profile_corba.htm [XMI] XML Metadata Interchange Specification, http://www.omg.org/technology/documents/formal/xmi.htm [XML/Value] XML Value Type Specification, http://www.omg.org/technology/documents/formal/xmlvalue.htm B.2 General Glossary Architecture Board (AB) - The OMG plenary that is responsible for ensuring the technical merit and MDA-compliance of RFPs and their submissions. Board of Directors (BoD) - The OMG body that is responsible for adopting technology. Common Object Request Broker Architecture (CORBA) - An OMG distributed computing platform specification that is independent of implementation languages. Common Warehouse Metamodel (CWM) - An OMG specification for data repository integration. CORBA Component Model (CCM) - An OMG specification for an implementation language independent distributed component model. Interface Definition Language (IDL) - An OMG and ISO standard language for specifying interfaces and associated data structures. Letter of Intent (LOI) - A letter submitted to the OMG BoD’s Business Committee signed by an officer of an organization signifying its intent to respond to the RFP and confirming the organization’s willingness to comply with OMG’s terms and conditions, and commercial availability requirements. Mapping - Specification of a mechanism for transforming the elements of a model conforming to a particular metamodel into elements of another model that conforms to another (possibly the same) metamodel. Metadata - Data that represents models. For example, a UML model; a CORBA object model expressed in IDL; and a relational database schema expressed using CWM.OMG RFP 18. Feb. 2013 13
  14. 14. mars/2013-02-05 RFP Template: ab/08-08-01 Metamodel - A model of models. Meta Object Facility (MOF) - An OMG standard, closely related to UML, that enables metadata management and language definition. Model - A formal specification of the function, structure and/or behavior of an application or system. Model Driven Architecture (MDA) - An approach to IT system specification that separates the specification of functionality from the specification of the implementation of that functionality on a specific technology platform. Normative – Provisions that one must conform to in order to claim compliance with the standard. (as opposed to non-normative or informative which is explanatory material that is included in order to assist in understanding the standard and does not contain any provisions that must be conformed to in order to claim compliance). Normative Reference – References that contain provisions that one must conform to in order to claim compliance with the standard that contains said normative reference. Platform - A set of subsystems/technologies that provide a coherent set of functionality through interfaces and specified usage patterns that any subsystem that depends on the platform can use without concern for the details of how the functionality provided by the platform is implemented. Platform Independent Model (PIM) - A model of a subsystem that contains no information specific to the platform, or the technology that is used to realize it. Platform Specific Model (PSM) - A model of a subsystem that includes information about the specific technology that is used in the realization of it on a specific platform, and hence possibly contains elements that are specific to the platform. Request for Information (RFI) - A general request to industry, academia, and any other interested parties to submit information about a particular technology area to one of the OMGs Technology Committee subgroups. Request for Proposal (RFP) - A document requesting OMG members to submit proposals to an OMG Technology Committee. Such proposals must be received by a certain deadline and are evaluated by the issuing Task Force. Task Force (TF) - The OMG Technology Committee subgroup responsible for issuing a RFP and evaluating submission(s).OMG RFP 18. Feb. 2013 14
  15. 15. mars/2013-02-05 RFP Template: ab/08-08-01 Technology Committee (TC) - The body responsible for recommending technologies for adoption to the BoD. There are two TCs in OMG – the Platform TC (PTC) focuses on IT and modeling infrastructure related standards; while the Domain TC (DTC) focuses on domain specific standards. Unified Modeling Language (UML) - An OMG standard language for specifying the structure and behavior of systems. The standard defines an abstract syntax and a graphical concrete syntax. UML Profile - A standardized set of extensions and constraints that tailors UML to particular use. XML Metadata Interchange (XMI) - An OMG standard that facilitates interchange of models via XML documents.OMG RFP 18. Feb. 2013 15

×