Issue 5968: The submission only gives one choice for managing node resources
Issue 6039: page 91: In the sequence diagram
Issue 6269: Technical sections 2.3.3 and 2.3.4
Issue 6435: MonolithicImplementationDescription Attributes
Issue 6598: Deployment Behavior
Issue 6599: Domain Information
Issue 6603: 6.4.17 ComponentPortDescription (02)
Issue 6632: property name issue
Issue 7163: Subcomponents Package Inconsistency
Issue 7164: Misuse of XMI Proxy Links
Issue 7242: Missing definition for connection in chapter 5:
Issue 7278: Semantics of IDL generated from Deployment & Configuration Specification
Issue 7280: For ExternalReferneceEndpoint add provider boolean attribute
Issue 7281: For ExternalReferneceEndpoint add optional port name attribute
Issue 7284: ExternalReferneceEndpoint need to indicate the type of interface
Issue 7285: Suggestion is to break ComponentExternalPortEndpoint
Issue 7286: ComponentExternalPortEndpoint definition is not unique enough
Issue 7302: Add "replace" parameter to installPackage
Issue 5968: The submission only gives one choice for managing node resources (deployment-ftf)
Click here for this issue's archive.
Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com)
Nature: Uncategorized Issue
Severity:
Summary:
The submission only gives one choice for managing node resources, which is always done by the domain (target manager). There is no capability of allowing a node/device to manage its resources and its states, and to indicate which node resources can be managed at the domain and which ones at the node or device level. Recommendation is add the capability in the description elements to indicate if the resources are managed by the node/device or by the domain, and operations to the node/device to manage this capability
Resolution: Add the possibility to update properties of nodes dynamically.
3) page 91: In the sequence diagram, the time when is called the commitRessources operation on the TargetManager instance is not clear for me. It seems that the operation begins before the end of the DomainApplication's activity period (call to "startLaunch").
Resolution:
The diagram in question is Figure 7-6 ("Executor in action") on document page number 101, pdf page number 111, in the convenience document in august. There are two flaws in this diagram:
1) It should be clear that before DomainApplicationManager returns from startLaunch, it should perform the commitResources operation.
2) It should not be normative just where the resource commitments happen between the DomainApplicationManager and DomainManager. It should be clear that implementations can do it either way. Both these classes are part of the execution manager and thus an execution manager could be implemented either way.
2.3.3 ComponentPackageDescription 2.3.4 ComponentImplementationDescription There should be a constraint stated for the configproperties? What should they relate to?
Resolution: There are currently no (formal or english) constraints that match configuration properties (in the PackageConfiguration, ComponentPackageDescription, ComponentImplementationDescription and SubcomponentInstantiationDescription classes) to configurable properties as identified by the component interface. That's why constraints are added
6.4.14 MonolithicImplementationDescription This description should have additional well-defined optional attributes such as entry point name, stack size, and process priority. Keep these elements separate from execParameters. ExecParameters should be parameters that are passed to the main process or entry point and used by the entry point or main process implementation. These should be defined at the PIM level.
Resolution: The resolution for this issue defines a separate parameter list for the implementation code in addition to the execution parameter list. Whilst the execution parameter list is intended for the node's execution environment, the new parameter list is passed to the component implementation while bootstrapping the component's implementation code. However, it is still unclear which execution parameters associated with a MonolithicImplementationDescription are intended for the execution environment (node) and which are in fact intended for the component implementation itself. This requires all execution parameters to be made available to both, with a reduction in error checking since neither the execution environment (node, container) nor the implementation can know whether parameters it doesn't understand are relevant to it. Thus no errors can be discovered when parameter names are incorrect.
Commit and releaseResources based upon a deployment plan. This should be a separate interface. For systems or domains implementations that need this behavior a component could exist that provides this behavior. Not all systems need to formally create a deployment plan (XML) to do deployment.
See issue #6597 for disposition
Make the getAllResources and getAvailableResources a separate interface. For systems or domains implementations that need this behavior a component could exist that provides this behavior. Not all systems need to formally create a domain. Some systems provide this information based upon their components. The issue, if a domain is distributed that contains distributed components that manage this information how does the domain map to these elements?
See issue #6597 for disposition
The OLD CCM DTD and SCA had the concept of connection ID for a required port. This was useful when a required port allowed multiple connections to it with the same interface, so it could distinguish the connection being to it. Add the flexibility in the Port definition of optional stating connection ids for a required port and allow the component assembly definition for a port connection to optional state a connection id to be used. For a required port, instead of stating connection IDs, it could optionally state the maximum number of connections per interface type for a required port. When not stated it is assumed to be one.
During the meetings and telephone conferences of the previous FTF it has been agreed that this issue is to be closed without change. A new more specific issue with respect to connection endpoint's definition has been raised instead (7281).
The "name" attribute of the Property class must be a URN, so to be consistent we should rename the attribute global_name, and insist that it is a URN
Discussion: During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be closed without change since all properties are already scoped by requirements or resources. Disposition: Closed, no change
In 6.4.7, (SubcomponentInstantiationDescription), an assembly can point
to another package to provide an instance of a subcomponent, using the
"package" reference to ComponentPackageDescription.
The resolution to issue 6047 changed the main "work product", the
package,
to contain a PackageConfiguration as the toplevel item, rather than a
ComponentPackageDescription.
For consistency, I suggest that SubcomponentInstantiationDescription
reference PackageConfiguration, too.
Proposed resolution:
In 6.4.7.3 (associations for SubcomponentInstantiationDescription),
change
package: ComponentPackageDescription [0..1]
Describes a package that provides an implementation for this
subcomponent instance.
to
package: PackageConfiguration [0..1]
The package that provides an implementation for this
subcomponent instance.Introduce an explicit importing mechanism: add a new class to the Component Data Model called "ComponentPackageImport", and use it in the SubcomponentInstantiationDescription.
Section 9.5.8, "Transformation Exceptions and Extensions" in the
"PSM for CCM to PSM for CCM for XML Transformation" chapter, contains
the text:
If the link attribute of a ComponentPackageDescription proxy that
is part of a SubcomponentInstantiationDescription element does not
contain a fragment identifier, then the referenced file can be
either a Component Package Descriptor or a package (i.e. a ZIP
file with the ".cpk" extension containing the package).
This was added for better modularity, to allow a package to "import"
another package, maybe from some external location. On second thought,
considering the implementation impact, this does not seem like such
a good idea, because it overloads an XMI proxy object with a second
meaning: either do what XMI says, or import a package.
It is also self-contradictory with the preceding sentence, which gives
clear semantics to linking to an XML document without a fragment
identifier.
I suggest to replace this with an explicit importing mechanism: add a
new class to the Component Data Model called "ComponentPackageImport",
and use it in the SubcomponentInstantiationDescription. This resolution
clarifies how to reuse packages.
Proposed resolution:
Add a new class "ComponentPackageImport" to the Component Data Model.
6.4.x ComponentPackageImport
6.4.x.1 Description
Imports a package via an URL.
6.4.x.2 Attributes
location: String [1..*]
Alternative locations of the package that is to be imported.
6.4.x.3 Associations
None.
6.4.x.4 Semantics
A ComponentPackageImport can be used instead of a
PackageConfiguration
to import a package, rather than providing the package "inline."
In 6.4.7.1 (SubcomponentInstantiationDescription description), replace
the
second paragraph,
The SubcomponentInstantiationDescription links to a package that
provides
implementations for the sub-component that is to be instantiatiated.
There
is either a link to a ComponentPackageDescription in case a package
recursively contains packages for its sub-components, or there is a
link
to a ComponentPackageReference that contains the requiredType of a
component
interface. Users of the Component Data Model will have to contact a
Repository (possibly via a search path) in order to find a package
that
implements this interface.
with
The SubcomponentInstantiationDescription specifies a package to
instantiate
a subcomponent from, and configures this subcomponent instance. The
package
can be provided in one of three ways:
- The package can be provided inline, as part of the same package,
using a
PackageConfiguration.
- A package can be imported, using a ComponentPackageImport. The
imported
package may be part of the enveloping package, or it may be
referenced
from an external location. This allows reusing packages.
- A package can be referenced indirectly, using a
ComponentPackageReference.
Users of the Component Data Model will have to contact a
Repository
(possibly via a search path) in order to find an appropriate
package.
In 6.4.7.3 (SubcomponentInstantiationDescription associations), add
importedPackage: ComponentPackageImport [0..1]
Imports a package by reference.
In 6.4.7.4 (SubcomponentInstantiationDescription constraints), replace
There can be either a package or a reference, but not both.
with
A package to supply an implementation for this subcomponent is
either
included, imported, or referenced:
context SubcomponentInstantiationDescription inv:
Set{self.package, self.importedPackage, self.reference}->size() =
1
In 6.5.1.5 (RepositoryManager semantics), add
The installPackage and createPackage operations recursively resolve
all
imported packages: in all SubcomponentInstantiationDescription
elements,
ComponentPackageImport elements are replaced with
PackageConfiguration
elements, containing the data that was loaded from the imported
package.
PackageConfiguration elements returned from findConfigurationByName
or
findConfigurationByUUID do not contain ComponentPackageImport
elements.
In 9.5.8 (Transformation Exceptions and Extensions), delete the second
sentence of the last paragraph, which reads
If the link attribute of a ComponentPackageDescription proxy that
is part of a SubcomponentInstantiationDescription element does not
contain a fragment identifier, then the referenced file can be
either a Component Package Descriptor or a package (i.e. a ZIP
file with the ".cpk" extension containing the package).Replace the special rule mentioned above with an explicit importing mechanism by adding a new class to the Component Data Model called "ComponentPackageImport".
The resolution for issue #6026 added several definitions to chapter 5 ("Terms and Definitions"). The definitions 5.10, 5.13, and 5.23 refer directly or implicitely to the term "connection" (between components). However, this term is not defined in chapter 5 yet.
Proposed resolution:
Don't change current definitions but add an appropriate definition for connection.
Resolution: Add a section defining the term connection.
see the following definition in the IDL generated from the Target Data
Model using UML Profile for CORBA, and have some issues with semantics when
interpreting the following generated IDL mapping from the model:
struct SharedResource {
string name;
::CORBA::StringSeq resourceType;
::CORBA::ULongSeq nodeRef;
SatisfierProperties property;
};
typedef sequence < SharedResource > SharedResources;
struct Resource {
string name;
::CORBA::StringSeq resourceType;
SatisfierProperties property;
};
typedef sequence < Resource > Resources;
struct Node {
string name;
string label;
::CORBA::ULongSeq sharedResourceRef;
::CORBA::ULongSeq connectionRef;
Resources resource;
};
struct Domain {
string UUID;
string label;
SharedResources sharedResource;
Nodes node;
Interconnects interconnect;
Bridges bridge;
};
The idea of the above IDL is to represent the following semantics:
A Domain is composed of Nodes (among other things). A Domain can also
contain a list of the resources that are shared among the different nodes
in the domain. There is also an association between the Nodes of the domain
and the SharedResources in a domain. Basically, the nodes of the domain
contain a list of the resources that they share with other nodes, and the
each shared resource keep track of the nodes that share it.
Please refer to Fig 6-4 Target Data Model Overview, in the document:
http://www.omg.org/cgi-bin/doc?ptc/2004-03-10
Ideally one should be able to represent this in IDL like this:
struct Node;
typedef Sequence<Node> Nodes;
struct SharedResource {
string name;
::CORBA::StringSeq resourceType;
Nodes nodeRef;
SatisfierProperties property;
};
except that this is invalid IDL. The alternative mapping that is generated
doesn't seem to make sense. What should I fill in as values for the
::CORBA::ULongSeq in struct SharedResource? Why did it get mapped to an
CORBA::ULongSeq? Is it intended that these unsigned longs will refer to the
*gasp* pointers of the actual nodes in my parsed DOM tree with Domain as
root? If so, it will not work with 64-bit machines. How is one supposed to
refer a IDL struct member i.e, node inside a Domain using unsigned long?
The only identifier that is unique among all nodes in a Domain is it's
name. But unsigned long just doesn't make sense to me.
The above illegal IDL definition which directly includes Nodes after just
forward declaring node would work if Node was mapped to a valuetype. But I
don't know if that is a feasible solution.
Any clarifications on this would be really helpful.During the meetings and telephone conferences of the previous FTF it has been agreed that this issue is to be closed without change since it is due to misunderstanding. The values for the ::CORBA::ULongSeq in struct SharedResource is the index of the referenced element in its container, i.e., in the case, it's the index of the target Node in the Domain (i.e., the index into the Domain's "node" list). The magic here is explained in the second paragraph of section 9.4.1: To void redundancy and circular graphs, non-composite associations between classes with a common owner are expressed by an ordinal attribute at the source (navigating) end, with the name of the attribute being the role name plus the suffix "Ref," and the type "unsigned long." The value of this attribute is the index of the target element in its container, with the first element being 0 (zero). To enable the usage of an index, the composition of the target element in its container is wualified with the "ordered" constraint. Note that this rule also applies to a number of other associations, e.g., the "instance" reference in the SubcomponentPortEndpoint class. Disposition: Closed, no change
For ExternalReferneceEndpoint add provider boolean attribute to indicate the role of the ExternalReferenceEndpoint. Rationale for change is to allow for components to be connected to ExternalReferenceEndpoint or an ExternalReferenceEndpoint to be connected to an assembly component. An example is a SWRadio use case for an I/O device resident in the SWRadio, where the I/O Device has required and provider ports.
Resolution: External endpoints are the "global references" within an assembly that indicate an attachment to something outside the assembly, unrelated to the ports of the component being implemented by the assembly, and unrelated to any of the subcomponents within the assembly. Since an assembly is re-usable and implementation independent, such a global reference is inherently unmodular, much like an "extern" declaration buried inside a piece of C code. The purpose is to attach to something expected to somehow exist in every environment that the assembly implementation will execute in. Thus it is in some sense a "requirement" of the assembly implementation that such a reference be resolvable at execution time. An obvious example is "layered" deployment, where an initial layer will provide services to applications deployed "on top of" the lower "service layer" applications. Currently, external endpoints simply have a "location" attribute that allows connection to anything expressible in a URL. This includes predefined CORBA objects, name service queries, etc. (see section 13.6.10 of the CORBA 3.0 spec). Since CORBA object URLs are very extensible, restricting these endpoints in the PSM to be CORBA Object URLs as defined in 13.6.10 of CORBA provides a way to specify a wide variety of mechanisms to object the reference. Issue 7280 asks for a boolean to indicate whether the external entity being connected is a user or provider. Usually, the other endpoints of a connection imply what role is required for the ExternalEndpoint, but this is ambiguous in some cases. Thus, a boolean attribute is added as requested by this issue.
For ExternalReferneceEndpoint add optional port name attribute to indicate the port that is used to connect to or to retrieve an interface from the ExternalReferenceEndpoint. Rationale for change is to allow for components to be connected to ExternalReferenceEndpoint that are components. An example is a SWRadio use case for an I/O device resident in the SWRadio, where the I/O Device has required and provider ports.
Resolution: Issue 7281 asks for a port name attribute to indicate, when the external entity being connected is a component, which port of the component should be used. This is necessary to connect to identified external components and when the global reference is to a user rather than a provider. Together with the resolution of issue 7080, this resolution properly enables global references to specify the intention to reference a service provider or service user, and if the intention is to reference a component, which port of that component is being referenced.
SubcomponentPortEndpoint, ComponentExternalPortEndpoint, and ExternalReferneceEndpoint need to indicate the type of interface. Rational: UML 2.0 defines ports that can be associated with many required and provider interfaces
Resolution: The second part body of this issue describes a different problem than the title and the first sentence of this issue. Thus the RTF decided to split this issue into two parts: 1st part: The issue with the current issue number covering the title of this issue. 2nd part: A separate issue with number 7877 has been raised covering the second part of the issue's body reading "Rationale: UML 2.0 defines ports that can be associated with many required and provider interfaces." to be resolved separately by this new issue. Again, the following resolution covers only the 1st part of this issue as described above. For SubcomponentPortEndpoint, the type(s) are obtained by navigating to the ComponentInterfaceDescription. For ComponentExternalPortEndpoint, the type(s) are obtained by navigating to the ComponentInterfaceDescription. For ExternalReferenceEndpoint, the types are indeed missing, thus a "supportedType" attribute is added to the ExternalReferenceEndpoint class. This allows assembly tools to validate the type compatibility of connections that involve an external reference endpoint.
Suggestion is to break ComponentExternalPortEndpoint from AssemblyConnectionDescription as a separate definition for the assembly external port definitions
During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be closed without change. An assembly's external ports are well-defined by the component interface that the assembly-based component implementation is implementing. In the Component Data Model, the ComponentInterfaceDescription of the interface is available via the "implements" association of the ComponentImplementation- Description element that the ComponentAssemblyDescription is embedded in. Therefore, it is not necessary to reiterate the set of an assembly's external ports within the ComponentAssemblyDescription. Disposition: Closed, no change
ComponentExternalPortEndpoint definition is not unique enough. A component can have the same port name. This definition needs to be qualified by a component as done for SubcomponentPortEndpoint.
During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be closed without change. The ComponentExternalPortEndpoint element always identifies a port of the component interface that is implemented by this assembly-based component implementation. The port type is well-defined by the component interface; its Component- InterfaceDescription is available via the "implements" association of the ComponentImplementationDescription element that the ComponentAssembly- Description is embedded in. There is no conflict with names of subcomponent ports. The namespace for ports and properties of each subcomponent instance is distinct from the namespace for ports and properties of the assembly-based component implementation itself. Disposition: Closed, no change
The RepositoryManager has two operations to install packages in the
Repository: installPackage() and createPackage(). But while the latter
has a "replace" parameter, to decide whether an existing package (with
the same installationName) shall be replaced or not, the former doesn't.
I don't see why this difference should exist.
Proposed resolution:
In section 6.5.1.2 (RepositoryManager operations), add a third "replace"
parameter of boolean type to the installPackage operation. Thus, change
installPackage (installationName: String, location: String)
Installs a package in the repository, under the given installation
name. Raises the NameExists exception if a configuration by this
name already exists. Raises the PackageError exception if an
internal error is detected in the package.
to
installPackage (installationName: String, location: String, replace:
Boolean)
Installs a package in the repository, under the given installation
name. If the replace parameter is true, an existing
PackageConfiguration
with the same name is replaced. If the replace parameter is false,
and if
a package with the same name exists in the repository, the
NameExists
exception is raised. Raises the PackageError exception if an
internal
error is detected in the package.Resolution: Add a third "replace" parameter of boolean type to the installPackage operation.