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.

No Data Available

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.

Add a prefix "Plan" to all the constants of the PlanLocalityKind enumeration.

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

;

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.

No Data Available

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.

No Data Available

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.

No Data Available

2.3.3 ComponentPackageDescription
2.3.4 ComponentImplementationDescription
There should be a constraint stated for the configproperties? What should
they relate to?

No Data Available

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

No Data Available

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

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

No Data Available

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.

No Data Available

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

;

typedef sequence < SharedResource > SharedResources;

struct Resource

;

typedef sequence < Resource > Resources;

struct Node

;

struct Domain

;

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

;

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.

No Data Available

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.

No Data Available

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?

No Data Available

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

No Data Available

Suggestion is to break ComponentExternalPortEndpoint from
AssemblyConnectionDescription as a separate definition for the assembly
external port definitions

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available