Remedy IT has published their initial submission for UCM Change of address: Melkrijder 11 3861 SG Nijkerk tel. +31 (0)88 053 0000

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
http://www.remedy.nl
Tel: +31-10-5220139
Primary contact: Johnny Willemsen (jwillemsen@remedy.nl)
OMG Document Number: mars/2014-05-01

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

5. 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://
www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/technology/agree-
ment.htm).

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

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

8. 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 http://www.omg.org/.
OMG Specifications
As noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications
are available from this URL:
http://www.omg.org/spec
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

9. 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: pubs@omg.org
Certain OMG specifications are also available as ISO standards. Please consult http://www.iso.org
Issues
The reader is encouraged to report any technical or editing issues/problems with this specification to http://www.omg.org/
report_issue.htm.

10. 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] https://www.dre.vanderbilt.edu/~schmidt/PDF/AMH2.pdf
• RPC over DDS [RPCDDS] http://www.omg.org/techprocess/meetings/schedule/RPC_over_DDS_RFP.html
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

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

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

13. 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
7.1.2.1 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.
7.1.2.2 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
7.1.2.3 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 7.1.6.2 encapsulate
execution models.
7.1.3 Component
7.1.3.1 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.

14. 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.
7.1.3.2 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?

15. 8 mars/2014-05-01
7.1.3.3 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.
7.1.3.4 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).
7.1.3.5 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-

16. 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.
7.1.6.1 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.
7.1.6.2 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

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

18. mars/2014-05-01 11
7.2.1.2 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.
7.2.2.1 DDS Based Publish/Subscribe
Note – The event and state interaction patterns can be defined by reusing the DDS4CCM specification [DDS4CCM].
7.2.2.2 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.

19. 12 mars/2014-05-01

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

21. 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 ();

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

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

24. 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.
8.6.2.1 Queue Service
TBD

25. 16 mars/2014-05-01
8.6.2.2 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 {

26. 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
};
};

27. 18 mars/2014-05-01