${taskforce.name} Avatar
  1. OMG Task Force

Deployment RTF — All Issues

  • Key: DEPL4
  • Issues Count: 32
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DEPL4-31 Information about Port Delegations Lost In Planning DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-32 IDL name clash due to enumeration values defined twice DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-28 Enumerated SatisfierProperties 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-26 Separation of components during deployment (opposite of collocation). DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-27 Resource Commitment Sequence Diagram Clarification 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-25 Requirement Satisfier "name" Attribute is not Optional DEPL 1.0 DEPL 4.0 Resolved closed
DEPL4-22 Target Manager Resource Commitment Granularity 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
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-16 Type of Components::ExternalReference::location does not exist DEPL 4.0 open
DEPL4-19 Multiplicity of Target::SharedResource::resourceUser ambiguous DEPL 4.0 open
DEPL4-12 Section: 7.6.1.1-7.6.1.2; 9.10 DEPL 4.0 open
DEPL4-13 Add startLaunch also to DomainApplication/NodeApplication DEPL 4.0 open
DEPL4-14 Multiplicity of Components::Component::ownedPort ambiguous overview diagram DEPL 4.0 open
DEPL4-15 Multiplicity of Components::Component::ownedPort ambiguous DEPL 4.0 open
DEPL4-11 Supports For Many Applications 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-6 SatisfierPropertyKind is too Restrictive DEPL 1.0 open
DEPL4-7 Locally Managed Capacity Indicator DEPL 1.0 open
DEPL4-3 New Requirement Satisfier Type DEPL 1.0 open
DEPL4-1 XML Schema of Deployment spec doesn't honour constraints present in model DEPL 1.0b1 open
DEPL4-2 Host Collocation Deployment Directive Capability Lacking DEPL 1.0 open
DEPL4-5 Component Factory Lacking DEPL 1.0 open
DEPL4-4 AssemblyController Component Lacking DEPL 1.0 open

Issues Descriptions

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

IDL name clash due to enumeration values defined twice

  • Key: DEPL4-32
  • Legacy Issue Number: 9239
  • Status: closed  
  • Source: Fraunhofer FOKUS ( 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

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

Separation of components during deployment (opposite of collocation).

  • Key: DEPL4-26
  • Legacy Issue Number: 7954
  • Status: closed  
  • Source: Fraunhofer FOKUS ( 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

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

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

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

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

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

Ambiguous mulitplicity of Target::CommunicationPath::connectedNode

  • Key: DEPL4-18
  • Legacy Issue Number: 17032
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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 ( 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

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

  • Key: DEPL4-16
  • Legacy Issue Number: 17030
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

Multiplicity of Target::SharedResource::resourceUser ambiguous

  • Key: DEPL4-19
  • Legacy Issue Number: 17033
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

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

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

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

  • Key: DEPL4-14
  • Legacy Issue Number: 17028
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

Multiplicity of Components::Component::ownedPort ambiguous

  • Key: DEPL4-15
  • Legacy Issue Number: 17029
  • Status: open  
  • Source: Fraunhofer FOKUS ( 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

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

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

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

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

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

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

  • Key: DEPL4-1
  • Legacy Issue Number: 7354
  • Status: open  
  • Source: Vanderbilt University ( 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

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

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