Issues for Components 2006 Revision Task Force mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 6001: CCMHome should have a get_container method
Issue 6286: portability of CCM descriptors
Issue 6438: CCMHome should have a get_components method
Issue 6671: [Components] Contradiction between IDL and Interface Repository concerning
Issue 6672: EnterpriseComponent should have a get_servant method
Issue 6673: HomeExecutorBase should have a get_servant method
Issue 6684: The association of entity component primary key and PSS key is unclear
Issue 6688: EnterpriseComponent should have a get_servant method
Issue 6689: HomeExecutorBase should have a get_servant method
Issue 7556: Generic connectivity for Receptacles, Emitters, Publishers
Issue 7732: EnterpriseComponent should have a set_persistent_object method
Issue 7733: HomeExecutorBase should have a set_context method
Issue 9173: add some feature to let an assembly look like a monolithic compoment
Issue 9174: "supports" keyword
Issue 10142: Contradictory sections in the CCM and Lightweight CCM specifications
Issue 10582: The D&C IDL part doesn't match 06-04-02.
Issue 13151: add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;
Issue 14026: spec should define how the base class of an executor is generated by the framework
Issue 14061: The spec mentions InvalidConfiguration as exception but there is no idl in this spec
Issue 14064: typedef CCMObjectSeq
Issue 14087: Event mechanism proposal
Issue 15051: ResourceCommitmentManager lacking
Issue 15052: two not used and document exceptions listed
Issue 15053: DifferentProcess used 2 times
Issue 15164: HomeConfiguration::set_configuration_values should document exception
Issue 15960: Incorrect statement that implies that connect_consumer returns a cookie

Issue 6001: CCMHome should have a get_container method (components-rtf)

The CCMHome interface does not provide a mechanism for locating the container that created a home.  The lack of a method to get a home's container is inconsistent with the rest of the CCM model.  Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

Resolution:

Replace the following text in formal/02-06-05 on page 1-41

interface CCMHome {
    CORBA::IRObject get_component_def();
    CORBA::IRObject get_home_def ();
    void remove_component ( in CCMObject comp)
        raises (RemoveFailure);
};

with

interface CCMHome {
    CORBA::IRObject get_component_def();
    CORBA::IRObject get_home_def ();
    void remove_component ( in CCMObject comp)
        raises (RemoveFailure);
    Container get_container();
};

and add the operation description

get_container

The get_container operation returns a reference to the Container object that created this CCMHome

Identifier (FPI). 

These FPIs are required for the CAD, CSD, CCD and CPF DTDs. 

Proposed resolution: 

Adds the CCM DTDs on the OMG web site and adds the following text in the specification: 

* section 6.3, before subsection 6.3.1 : 

The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" /> 

* section 6.4, before subsection 6.4.1 : 

The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" /> 

* section 6.4.4: 

replace 

<!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd"> 

with 

<!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" /> 

* section 6.7, before subsection 6.7.1 : 

The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" /> 

* section 6.7.1: 

replace 

<!DOCTYPE componentassembly SYSTEM "componentassembly.dtd"> 

with 

<!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" /> 

* section 6.8, before subsection 6.8.1 : 

The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" /> 

The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed).  The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs).  Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.


Resolution:


Replace the following text in formal/02-06-05 on page 1-41


interface CCMHome {
    CORBA::IRObject get_component_def();
    CORBA::IRObject get_home_def ();
    void remove_component ( in CCMObject comp) raises (RemoveFailure);
};


with


typedef sequence<CCMObject> CCMObjects;


interface CCMHome {
    CORBA::IRObject get_component_def();
    CORBA::IRObject get_home_def ();
    void remove_component ( in CCMObject comp) raises (RemoveFailure);
    CCMObjects get_components();
};


and add the operation description


get_components


The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:



A facet is declared with the following syntax:
(120) <provides_dcl> ::= “provides” <interface_type> <identifier>
(121) <interface_type> ::= <scoped_name>
| “Object”
The interface type shall be either the keyword Object, or a scoped name that denotes
a previously-declared interface type which is not a component interface, ...



In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:



// write interface
ProvidesDef create_provides (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in InterfaceDef interface_type
);
UsesDef create_uses (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in InterfaceDef interface_type,
in boolean is_multiple
);



Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.


1) replace in ComponentDef:


// write interface
ProvidesDef create_provides (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in IDLType interface_type
);
UsesDef create_uses (
in RepositoryId id,
in Identifier name,
in VersionSpec version,
in IDLType interface_type,
in boolean is_multiple
);


2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with


interface ProvidesDef : Contained {
// read interface
readonly attribute IDLType interface_type;
};


struct ProvidesDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
IDLType interface_type;
};


interface UsesDef : Contained {
// read interface
readonly attribute IDLType interface_type;
readonly attribute boolean is_multiple;
};


struct UsesDescription {
Identifier name;
RepositoryId id;
RepositoryId defined_in;
VersionSpec version;
IDLType interface_type;
boolean is_multiple;
};

The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now. 

Resolution: 

Replace the following text in formal/02-06-05 on page 3-39 

module Components { local interface EnterpriseComponent {}; }; 

with 

module Components { local interface EnterpriseComponent { Servant get_servant() raises (CCMException); }; }; 

and add the operation description 

get_servant 

The get_servant operation returns a reference to the servant.

The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now. 

Resolution: 

Replace the following text in formal/02-06-05 on page 3-40 

module Components { local interface HomeExecutorBase {}; }; 

with 

module Components { local interface HomeExecutorBase { Servant get_servant() raises (CCMException); }; }; 

and add the operation description 

get_servant 

The get_servant operation returns a reference to the servant.

Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

When creating component or facet reference of service or session
component, the first step is creating the object reference and
associating its PortableServer::ObjectId with servant. Currently, the
container manages executor, but the EnterpriseComponent interface does
not provide a mechanism to get servant. The method would be very useful
as it means the container can use executor to get servant, which is not
possible now.


Resolution:


Replace the following text in formal/02-06-05 on page 3-39


module Components {
 local interface EnterpriseComponent {};
};


with


module Components {
 local interface EnterpriseComponent {
  Servant get_servant()
   raises (CCMException);
 };
};


and add the operation description


get_servant


The get_servant operation returns a reference to the servant.

This question is similar to the first one. When creating component or
facet reference of service or session component, the first step is
creating the object reference and associating its
PortableServer::ObjectId with servant. Currently, the container manages
executor, but the HomeExecutorBase interface does not provide a
mechanism to get servant. The method would be very useful as it means
the container can use executor to get servant, which is not possible now.


Resolution:


Replace the following text in formal/02-06-05 on page 3-40


module Components {
 local interface HomeExecutorBase {};
};


with


module Components {
 local interface HomeExecutorBase {
  Servant get_servant()
   raises (CCMException);
 };
};


and add the operation description


get_servant


The get_servant operation returns a reference to the servant.

The CCMObject interface contains numerous operations for generic
connection management (in addition to the type-specific operations
defined by equivalent IDL for a component).


However, there's a separate set of "connect" and "disconnect"
operations for each kind of port, i.e., receptacles, emitters and
publishers. This is inconvenient for generic software that treats
ports generically, such as the deployment infrastructure in an
implementation of the Deployment and Configuration specification.


The set of operations might even get larger in the future, when
Streams for CCM becomes available.


I thus propose to add generic "connect_feature" and "disconnect_
feature" operations that is able to interconnect compatible ports
regardless of the type of port.


Proposed resolution:


In section 1.11.1, "CCMObject Interface," add the following two
operations to the CCMObject interface:


module Components {
  interface CCMObject : Navigation, Receptacles, Events {
    Cookie connect_feature (in FeatureName name,
                            in Object connection)
      raises (InvalidName, InvalidConnection, AlreadyConnected,
              ExceededConnectionLimit);
    void disconnect_feature (in FeatureName name,
                             in Cookie ck)
      raises (InvalidName, InvalidConnection, CookieRequired,
              NoConnection);
    /* other operations as before */
  };
};


Add the following explanation to the same section:


  connect_feature


  The connect_feature operation connects the object reference
  specified by the connection parameter to the component feature
  specified by the name parameter. The feature must be either a
  receptacle, emitter or publisher port.


  If the feature identified by the name parameter is a receptacle
  port, the connect_feature operation acts equivalent to calling
  the connect operation on the Receptacles interface. 


  If the feature identified by the name parameter is an emitter
  port, the connect_feature operation acts equivalent to calling
  the connect_consumer operation on the Events interface. A nil
  "cookie" value is returned.


  If the feature identified by the name parameter is a publisher
  port, the connect_feature operation acts equivalent to calling
  the subscribe operation on the Events interface.


  If the feature identified by the name parameter is neither
  receptacle, emitter or publisher port, or if the component does
  not have any feature by that name, the InvalidName exception is
  raised.



  disconnect_feature


  The disconnect_feature operation dissolves the connection
  identified by the ck cookie to the component feature specified
  by the name parameter.


  If the feature identified by the name parameter is a receptacle
  port, the disconnect_feature operation acts equivalent to calling
  the disconnect operation on the Receptacles interface. 


  If the feature identified by the name parameter is an emitter
  port, the disconnect_feature operation raises the InvalidConnection
  exception if a non-nil cookie is passed as the ck parameter;
  otherwise, it acts equivalent to calling the disconnect_consumer
  operation on the Events interface.


  If the feature identified by the name parameter is a publisher
  port, the disconnect_feature operation acts equivalent to calling
  the unsubscribe operation on the Events interface.


  If the feature identified by the name parameter is neither
  receptacle, emitter or publisher port, or if the component does
  not have any feature by that name, the InvalidName exception is
  raised.

There is no standard way for container to intercept component state management.
By which container can implement O/R mapping and management component states.
 
Resolution:
 
Container can intercept state management by provide a storage object for executor segment.
Replace the following text in formal/02-06-05 on page 3-39
 
module Components
{
 local interface EnterpriseComponent 
 {
        
 };
};
 
with
 
module Components
{
 local interface EnterpriseComponent 
 {
        void set_persistent_object(in StorageObjectBase);
 };
};
 
and add the operation description
 
set_persistent_object 
 
Set context object for executors

Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.
 
Resolution:
 
Replace the following text in formal/02-06-05 on page 3-40
 
module Components {
 local interface HomeExecutorBase {};
};
 
with
 
module Components {
 local interface HomeExecutorBase {  
  void set_context(in CCMContext con);
 };
};
 
and add the operation description
 
set_context
 
Set context object for home executor.

It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file. 

Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation

I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.


In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."


This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).


But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:


"For a component declaration with the following form:


  component <component_name> : <base_name>
  supports <interface_name_1>, <interface_name_2> { … };


the equivalent interface shall have the following form:
  interface <component_name>
  : <base_name>, <interface_name_1>, <interface_name_2> { … };"


The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.

The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02

We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;

The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor

The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members

In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject

The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code 

The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

The IDL file 07-02-01 related to CCM we have the following exceptions


  exception LastConfiguration {
  };


  exception InvalidReference {
  };


LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02

InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

DifferentProcess is used in LocalityKind and in PlanLocalitiyKind. This will result in illegal idl because both enums are in the deployment module. We propose to prefix all values in PlanLocalityKind with Plan

HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:


The cookie return value can be used to disconnect from the source.


I think that this sentence should be removed from the specification since connect_consumer is declared as follows:


void connect_consumer (
  in FeatureName emitter_name,
  in EventConsumerBase consumer)
    raises (InvalidName, AlreadyConnected, 
            InvalidConnection);

Also, disconnect_consumer doesn't provide a cookie as input parameter.