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 7354: XML Schema of Deployment spec doesn't honour constraints present in model Jira Issue DEPL4-1
Issue 7666: Host Collocation Deployment Directive Capability Lacking Jira Issue DEPL4-2
Issue 7734: New Requirement Satisfier Type Jira Issue DEPL4-3
Issue 7735: AssemblyController Component Lacking Jira Issue DEPL4-4
Issue 7736: Component Factory Lacking Jira Issue DEPL4-5
Issue 7737: SatisfierPropertyKind is too Restrictive Jira Issue DEPL4-6
Issue 7738: Locally Managed Capacity Indicator Jira Issue DEPL4-7
Issue 7746: Deployment descriptors Jira Issue DEPL4-8
Issue 8286: ArtifactDeploymentDescription: "node" should be optional Jira Issue DEPL4-9
Issue 9177: Monitor or Verify Lacking in Deployment Process Jira Issue DEPL4-10
Issue 9178: Supports For Many Applications Jira Issue DEPL4-11
Issue 9884: Section: 7.6.1.1-7.6.1.2; 9.10 Jira Issue DEPL4-12
Issue 14088: Add startLaunch also to DomainApplication/NodeApplication Jira Issue DEPL4-13
Issue 17028: Multiplicity of Components::Component::ownedPort ambiguous overview diagram Jira Issue DEPL4-14
Issue 17029: Multiplicity of Components::Component::ownedPort ambiguous Jira Issue DEPL4-15
Issue 17030: Type of Components::ExternalReference::location does not exist Jira Issue DEPL4-16
Issue 17031: Stereotype-property Components::Port::UID ambiguous Jira Issue DEPL4-17
Issue 17032: Ambiguous mulitplicity of Target::CommunicationPath::connectedNode Jira Issue DEPL4-18
Issue 17033: Multiplicity of Target::SharedResource::resourceUser ambiguous Jira Issue DEPL4-19

Issue 7354: XML Schema of Deployment spec doesn't honour constraints present in model (deployment-rtf)

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="https://www.omg.org/Deployment"   xmlns:xmi="https://www.omg.org/XMI"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="https://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" />    

During the meetings and telephone conferences of the RTF it has been agreed that this issue is to be transferred to the MOF2XMI RTF.   The source of this problem (issue #5950) has already been submitted to the MOF2XMI FTF. They acknowledged the problem but decided to close it without change since it would be too much work for them. Now a related issue is popping up again.  

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.    

See issue #7667 for disposition

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.  

During the RTF meetings and telephone conferences the RTF agreed that a concrete use case is needed in order to specify an appropriate resolution for this issue. Since such use case is not yet available this issue is deferred to the next Deployment RTF

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.  

During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be further investigated. Thus, this issue is deferred to the next Deployment RTF.

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

During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be further investigated. Thus, this issue is deferred to the next Deployment RTF

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.  

During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be further investigated. Thus, this issue is deferred to the next Deployment RTF.

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    

During the RTF meetings and telephone conferences the RTF agreed that this issue needs to be further investigated. Thus, this issue is deferred to the next Deployment RTF.

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 >         

This issue asks for additional features for supporting the configuration of dynamically created components during run-time. Since dynamic configuration goes beyond the scope of the current deployment specification, this issue is deferred to a future RFP for dynamic deployment.

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.

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.   

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.   

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.   

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  

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.

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)

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.

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.

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.

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.