Issue 5953: Sequence metatype
Issue 5954: MOF requires Associations to be Named
Issue 5955: Misuse of ComponentPackageReference for Implementation Dependencies
Issue 5956: Dependency relationships are not a MOF construct
Issue 5957: Inconsistent use of label attribute in DeploymentPlan
Issue 5958: References to DataTypes not valid MOF
Issue 5959: XMI should be used for schema generation
Issue 5960: Missing explanation for selectRequirement in SubcomponentInstantiationDescr
Issue 5961: createPackage operation for RepositoryManager
Issue 5962: References chapter is empty
Issue 5963: Use optional attributes for optional values
Issue 5964: No Traceability if optional labels are blank
Issue 5965: Should be able to create Applications dynamically
Issue 5966: The CCM XML is totally replaced with new Schema XML
Issue 5967: .Package, Component, Component Implementation Description elements, etc
Issue 5968: The submission only gives one choice for managing node resources
Issue 5969: The install and uninstall operations should be decoupled
Issue 5983: Naming of subpackages
Issue 5984: Typo in OCL for Capability
Issue 5985: PIM or PSM for CCM
Issue 5986: Move shared classes to common
Issue 5993: Base64 encoding
Issue 6024: Any mapping in XML is too verbose
Issue 6025: Scope chapter is empty
Issue 6026: Terms and Definitions chapter is empty
Issue 6027: Submission allows multiple objects with identical names (unique identifiers
Issue 6037: page 16 : in the Table 1
Issue 6038: targetManager association
Issue 6039: page 91: In the sequence diagram
Issue 6040: Capability class
Issue 6041: typo page 98
Issue 6042: 6) typo page 89
Issue 6043: page 99: the deployRequirement association
Issue 6044: typo page 127
Issue 6045: page 131: Inconsistency
Issue 6046: typo page 131
Issue 6047: Need global unique identifier scheme compliant with MOF 2.0 standard
Issue 6048: There is no ObjectSeq type in orb.idl
Issue 6051: Index base clarification
Issue 6052: Any string content clarification
Issue 6053: Alternative Locations
Issue 6265: Editorial - Consistency
Issue 6266: 2. Editorial - Consistency
Issue 6267: 3. Technical - Interconnect
Issue 6268: Editorial - Renaming Suggestion
Issue 6269: Technical sections 2.3.3 and 2.3.4
Issue 6270: Rockwell Collins listed as submitter
Issue 6382: Troublesome paragraph issue
Issue 6383: Deployment issue: editorial clarification in para 3 in 9.5.8
Issue 6384: Persistence confusion in deployment spec
Issue 6385: No need for MIME reference
Issue 6386: Inconsistent naming of ValueType and EnumType attributes
Issue 6387: DataValue typo
Issue 6388: Dangling references to "label" attribute
Issue 6392: 6.4.14 MonolithicImplementationDescription
Issue 6435: MonolithicImplementationDescription Attributes
Issue 6436: MonolithicImplementationDescription Execute Parameters PSM
Issue 6597: replace the update operation
Issue 6598: Deployment Behavior
Issue 6599: Domain Information
Issue 6602: 6.4.17 ComponentPortDescription (01)
Issue 6603: 6.4.17 ComponentPortDescription (02)
Issue 6604: 6.4.17 ComponentPortDescription (03)
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 7279: ExternalReferneceEndpoint
Issue 7280: For ExternalReferneceEndpoint add provider boolean attribute
Issue 7281: For ExternalReferneceEndpoint add optional port name attribute
Issue 7282: Constraint Definition
Issue 7283: ExternalReferneceEndpoint, SubcomponentPortEndpoint, ..
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 5953: Sequence metatype (deployment-ftf)
Click here for this issue's archive.
Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:
This is an issue for the Deployment FTF:
The sequence metatype is not required in MOF. Parameter and
attribute multiplicities should be used instead.
Proposed resolution:
In section 3.3, "Model Diagram Conventions", delete paragraphs 9
("This specification is aligned with MOF 1.4 ...") and 10 ("Note-
Instances of the Sequence metaclass ...") and the diagram preceding
paragraph 9.
Add paragraph:
"This specification uses the notation of placing the multiplicity
in square brackets after the type, as in "label: String [1]". If
the multiplicity is omitted from an attribute, parameter or return
value, the default of one to one is used."
Throughout the document, replace all occurences of the Sequence
type with the new notation.
In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation",
in the Generic Transformation Rules subsection, rewrite paragraphs
3 ("Wherever the multiplicity at the navigable end of a navigable
association ...") and 4 ("A similar rule is applied for all uses of
the Sequence data type ...") to read:
Wherever the multiplicity of an attribute, parameter or return
value is not exactly one (but 0..1, 1..* or *), a new class is
introduced to represent a sequence of the type of the attribute,
parameter or return value. The sequence class has the <<CORBA-
Sequence>> stereotype, and its name is the english plural of
the name of the type. The sequence class has a composition
association with the element class that is navigable from the
sequence to the element. The composition is qualified with the
index of the sequence. The attribute, parameter or return value
is then replaced with an attribute, parameter or return value,
respectively, with the same name as before, but with the type
being the newly introduced sequence class and the exactly one
(1..1) multiplicity.
A similar rule is applied to all navigable association or
composition ends whose multiplicity is not exactly one (but
0..1, 1..* or *): a new class is introduced to represent a
sequence of the class at the navigable end, this sequence
class is defined as described above. The original association
or composition end is then replaced with a navigable association
or composition end, with the same role name as before, at the
new sequence class, with a multiplicity of exactly one (1..1).
According to the rules in the UML Profile for CORBA, these
associations and compositions will then map to a structure
member in IDL, its type being a named sequence of the
referenced type.
Excepted from the two rules above are attributes, parameters,
return values or navigable association or composition ends
where the type is String, unsigned long or Endpoint, Instead
of defining new sequence types, the existing types in the
CORBA package are being used; see below.
In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation",
in the Special Transformation Rules subsection, rewrite the items
for "Sequence(String)", "Sequence(unsigned long)" and "Sequence(End-
point)" to talk about "Sequence of String", "Sequence of unsigned
long" and "Sequence of Endpoint", respectively.This is an editorial issue for the Deployment FTF:
MOF requires that all associations and association ends be
named. The model conventions section should mention default
names even if they are suppressed in the diagrams.
Proposed resolution:
In section 3.3, "Model Diagram Conventions", rewrite paragraphs
4 ("Role names on association ends ..."), 5 ("Role names at the
navigable end ..."), 6 ("If a role names is suppressed ...") and
7 ("If an association name is suppressed ...") to read
Role names on associations are made explicit wherever they are
expected to appear in generated code, e.g. as an interface's
attribute name.
Role names at the navigable end of a derived association are
normally suppressed. Therefore, if the role name at the navigable
end of an association is suppressed, the association is derived.
If a role name is suppressed at the end of an association, the
name of the type at the association end, starting with a lowercase
character, is used as the role name. This is the same implicit
rule as in OCL.
Implicit association names are used throughout the model. For
unidirectional associations, the name of the class at the source
plus an underscore plus the name of the navigable end is used as
the name of the association. For bidirectional associations, the
concatenation of the class names at both ends, in alphabetical
order, with an underscore inbetween, is used as the name of the
association.The ComponentImplementationDescription class references the
ComponentPackageReference class to express dependencies on
implementations that have to exist in the target environment.
Because of the different semantics, a new class should be
introduced instead.
Proposed resolution:
In section 3.10, "Common Elements", add an ImplementationDepen-
dency class as follows:
ImplementationDependency
Description
Expresses a dependency that an implementation has on the
target environment. Before this implementation can be
deployed, an application of the required type must exist
(it must have finished launching) in the target environment.
Attributes
- requiredType: String The interface type of which an
application must exist.
Associations
No associations.
Constraints
No constraints.
Semantics
When launching an application, the ExecutionManager and
DomainApplicationManager verify that applications of the
required type are already executing.
In section 3.4, "Component Data Model", in the Associations
section for the ComponentImplementationDescription class, update
the type of the dependsOn association to be ImplementationDepen-
dency:
- dependsOn: ImplementationDependency [*] Expresses a depen-
dency on another package; implementations of the referenced
interfaces must be deployed in the target environment before
this implementation can be deployed.
In section 3.8, "Execution Data Model", in the Associations
section for the DeploymentPlan class, update the type of the
dependsOn association to be ImplementationDependency.This is a new editorial issue for the Deployment FTF: The ImplementationArtifactDescription class makes use of a dependency relationship (to ImplementationArtifact), which is not a MOF construct. The dependency should be removed from the core model and moved to a non-normative package instead. Also, as a meta-concept, ImplementationArtifact should not be part of the ComponentDataModel. Proposed resolution: In section 3.4, "Component Data Model", in the description of the ImplementationArtifactDescription, remove the <<describes>> depen- dency to ImplementationArtifact from the diagram. Remove the ImplementationArtifact class. In section 3.12, "Relations to Other Standards", add Implemen- tationArtifactDescription to the diagram, and show its dependency on ImplementationArtifact. Paste the description and semantics for ImplementationArtifact from the text that was cut from section 3.4. At the beginning of section 3.12, add the explanation This section relates some classes in this platform independent model to classes from other packages. This section is explanatory and non-normative.
Elements of the DeploymentPlan use the "label" attribute and
describe it as a unique identifier, which is inconsistent with
the description of the label attribute in the modeling
conventions.
Proposed resolution:
Elements of the DeploymentPlan do not need a "human readable
label". They should have "name" and "source" attributes. The
Planner can generate unique names for all elements, and use
the "source" attribute to provide traceability, by filling it
with location data for the source element in the Component
Data Model. In an error condition, the exception can indicate
the name of the faulty item in the Deployment Plan, a user can
then locate this element by name, read the source attribute,
and thus trace the error to the original element.
In section 3.8, "Execution Data Model", in the Attributes
section for the ArtifactDeploymentDescription class, delete
the "label" attribute, and add "name" and "source" attributes:
- name: String A unique identifier for this element of
the DeploymentPlan
- source: String [*] Identifies the ImplementationArtifact-
Description elements that caused this
artifact to be part of the deployment.
Replace the third paragraph of the Semantics section ("A Planner
can generate a human readable label ...") with
A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and Implementation-
ArtifactDescription elements, describing a "path" of the
artifact's origins in the Component Data Model. The source
attribute may have more than one element, since Artifact-
DeploymentDescription elements may be shared among instance
deployments, if the same implementation artifact is part of
multiple component implementations. In case of an error, a
user can use this information to track the problem and
identify its source.
A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.
In the Attributes section for the MonolithicDeploymentDescrip-
tion class, delete the "label" attribute, and add "name" and
"source" attributes:
- name: String A unique identifier for this element of
the DeploymentPlan
- source: String [*] Identifies the MonolithicImplementation-
Description elements that caused this
component to be part of the deployment.
Replace the second paragraph of the Semantics section ("A
Planner can generate a human readable label ...") with
A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and MonolithicImple-
mentationDescription elements, describing a "path" of the
component implementation's origins in the Component Data
Model. The source attribute may have more than one element,
since MonolithicDeploymentDescription elements may be shared
among instance deployments, if the same component implementation
artifact is deployed more than once. In case of an error, a
user can use this information to track the problem and
identify its source.
A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.
In the Attributes section for the InstanceDeploymentDescrip-
tion class, delete the "label" attribute, and add "name" and
"source" attributes:
- name: String A unique identifier for this element of
the DeploymentPlan
- source: String Identifies the MonolithicImplementation-
Description elements that caused this
component to be part of the deployment.
Replace the first paragraph of the Semantics section ("A Planner
can generate a human readable label ...") with
A Planner may compose a human readable value for the source
attribute by combining the label attributes of packages,
implementations, assembly subcomponents and MonolithicImple-
mentationDescription elements, describing a "path" of the
component implementation's origins in the Component Data
Model. In case of an error, a user can use this information
to track the problem and identify its source.
A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.
In the Attributes section for the PlanConnectionDescription
class, delete the "label" attribute, and add "name" and "source"
attributes:
- name: String A unique identifier for this element of
the DeploymentPlan
- source: String [*] The labels of all AssemblyConnection De-
scription elements that were combined into
this PlanConnectionDescription.
Add to the Semantics section:
A Planner may compose a human readable value for the source
attribute by combining the label attributes of package imple-
mentations, assembly subcomponents and AssemblyConnectionDe-
scription elements, describing a "path" of the connection's
origins in the Component Data Model. The source attribute may
have more than one element, since a connection in the "flatte-
ned" plan might be a combination of multiple connection segments
on different levels of the assembly hierarchy. In case of an
error, a user can use this information to track the problem
and identify its source.
A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.
In the Attributes section for the PlanPropertyMapping class,
delete the "label" attribute, and add "name" and "source"
attributes:
- name: String A unique identifier for this element of
the DeploymentPlan
- source: String [*] The labels of all AssemblyConnection De-
scription elements that were combined into
this PlanConnectionDescription.
Add to the Semantics section:
A Planner may compose a human readable value for the source
attribute by combining the label attributes of package imple-
mentations, assembly subcomponents and AssemblyPropertyMapping
elements, describing a "path" of the mapping's origins in the
Component Data Model. The source attribute may have more than
one element, since a mapping in the "flattened" plan might be
a combination of multiple mapping "segments" on different
levels of the assembly hierarchy. In case of an error, a user
can use this information to track the problem and identify its
source.
A Planner must generate a name that is unique among the top-
level elements in a DeploymentPlan.
In section 3.11, "Exceptions", rename the "label" attribute to
"name" in the ResourceNotAvailable, PlanError, StartError and
StopError exceptions.
For consistency, also make a similar change in the PackageError
exception: delete the "label" attribute, and add a "source"
attribute:
- source: String Identifies a location in the package
where the error occured.
Change the Semantics section to read:
The implementation of the RepositoryManager interface should
compose a human readable value for the source attribute from
the label attributes of elements in the hierarchy defined by
the PackageConfiguration, ComponentPackageDescription, Compo-
nentImplementationDescription, SubcomponentInstantiationDe-
scription, AssemblyConnectionDescription, AssemblyProperty-
Mapping and ImplementationArtifactDescription elements so
that a user can locate the problem as precisely as possible.This is a new editorial issue for the Deployment FTF: The SatisfierProperty class contains a reference to a DataType (SatisfierPropertyKind), which is not legal MOF. "kind" should be listed as an attribute. Proposed resolution: In section 3.10, "Common Elements", for the SatisfierProperty class, move "kind" from Associations to Attributes. While at it, also correct the typo that shows kind to have zero to many multi- plicity. The correct multiplicity is exactly one, as shown in the diagram. In section 6.3, "PIM to PIM for CCM Transformation", update the diagram for ComponentInterfaceDescription to show "kind" as an attribute, removing the association to CCMComponentPortKind. In the same section, update the diagram for PlanSubcomponentPort- Endpoint to show "kind" as an attribute, also removing the asso- ciation to CCMComponentPortKind
This is a new issue for the Deployment FTF:
Instead of introducing a new set of rules, the existing rules
for XMI 2.0 Schema Production should be used.
Proposed resolution:
In section 6.1, "Introduction", change the last paragraph to read,
The M1 mapping is realized using the UML Profile for CORBA, the
M2 mapping is realized using the XML Metadata Interchange (XMI)
Version 2 specification, chaper 2, "XML Schema Production."
In section 6.5, "PIM for CCM to PSM for CCM for XML Transformation",
change the first paragraph to read
This section defines transformation T3 (as described in the
introduction). It transforms the PIM for CCM into a PSM for CCM
for XML that can be used to generate a concrete XML schema using
the mapping rules described in chapter 2, "XML Schema Production"
of the XML Metadata Interchange (XMI) Version 2 specification.
Change the Generic Transformation Rules to read
Data model elements, annotated with the «Description» or
«enumeration» stereotype (or a stereotype that inherits from it),
are used to generate XML schema for persistent storage of metadata.
Management model elements, annotated with the «Manager» or
«Exception» stereotype, are not part of the PSM for CCM for XML,
they are mapped to IDL only.
All classes in the PSM for CCM for XML are annotated with the
"org.omg.xmi.contentType" tag set to the value "complex".
All attributes are annotated with the "org.omg.xmi.element"
tag set to "true".
All packages are annotated with the "org.omg.xmi.nsURI" tag
set to "http://www.omg.org/DnC" and the "org.omg.xmi.nsPrefix"
tag set to the value "DnC".
In the Special Transformation Rules section, in the description for
the Any type, delete the Note that reads "Investigate whether the Any
type that is part of XMI is sufficient."
In the Others subsection of the Special Transformation Rules, add the
following paragraph:
The location attribute of the ImplementationArtifactDescription
class and the idlFile attribute of the ComponentInterfaceDescription
class contain URIs pointing to a file. URIs that consist of a
relative path (using the rel_path branch in the URI BNF) are
interpreted relative to the directory that the current document
is in. URIs that consist of an absolute path (using the abs_path
branch in the URI BNF) are interpreted relative to the current
package.
Change the Transformation Exceptions and Extensions section to read
Metadata for a component package is usually spread out across several
XML files, which we call descriptors. Certain associations are expected
to be expressed by links within the same document, others are expected
to link across documents. XMI takes care of both patterns by way of
"proxies," which do not contain nested elements but a link attribute
(either "href" or "xlink:href") referencing the target element by URI.
A schema produced using the XMI rules for schema production allows
proxies to appear anywhere.
Composition associations in the model express that the class at the
composite end owns and contains the class at the part end. In an XML
file, the element that defines the class at the part end usually
directly contains the definition for the class at the composite
end. Since the default multiplicity on the near end of a composite
association is one to one, the contained item cannot be legally
contained in another element. It is possible to store it by itself
in a separate file, though.
For non-composite associations between classes with a common owner
(composite end of composition), the definition of the class at the
source end of the association must contain a proxy linking to the
element at the target end of the association. The definition of the
class at the source end cannot contain the definition of the element
at the target end, because it is owned by the common owner, and its
identity cannot be duplicated.
Non-composite associations between classes that do not have a common
owner are usually expressed by the element definining the class at
the source end containing a proxy that links to an external document.
Direct containment is possible but may result in duplicated data.
While tools can decide to either combine information into a single
XML document or to place information into arbitrary files, using XMI
proxies to link to that information, it is expected that some model
elements usually appear as the outermost document element of a
standalone XML file. These commonly used descriptors are assigned
descriptive terms and standard file extensions.
- A Component Package Descriptor contains a ComponentPackageDescription
document element; it has the ".cpd" file extension.
- A Component Implementation Descriptor contains a
ComponentImplementationDescription document element; it has the
".cid" file extension.
- An Implementation Artifact Descriptor contains an
ImplementationArtifactDescription document element; it has the
".iad" file extension.
- A Component Interface Descriptor contains a
ComponentInterfaceDescription document element; it has the
".ccd" (CORBA Component Descriptor) file extension.
- A Domain Descriptor contains a Domain document element; it has
the ".cdd" (Component Domain Descriptor) file extension.
- A Deployment Plan Descriptor contains a DeploymentPlan document
element; it has the ".cdp" (Component Deployment Plan) file
extension.
- A Toplevel Package Descriptor contains a
ToplevelPackageDescription document element; it has the
"package.pcd" file name.
- Package files use the ".cpk" extension.
Spreading information across files according to these patterns
allow better reuse, for example by extracting an implementation
from a package.
Proxies follow the linking semantics specified by XMI. If a URI
reference does not contain a fragment identifier (the "#id_value"
part), then the target of the reference is the outermost document
element of an descriptor file. 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).
If a proxy's URIs consists of a relative path (using the rel_path
branch in the URI BNF), then it is interpreted relative to the
directory that the current document is in. URIs that consist of
an absolute path (using the abs_path branch in the URI BNF) are
interpreted relative to the current package.
If a proxy's URI reference is a relative path, then the referenced
file is looked for in the same directory as the document that
contains the referencing element. If the URI reference is an absolute
path, then the referenced file is looked for in the same package as
the document that contains the referencing element.
For backward compatibility, if the target of a proxy link does not
exist, it will also be looked for under a top level "meta-inf"
directory.
Change the Mapping to XML section to read
After applying the transformations defined in this section, an XML
Schema is generated by applying the rules set forth in the XML
Metadata Interchange specifcation, chapter 2, "XML Schema Production."
Delete section 6.6, "Mapping Discussion."
Delete chapter 7, "Mapping to XML Schema."The diagram for the SubcomponentInstantiationDescription shows
a composition relationship to Requirement called selectRequirement
that is not mentioned in the class' Associations section.
Proposed resolution:
In section 3.4, "Component Data Model", in the description of the
SubcomponentInstantiationDescription class, add the following text
to the "Associations":
selectRequirement: Requirement [*]
Expresses selection requirements on the implementation that
will be chosen for the subcomponent. During planning, these
selection requirements are matched against implementation
capabilities in the ComponentImplementationDescription elements
that are part of the referenced packageThere is no way for a client to put a package into the reposi-
tory at runtime, without creating an XML-based, ZIP'd package.
It might be useful to have a createPackage (name, label, package,
baseURL) in the Repository Manager. This method would do less
than the installPackage methods. Relative URLs in the package
would be interpreted according to the baseURL.
Proposed resolution:
In section 3.5, "Component Management Model", add a createPackage
operation to the RepositoryManager interface:
createPackage (name: String, label: String,
package: ComponentPackageDescription,
baseLocation: String)
Installs a ComponentPackageDescription in the repository,
assigning the given name and label to the new Package-
Configuration. Relative locations in elements of the package
are interpreted according to the baseLocation. Raises the
PackageError exception if an internal error is detected
in the package.References to specific versions of MOF, UML, XMI, UML Profile to CORBA, URIs etc. should be mentioned. Proposed resolution: Add "normative" references to: - CORBA Components 3.0 - HTTP 1.1 (RFC 2616) - MIME (RFC 2045) - MOF 1.4 - UML 1.5 - UML Profile for CORBA - Uniform Resource Identifiers (RFC 2396) - Uniform Resource Names (RFC 2141) - XML Metadata Interchange 2.0 - Extensible Markup Language - XML Schema - ZIP File Format Add "non-normative" references to: - MOF 2.0 Core Proposal - UML 2.0 Infrastructure submission - UML 2.0 Superstructure submission - UML Profile for QoS submission Use these references throughout the document wherever appropriate.
Some attributes (like UUIDs and labels) are described as optional. In the model, optional attributes (multiplicity 0..1) should be used for them; this has the advantage that no empty elements are needed in XML documents; optional attributes could still be mapped to empty (but non-optional, i.e. non-sequence) strings in the PSM for CCM for IDL. Proposed resolution: Make all occurences of "label" and "UUID" attributes optional by changing "label: String" to "label: String [0..1]", likewise for UUID. The default value is set to "" (the empty string). In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", add a paragraph that reads For all attributes of type String with multiplicity 0..1, update the multiplicity to 1..1. If the value is missing in an XML re- presentation of the model, the empty string is used as the default value.
The Execution Data Model explains that the Planner may construct label attributes from the Component Data Model's label attributes. This is problematic, and does not provide traceability if the original label attributes are empty. An alternative is to name each subelement. This is easy e.g. in the ComponentAssemblyDes- cription, by changing the label attribute to name. For the implementations in a package, or for artifacts in a monolithic implementation, a qualified association could be used, were they available in MOF (they are not); new classes would have to be introduced, such as a NamedComponentImplementationDescription class that is contained by the ComponentPackageDescription, has a name attribute and a reference to the "real" ComponentImple- mentationDescription. Proposed resolution: In the elements of a ComponentAssemblyDescription (Subcomponent- instantiationDescription, AssemblyConnectionDescription, Assembly- PropertyMapping), change the "label" attribute to a "name" attri- bute, and clarify that the name must be unique among these ele- ments. Introduce a new class NamedComponentImplementationDescription with a 1..1 association to ComponentImplementationDescription. Edit ComponentPackageDescription by making its 1..* "implements" relationship point to the new class. Introduce a new class NamedImplementationArtifactDescription with a 1..1 association to ImplementationArtifactDescription. Edit MonolithicImplementationDescription by making its 1..* "primaryArtifact" relationship point to the new class. Edit ImplementationArtifactDescription by making its 0..* "dependsOn" relationship point to the new class. Throughout the ExecutionDataModel, clarify that these names are used (instead of labels) to generate a human readable path that identifies the source element.
Should be able to create Applications dynamically solely based upon the Component Package Description. Submission was to address both static and dynamic deployment. Only static being addressed in specification based upon existing deployment plan. A system can determine how to deploy the component based upon the component's deployment requirements and domain target environment capabilities. Recommendation is to add an Application Factory concept that is associated with a Component Package Description that can create an application that determines the deployment plan dynamically. The Application that gets created is the same Application type created from a Domain Application Factory. This deployment behavior was in the previous CCM specification and in the current SCA. The appropriate name for this should be Domain Application Factory but this is name already in use the specification. I suggest renaming Domain Application Factory to a different name since it is based upon a specific deployment plan, so this name can be used for above behavior. The above Application Factory concept could be used to support any deployment plan since it has to obey the component package description
2.The CCM XML is totally replaced with new Schema XML. Companies have invested a great about of money in implementing the existing CCM XML. So I don't think the XML should be totally replaced. I think the XML should have been extended where changes need to be made to address Deployment & Configuration needs. There should be two PSMs, one for DTDs XML and one for Schema XML both derived from the same PIM. This PIM should have been based from the CCM XML and extended/modified where necessary. The JTRS SCA is based upon the CCM XML and the SCA made some D&C extensions. I am not expecting the SCA extensions to be adapted as standard within the OMG but the concepts. Some of these SCA concepts are in the D&C submission. Recommendation is add a XML DTD PSM definition and use similar names that were in the CCM XML DTD to reduce impact. Lets not reinvent the wheel unnecessary.
3.Package, Component, Component Implementation Description elements, etc. have no informational attributes such as description, author, title, version. Why were these attributes left out at the PIM level? Recommendation is to add these elements to PIM and PSM
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.
The install and uninstall operations should be decoupled from the XML parsing interface. There may be systems that don't offer this capability of a visible XML parser but still need the capability to install and uninstall
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. This is to split the interface in question into uninstallation/ installation and XML parsing features at PIM level. They may be mapped on a joint interface at PSM level. Since a concrete text proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF
There are two typos in the names of packages as mentioned in the Model Diagram Conventions: it should be Component and Exception (singular) instead of Components and Exceptions. Proposed resolution: In section 3.3, "Model Diagram Conventions," change the second sentence of the first paragraph from All classes are part of the Deployment and Configuration package, which contains the Components, Target, Execution, Common and Exceptions subpackages. to read All classes are part of the Deployment and Configuration package, which contains the Component, Target, Execution, Common and Exception subpackages.
It should read "context Capability", not "context Capacity".
In the PSM for CCM chapter, should the result of the T1 trans- formaion be called PIM for CCM or PSM for CCM? I believe there was a majority for "PSM" at the OMG meeting in Paris. Proposed resolution: Change all occurences of "PIM for CCM" to "PSM for CCM".
The ComponentExternalPortEndpoint and ExternalReferenceEndpoint classes are used by both the Component Data Model and Execution Data Model. They should therefore appear in the Common package. Proposed resolution: In section 3.4, "Component Data Model", cut the ComponentExternal- PointEndpoint and ExternalReferenceEndpoint classes. Paste them into section 3.10, "Common Elements."
in the last telecon, there was some concern about the MIME reference, which is used from the XML mapping, which explains, "For convenience, if the data type is a sequence or array of octet, the value is represented by a single SimpleValue element that holds, in the value attribute, the data in Base64 encoding." An alternative would be to add a new "BinaryValue" element to the DataValue element; the BinaryValue could then be declared to have the "base64Binary" type that is predefined by the XML Schema spec. The one argument in favor of that is that we could then depend on XML to define that element's contents (rather than referencing MIME separately).
The current mapping for the Any type in the PSM for CCM for XML
(section 9.5.4, page 117 in ptc/03-07-08) is very verbose, for
example an execution parameter property looks like
<execParameter>
<name>entrypoint</name>
<value>
<type>
<simple>
<type>string</type>
</simple>
</type>
<value>
<value>
<value>main</value>
</value>
</value>
</value>
</execParameter>
While not quite "broken," the mapping could be simplified - and
made less intimidating to those who prefer looking at XML code in
a text editor - by not separating the DataType from the DataValue,
but by combining them. An updated UML diagram for a better mapping
of the Any type is attached - it would eliminate the DataValue
type. By including an "Opaque" element of "base64Binary" type,
this mapping includes a potential resolution for 5993.
According to this updated mapping, the execution parameter above
would look like
<execParameter>
<name>entrypoint</name>
<value>
<simple>
<type>string</type>
<value>main</value>
</simple>
</value>
</execParameter>
Reformatting the submission to match the ISO format created an empty "Scope" chapter. We must fill it with some content. >From the template: "A paragraph or two. The Scope clause shall appear at the beginning of each specification and define, without ambiguity, the subject of the specification and the aspect(s) covered. It indicates the limits of applicability of the specification or particular parts of it. It shall not contain requirements. The scope shall be succinct so that it can be used as a summary for bibliographic purposes. It shall be worded as a series of statements of fact. Forms of expression such as «This specification defines [establishes] [gives guidelines for] [defines terms] [specifies] ...» shall be used. Statements of applicability of the standard shall be introduced by the wording «This specification is applicable to ...»."
Reformatting the submission to match the ISO format created an empty "Terms and Definitions" chapter. We must fill it with some content. >From the template: "For the purposes of this specification, the following terms and definitions apply /the terms and definitions given in [list of other documents] and the following apply. The Terms and definitions clause is an optional element giving definitions necessary for the understanding of certain terms used in the specification. The term and definition list is introduced by a standard wording (above), which shall be modified as appropriate." This chapter should probably define concepts like Component, Component Package, Assembly, Repository, Domain, ...
Subject: Submission allows multiple objects with identical names (unique identifiers, UUID, URI). Problem: This creates an enormous potential risk for object identification errors, by allowing duplicate identities to exist. Risks include problems reclaiming resources, naming service references, etc. Some examples of this area of concern are provided below, there might be other instances that have not been identified in this list. MOF 2.0 document states 8.3. Classifier requirements for instantiation Names must be unique within Class, Package, and Operation Examples: 6.4.3.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the package; packages with the same non-empty UUID must be identical. 6.4.4.4 Constraints If the UUID attribute is not the empty string, then it must contain a unique identifier for the implementation; implementations with the same non-empty UUID must be identical. 6.4.15.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the artifact; artifacts with the same non-empty UUID must be identical. 6.4.17.4 Constraints If the UUID field is non-empty, then it must contain a unique identifier for the interface; interfaces with the same non-empty UUID must be identical. Proposed Resolution: Correct requirements to disallow any use of duplicate (identical) identifiers in all defined name spaces.
1) page 16 : in the Table 1 (D& C Model Segmentation Summary), the crossing between "Execution Model" and "Management Model" should be " Execution Management Model " instead of " Target Execution Model
2) page 65 : according to the UML diagram, the targetManager association described in the ApplicationManager class should only be described in the DomainApplicationManager class .
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.
4) page 96: Is it intentional that Capability class is not present in the figures describing the profile? I have the same question with the Requirement class.
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. Since a concrete text proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
) typo page 98: "A ComponentImplementation is an abstract class that contains the defines the attributes and association..."
6) typo page 89: The attribute of the ComponentImplementation class is written capacityt
7) page 99: the deployRequirement association described in the ComponentAssembly stereotype doesn't appear in the diagrams. It is certainly a consequence of the point 4).
Discussion: During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF
8) typo page 127: "Regular associations in the UML models (not aggreagations) ..."
page 131: Inconsistency: A sentence in the §3.4 page 7 is "The included IDL is normative due to the lack of tools to perform the mapping automatically." and at page 131 an other one says, "This chapter contains IDL that has been produced from the PIM using these rules. It is non-normative, ...".
10) typo page 131: the 'reason' fields of the exceptions are all written 'reaon'.
Problem:
"UUID names" need to be defined as hierarchical in nature to create global uniqueness, while still supporting a simple local uniqueness. This should be accomplished using the URI approach defined by W3C as referenced in MOF 2.0. This approach provides an unambiguous solution that is scalable.
The following MOF 2.0 excerpt references the W3C URI uniqueness as a solution.
P1_01_MOF-Architecture.fm ad/2002-12-10 1-18
7. MOF 2.0 models the concept of identity. The lack of this capability in MOF, UML, CWM etc., made interoperability of metadata difficult to implement. The submitters understand that modeling identity is not easy, but we plan to show its usefulness in a simple domain - identity of metadata first. A key design goal is to make it easy to map this model of identity to W3C identity and referencing mechanisms such as the URI.
The following excerpt from the W3C URI spec introduces the concept of an absolute URI. Using this absolute URI as a tentative solution would resolve the current naming and uniqueness concerns. An objects globally unique name would consist of its local name space name prefixed with the names of all objects in its containment hierarchy.
Berners-Lee, et. al. Standards Track [Page 10]
RFC 2396 URI Generic Syntax August 1998
3. URI Syntactic Components
The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:
<scheme>:<scheme-specific-part>
An absolute URI contains the name of the scheme being used (<scheme>)
followed by a colon (":") and then a string (the <scheme-specific-
part>) whose interpretation depends on the scheme.
The URI syntax does not require that the scheme-specific-part have
any general structure or set of semantics which is common among all
URI. However, a subset of URI do share a common syntax for
representing hierarchical relationships within the namespace. This
"generic URI" syntax consists of a sequence of four main components:
<scheme>://<authority><path>?<query>
each of which, except <scheme>, may be absent from a particular URI.
For example, some URI schemes do not allow an <authority> component,
and others do not use a <query> component.
absoluteURI = scheme ":" ( hier_part | opaque_part )
URI that are hierarchical in nature use the slash "/" character for
separating hierarchical components. For some file systems, a "/"
character (used to denote the hierarchical structure of a URI) is the
delimiter used to construct a file name hierarchy, and thus the URI
path will look similar to a file pathname. This does NOT imply that
the resource is a file or that the URI maps to an actual filesystem
pathname.
hier_part = ( net_path | abs_path ) [ "?" query ]
net_path = "//" authority [ abs_path ]
abs_path = "/" path_segments
URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser.
opaque_part = uric_no_slash *uric
uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
"&" | "=" | "+" | "$" | ","
We use the term <path> to refer to both the <abs_path> and
<opaque_part> constructs, since they are mutually exclusive for any
given URI and can be parsed as a single component.
Proposed resolution:
Require the use of unique component identifiers, these identifiers cannot be optional, duplicate, or blank/empty. All objects requiring identity management, or providing containment must have unique identifiers constructed using URI format and character content guidelines.
NOTE: there could be both a "relative" local unique identifier, and a global unique identifier (absolute). All objects need the local unique, but not all objects need the absolute global identifier. This point requires further discussion.
Use all unique component identifiers involved in an individual components containment hierarchy to produce a globally unique identifier for it. The W3C URI specification provided above states that this approach using identifiers with separator characters can be used for resources that are not related to file systems. These identifiers are intended to be global identifiers, and not necessarily paths to objects. It could be assumed that a well defined name would provide object locator information if properly used.
The FTF team should feel free to define exactly this global identifier constructed using unique namespace identifiers and "separator characters". The scheme should be described, but left available for implementers to define.
On page 115, section 9.4.6 claims that there is an ObjectSeq
type defined in the CORBA module. That is not true. There are
lots of sequences of basic types, but no ObjectSeq.
Proposed resolution:
Delete section 9.4.6.
Using the generic transformation rules and the special rule
for the mapping of the Endpoint class, a Sequence(Endpoint)
will then map to an Endpoints sequence that contains Object
elements, ultimately resulting in the following IDL:
module Deployment {
typedef sequence<Object> Endpoints;
};The second paragraph of 9.4.1 (Generic Transformation Rules for the PIM for CCM to PSM for CCM for IDL Transformation) reads, in part, To avoid redundancy and circular graphs, non-composite associations between classes with a common owner are expressed by an ordinal attribute [...] The value of this attribute is the index of the target element in its container. It should be clarified that the index is zero-based. Proposed resolution: In section 9.4.1, second paragraph, amend the second sentence to read, The value of this attribute is the index of the target element in its container, with the index of the first element being 0 (zero).
According to section 9.5.6, "the SimpleValue element is used for primitive values, enum values and object references. Its value attribute contains a stringified representation of the primitive value." It goes on, "for char, wchar, string, wstring types, the value attribute holds an unquoted literal (i.e. no single or double quotes, and no leading L prefix) that conforms to the IDL syntax and semantics chapter." This was intended to allow inclusion of escaped characters such as \x0d. However, that is unnecessary, as XML is perfectly able to process Unicode and escape arbitrary (and markup) characters in itself, such as 
 Proposed resolution: Replace the 10th sentence of the first paragraph of section 9.5.6, For char, wchar, string, wstring types, the value attribute holds an unquoted literal (i.e. no single or double quotes, and no leading L prefix) that conforms to the IDL syntax and semantics chapter. to read For the char and wchar types, the value attribute holds a string of length 1.
It should be possible to supply alternative URI locations for
artifacts.
Here's another issue that I'd like to put on record before it
gets forgotten. It goes back to the discussion on HTTP. At the
moment, NodeManagers are essentially forced to use HTTP for
downloading artifacts from the Repository, since (a) that is
the "least common denominator" as defined by the specification
and (b) the Repository can offer only a single location.
The proposed solution enables the RepositoryManger to supply
multiple alternative locations for an artifact, one of which
must be a HTTP URI. Other locations could use more optimal
(including non-standard) transports that a NodeManager could
use if supported. (Otherwise, the NodeManager would fall back
to HTTP.)
Proposed resolution:
In section 6.3, "Model Diagram Conventions," change the text
for the standard "location" attribute from
location: references an entity outside of the model. The
location attribute is of type String, its value must comply
to the URI syntax.
to
location: references an entity outside of the model. The
location attribute is of type String, its value(s) must
comply to the URI syntax. Multiple alternative locations
to the same entity may be supplied (multiplicity 1..*);
applications can then choose any of these locations to
access the entity (e.g. choosing a local file URI over
a http reference).
In section 6.4.15.2 (ImplementationArtifactDescription
attributes), change the location attribute to
location: String [1..*] Alternative locations to the
ImplementationArtifact.
In section 6.8.2.2 (ArtifactDeploymentDescription attributes),
change the location attribute to
location: String [1..*] Alternative locations where the
artifact can be loaded from. Copied from Implementation-
ArtifactDescription.
In section 9.3.1 (ComponentInterfaceDescription), change the
idlFile attribute from
idlFile: String
to
idlFile: String [*]
and change the second sentence from
If it is not the empty string, it contains a URL that
references an IDL file that contains the definition for
this component or home.
to
The idlFile attribute, if present, contains alternative URIs
that reference an IDL file containing the component's (or
home's) interface definition.
In section 9.7.5, change the fourth (last) paragraph from
If a RepositoryManager supports URL schemes in addition to
http, it shall offer a configuration parameter that allows
user selection of the scheme(s) that will be used in
ImplementationArtifactDescription elements.
to
The RepositoryManager must supply a "http" URI as part of
the location attribute in the ImplementationArtifactDescription
element. A RepositoryManager may optionally include other
alternative locations to provide NodeManger implementations
with a choice of transports to use for downloading artifacts.Throughout the document not all roles are described in the text. For example section 2.5.3 interconnect
During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be solved. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
Throughout the document association names are not consistent. Some association names are verb phrases and some are noun phrased. Suggest being consistent by using noun phrases for association role names. This seems to be common practice in industry. Sections 2.3.3 and 2.3.4 are examples where verb phrases are being used.
During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be solved. Since a concrete proposal for resolution is not yet available, this issue is deferred to the next Deployment RTF.
The Interconnect between nodes is more than a reference to a node. Interconnections between nodes or devices usually entail specific node's ports that participate in the interconnection.
2.3.4 ComponentImplementationDescription Why do call a single implementation of one component monolithic? An assembly is more monolithic. A better name would be ComponentSingleImplementation
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
After Reviewing the official submission for this document, it was discovered that Rockwell Collins is still listed as a copywrite holder on this document. Rockwell Collins withdrew as submitter and should nolonger be listed.
While the problematic paragraph (para 3 in 9.5.8) in the solution to issue 5959 raised by Kevin could possibly be clarified by the proposed text below, the first 4 paragraphs of section 9.5.8 are not normative anyway, but simply elaborate certain flexibilities of the standard XMI MOF-to-XML-schema mapping. Thus while replacing the paragraph might help readers understand it, we might want to consider deleting all these paragraphs since there is no normative content. Any opinions about whether to use this (better?) paragraph or nuke all four of them?
Paragraph 2 of section 9.5.8 (of document ptc/03-10-01) is very confusing. While it is not normative, it is worth making clearer. (Original defect identified by Kevin Richardson). Existing paragraph: Composition associations in the model express that the class at the composite end owns and contains the class at the part end. In an XML file, the element that defines the class at the part end usually directly contains the definition for the class at the composite end. Since the default multiplicity on the near end of a composite association is one to one, the contained item cannot be legally contained in another element. It is possible to store it by itself in a separate file, though. Proposed improved paragraph: Composition associations in UML express that the class at the composite end (the containing class) owns and contains the class at the part end (the contained class). It is typical, in XML documents, for instances of contained classes to be embedded within the instance of the containing class. However, it is also possible to store contained instances by themselves in a separate file by using a proxy (using "href" or "xlink:href") to reference the contained instance in a separate file. Since the multiplicity on the composite end of a composite association is always one to one in this specification, contained instances can only have a single such proxy reference.
Paragraph 1 of 9.5.1 of document ptc/03-10-01 could be interpreted to mean that persistence was somehow required. Since this is not normative, the wording should be fixed to avoid such an implication; Old paragraph: Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate an XML schema for persistent storage of metadata. Proposed new paragraph: Data model elements, annotated with the «Description» or «enumeration» stereotype (or a stereotype that inherits from it), are used to generate an XML schema for representing metadata in XML documents for distribution, interchange or persistence. The only normative use of such XML-based metadata in this specification is for installing component packages using the RepositoryManager's installPackage operation.
The resolution for issue 5962 added references. This included a reference to RFC 2045 (MIME) for the description of Base64 encoding. At the same time, the resolution for issue 6024 makes use of Base64 implicit by using the XML data type xsd:base64Binary. Therefore, there is no need having a normative reference to MIME. Proposed resolution: In section 4.1, Remove normative reference to MIME.
In section 9.5.5, the name of the "type" attribute of the ValueType class is inconsistent. The attribute holding the Repository Id is named "typeId" elsewhere. Also, the "members" attribute of the EnumType is inconsisting with the model diagram conventions for use of the plural, should be "member". Proposed resolution: In section 9.5.5, change the name of the "type" attribute of the ValueType class to "typeId". Change the name of the "members" attribute of the EnumType class to "member".
In section 9.6.6, the DataValue class has an attribute named "ulonglong" with the type being "xsd:ulong". That is a typo, the type should be "xsd:unsignedLong". Proposed resolution: In the diagram of section 9.6.6, change "xsd:ulong" to "xsd:unsignedLong".
In the adopted specification, some classes used "label" attributes
for identification purposes to support traceability. Issue 5964
changed these classes to have "name" instead of "label" attributes.
However, some references to the "label" attributes still exist in
the document.
Proposed resolution:
In section 6.4.9.1, remove the paragraph that reads
A label can optionally be associated with the AssemblyCon-
nectionDescription. Assembly design tools might use this label
to visualize the connection.
In section 6.8.3.1, change the fifth sentence of the first paragraph
from
The MonolithicDeploymentDescription contains a human-readable
label and references ArtifactDeploymentDescription elements for
all artifacts that are part of the deployment.
to read
The MonolithicDeploymentDescription references ArtifactDeploy-
mentDescription elements for all artifacts that are part of
the deployment.
In section 6.11.1.1, update the diagram for the PackageError
exception.
Deployment & Configuration Technical Issue 6.4.14 MonolithicImplementationDescription The deployRequirement relationship is too broad. A component implementation needs to able to specify resources required (used by) a component and a resource deployed on requirement. Also in the ComponentAssemblyDescription you need to be able to reference these (both types) resources so a component in the assembly can connect to these resources. These are concepts in the SCA that are not in the D & C specification.
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.
Add another subsection to 9.7 miscellaneous and call it Execute Parameters The specification should make a recommendation and state some well-defined execparameters that are passed to a process or entry when a component is manifest by a process. The deployment machinery needs to be able to obtain the object reference for this component. The execparameters that need to be specified are: 1. NamingContext of where the component's object reference is to be placed. 2. Naming Service IOR to be used for this registration 3. Component instance identifier
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
6.7.1. Target Manager The Target manager serves 3 purposes, deployment behavior, domain information, and registration information. Three different actors use this component. Issue 1: To be consistent with other interfaces for registering and unregistering information with the domain. I would replace the update operation with two operations, register node and unregister node. The register node takes in an abstract nodeManager (needs to be added to spec) and node's xml profile descriptor. This provides a more open interface and can easily accommodate extensions by the type of node manager registering and type of profile information. This allows domains to extend the behavior as necessary without changing the specification. This needs to be a separate interface. The separate interface again provides the capability of extending the registration interface with system/domain specific registration needs. This also may affect the domain profile definition since a node can a profile associated with it. For systems or domains implementations that need this behavior a component could exist that provides this behavior. Not all systems need to formally register their information.
During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. A concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
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
For SupportedType attribute, how can one distinguish between the interfaces provided and required for a port when a port is both a provider and a user?
During the RTF meetings and telephone conferences the RTF agreed on a general solution outline. However, further discussion is needed on the proposed resolution. Thus, this issue is deferred to the next Deployment RTF
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).
For a port definition allow the capability to optional supply port characteristic and capability properties.
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 a navigable association to Requirement with multiplicity being "*". Rationale for change is to allow for PSMs to qualify the requirements needed for an ExternalReferenceEndpoint. An example is a SWRadio use cases for this are: a. To be able to specify a service needed that the domain is aware of. b. To be able specify a device that deployment machinery used for the deployment of a component. c. To be able to specify a service that was chosen by the deployment machinery that was specified for a component deployment requirement.
During the RTF meetings and telephone conferences the RTF agreed that further information from the poster of this issue is needed. Thus, this issue is deferred to the next Deployment RTF.
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.
Constraint Definition lacks the requirement of what constitutes a valid connection. For a connection there must be at least one required port/interface and at least one provider port/interface.
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
ExternalReferneceEndpoint, SubcomponentPortEndpoint, ComponentExternalPortEndpoint needs to indicate the type of port/interface. Rational: This allows the deployment machinery or planner not to process all the components component descriptor files to determine the type of port/interface.
During the RTF meetings and telephone conferences the RTF agreed that a concrete text proposal is needed for resolving this issue. Since such proposal is not yet available this issue is deferred to the next Deployment RTF.
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.