Deployment and Configuration of component-based Distributed Applications Avatar
  1. OMG Specification

Deployment and Configuration of component-based Distributed Applications — All Issues

  • Acronym: DEPL
  • Issues Count: 112
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DEPL4-34 Make use of IDL4 map DEPL 4.0 open
DEPL4-33 Extension needed for IDL4 datatypes DEPL 4.0 open
DEPL-78 No type safety when external packages are referenced DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL4-32 IDL name clash due to enumeration values defined twice DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-31 Information about Port Delegations Lost In Planning DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-30 Deployment Requirements in Deployment Plan DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-29 Distinguish Node vs. Component Exec Parameters in Deployment Plan DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-28 Enumerated SatisfierProperties DEPL 1.0 DEPL 4.0 Resolved closed
DEPL-77 Deployment Behavior DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-76 MonolithicImplementationDescription Attributes DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-75 Technical sections 2.3.3 and 2.3.4 DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-74 page 91: In the sequence diagram DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-65 Misuse of XMI Proxy Links DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-64 Subcomponents Package Inconsistency DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-67 Semantics of IDL generated from Deployment & Configuration Specification DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-66 Missing definition for connection in chapter 5: DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-61 Domain Information DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-60 The submission only gives one choice for managing node resources DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-71 Suggestion is to break ComponentExternalPortEndpoint DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-70 ExternalReferneceEndpoint need to indicate the type of interface DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-63 property name issue DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-62 6.4.17 ComponentPortDescription (02) DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-69 For ExternalReferneceEndpoint add optional port name attribute DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-68 For ExternalReferneceEndpoint add provider boolean attribute DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL-59 ExternalReferneceEndpoint, SubcomponentPortEndpoint, .. DEPL 1.0b1 open
DEPL-58 Constraint Definition DEPL 1.0b1 open
DEPL-57 ExternalReferneceEndpoint DEPL 1.0b1 open
DEPL-73 Add "replace" parameter to installPackage DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL4-2 Host Collocation Deployment Directive Capability Lacking DEPL 1.0 open
DEPL4-1 XML Schema of Deployment spec doesn't honour constraints present in model DEPL 1.0b1 open
DEPL4-5 Component Factory Lacking DEPL 1.0 open
DEPL4-4 AssemblyController Component Lacking DEPL 1.0 open
DEPL4-3 New Requirement Satisfier Type DEPL 1.0 open
DEPL-72 ComponentExternalPortEndpoint definition is not unique enough DEPL 1.0b1 DEPL 1.0 Resolved closed
DEPL4-22 Target Manager Resource Commitment Granularity DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-24 Resource Deployment Description Insufficient DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-23 Resource Deployment Description Clarification DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-27 Resource Commitment Sequence Diagram Clarification DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-26 Separation of components during deployment (opposite of collocation). DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-25 Requirement Satisfier "name" Attribute is not Optional DEPL 1.0 DEPL 4.0 Resolved closed
DEPL-56 6.4.17 ComponentPortDescription (03) DEPL 1.0b1 open
DEPL4-21 UML 2.0 port issue DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-20 Process Collocation Deployment Directive Capability Lacking DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-19 Multiplicity of Target::SharedResource::resourceUser ambiguous DEPL 4.0 open
DEPL4-10 Monitor or Verify Lacking in Deployment Process DEPL 1.0 open
DEPL4-9 ArtifactDeploymentDescription: "node" should be optional DEPL 1.0 open
DEPL4-8 Deployment descriptors DEPL 1.0 open
DEPL4-7 Locally Managed Capacity Indicator DEPL 1.0 open
DEPL4-13 Add startLaunch also to DomainApplication/NodeApplication DEPL 4.0 open
DEPL4-12 Section: 7.6.1.1-7.6.1.2; 9.10 DEPL 4.0 open
DEPL4-18 Ambiguous mulitplicity of Target::CommunicationPath::connectedNode DEPL 4.0 open
DEPL4-17 Stereotype-property Components::Port::UID ambiguous DEPL 4.0 open
DEPL4-15 Multiplicity of Components::Component::ownedPort ambiguous DEPL 4.0 open
DEPL4-14 Multiplicity of Components::Component::ownedPort ambiguous overview diagram DEPL 4.0 open
DEPL4-11 Supports For Many Applications DEPL 4.0 open
DEPL4-16 Type of Components::ExternalReference::location does not exist DEPL 4.0 open
DEPL4-6 SatisfierPropertyKind is too Restrictive DEPL 1.0 open
DEPL-8 Missing explanation for selectRequirement in SubcomponentInstantiationDescr DEPL 1.0b1 open
DEPL-7 XMI should be used for schema generation DEPL 1.0b1 open
DEPL-6 References to DataTypes not valid MOF DEPL 1.0b1 open
DEPL-5 Inconsistent use of label attribute in DeploymentPlan DEPL 1.0b1 open
DEPL-2 MOF requires Associations to be Named DEPL 1.0b1 open
DEPL-1 Sequence metatype DEPL 1.0b1 open
DEPL-4 Dependency relationships are not a MOF construct DEPL 1.0b1 open
DEPL-3 Misuse of ComponentPackageReference for Implementation Dependencies DEPL 1.0b1 open
DEPL-14 The CCM XML is totally replaced with new Schema XML DEPL 1.0b1 open
DEPL-13 Should be able to create Applications dynamically DEPL 1.0b1 open
DEPL-11 Use optional attributes for optional values DEPL 1.0b1 open
DEPL-10 References chapter is empty DEPL 1.0b1 open
DEPL-12 No Traceability if optional labels are blank DEPL 1.0b1 open
DEPL-9 createPackage operation for RepositoryManager DEPL 1.0b1 open
DEPL-25 Submission allows multiple objects with identical names (unique identifiers DEPL 1.0b1 open
DEPL-24 Terms and Definitions chapter is empty DEPL 1.0b1 open
DEPL-22 Any mapping in XML is too verbose DEPL 1.0b1 open
DEPL-21 Base64 encoding DEPL 1.0b1 open
DEPL-16 The install and uninstall operations should be decoupled DEPL 1.0b1 open
DEPL-15 .Package, Component, Component Implementation Description elements, etc DEPL 1.0b1 open
DEPL-23 Scope chapter is empty DEPL 1.0b1 open
DEPL-28 Capability class DEPL 1.0b1 open
DEPL-27 targetManager association DEPL 1.0b1 open
DEPL-17 Naming of subpackages DEPL 1.0b1 open
DEPL-19 PIM or PSM for CCM DEPL 1.0b1 open
DEPL-18 Typo in OCL for Capability DEPL 1.0b1 open
DEPL-20 Move shared classes to common DEPL 1.0b1 open
DEPL-26 page 16 : in the Table 1 DEPL 1.0b1 open
DEPL-47 Persistence confusion in deployment spec DEPL 1.0b1 open
DEPL-46 Deployment issue: editorial clarification in para 3 in 9.5.8 DEPL 1.0b1 open
DEPL-52 6.4.14 MonolithicImplementationDescription DEPL 1.0b1 open
DEPL-51 Dangling references to "label" attribute DEPL 1.0b1 open
DEPL-45 Troublesome paragraph issue DEPL 1.0b1 open
DEPL-44 Rockwell Collins listed as submitter DEPL 1.0b1 open
DEPL-49 Inconsistent naming of ValueType and EnumType attributes DEPL 1.0b1 open
DEPL-48 No need for MIME reference DEPL 1.0b1 open
DEPL-54 replace the update operation DEPL 1.0b1 open
DEPL-53 MonolithicImplementationDescription Execute Parameters PSM DEPL 1.0b1 open
DEPL-55 6.4.17 ComponentPortDescription (01) DEPL 1.0b1 open
DEPL-50 DataValue typo DEPL 1.0b1 open
DEPL-43 Editorial - Renaming Suggestion DEPL 1.0b1 open
DEPL-36 There is no ObjectSeq type in orb.idl DEPL 1.0b1 open
DEPL-35 Need global unique identifier scheme compliant with MOF 2.0 standard DEPL 1.0b1 open
DEPL-39 Alternative Locations DEPL 1.0b1 open
DEPL-38 Any string content clarification DEPL 1.0b1 open
DEPL-37 Index base clarification DEPL 1.0b1 open
DEPL-42 3. Technical - Interconnect DEPL 1.0b1 open
DEPL-41 2. Editorial - Consistency DEPL 1.0b1 open
DEPL-34 typo page 131 DEPL 1.0b1 open
DEPL-33 page 131: Inconsistency DEPL 1.0b1 open
DEPL-31 page 99: the deployRequirement association DEPL 1.0b1 open
DEPL-30 6) typo page 89 DEPL 1.0b1 open
DEPL-40 Editorial - Consistency DEPL 1.0b1 open
DEPL-29 typo page 98 DEPL 1.0b1 open
DEPL-32 typo page 127 DEPL 1.0b1 open

Issues Descriptions

Make use of IDL4 map

  • Key: DEPL4-34
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The API can be simplified for the users by replacing various sequences with the new IDL4 map type.

  • Reported: DEPL 4.0 — Fri, 18 Aug 2023 07:17 GMT
  • Updated: Wed, 23 Aug 2023 20:15 GMT

Extension needed for IDL4 datatypes

  • Key: DEPL4-33
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    IDL4 extends the IDL type system with the types coming from DDS X-Types (maps,bitset.struct inheritance,bitmasks), the D&C specification should be extended to support these types in the xsd

  • Reported: DEPL 4.0 — Mon, 27 Mar 2023 09:11 GMT
  • Updated: Fri, 31 Mar 2023 18:25 GMT

No type safety when external packages are referenced

  • Key: DEPL-78
  • Legacy Issue Number: 7557
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The ComponentPackageReference element (6.4.8) allows to reference
    an external package (to be resolved during planning by searching
    repositories), for example to instantiate a subcomponent instance
    from, in an assembly.

    However, there is no type safety here; an assembly design tool has
    no way of validating that the ports (which are referenced by
    connections within the assembly) actually exist in the component
    interface of the referenced component.

    Actually, there is little point in ComponentPackageReference having
    an optional "requiredType"; there should always be a mandatory type
    that the referenced package must support.

    To an assembly design tool, just having the "requiredType" repository
    id is insufficient for validation, the full
    ComponentInterfaceDescription
    is necessary.

    Proposed resolution:

    In section 6.4.8.2, ComponentPackageReference Attributes, delete the
    "requiredType" attribute.

    Add a "requiredType" composition association to ComponentInterface-
    Description, with multiplicity 1..1.

    In section 6.4.8.3, ComponentPackageReference Constraints, delete the
    constraints, and replace with "No constraints." (Rationale: when type
    conformance is mandatory, the existing constraing will always be met.)

    In section 6.4.8.4, ComponentPackageReference Semantics, replace the
    existing text

    The planner will search one or more repositories for package
    configurations that satisfy all requirements.

    with

    The planner will search one or more repositories for package
    configurations that support the requiredType, and that match the
    requiredUUID and requiredName attributes, if present.

  • Reported: DEPL 1.0b1 — Thu, 1 Jul 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 02:08 GMT

IDL name clash due to enumeration values defined twice

  • Key: DEPL4-32
  • Legacy Issue Number: 9239
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Andreas Hoffmann)
  • Summary:

    In section 6.4.11.5 (Semantics of LocalityKind), different values including "DifferentProcess" and "NoConstraint" are defined for the LocalityKind enumeration of the Component Data Model. In section 6.8.6.5 (Semantics of PlanLocalityKind), the constants for the PlanLocalityKind enumeration are defined for the Execution Data Model, also containg these two names mentioned above. The problem is that enumeration names are introduced into their parent scope. Thus, the definition of the PlanLocalityKind reusing the same names as used in the LocalityKind enumeration causes a name clash in the IDL.

    Proposed resolution:

    Add a prefix "Plan" to all the constants of the PlanLocalityKind enumeration.

    In section 6.8.6.5, change the bullet list from

    SameProcess: This value specifies that the component instances that the PlanLocality element referers to shall be started in the same process by the deployment engine.

    DifferentProcess: This value specifies that the component instances that the PlanLocality element referers to shall be started in different processes by the deployment engine.

    NoConstraint: This value specifies that there is no locality constraint for the component instances that the PlanLocality element refers to. The purpose of this special value is to enable to switch locality constraints temporarily off without loosing the structure of the DeploymentPlan, i.e. the PlanLocality class instance with its associations to InstanceDeploymentDescription can be kept for later reuse but has currently no impact on the execution of the DeploymentPlan.
    to

    PlanSameProcess: This value specifies that the component instances that the PlanLocality element referers to shall be started in the same process by the deployment engine.

    PlanDifferentProcess: This value specifies that the component instances that the PlanLocality element referers to shall be started in different processes by the deployment engine.

    PlanNoConstraint: This value specifies that there is no locality constraint for the component instances that the PlanLocality element refers to. The purpose of this special value is to enable to switch locality constraints temporarily off without loosing the structure of the DeploymentPlan, i.e. the PlanLocality class instance with its associations to InstanceDeploymentDescription can be kept for later reuse but has currently no impact on the execution of the DeploymentPlan.

  • Reported: DEPL 1.0 — Wed, 18 Jan 2006 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    Add a prefix "Plan" to all the constants of the PlanLocalityKind enumeration.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Information about Port Delegations Lost In Planning

  • Key: DEPL4-31
  • Legacy Issue Number: 8984
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The resolution for issue 6392 introduced the ability
    for a monolithic implementation to delegate some of its
    ports to a resource.

    To this effect, the ImplementationRequirement element
    has three attributes, "resourceUsage", "resourcePort"
    and "componentPort" to identify how the component
    instance uses the resource.

    In the deployment plan, the InstanceResourceDeployment-
    Description element captures which resource was chosen
    to satisfy the requirement. It has a "resorceUsage",
    but neither "resourcePort" and "componentPort"
    attributes.

    This information is necessary in the deployment plan.

    Proposed resolution:

    Add "resourcePort" and "componentPort" attributes to
    the InstanceResourceDeploymentDescription element, to
    carry the information from the original implementation
    requirement.

    In section 6.8.12.2, add two attributes:

    resourcePort [0..1]: The resource port used by the
    component instance. Copied from the original
    ImplementationRequirement.

    componentPort [0..1]: The component port delegated
    to or used by the resource. Copied from the
    original ImplementationRequirement.

  • Reported: DEPL 1.0 — Wed, 31 Aug 2005 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Deployment Requirements in Deployment Plan

  • Key: DEPL4-30
  • Legacy Issue Number: 8983
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Deployment Plan, in its Artifact Deployment Description
    and Monolithic Deployment Description element, copies the
    deployment requirements from the component data model, i.e.,
    from the Implementation Artifact Description and Monolithic
    Implementation Description, respectively.

    However, while the deployment requirements for a monolithic
    implementation are represented using the Implementation
    Requirement element, Monolithic Deployment Description only
    allows deployment requirements to be of type Requirement,
    and is thus not able to completely capture the original
    requirement.

    This is an effect of the resolution of issue 6392, which
    extended deployment requirements for monolithic
    implementations in the component data model from
    "Requirement" to "ImplementationRequirement", but neglected
    to make a similar change to the Monolitic Deployment
    Description.

    This information may not be necessary in the deployment plan
    in the first place, as an Instance Deployment Description
    now, also as a result of this resolution, captures the
    resources that were chosen to satisfy the monolithic
    implementation's requirements.

    As noted in the resolution, an issue to remove the copies
    of deployment requirements should be raised separately. Here
    it is.

    Proposed resolution:

    Remove the copies of deployment requirements, in both
    Artifact Deployment Description and Monolithic Deployment
    Description.

    In section 6.8.2.1, "ArtifactDeploymentDescription
    Description", change the last sentence from

    Execution parameters and deployment requirements are
    copied from the ImplementationArtifactDescription.

    to

    Execution parameters are copied from the
    ImplementationArtifactDescription.

    In section 6.8.2.3, "ArtifactDeploymentDescription
    Associations", remove the "deployRequirement"
    association.

    In section 6.8.3.1, "MonolithicDeploymentDescription
    Description", change the last sentence from

    The execution parameters and deployment requirements
    are copied from the MonolithicImplementationDescription.

    to

    The execution parameters are copied from the
    MonolithicImplementationDescription.

    In section 6.8.3.3, "MonolithicDeploymentDescription
    Associations", remove the "deployRequirement"
    association.

  • Reported: DEPL 1.0 — Tue, 30 Aug 2005 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Distinguish Node vs. Component Exec Parameters in Deployment Plan

  • Key: DEPL4-29
  • Legacy Issue Number: 8979
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The resolution for issue 6435 split the former "execution
    parameters" into "node execution parameters" and "component
    execution parameters" within the Component Data Model, by
    extending the MonolithicImplementationDescription element
    to have separate "nodeExecParameter" and "componentExec-
    Parameter" property lists.

    However, the resolution neglected to make a similar change
    to the Execution Data Model – the MonolithicDeployment-
    Description element in the Deployment Plan only has a single
    list of "execParameter" properties.

    This should be changed to be in sync with the Component
    Data Model.

    Proposed resolution:

    In section 6.8.3.3 (MonoliticDeploymentDescription
    associations), remove the "execParameter" association.

    Instead, add the following two associations:

    nodeExecParameter: Property[*]
    Execution parameters that are passed to the target
    environment. Copied from the MonoliticImplementation-
    Description.
    componentExecParameter: Property[*]
    Execution parameters that are passed to the primary
    artifact. Copied from the MonoliticImplementation-
    Description.

  • Reported: DEPL 1.0 — Fri, 26 Aug 2005 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Enumerated SatisfierProperties

  • Key: DEPL4-28
  • Legacy Issue Number: 8944
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Section 9.3.5, "SatisfierProperty," defines the concrete
    data types that a SatisfierProperty's value can assume,
    depending on the SatisfierPropertyKind.

    For the "Attribute" kind, it allows the value to be of a
    (user-defined) enumeration type. It then says, "if the value
    of the SatisfierProperty is of enumeration type, the value
    of the Property is of type string, containing the enumeration
    value that must compare equal to the SatisfierProperty value.

    This is straightforward enough. E.g., it allows a
    DomainAdministrator to enumerate the kinds of processors
    in a domain,

    enum Processors

    { ix86, ppc, sparc }

    ;

    and then to tag each node with a resource containing a
    property of this type, its value specifying the actual
    processor type of the node.

    It seemed like a good idea. Yet this feature does not buy
    much. The DomainAdministrator could just as well use an
    attribute of type string to the same effect. The only
    advantage is that the enumerated property allows the
    DomainAdministrator to constrain the values that a
    SatisfierProperty may have. But it's the DomainAdmininstrator
    constraining himself, so it's not much of a constraint.

    However, this feature does add a dependency on DynamicAny
    for both the TargetManager and the Planner, which do not
    know about any user-defined enumeration types. All the other
    SatisfierPropertyKind options use basic IDL data types (long,
    unsigned long, double or string).

    So, because of the added complexity, and the low mileage, I
    propose to remove enumerated properties from the spec.

    Proposed resolution:

    In section 9.3.5, "SatisfierProperty," change the fourth
    and fifth bullet from:

    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double, string, or an enumeration type.
    In the case of long, double or string, the value of the
    Property must be of the same type. If the value of the
    SatisfierProperty is of enumeration type, the value of
    the Property is of type string, containing the enumeration
    value that must compare equal to the SatisfierProperty
    value.

    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double, string, or an
    enumeration type. The same rules as for the Attribute kind
    apply.

    To:

    For the Attribute kind, the value of the SatisfierProperty
    is of type long, double or string. The value of the
    Property must be of the same type and compare equal to
    the SatisfierProperty value.

    For the Selection kind, the value of the SatisfierProperty
    is a sequence of type long, double or string. The same
    rules as for the Attribute kind apply.

  • Reported: DEPL 1.0 — Mon, 1 Aug 2005 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Deployment Behavior

  • Key: DEPL-77
  • Legacy Issue Number: 6598
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

MonolithicImplementationDescription Attributes

  • Key: DEPL-76
  • Legacy Issue Number: 6435
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 5 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Technical sections 2.3.3 and 2.3.4

  • Key: DEPL-75
  • Legacy Issue Number: 6269
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    2.3.3 ComponentPackageDescription
    2.3.4 ComponentImplementationDescription
    There should be a constraint stated for the configproperties? What should
    they relate to?

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

page 91: In the sequence diagram

  • Key: DEPL-74
  • Legacy Issue Number: 6039
  • Status: closed  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Misuse of XMI Proxy Links

  • Key: DEPL-65
  • Legacy Issue Number: 7164
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Subcomponents Package Inconsistency

  • Key: DEPL-64
  • Legacy Issue Number: 7163
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 16 Mar 2004 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of IDL generated from Deployment & Configuration Specification

  • Key: DEPL-67
  • Legacy Issue Number: 7278
  • Status: closed  
  • Source: Vanderbilt University ( Mr. Krishnakumar Balasubramanian)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing definition for connection in chapter 5:

  • Key: DEPL-66
  • Legacy Issue Number: 7242
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Andreas Hoffmann)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 15 Apr 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain Information

  • Key: DEPL-61
  • Legacy Issue Number: 6599
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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?

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The submission only gives one choice for managing node resources

  • Key: DEPL-60
  • Legacy Issue Number: 5968
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • 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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggestion is to break ComponentExternalPortEndpoint

  • Key: DEPL-71
  • Legacy Issue Number: 7285
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Suggestion is to break ComponentExternalPortEndpoint from
    AssemblyConnectionDescription as a separate definition for the assembly
    external port definitions

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint need to indicate the type of interface

  • Key: DEPL-70
  • Legacy Issue Number: 7284
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property name issue

  • Key: DEPL-63
  • Legacy Issue Number: 6632
  • Status: closed  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Tue, 18 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (02)

  • Key: DEPL-62
  • Legacy Issue Number: 6603
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For ExternalReferneceEndpoint add optional port name attribute

  • Key: DEPL-69
  • Legacy Issue Number: 7281
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

For ExternalReferneceEndpoint add provider boolean attribute

  • Key: DEPL-68
  • Legacy Issue Number: 7280
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint, SubcomponentPortEndpoint, ..

  • Key: DEPL-59
  • Legacy Issue Number: 7283
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constraint Definition

  • Key: DEPL-58
  • Legacy Issue Number: 7282
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ExternalReferneceEndpoint

  • Key: DEPL-57
  • Legacy Issue Number: 7279
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 30 Apr 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add "replace" parameter to installPackage

  • Key: DEPL-73
  • Legacy Issue Number: 7302
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 5 May 2004 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Host Collocation Deployment Directive Capability Lacking

  • Key: DEPL4-2
  • Legacy Issue Number: 7666
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem: The CCM DTD and SCA DTD in the assembly descriptors has the
    capability to direct deployment of components on the same
    processor. The capability is needed for deployment considerations to direct
    which components are to be collocated on the same processor.
    Example use case is there are devices in the system with the same
    characteristics but when deploying the components, one wants to ensure that
    certain components are deployed on the same processor not on different
    processors with the same characteristics.
    Recommended solution: Is to add an optional zero to many Host Collocation
    element to the ComponentAssemblyDescription.

  • Reported: DEPL 1.0 — Fri, 3 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Schema of Deployment spec doesn't honour constraints present in model

  • Key: DEPL4-1
  • Legacy Issue Number: 7354
  • Status: open  
  • Source: Vanderbilt University ( Mr. Krishnakumar Balasubramanian)
  • Summary:

    Hi,

    The Deployment & Configuration XML Schema defines a Property element like:

    <xsd:complexType name="Property">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
    <xsd:element name="name" type="xsd:string" />
    <xsd:element name="value" type="Deployment:Any" />
    <xsd:element ref="xmi:Extension" />
    </xsd:choice>
    <xsd:attribute ref="xmi:id" use="optional" />
    <xsd:attributeGroup ref="xmi:ObjectAttribs" />
    </xsd:complexType>
    <xsd:element name="Property" type="Deployment:Property" />

    This allows for the following invalid Property file to be passed silently
    by the XML Schema validator:

    <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
    <Deployment:Property
    xmlns:Deployment="http://www.omg.org/Deployment"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.omg.org/Deployment Deployment.xsd">
    <name>ORBSvcConf</name>
    <value>
    <type>
    <kind>tk_string</kind>
    </type>
    <value>
    <string>Foo</string>
    </value>
    </value>
    <value>
    <type>
    <kind>tk_short</kind>
    </type>
    <value>
    <long>123</long>
    </value>
    </value>
    </Deployment:Property>

    The model in 6.10.8 has a containment association with a cardinality one
    for value. The schema generated from that model doesn't match the semantics
    in the model. This is just an example. There are a lot of elements where
    the semantics imposed by the schema are different from what is described in
    the model. I am curious as to why this is allowed. It can be easily fixed
    by changing the schema to:

    <xsd:complexType name="Property">
    <xsd:sequence minOccurs="0" maxOccurs="1">
    <xsd:element name="name" type="xsd:string" />
    <xsd:element name="value" type="Deployment:Any" />
    <xsd:element ref="xmi:Extension" minOccurs="0" />
    </xsd:sequence>
    <xsd:attribute ref="xmi:id" use="optional" />
    <xsd:attributeGroup ref="xmi:ObjectAttribs" />
    </xsd:complexType>
    <xsd:element name="Property" type="Deployment:Property" />

  • Reported: DEPL 1.0b1 — Thu, 13 May 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Component Factory Lacking

  • Key: DEPL4-5
  • Legacy Issue Number: 7736
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Issue 3: Component Factory Lacking
    Both the SCA and CCM has the capability of expressing factory concepts in
    the assembly description. The factory concepts allow for the deployment
    machinery to create components in the assembly from a component factory
    that is a component of the assembly or service of the node/device.

    Recommendation
    Update SubcomponentInstantiationDescription to add an optional element that
    can be used to reference a component in the assembly or a referenced
    service that is a component factory. This new element should also contain
    optional properties that can be used by the factory for component creation

  • Reported: DEPL 1.0 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssemblyController Component Lacking

  • Key: DEPL4-4
  • Legacy Issue Number: 7735
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Issue 2: AssemblyController Component Lacking
    Lacking the capability of expressing a AssemblyController component in a
    assembly component description. One use case is the SCA and the SWRadio
    spec. The assembly controller is the component in assembly that is the main
    controller and the Application proxy communicates with when specified.
    Recommendation:
    Add an optional AssemblyControllerComponent Element to the
    AssemblyComponent description. The AssemblyControllerComponent Element
    definition contains an attribute, which identifies the component in the
    assembly that is the assembly controller component. Add
    AssemblyControllerComponent Element as subsection to 6.4. Update section
    6.4.9.1 figure. Update PSM XML for ComponentAssemblyDescription.

    This also allows PSMs to constraint the definition to always none or
    mandatory for a assembly controller.

  • Reported: DEPL 1.0 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

New Requirement Satisfier Type

  • Key: DEPL4-3
  • Legacy Issue Number: 7734
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Issue 1: New Requirement Satisfier Type
    Unable to express a node/device characteristic as a set where each item is
    an instance of the same characteristic class. For example, node/device may
    have many runtimes, libraries, communication paths/QoS. One needs to be
    able to express a characteristic such as runtime or library as one
    characteristic with multiple instances, where each instance contains the
    same requirement satisfier definition. For example, for runtime or library
    characteristic each instance in the set would contain name and its value
    and version and its value, as a set of instances of a characteristic that
    contains name and version in this case. This would allow one to state the
    set of libraries or runtimes in a consistent manner all belonging to the
    runtime or library characteristic.

    Right now for the D & C, I would have to define a RequirementSatisfier as
    RunTime1 and RunTime2 instead of RunTime. I am able to express a
    requirement as RunTime but this will not be matched against RunTime1 and
    RunTime2.

    Potential Recommendation
    Add definition for RequirementSetSatisfier that contains 1 one to many
    RequirementSatisfier. The constraint being the RequirementSatisfier
    definition has to be the same except for the values.

    Appears that an abstract definition is needed for the
    RequirementSetSatisfier and RequirementSatisfier since a node or device can
    have either or both of them, and they have common attributes (name,
    resourceType).

    This added capability would also cause changes to the update operation to
    support this information.

  • Reported: DEPL 1.0 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ComponentExternalPortEndpoint definition is not unique enough

  • Key: DEPL-72
  • Legacy Issue Number: 7286
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Sun, 30 Apr 2000 04:00 GMT
  • Disposition: Resolved — DEPL 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Target Manager Resource Commitment Granularity

  • Key: DEPL4-22
  • Legacy Issue Number: 7880
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    At the moment, resources are committed and later released according to
    a Deployment Plan – the Execution Manager just sends over the full
    plan, and the Target Manager has to pick it apart. We considered this
    a good idea – after all, the plan contains all information about
    resources that will be used by an application. In retrospect, however,
    it looks like a design break. The plan contains a lot of information
    that the Target Manager is not interested in. So the Target Manager
    has to dissect information that it should not need to see in the first
    place.

    Also, and maybe more importantly, the only way of releasing resources
    is by sending the very same plan to the Target Manager all over again,
    as the Target Manager does not keep track of allocations.

    This does not allow for the early release of resources, in case the
    application does not need all that were reserved, or in case part of
    the application finishes early.

    Therefore I propose to replace the current "commitResources" and
    "releaseResources" operations with a per-application "resource
    commitment" object that allows to commit and release resources in a
    fine-grained manner, and that keeps track of the current commitment,
    so that the remaining resources that are in use by an application
    can be released by simply destroying the object.

    By not sending the full Deployment Plan, that would also dramatically
    cut communication between the Execution Manager and the Target Manager.

  • Reported: DEPL 1.0 — Mon, 25 Oct 2004 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resource Deployment Description Insufficient

  • Key: DEPL4-24
  • Legacy Issue Number: 7941
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 6.8.9, the ResourceDeploymentDescription, part of a
    DeploymentPlan, contains information about the resources that were
    chosen to satisfy a requirement.

    It has a "resourceValue" association to an Any value.

    However, resources and requirements have not just one value, but a
    set of properties; see 6.10.4 (RequirementSatisfier) and 6.10.7
    (Requirement).

    Therefore, the "resourceValue" must be replaced with a set of
    "Properties" elements.

    Proposed resolution:

    In section 6.8.9.3 (ResourceDeploymentDescription associations),
    replace the current association

    resourceValue: Any [1]
    The aspect of the resource actually allocated, if any, of
    the appropriate type of the resource's SatisfierPropertyKind
    attribute. For Quantity, it is the ordinal allocated. For
    Allocation, it is the allocated capacity, for Selection, it
    is the matched string. For others, it is the value of the
    matched property.

    with

    property: Property [*]
    The aspects of the resource actually allocated, if any. The
    property values are of the appropriate types according to
    their matched SatisfierProperty's SatisfierPropertyKind
    attribute. For Quantity, it is the ordinal allocated. For
    Allocation, it is the allocated capacity, for Selection, it
    is the matched string. For others, it is the value of the
    matched property

  • Reported: DEPL 1.0 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resource Deployment Description Clarification

  • Key: DEPL4-23
  • Legacy Issue Number: 7940
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Sections 6.8.9, 6.8.10 and 6.8.11 describe the ResourceDeployment-
    Description, InstanceResourceDeploymentDescription and Connection-
    ResourceDeploymentDescription elements, which identify the resources
    that were chosen to satisfy a requirement.

    There are three minor editorial issues here:

    (1)

    In 6.8.11.2 (ConnectionResourceDeploymentDescription Attributes),
    the targetName attribute always identifies an Interconnect or a Bridge,
    but never a Node.

    Proposed resolution:

    Update the description for the targetName attribute; change the text
    in parentheses from

    (i.e., the name of a Node, Interconnect or Bridge)

    to

    (i.e., the name of an Interconnect or Bridge)

    (2)

    Also in 6.8.11.2 (ConnectionResourceDeploymentDescription Attributes),
    the targetName provides a scope for the resource, not for a requirement.

    Proposed resolution:

    Update the description for the targetName attribute; change the
    second half of the first sentence (after the comma) from

    [...], to provide scope for the requirementName.

    to

    [...], to provide scope for the resourceName.

    (3)

    Finally, I'd like to clarify in section 6.8.10 (InstanceResource-
    DeploymentDescription) that the resourceName is within the scope of
    the node that this instance is deployed on.

    Proposed resolution:

    In section 6.8.10.5 (InstanceResourceDeploymentDescription semantics),
    add the following text:

    An InstanceResourceDeploymentDescription is always used in the context
    of an InstanceDeploymentDescription, which identifies the node that a
    component instance is deployed on. This node provides scope for the
    resourceName.

  • Reported: DEPL 1.0 — Fri, 19 Nov 2004 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resource Commitment Sequence Diagram Clarification

  • Key: DEPL4-27
  • Legacy Issue Number: 7971
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the latest document, with the resolution to issue 6039 applied,
    figure 8-13 on page 123, contains a note attached to the
    "commitResource"
    operation between the DomainApplicationManager and the TargetManager,
    indicating that:

    This call could come from either the DomainApplicationManager
    or the DomainApplication, as an implementation choice.

    It was intended that implementations can also delegate resource
    commitment
    can also be delegated to nodes.

    Proposed resolution:

    Change the note identified above to read

    Can be delegated to DomainApplication or NodeApplication.

  • Reported: DEPL 1.0 — Wed, 8 Dec 2004 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Separation of components during deployment (opposite of collocation).

  • Key: DEPL4-26
  • Legacy Issue Number: 7954
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Andreas Hoffmann)
  • Summary:

    The current specification does not support the separation of components during depoyment. It should be possible to specify a such a requirement as input for the deployment planning process. Use cases for this are for instance:

    • to request the instantiation of components in different processes for single threaded component implementations
    • to request the instantiation of components in different processes or on different hosts for fault tolerance reasons
    • to request the instantiation of components on different hosts for performance reasons (with respect to CPU load)

    This issue should be resolved together with issue #7666 (host collocation) and issue #7667 (process collocation).

  • Reported: DEPL 1.0 — Tue, 30 Nov 2004 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Requirement Satisfier "name" Attribute is not Optional

  • Key: DEPL4-25
  • Legacy Issue Number: 7945
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 6.10.4.2 (RequirementSatisfier attribute), the
    description for the "name" attribute reads, "An optional name
    for the requirement satisfier."

    This is in violation of our convention for "name" attributes
    (see section 6.3), and in fact, other parts of the specification
    make use of the fact that the name uniquely identifies a
    RequirementSatisfier within its parent, e.g., the Resource
    Deployment Description element; its resourceName identifies a
    resource by the requirement satisfier's name.

    Proposed resolution:

    In section 6.10.4.2, change the description for the "name"
    attribute from

    name: String An optional name for the requirement satisfier.

    to

    name: String The requirement satisfier's name, which uniquely
    identifies this requirement satisfier within its
    container.

  • Reported: DEPL 1.0 — Tue, 23 Nov 2004 05:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (03)

  • Key: DEPL-56
  • Legacy Issue Number: 6604
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    For a port definition allow the capability to optional supply port
    characteristic and capability properties.

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.0 port issue

  • Key: DEPL4-21
  • Legacy Issue Number: 7877
  • Status: closed  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    UML 2.0 allows for ports to have a set of required interfaces and a set
    of provided interfaces.

    The definition of port interfaces in the PIM should allow for this, even though
    the PSM for CCM must constrain this.

    Note that change must also be consistently applied to the external reference endpoints
    (all other endpoints are for component ports with an associated port interface
    definition in the ComponentPortDescription class).

  • Reported: DEPL 1.0 — Wed, 20 Oct 2004 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Process Collocation Deployment Directive Capability Lacking

  • Key: DEPL4-20
  • Legacy Issue Number: 7667
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem: The CCM DTD in the assembly descriptor has the
    capability to direct deployment of components on the same
    processor and the PIM and PSM for SWRadio Components infrastructure
    supports the deployment concept of process collocation. The capability is
    needed for deployment considerations to direct
    which components are to be collocated within the same process. Flexibility
    should be given to express how components are to be deployed.
    One reason to do this is performance considerations. Another use case is
    the components could be an assembly which represents an application service
    that is deployed in one process space.
    Recommended solution: Is to add an optional zero to many Process
    Collocation
    element to the ComponentAssemblyDescription.

  • Reported: DEPL 1.0 — Fri, 3 Sep 2004 04:00 GMT
  • Disposition: Resolved — DEPL 4.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Target::SharedResource::resourceUser ambiguous

  • Key: DEPL4-19
  • Legacy Issue Number: 17033
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The multiplicity of the stereotype-property Target::SharedResource::resourceUser is [0..*] in the overview picture, but [1..*] in the textual description. There seems to be no reason why there should be at least one user for a shared resource.

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Monitor or Verify Lacking in Deployment Process

  • Key: DEPL4-10
  • Legacy Issue Number: 9177
  • Status: open  
  • Source: NUDT ( DongMin Hu)
  • Summary:

    Monitor or Verify Lacking in Deployment Process: In order to make the deployment process more perfect,this specification adds deployment planning before real deployment process begins,the monitoring should be added after the deployment as well.Only implementing deployment does not means the end for an application,it will be wonderful if monitoring the effects of the performed deployment on the target system which may be chosed from several valid deployment plans.This will also be helpful to assess which choice of deployment plans is a better one and to support dynamically upgrade of existing component versions. Recommendation: Monitoring should be added to the deployment process(chapter1.3) and Monitorer should be conrrespondingly added to the Actor (chapter 7). Monitoring may involve many things here we can choose some tightly correlated to deployment.Monitoring the existing application may be easy.During the perfomation of current deployment plan,the deployer can use deploy tools to get CPU or memory's running state of each node in the domain and the network traffic may also be considered.Add some corresponding xml files or elements to describe them will be ok.But for monitoring of dynamically upgrating,we consider a example that a component will be replaced by a set of its versions encapsulated in a wrapper.During the monitoring process,the wrapper is responsible for "hiding" from the rest of the system the fact that a given component exists in multiple version and the role of the wrapper is to relay to all component versions each invocation that it receives from the rest of the system then to propagate the generated results to the rest of the system.We can authoritate different operations to different versions and only the result of the authoritative version will be propagated outside while results of other versions will be logged for comparison of their perfomance?correctness and reliability.After some given time,assesses a better version for use and removes others.There are other algorithms to find out.

  • Reported: DEPL 1.0 — Wed, 23 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ArtifactDeploymentDescription: "node" should be optional

  • Key: DEPL4-9
  • Legacy Issue Number: 8286
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 6.8.2.2 (ArtifactDeploymentDescription attributes),
    the text for the "node" attribute explains,

    node: String
    The name of the node where the artifact is to be installed.
    If blank, the node is implied by the InstanceDeploynment-
    Description parent.

    The empty string should not have a special meaning. Rather,
    the attribute should be optional.

    Proposed resolution:

    Change the attribute to have 0..1 multiplicity, and change
    the text to read as follows:

    node: String [0..1]
    The name of the node where the artifact is to be installed.
    If missing, the node is implied by the InstanceDeployment-
    Description parent.

  • Reported: DEPL 1.0 — Tue, 15 Feb 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment descriptors

  • Key: DEPL4-8
  • Legacy Issue Number: 7746
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    For components created at runtime instead of configuration time, they cannot utilize advantages of Assembly-configurator infrstructure. Those components must using ad hoc Naming or ior to locate other components or assemblies.

    Resolution:

    When a component is created, assembly object call object configurator of type Components::Configurator's mothod to connect component to other components or assemblies:

    void configure (in CCMObject comp)

    Some extension must add to deployment descriptors, assembly object using these information to connect newly created component to other components or assemblies.

    Replace the following text in formal/02-06-05 on page 7-14

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    )* >

    with

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    connectcomponentinstantiation
    )* >

    Add the following text in formal/02-06-05 on page 7-14

    <!ELEMENT connectcomponentinstantiation
    (homeplacementref
    , (connectinterface

    connectevent
    )*
    ) >
    <!ATTLIST connectcomponentinstantiation
    id ID #REQUIRED >
  • Reported: DEPL 1.0 — Thu, 16 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Locally Managed Capacity Indicator

  • Key: DEPL4-7
  • Legacy Issue Number: 7738
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    The capability is lacking to indicate if the capacity model for a capacity
    is managed by the node/device or not. The Deployment and Configuration
    specification should not constraint System Architecture/Developers from
    architecting/implementing the system but be flexible. The OMG SWRadio spec
    allows for this flexibility. One Example use case of this is multiple
    domains trying to reserve capacity from the same device.

    Recommendation
    At a locallyManaged boolean attribute to the RequirementSatisfier.
    Add a new interface called CapacityManager or CapacityAllocator. This
    allows a node/device to realize this type of interface. A node/device would
    only have to support this interface if it had capacities that are locally
    managed. Recommendation for the interface definition is based upon the
    SWRadio DeviceComponent allocateCapacity and deallocateCapacity operations

  • Reported: DEPL 1.0 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add startLaunch also to DomainApplication/NodeApplication

  • Key: DEPL4-13
  • Legacy Issue Number: 14088
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Only the DomainApplicationManager and NodeApplicationManager have a startLaunch, on both classes this leads to a call to a DomainApplication/NodeApplication but this has no name in figure 9.1. We propose to seperate construction with the real functionality. Add startLaunch also to DomainApplication/NodeApplication which means adding it also to the application interface

  • Reported: DEPL 4.0 — Tue, 21 Jul 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.6.1.1-7.6.1.2; 9.10

  • Key: DEPL4-12
  • Legacy Issue Number: 9884
  • Status: open  
  • Source: AGH - University of Science and Technology ( Jacek Cala)
  • Summary:

    On page 51 (section 7.6.1) there is inconsistency between TargetManager interface depicted in figure in subsection 7.6.1.1 and operations' description in subsection 7.6.1.2. In the figure there is 'commitResources' operation whereas in the description there is 'createResourceCommitment' operation. Which one is correct? Just to mention that on page 121 (section 9.10) in figure 9.1 - Executor in Action there is invocation of commitResources operation.

  • Reported: DEPL 4.0 — Thu, 6 Jul 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguous mulitplicity of Target::CommunicationPath::connectedNode

  • Key: DEPL4-18
  • Legacy Issue Number: 17032
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The multiplicity of stereotype-property Target::CommunicationPath::connectedNode is [1..*] in the overview picture, in textual description it is [*]. The multiplicity of [1..*] makes more sense, since the source for the derived property is
    self.interconnect.connectedNode, where CommunicationPath::interconnect has multiplicity [1..*] and Interconnect::connectedNode has multiplicity [1..*], so there should be at least one connectedNode.

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Stereotype-property Components::Port::UID ambiguous

  • Key: DEPL4-17
  • Legacy Issue Number: 17031
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The name and description of stereotype-property Components::Port::UID seems odd. Other stereotypes have a UUID property, providing a unique identifier. The description "The primary type of the port." does not seem to fit.

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Components::Component::ownedPort ambiguous

  • Key: DEPL4-15
  • Legacy Issue Number: 17029
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The property Components::ComponentImplementation::capacity is of type Sequence(Capacity). The type Capacity is not existent, neither in the UML meta-model nor in the DEPL specification. It is most likely (also judging from the stand-alone PIM meta-model) that the type Capability was meant here. So the property should be exchanged by the property:
    Components::ComponentImplementation::capability(Capability)

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity of Components::Component::ownedPort ambiguous overview diagram

  • Key: DEPL4-14
  • Legacy Issue Number: 17028
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    In the overview diagram the property Components::Component::ownedPort has the multiplicity [1..*] in textual description, however, the multiplicity is [*]. There seems to be no reason why a component should have at least one port.

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supports For Many Applications

  • Key: DEPL4-11
  • Legacy Issue Number: 9178
  • Status: open  
  • Source: Anonymous
  • Summary:

    Supports For Many Applications: The current specification is more and more consummate for deploying an application.In the case of actual distributed environments such as embedded system,several applications running at the same time may be more hopeful.Although deploying several applications involves more things to consider,firstly we can add an ApplicationController component.The application controller is the component that coordinates and communicates with each application. Recommendation: The application controller component can be considered an assembly-based component in which each assembly component represents an application.Add an optional ApplicationControllerComponent Elment to the assemblyComponent description which contains an attribute that identifies the component is the application controller component.The corresponding PSM XML should be updated for assemblyComponent description.In implementation,an ApplicationFactory should be added which is reponsible for creating applications.

  • Reported: DEPL 4.0 — Wed, 23 Nov 2005 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type of Components::ExternalReference::location does not exist

  • Key: DEPL4-16
  • Legacy Issue Number: 17030
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Max Bureck)
  • Summary:

    The property Components::ExternalReference::location is of type URL. This type is neither defined in the UML meta-model, nor in the DEPL profile. The type should be String and maybe a constraint or regular expression should be defined to restrict the value to a URL.

  • Reported: DEPL 4.0 — Mon, 23 Jan 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

SatisfierPropertyKind is too Restrictive

  • Key: DEPL4-6
  • Legacy Issue Number: 7737
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    The satisfierPropertykind should not be an enumeration type. This does not
    allow for growth or expressing other capacity models. This issue was
    discuss at the St. Louis meeting
    Recommendation
    Is to change from a enumeration type to string but keep the enumeration
    list as well-define string values along with their meaning.

  • Reported: DEPL 1.0 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing explanation for selectRequirement in SubcomponentInstantiationDescr

  • Key: DEPL-8
  • Legacy Issue Number: 5960
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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 package

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI should be used for schema generation

  • Key: DEPL-7
  • Legacy Issue Number: 5959
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

References to DataTypes not valid MOF

  • Key: DEPL-6
  • Legacy Issue Number: 5958
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of label attribute in DeploymentPlan

  • Key: DEPL-5
  • Legacy Issue Number: 5957
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF requires Associations to be Named

  • Key: DEPL-2
  • Legacy Issue Number: 5954
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence metatype

  • Key: DEPL-1
  • Legacy Issue Number: 5953
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • 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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dependency relationships are not a MOF construct

  • Key: DEPL-4
  • Legacy Issue Number: 5956
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misuse of ComponentPackageReference for Implementation Dependencies

  • Key: DEPL-3
  • Legacy Issue Number: 5955
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The CCM XML is totally replaced with new Schema XML

  • Key: DEPL-14
  • Legacy Issue Number: 5966
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should be able to create Applications dynamically

  • Key: DEPL-13
  • Legacy Issue Number: 5965
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use optional attributes for optional values

  • Key: DEPL-11
  • Legacy Issue Number: 5963
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

References chapter is empty

  • Key: DEPL-10
  • Legacy Issue Number: 5962
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Traceability if optional labels are blank

  • Key: DEPL-12
  • Legacy Issue Number: 5964
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

createPackage operation for RepositoryManager

  • Key: DEPL-9
  • Legacy Issue Number: 5961
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Submission allows multiple objects with identical names (unique identifiers

  • Key: DEPL-25
  • Legacy Issue Number: 6027
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 29 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terms and Definitions chapter is empty

  • Key: DEPL-24
  • Legacy Issue Number: 6026
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any mapping in XML is too verbose

  • Key: DEPL-22
  • Legacy Issue Number: 6024
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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>

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Base64 encoding

  • Key: DEPL-21
  • Legacy Issue Number: 5993
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 8 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The install and uninstall operations should be decoupled

  • Key: DEPL-16
  • Legacy Issue Number: 5969
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

.Package, Component, Component Implementation Description elements, etc

  • Key: DEPL-15
  • Legacy Issue Number: 5967
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 18 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope chapter is empty

  • Key: DEPL-23
  • Legacy Issue Number: 6025
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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 ...ยป."

  • Reported: DEPL 1.0b1 — Mon, 28 Jul 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capability class

  • Key: DEPL-28
  • Legacy Issue Number: 6040
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

targetManager association

  • Key: DEPL-27
  • Legacy Issue Number: 6038
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    2) page 65 : according to the UML diagram, the targetManager association
    described in the ApplicationManager class should only be described in the
    DomainApplicationManager class .

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Naming of subpackages

  • Key: DEPL-17
  • Legacy Issue Number: 5983
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

PIM or PSM for CCM

  • Key: DEPL-19
  • Legacy Issue Number: 5985
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in OCL for Capability

  • Key: DEPL-18
  • Legacy Issue Number: 5984
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    It should read "context Capability", not "context Capacity".

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move shared classes to common

  • Key: DEPL-20
  • Legacy Issue Number: 5986
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Thu, 19 Jun 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 16 : in the Table 1

  • Key: DEPL-26
  • Legacy Issue Number: 6037
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Persistence confusion in deployment spec

  • Key: DEPL-47
  • Legacy Issue Number: 6384
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 22 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deployment issue: editorial clarification in para 3 in 9.5.8

  • Key: DEPL-46
  • Legacy Issue Number: 6383
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 22 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.14 MonolithicImplementationDescription

  • Key: DEPL-52
  • Legacy Issue Number: 6392
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 29 Oct 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Dangling references to "label" attribute

  • Key: DEPL-51
  • Legacy Issue Number: 6388
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Troublesome paragraph issue

  • Key: DEPL-45
  • Legacy Issue Number: 6382
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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?

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rockwell Collins listed as submitter

  • Key: DEPL-44
  • Legacy Issue Number: 6270
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 17 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent naming of ValueType and EnumType attributes

  • Key: DEPL-49
  • Legacy Issue Number: 6386
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No need for MIME reference

  • Key: DEPL-48
  • Legacy Issue Number: 6385
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

replace the update operation

  • Key: DEPL-54
  • Legacy Issue Number: 6597
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 11 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MonolithicImplementationDescription Execute Parameters PSM

  • Key: DEPL-53
  • Legacy Issue Number: 6436
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Wed, 5 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.17 ComponentPortDescription (01)

  • Key: DEPL-55
  • Legacy Issue Number: 6602
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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?

  • Reported: DEPL 1.0b1 — Wed, 12 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

DataValue typo

  • Key: DEPL-50
  • Legacy Issue Number: 6387
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 21 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial - Renaming Suggestion

  • Key: DEPL-43
  • Legacy Issue Number: 6268
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no ObjectSeq type in orb.idl

  • Key: DEPL-36
  • Legacy Issue Number: 6048
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

    ;

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need global unique identifier scheme compliant with MOF 2.0 standard

  • Key: DEPL-35
  • Legacy Issue Number: 6047
  • Status: open  
  • Source: Rockwell Collins ( David Fitkin)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alternative Locations

  • Key: DEPL-39
  • Legacy Issue Number: 6053
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Wed, 27 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any string content clarification

  • Key: DEPL-38
  • Legacy Issue Number: 6052
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 12 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Index base clarification

  • Key: DEPL-37
  • Legacy Issue Number: 6051
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Tue, 12 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

3. Technical - Interconnect

  • Key: DEPL-42
  • Legacy Issue Number: 6267
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

2. Editorial - Consistency

  • Key: DEPL-41
  • Legacy Issue Number: 6266
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    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.

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 131

  • Key: DEPL-34
  • Legacy Issue Number: 6046
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    10) typo page 131: the 'reason' fields of the exceptions are all written
    'reaon'.

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 131: Inconsistency

  • Key: DEPL-33
  • Legacy Issue Number: 6045
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 99: the deployRequirement association

  • Key: DEPL-31
  • Legacy Issue Number: 6043
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

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

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

6) typo page 89

  • Key: DEPL-30
  • Legacy Issue Number: 6042
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    6) typo page 89: The attribute of the ComponentImplementation class is
    written capacityt

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial - Consistency

  • Key: DEPL-40
  • Legacy Issue Number: 6265
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Throughout the document not all roles are described in the text. For
    example section 2.5.3 interconnect

  • Reported: DEPL 1.0b1 — Tue, 9 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 98

  • Key: DEPL-29
  • Legacy Issue Number: 6041
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    ) typo page 98: "A ComponentImplementation is an abstract class that
    contains the defines the attributes and association..."

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo page 127

  • Key: DEPL-32
  • Legacy Issue Number: 6044
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    8) typo page 127: "Regular associations in the UML models (not
    aggreagations) ..."

  • Reported: DEPL 1.0b1 — Fri, 1 Aug 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT