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: 19
  • Description: All Issues
Closed All
All Issues

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

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

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