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

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

  • Acronym: DEPL
  • Issues Count: 32
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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-73 Add "replace" parameter to installPackage DEPL 1.0b1 DEPL 1.0 Resolved closed
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
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

Issues Descriptions

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

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

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

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