Issues for Deployment Revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7557: No type safety when external packages are referenced Jira Issue DEPL-78
Issue 7667: Process Collocation Deployment Directive Capability Lacking Jira Issue DEPL4-20
Issue 7877: UML 2.0 port issue Jira Issue DEPL4-21
Issue 7880: Target Manager Resource Commitment Granularity Jira Issue DEPL4-22
Issue 7940: Resource Deployment Description Clarification Jira Issue DEPL4-23
Issue 7941: Resource Deployment Description Insufficient Jira Issue DEPL4-24
Issue 7945: Requirement Satisfier "name" Attribute is not Optional Jira Issue DEPL4-25
Issue 7954: Separation of components during deployment (opposite of collocation). Jira Issue DEPL4-26
Issue 7971: Resource Commitment Sequence Diagram Clarification Jira Issue DEPL4-27
Issue 8944: Enumerated SatisfierProperties Jira Issue DEPL4-28
Issue 8979: Distinguish Node vs. Component Exec Parameters in Deployment Plan Jira Issue DEPL4-29
Issue 8983: Deployment Requirements in Deployment Plan Jira Issue DEPL4-30
Issue 8984: Information about Port Delegations Lost In Planning Jira Issue DEPL4-31
Issue 9239: IDL name clash due to enumeration values defined twice Jira Issue DEPL4-32

Issue 7557: No type safety when external packages are referenced (deployment-rtf)

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.

Resolution:  Make the type information for references to external packages mandatory by pointing to the respective ComponentInterfaceDescription  

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.  

Resolution:  Introduce an additional class called Locality to the ComponentAssemblyDescription that allows for specifying locality constraints on the deployment process.   Add a new class called PlanLocality to the DeploymentPlan that allows for specifying special process locality constraints for the deployment engine executing the deployment plan.    

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

See issue #6602 for disposition  Resolution:  As part of the resolution to issue 7953, a constraint has been added that states each port stereotyped as SWRadioPort has a set of 1 required and 1 provided interface at most.  Since SWRadioPort is the parent for all Port stereotypes defined in the PIM,  by definition, this takes care of the problem addressed in issue 7877.  Hence, issue 7877 should be closed with no change required to the specification, per the resolution for issue 7953.  Revised Text:  N/A  Disposition:	Closed, no change  

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.

Resolution:  As indicated by the issue, the "commitResources" and "releaseResources" are replaced by a per-application "resource commitment" object. This solution aims to minimize the communication between the Execution Manager and the Target Manager, both in terms of the amount of data and the required roundtrips.    First, a data structure "ResourceAllocation" is introduced into the Target Management Model. It identifies a resource by name, and an amount that is being allocated. An application's total set of allocated resources can be expressed as a sequence of this structure.    

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.

Resolution:  Change the text as proposed.  

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

Resolution:  Change the text as proposed  

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.

Resolution:  Change the text as proposed  

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

See issue #7667 for disposition

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.

Resolution:  Change the text as proposed above  

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.

Resolution:  Because of the added complexity, and the low mileage, I propose to remove enumerated properties from the spec.   

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.

Resolution:  Split the "execution parameters" in the Execution Data Model into two sets of parameters to be in sync with the Component Data Model.  

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.

Remove the copies of deployment requirements, in both ArtifactDeploymentDescription and MonolithicDeploymentDescription.

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.

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

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.