Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Remedy IT Initial Submission for the Unified Component Model (UCM) for Distributed, RealTime, and Embedded Systems


Published on

Remedy IT has published their initial submission for UCM

Change of address:
Melkrijder 11
3861 SG Nijkerk
tel. +31 (0)88 053 0000

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Remedy IT Initial Submission for the Unified Component Model (UCM) for Distributed, RealTime, and Embedded Systems

  1. 1. Date: May 2014 Initial Submission Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands Tel: +31-10-5220139 Primary contact: Johnny Willemsen ( OMG Document Number: mars/2014-05-01
  2. 2. Copyright © 1997-2012 Object Management Group. Copyright © 2014 Remedy IT USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice. LICENSES The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification. Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control. PATENTS The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. GENERAL USE RESTRICTIONS Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, tng, or information storage and retrieval systems--without permission of the copyright owner.
  3. 3. DISCLAIMER OF WARRANTY WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification. RESTRICTED RIGHTS LEGEND Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 140 Kendrick Street, Needham, MA 02494, U.S.A. TRADEMARKS MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™, CWM™, CWM Logo™, IIOP™ , IMM™ , MOF™ , OMG Interface Definition Language (IDL)™ , and OMG Systems Modeling Language (OMG SysML)™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners. COMPLIANCE The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials. Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites.
  4. 4. OMG’s Issue Reporting Procedure All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://, under Documents, Report a Bug/Issue ( ment.htm).
  5. 5. mars/2014-05-01 i Preface..........................................................................................iii 1 Scope 1 2 Conformance 1 3 Normative References 1 4 Terms and Definitions 1 5 Symbols 2 6 Additional Information 2 6.1 Changes to Adopted OMG Specifications 2 6.2 How to Read this Specification 2 6.3 Acknowledgements 2 7 Platform Independent Model (PIM) 5 7.1 Overview 5 7.2 High Level Overview 5 7.3 Container 6 7.3.1 Component Hosting 6 7.3.2 Container Service Registry 6 7.3.3 Execution Model 6 7.4 Component 6 7.4.1 Component Context 6 7.4.2 Component Lifecycle 7 7.4.3 Component Configuration Values 8 7.4.4 Component Facets 8 7.4.5 Component Receptacles 8 7.5 Connectors 8 7.6 Homes 8 7.7 Container services 9 7.7.1 Timer Container Service 9 7.7.2 Messaging Container Service 9 7.8 Assemblies 9 7.9 Interaction patterns 10 7.10 Request/reply 10 7.10.1 CORBA Based Request/Reply 10 7.10.2 DDS Based Request/Reply 11 7.11 Publish/Subscribe 11 7.11.1 DDS Based Publish/Subscribe 11 7.11.2 CORBA Event Based Publish/Subscribe 11 7.12 D&C Based Deployment Model 11
  6. 6. ii mars/2014-05-01 7.13 Other Deployment Models 11 7.14 Various Comments and Ideas 11 8 IDL Platform Specific Model 11 8.1 Introduction 11 8.2 Differences With LwCCM 11 8.3 Core 11 8.4 Container 12 8.5 Registry 12 8.6 Component 12 8.7 Port 13 8.8 Locator 13 8.9 Configurator 13 8.10 Context 14 8.11 Home 14 8.12 Container services 14 8.13 Timer Container Service 15 8.14 Messaging Container Services 15 8.14.1 Queue Service 15 8.14.2 Dispatcher Service 16 8.15 Example Component 16
  7. 7. mars/2014-05-01 iii Preface About the Object Management Group OMG Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies and academia. OMG member companies write, adopt, and maintain its specifications a mature, open process. OMG's specifications implement the Model Driven Architecture® (MDA®), maximizing ROI through a full-lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG's specifications include: UML® (Unified Modeling Language™); CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry- specific standards for dozens of vertical markets. More information on the OMG is available at OMG Specifications As noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications are available from this URL: Specifications are organized by the categories: Business Modeling Specifications Middleware Specifications • CORBA/IIOP • Data Distribution Services • Specialized CORBA IDL/Language Mapping Specifications Modeling and Metadata Specifications • UML, MOF, CWM, XMI • UML Profile Modernization Specifications
  8. 8. iv mars/2014-05-01 Platform Independent Model (PIM), Platform Specific Model (PSM), Interface Specifications • CORBAServices • CORBAFacilities OMG Domain Specifications CORBA Embedded Intelligence Specifications CORBA Security Specifications All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. (as of January 16, 2006) at: OMG Headquarters 109 Highland Ave Needham MA 02494 USA USA Tel: +1-781-444-0404 Fax: +1-781-444-0320 Email: Certain OMG specifications are also available as ISO standards. Please consult Issues The reader is encouraged to report any technical or editing issues/problems with this specification to report_issue.htm.
  9. 9. mars/2014-05-01 1 1 Scope This specification defines the Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems. 2 Conformance This specification defines X conformance points. Implementations must support at least one of these conformance points: • TBD 3 Normative References The normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. • Asynchronous Method Invocation for CORBA Component Model [AMI4CCM] formal/2013-04-01 • Common Object Request Broker [CORBA] formal/2012-11-12 • Deployment and Configuration of Component-based Distributed Applications [DEPL] formal/2006-04-02 • Quality of Service for CCM [QOS4CCM] formal/2008-10-02 • Data Distribution Service [DDS] formal/2007-01-01 • DDS for Lightweight CCM [DDS4CCM] formal/2012-02-01 • IDL to C++11 [CPP11] formal/2014-01-01 • IDL4 [IDL4] mars/2014-03-01 • Robotic Technology Component [RTC] formal/2012-09-01 • TAO AMH [AMH] • RPC over DDS [RPCDDS] 4 Terms and Definitions For the purposes of this specification, the terms and definitions given in the normative reference and the apply. Component A specific, named collection of features that can be described by a component definition Executor The user created implementation Connector
  10. 10. 2 mars/2014-05-01 An endpoint entity deployed together with a component to implement the port at runtime according to GIS concepts Container A container provides the runtime execution environment for a component Context Interface that provides access to the references for the component ports Generic Interaction Support (GIS) The generic connector concept as defined in the IDL4 specification Home A component factory Locator Proxy between the UCM framework and the user provided executor Port Delivers interaction support 5 Symbols List of symbols/abbreviations. 6 Additional Information 6.1 Changes to Adopted OMG Specifications . 6.2 How to Read this Specification The rest of this document contains the technical content of this specification. Although the chapters are organized in a logical manner and can be read sequentially, this reference specification is intended to be read in a non-sequential manner. Consequently, extensive cross-references are provided to facilitate browsing and search. 6.3 Acknowledgements The companies submitted and/or supported parts of this specification: • Northrop Grumman Corporation (NGC)
  11. 11. mars/2014-05-01 5 7 Platform Independent Model (PIM) 7.1 Overview The Unified Component Model (UCM) for Distributed, Real-Time and Embedded Systems is defined as a Platform Independent Model (PIM). This PIM can be transformed into the IDL Platform Specific Model (PSM) defined in Section 8 of this document, or into alternative PSMs. A UCM solution will require an implementation based upon multiple specifications to supplement the UCM core component model defined in this document. Supplements must include at a minimum specifications for connectors to implement ports, a deployment model, and possible generic or domain specific extensions. Note – This initial submission combines everything into one document to simplify reading and discussions. UCM defines a unified component model which focuses on distributed, real-time and embedded systems. The generic meta model defines a platform and communication middleware agnostic component model. Using generic interaction support (GIS) UCM defines standards based interoperability between components at runtime without tying UCM to a specific communication middleware. The separation between the Platform Independent Model and the Platform Specific Model makes it possible to specialize a UCM implementation for a specific environment. The UCM meta model enables the modeling of the type system, interfaces, ports, and components. This meta model is a subset of the IDL4 [IDL4] meta model. Note – At this moment the IDL meta model is not part of the UCM specification. It is something to be added as part of the revised submission. 7.1.1 High Level Overview UCM defines a unified component model in order to model, implement, and deploy components in a standardized way. Components use ports to provide and use services to/from other entities including (but not limited to) UCM components, other (legacy) software services, and hardware devices. Ports provide the specific connections using different interaction patterns which at the end allow interaction with other entities. Supported interaction patterns are at least request-reply and publish-subscribe. Components are hosted at runtime by a UCM container. The container provides services to a “component executor” which implements the user business logic. The container also provides a standardized API for managing components hosted by the UCM container. Using this standardized API additional deployment models can be defined. These deployment models can, for example, use the OMG Deployment and Configuration [DEPL] standard. In more constrained environments a minimalistic deployment model can use this standardized API. A port of the component is connected inside the model using a specific interaction pattern. At runtime the interaction pattern is delivered by a connector fragment which is deployed together with the component in the container. The connector fragment implementation handles interoperability of the port using a specific communication mechanism. The user defined business logic is implemented in the “component executor”. The implementation uses a specific UCM PSM. Components implemented using different PSMs interoperate when they use the same interaction pattern using the same communication mechanism.
  12. 12. 6 mars/2014-05-01 Components can be grouped together to form an assembly. Either a component or an assembly can be deployed as one entity by the deployment model. 7.1.2 Container The UCM container hosts the components and connectors at runtime. The container exposes two different APIs. First it exposes a “deployment API”. This deployment API can be used to manage the set of hosted components within the container. This can for example be a deployment tool that interacts with the container or a monitor tool that provides insight into the running system. Secondly the container provides a service API to the components it hosts to access the container and additional services. Note – Instead of deployment API we could also call it containment or management API Component Hosting The deployment API provides the deployment model the service to add and remove components from the container. By standardizing this API different deployment models can be defined as additions to the UCM core. In order to be more flexible with respect to implementation differences and future changes components are not directly registered into the container, but through a standardized proxy that contains the reference to the component, the “locator”. This locator allows the container access to the component, but also provides access to other entities that are related to a component. Note – A standardized proxy approach for homes, connectors, and services would increase flexibility for the implementation of UCM. This is something that is not the concern of the component developer. Container Service Registry The container service registry provides a flexible way to install services within the container. All components within one container share the same container services. Services can be installed by the deployment model, components, and connectors. It is the responsibility of the entity that installs a service into the container to also remove this service from the container. Note – Also here a locator should be registered Execution Model The default UCM execution model is a single threaded and non reentrant model with inversion of control. This model is the simplest execution model, but will not work for all UCM systems. With UCM we don’t want to restrict the number of different runtime execution models. The Messaging Container Services as described in Section encapsulate execution models. 7.1.3 Component Component Context The UCM “component context” provides the component access to the references that are tied to the component ports, as well as the service registry. As part of the component the ports the component uses are specified. Within the runtime environment the references for these ports can be retrieved from the component context. The component specific context API is inherited from the generic UCM context. The component specific context is generated based on the component definition. The content of the component context can change during runtime of the component.
  13. 13. mars/2014-05-01 7 Discussion – In our current proposal we have a generic static context API where the name of the port is one of the arguments of each operation which will lead to a smaller API, but within the context implementation more string matching has to happen. Also, a change in the port definition of the component without a change to the implementation of the component will lead to a runtime error instead of a compile error. This enables some template programming because the operation names and signatures are constant. Component Lifecycle All components will go through a predefined lifecycle during their existence. Using the lifecycle callbacks the component developer can react at specific predefined points in the existence of a component. These lifecycle callbacks are called by the runtime environment at predefined moments. The following lifecycle callbacks are called. • on_configured: the component has been created and all its initial configuration values have been set and the compo- nent changes from created state to the passive state. It should now prepare for handling incoming requests. At the moment this operation returns it has to serve these incoming requests • on_activate: the component is allowed to make outgoing requests and changes from the passive state to the active state • on_passivate: the component must stop making outgoing requests and but still should expect incoming requests. It changes back to the passive state • on_remove: the component changes from the passive state to the created state. It could now get removed, or get a dif- ferent configuration and change back to the passive state Note – Should there be an option for when a component is not interested in a particular lifecycle callback? The current IDL2C++11 local language mappings require that all callbacks are implemented. Can we do something about this, maybe some new annotation? Tag the interface or operation as listener? Discussion – What if different domains would like different lifecycle models? Those models could be simpler, but also more complex than the default model we propose. Would this require the lifecycle methods to be on a separate interface or would there be a different component base? How would this affect the deployment model?
  14. 14. 8 mars/2014-05-01 Component Configuration Values Components can define attributes using the UCM type system. The UCM runtime could support the ability to set these defined attributes to a default for a given component. Any deployment model supporting UCM should deliver the capability to set these defined attributes to a specific value after the creation of the component. In order for the deployment model to set the attributes, any component defining attributes has to define a “configurator”. This configurator implements the ability to set the value of a set of attributes of the component. Component Facets For each facet of a component a get_<foo> factory operation is added to the component executor (foo has to be replaced with the concrete facet name). Component Receptacles For each receptacle of a component a get_<foo> operation is added to the component context (foo has to be replaced with the concrete receptacle name). 7.1.4 Connectors A connector ‘connects’ a component to another entity. This could be another component, but also non-component software services, legacy systems, or hardware devices. A connector fragment implements the functionality to translate a specific port to a specific communication middleware (CORBA, DDS, shared memory, etc), other non-component services, or hardware devices. This doesn’t necessarily imply that there is a one to one connection between the entities a connector connects. At deployment time the logical connector is split into “connector fragments” which are deployed collocated with the entities they ‘connect’. Connector fragments include support for attributes using the UCM type system. Connector fragments are intended to be small and lightweight and are deployed into the container. 7.1.5 Homes UCM supports the concept of a home. A home is a component factory which provides the ability to create components at runtime. Homes can be deployed using the UCM deployment API. On a home attributes can be defined, just as with components. These attributes can be set by a deployment model. The user has to provide an implementation of the home in the “home executor”. In addition to attribute accessors, a home executor has a create() operation. The responsibility of this create operation is to return a new created component executor. The UCM generated code for a home will create the needed component locator for the created component executor. After that the UCM infrastructure will install the component into the same container as the home. It is the responsibility of the user of the home to then set all attributes on the created component and walk the component through its lifecycle states. Note – Another solution would be that the home executor (or generated code) would also automatically walk the component through its lifecycle states, but that would prevent any more complex usage of homes where the user for example wants to deploy multiple components/connectors and then have this set of components walk through their lifecycle per a consistent state transition sequence. To keep the UCM model for a home simple, setting of attribute configuration values onto the new component is the responsibility of the entity using the home. Note – Adding user defined create operations with custom arguments only complicates UCM and doesn’t bring any additional value to our idea. These custom operations can’t be used by any generic deployment model, and they define two ways of con-
  15. 15. mars/2014-05-01 9 struction (through a home and without a home) with different behaviour and semantics. If the constructed component has to get some initial settings, the configuration values of the component are the way to do this. This approach works with and with- out homes. It could be an option to pass the configuration values of the component to the create() operation of the home. The home is then able to make some create decisions based on the passed configuration values. It would simplify the model when regular component instantiation and home support are using the same concepts. 7.1.6 Container services Container services offer a way to extend the functionality of a container without an explosion of the container API and built-in functionality for the container itself. Container services are deployed and installed into a container, to be used by any component or connector within that container. Timer Container Service It is a common use case that components need to react to single or recurring timers. By defining a standard timer container service component developers can schedule, cancel, and react to timers in a standardized way. The timer container service will provide the service to schedule, cancel, and react to a timer. Messaging Container Service UCM doesn’t have a mandatory dependency on any communication middleware. This implies that UCM cannot use for example RTCORBA for its execution models. Also, a different kind of communication middleware can deliver different threading semantics which UCM has to shield the components against. For example, several DDS implementations are multi- threaded by design. Multiple DDS threads could callback into user code at the same moment which would violate the default single threaded UCM model. The messaging container services deliver the infrastructure for the various UCM execution models. They comprise the queue and the dispatcher service. The queue service provides the support to retrieve a message queue and schedule, cancel, and retrieve messaging objects into and from a message queue. The dispatcher service uses the queue service for retrieving messaging objects which it invokes as operations on the components. By defining multiple types of queue and dispatcher implementations different execution models can be achieved, like single threaded (one queue with a single-threaded dispatcher), multi-threaded (one queue with a multi-threaded dispatcher), single threaded per component (one queue per component and a single threaded dispatcher for each component), etc, as well as allowing for different prioritization models (FIFO, LIFO, etc). In order for the execution models to work, any connector or other service which wants to invoke operations on a user component has to use the messaging container service. A violation of this rule will break the execution model semantics. The messaging container service is not something user components will interact with explicitly. It is purely for connectors and other container services. 7.1.7 Assemblies An assembly is a grouping of components with internal connections defined between these components. The assembly concept makes it easier to reuse a group of components, as well as to define complex systems using nested hierarchies of assemblies. The user of an assembly only has to connect the external visible ports of the assembly, not all the internal ports. A definition of an assembly results in a factory and locator for that assembly. The deployment model is able to deploy the assembly with one factory invocation. It is the responsibility of the assembly factory to create all internal components and connectors, connect all internal ports, and redirect configuration values to the appropriate internal entities. The deployment model can then connect the external ports of the assembly. Note – Allowing the creation of an assembly factory greatly simplifies deployment of larger systems
  16. 16. 10 mars/2014-05-01 7.2 Interaction patterns 7.2.1 Request/reply UCM supports the request/reply interaction pattern. This interaction pattern is provided as a function style API, defined as a set of user-defined operations. The component developer can invoke an operation at the programming language level with the ability to send and receive user data. UCM will allow the user to group operations into an interface. This single user-defined interface is grouped together with additional interfaces defined by the UCM request/reply port itself, as needed, to support alternative interaction semantics such as asynchronous client side invocation or asynchronous server side implementation. The collective set of interfaces for a single UCM request/reply port are available to the component executor. Note – A UCM port is similar to the LwCCM extended port. For asynchronous client side invocations UCM will use the concepts of the existing AMI4CCM standard [AMI4CCM]. The UCM request/reply port containing the user defined interface is extended with the AMI4CCM implied interfaces. For asynchronous server side functionality UCM will use the concepts of the Asynchronous Message Handling (AMH) as available as part of TAO [AMH]. AMH defines a set of interface conversion rules that lead to a set of interfaces on the server side. The UCM request/reply port containing the user defined interface is extended with the AMH implied interfaces. By standardizing the request/reply interaction pattern different UCM implementations can support different kinds of communication middleware solutions. In order to guarantee interoperability a mapping of the request/reply interaction pattern to a specific communication middleware has to be standards based at the wire protocol level. Note – These mappings shall not be part of the core UCM specification but will be included in separate specifications. In order to simplify the discussion some mapping details are part of this initial submission. CORBA Based Request/Reply UCM can be implemented with CORBA based request/reply interaction support. A CORBA request/reply specification will standardize the way UCM ports, interfaces, and type system are translated to CORBA interfaces and types. The main difference between CORBA and UCM is the definition of the interface. With UCM an interface is local by default, whereas with CORBA an interface is remote by default. A CORBA based request/reply interaction style can be easily defined so that the interfaces of the ports connected to the CORBA based request/reply connectors are also available in a remote version. Just as with DDS, CORBA defines a set of policies to control its behavior. The CORBA based request/reply part of UCM will also standardize the way CORBA policies can be configured on the CORBA connector fragments. A CORBA request/reply connection in the model is deployed as two collocated CORBA connector fragments. The server side of a CORBA connector will have configuration values indicating how the CORBA connector fragment has to register itself to the CORBA middleware. The client side of a CORBA connector will have configuration values that will enable it to connect to the correct CORBA servant. It is up to the CORBA connector fragments to establish the connection, as specified by connector configuration values. This could for example enforce that the connection is created at startup or that it is delayed to the moment the connection gets used the first time.
  17. 17. mars/2014-05-01 11 DDS Based Request/Reply UCM can be implemented with DDS based request/reply interaction support. With a function based API the DDS request/ reply interaction support has to standardize the mapping of a port and each of its operations to DDS topics. The identity of the port at runtime has to be standardized so that connections made as part of the deployment are handled correctly at runtime. The proposal is to use part of the work of the RPC over DDS efforts [RPCDDS]. Because a revised RPCDDS submission is in progress this part is left further unspecified until the RPC over DDS standard is in place. 7.2.2 Publish/Subscribe UCM supports the publish/subscribe interaction pattern. The UCM core specification will at least standardize an event and state based interaction pattern. DDS Based Publish/Subscribe Note – The event and state interaction patterns can be defined by reusing the DDS4CCM specification [DDS4CCM]. CORBA Event Based Publish/Subscribe Note – There could be an addon specification that defines the publish/subscribe event interaction pattern using the CORBA event channel. 7.3 D&C Based Deployment Model The OMG has an existing Deployment and Configuration [DEPL] standard for deployment. UCM based systems can be deployed with D&C but this is slightly different compared to, for example, a deployment of a LwCCM system. In the deployment plan for a UCM based system only connections between the collocated components and connector fragments are defined. The CORBA connections as part of a LwCCM plan are replaced by CORBA connectors that are collocated with the components. The CORBA connector fragments are configured using configuration values with the needed meta data the fragment needs to provide or use a CORBA connection. It is the responsibility of the CORBA connector fragment to setup the CORBA connection. This will not be done by the D&C toolchain. This is similar to the DDS4CCM connector fragments which are configured using configuration values for the topic, domain, and other DDS configuration settings. It is up to DDS itself, within a DDS4CCM connector fragment implementation to connect publishers and subscribers together. Each connector fragment has the responsibility to setup the connection that is needed. With DDS this establishment is left to the underlying middleware, with CORBA it has to be handled explicitly in the connector. 7.3.1 Other Deployment Models Since UCM standardizes the deployment container API, other deployment models are possible. A different deployment model could for example define much smaller and easier to use deployment plans. Additional deployment models could focus on single node deployment capabilities which lead to much more flexibility than the D&C based deployment models. 7.4 Various Comments and Ideas The COPI part of QoS4CCM is dependent on the CORBA built in support of CCM. We shouldn’t try to support that. What about the QoS Enablers part of QoS4CCM? We can see some use cases for that.
  18. 18. 12 mars/2014-05-01
  19. 19. mars/2014-05-01 11 8 IDL Platform Specific Model This chapter describes the IDL PSM for UCM. The IDL within this chapter can be translated to a specific programming language using the already existing standardized IDL Language Mappings. As reference for the IDL specification this submission refers to IDL4 [IDL4]. From IDL4 the UCM IDL PSM uses the following building blocks: • Core Data Types • Interfaces - Basic • Components - Basic • Components CCM - Specific • Extended Ports and Connectors • Template Modules • Extended Data-Types • Annotations 8.1 Introduction In the context of UCM all IDL interfaces are local interfaces. 8.1.1 Differences With LwCCM The UCM IDL PSM is similar in some areas to LwCCM but there are several key differences: • Interfaces are implied local • No usage of the IDL keyword ‘supports’ and its implied CORBA dependency • Component and home attributes are local • No mandatory dependency on CORBA • No ability to retrieve the CORBA side of a component through the component context • Interfaces derive directly or indirectly from UCM::Object instead of CORBA::Object • No usage of valuetypes • Reduced functionality for homes 8.2 Core The UCM core IDL types are all defined in the ucm.idl IDL file.
  20. 20. 12 mars/2014-05-01 8.3 Container The UCM container is defined as follows in the ucm_container.idl IDL file. module UCM { interface Container { // Accessors to retrieve the various registries. If a container // doesn’t support a specific registry it can just return a nil // reference readonly attribute Registry the_service_registry; readonly attribute Registry the_component_registry; readonly attribute Registry the_connector_registry; readonly attribute Registry the_home_registry; // Initialize the container void initialize (); // Finalize a container, will let the container cleanup void fini (); }; }; 8.3.1 Registry The UCM container has to contain components, connectors, homes, and services. Each containment is referenced within an instance of the registry interface. The UCM registry is defined as follows in the ucm_registry.idl IDL file. module UCM { // Registry with containing UCM objects interface Registry { // Install an element void install (in string id, in Object reference) raises (Installation_Failure); // Uninstall an element Object uninstall (in string id); raises (Uninstallation_Failure); // Find an element Object resolve (in string id); }; }; 8.4 Component All UCM components are derived from UCM::Component in the IDL PSM. Each component has a context related to it and the context will provide access to all receptacles of the component. A UCM component shall be represented in IDL as a component with the same name. This component must inherit from UCM::Component which is defined as follows in the ucm_component.idl IDL file. module UCM { interface Component { // All lifecycle callbacks void on_configured ();
  21. 21. mars/2014-05-01 13 void on_activate (); void on_passivate (); void on_remove (); // Operation to set the component context onto the component void set_context (in Context context); }; }; 8.4.1 Port All UCM component ports are defined per IDL GIS templated module, connector and extended port concepts using the IDL "port" keyword. No additional IDL syntax extensions or changes are required. An extended "port" is defined by selecting the name of the port defining the desired interaction pattern from within an IDL templated module instantiation of the desired interaction pattern. 8.4.2 Locator A locator will be registered with a container for each component. It provides access to the component, context, and configurator. The locator is defined as follows in the ucm_locator.idl IDL file. module UCM { // An instance of the Locator is registered with the container so that the infrastructure has a // standardized way to find the component, context, and configurator interface Locator { readonly attribute Component the_component; readonly attribute Context the_context; readonly attribute Configurator the_configurator; }; 8.4.3 Configurator For each component a configurator is generated which provides the functionality to use a set of configuration values and set them onto the component executor. At the moment a component doesn’t have any configuration values it can use a nil reference for the configurator. The configurator is defined as follows in the ucm_configurator.idl IDL file. module UCM { // Make sure the concrete type of the value is a typedef typedef Any ConfigValueType; struct ConfigValue { string name; ConfigValueType value; }; typedef sequence<ConfigValue> ConfigValues; typedef sequence<string> NameList; exception ConfigurationError { // List of attribute names which we were unable to set NameList name_list; }; interface Configurator { // Set the configuration on the component. Tries to set all values onto the component and in case some // fail, gathers the names of the ones that did fail and raises them. In case there are then multiple attributes // incorrect they are all listed preventing a trial/error to just fix one each time void set_configuration (in Object object, in ConfigValues descr)
  22. 22. 14 mars/2014-05-01 raises (ConfigurationError); }; }; 8.4.4 Context The generic part of the UCM Context is defined as follows in the ucm_context.idl in the IDL file. module UCM { typedef sequence<Object> ObjectSeq; interface Context { readonly attribute Registry the_service_registry; void connect (in FeatureName name , in Object connection, in string conn_name) raises (InvalidName, InvalidConnection, AlreadyConnected); Object disconnect (in FeatureName name, in string conn_name) raises (InvalidName, InvalidConnection, NoConnection); ObjectSeq get_receptacle (in FeatureName receptacle_name); }; For each component a specific component context is generated in the same module as the component. This context derives from UCM::Context and for each receptacle of the component a separate operation is added. module Foo { interface FooContext : Context { Object get_... () }; }; 8.5 Home A UCM Home is defined using the IDL home syntax. For example a home for a component Foo is defined as follows. module MyModule { home FooHome manages Foo { }; // Implied IDL interface FooHomeExecutor { Foo create () }; }; The home can contain attributes which can be set by a deployment tool. A home has the ability to define and use attributes. 8.6 Container services With the minimalistic container the way to extend its functionality is to provide container services. The UCM standard defines some optional container services which could be delivered by a UCM implementation.
  23. 23. mars/2014-05-01 15 8.6.1 Timer Container Service The timer container service provides the ability to schedule, cancel, and react to time based triggers. The timer service is defined as follows in the ucm_timer_service.idl IDL file. module UCM { struct TimeT { long seconds; unsigned long nanosec; }; enum timeout_enum_t { ABSOLUTE_TIME, RELATIVE_TIME }; // Timeout can be relative or absolute, as denoted by the flag. struct timeout_t { // Time value for timeout TimeT time_val; // Timeout type timeout_enum_t flag; }; interface Timer_Callback { void on_timeout (in timeout_t time); }; interface Timer { void cancel (); boolean is_canceled (); }; interface Timer_Service { Timer start_scheduler_periodic ( in timeout_t delay_time, in timeout_t rate, in Timer_Callback cb, in Context ctx); Timer start_scheduler_sporadic ( in timeout_t time, in Timer_Callback cb, in Context ctx); }; }; 8.6.2 Messaging Container Services The messaging component container services provide a flexible queuing and dispatching system. Note – Before defining the concrete IDL for this service we first want to assess the input from the other UCM interested par- ties for their interest in such a service. Queue Service TBD
  24. 24. 16 mars/2014-05-01 Dispatcher Service TBD 8.7 Example Component Below is a notional user level IDL example definition of a UCM component. A number of assumptions have been made per this example, as delineated below. Most of these assumptions relate to UCM compliant generic request-reply (per AMI4CCM and DDS4CCM precedent) and pub-sub (per DDS4CCM precedent) interaction pattern connector specifications, which must be defined specifically for UCM in order to ensure that they are middleware agnostic. 1) Suggested normative names for standard UCM #include files and connector types (DDS and CORBA assumed initially). 2) Connector namespace and templated module names for compliant UCM connectors. 3) Notional syntax for instantiating a request-reply templated module to define a UCM request-reply connector type. This is subject to further review against AMI4CCM concepts, since something similar in concept with an IDL interface defined as a template parameter was initially rejected during the DDS4CCM spec development cycle. 4) Continued need for a user-defined sequence typedef for pub-sub messages, per the DDS4CCM specification. 5) Assume UCM only uses the IDL "port" keyword to define user-level component ports. Basic implicitly local "provides" and "uses" ports are to be used only within an IDL extended "porttype" definition, which are then used to define an IDL "mirrorport" on a UCM connector type, per the IDL specification. 6) Assume the basic DDS4CCM ConnectorStatusListener port is rolled into the fully encapsulated UCM pub-sub State and Event connectors, so that it will no longer have to be specified at the user component level as a basic "provides" port per the prior assumption. As such, it would only show up in a deployment model connection list, rather than as a user- defined component port artifact. 7) Assume existing DDS4CCM pub-sub connector types are made more generic for UCM, to get rid of DDS specifics like dds_entity ports and DDS prefixes on types and port names. 8) Assume rename of DDS4CCM pub-sub connector extended porttypes for UCM to remove "DDS_" prefixes, changed to "Write", "Update", "Listen", "StateListen", "Get", and "Read". Per these names, we also assume no State vs. Event connector rename of their shared Listen, Read and Get porttypes to remove ambiguity in IDL definitions, which would offer a compile time optimization if renamed to be unique for each. 9) Assumes UCM extended request-reply connectors offer four separate client and server side, synchronous and asynchronous extended porttypes to satisfy the required UCM interaction semantics, called "Provides", "ProvidesAsync", "Uses" and "UsesAsync". // Notional user level IDL PSM definition example for a UCM component #include <ucm.idl> // UCM Core types #include <ucm_request_reply.idl> // UCM request/reply interaction pattern definition #include <ucm_pub_sub_event.idl> // UCM pub/sub event interaction pattern definition #include <ucm_pub_sub_state.idl> // UCM pub/sub state interaction pattern definition module Example { typedef string StatusString; // Define a "Control Service" interface interface ControlService {
  25. 25. mars/2014-05-01 17 boolean setValue(in double dVal); void start(); void stop(); }; // Define a "Status Service" interface interface StatusService { void getStatus(out StatusString status); }; // Define a "Data Main" message type struct DataMainMsg { long mainValue; //@Key short otherValue; }; // Define a "Data Aux" message type struct DataAuxMsg { long auxValue; boolean isGood; }; // Define/instantiate a "Control Service" request/reply module module UCM::RequestReply<ControlService> myControlService; // Define/instantiate a "Status Service" request/reply module module UCM::RequestReply<StatusService> myStatusService; // Define/instantiate a "Data Main" pub/sub state module typedef sequence <DataMainMsg> DataMainMsgSeq; module UCM::PubSubState <DataMainMsg, DataMainMsgSeq> myDataMain; // Define/instantiate a "Data Aux" pub/sub event module typedef sequence <DataAuxMsg> DataAuxMsgSeq; module UCM::PubSubEvent <DataAuxMsg, DataAuxMsgSeq> myDataAux; // Define our example UCM component with 4 UCM (extended GIS) ports component myUcm_comp { port myControlService::Provides controlSvc; // sync service port example port myStatusService::UsesAsync status; // async client port example port myDataMain::StateListen dataMainSub; // state subscriber port example port myDataAux::Write dataAuxPub; // event publisher port example }; };
  26. 26. 18 mars/2014-05-01