Deployment is an iterative process, where changes are needed in the topology model representing the deployment scenario at different stages and across different boundaries of the application life cycle. A topology model allows for the partial abstracted definitions of the unit that can be realized to other partial or concrete definitions of the units of that type through realization link relationships.
Typically, a topology may be defined to abstract and represent a specific concern in the IT system. Such an abstracted topology can then be reused in other topologies by means of imported definitions that can be further customized. The topology model also allows defining a contract in the topology by encapsulating the topology or the elements within a topology. The encapsulation on the element dictates whether it is visible or overridden in the context of the import. The overridden value is then stored with the instance configuration defined for the contract in the importing topology. This allows for the same topology to be imported in multiple topologies and to have override values corresponding to the import instance in each of the importing topology.
Additional semantics usually need to be added to completely define the requirement or to scope the capability of the system. The topology model allows such semantic additions that provide additional validation by the means of a constraint definition. The core platform also contains predefined constraints commonly used in expressing deployment architecture. As an example, the common concept of communication between the two pieces of an IT system is defined as first class link relationships.
The basic concepts defined the concept of capability as the usable ability defined in the IT system. These abilities are usually specialized by domains where additional attributes are defined on these. At times, the set of these attributes may not be fully known at the time of the capability definition in the domain and need to be added later. Topology models allow for such on-the-fly additions through custom attributes defintion.
We will drill down into each of these concepts in the following sections and see examples in action.
At a high level, the model is organized into a set of topologies that contain imports for other topologies, units, and the different relationships that can be expressed through relationship links between the units. Constraints can be added to the unit, requirement, capability, link, or constraint to define the additional need on the target application or environment. Figures 1 and 2 are updated versions of the UML model defined in Part 1, with the new concepts that are discussed in this article.
Figure 1. Updated topology model
Figure 2. Constraint model
A RealizationLink type is used to link a conceptual
unit with another unit (concrete or conceptual) to indicate that the target unit
will replace ("realize") the conceptual unit. It also provides a
way to define a representation for one or more units without forcing the concrete
unit to be selected. It basically holds the relationship between a source unit
that is realized by a target unit. For a topology to be complete, every conceptual
unit within a topology must be realized, where each conceptual unit constraints
the target of the realization link. A realization link is valid when the source
unit type is the same type or super type of the target unit and the capabilities
on the source unit are the subset of the capabilities of the target unit. The
topology is the container for all the realizationlink.
RealizationLink is contributed from the
http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ namespace that is defined in the
topology schema. A realization link instance defined in the topology model is
uniquely identified by its name within the scope of a topology.
Listing 1. Realization Link
<core:unit displayName="Sample
Unit" name="SampleUnit"
conceptual="true"> <generic:capability.generic
displayName="Generic" name="Generic"
linkType="any"/> </core:unit>
<core:unit displayName="ServerUnit1"
name="ServerUnit" conceptual="false">
<generic:capability.generic displayName="Generic"
name="Generic" linkType="any"/>
<j2ee:capability.servletContainer description="This is a j2ee
servlet container capability" displayName="J2ee Servlet
Container Capability" name="j2eeServletContainer"
linkType="hosting"
containerVersion="2.3"/> </core:unit>
<core:link.realization
name="SampleUnitRealizedByServerUnit"
source="/SampleUnit"
target="/ServerUnit"/>
|
Typically, realization links are created across topologies but are not limited to that use. There can be multiple levels of realizations for a conceptual unit in a topology so that the target of the realization is the same type or the subtype of the source unit being realized. You can define a conceptual unit and create its partial capability definition. You can also define all the requirements of that unit so that it can be used in defining the model. As an example, a conceptual server definition may be defined in a topology, and the application components can be hosted on that server based on the capabilities that it provides. At a later time, you can realize the conceptual server to a concrete server that may contain the server instance definition, such as hte installation location, and so forth. As shown in this example, a topology model may be created so that it contains:
- A conceptual ServerUnit of type Unit with
- a J2EEContainer capability with a containerVersion attribute that is not set
- A concrete J2EEServer unit of type J2EEServerUnit with
- a J2EEContainer capability with a containerVersion attribute that is set to 1.4
- a ServletContainer capability with a containerVersion attribute that is set to 2.3
A valid realization link can then be defined between the conceptual ServerUnit and the concrete J2EEServer unit, since ServerUnit's type Unit is the super type of J2EEServerUnit and the target of the realization contains all the capabilities of the realization link source.
Listing 2. Realization link domain example
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2ee="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
description="This is a sample topology describing the anatomy of the
topology model" displayName="Sample Topology"
name="SampleTopology"
decoratorSemantic="com.ibm.ccl.soa.deploy.analysis.ads"
namespace="developerworks.deploy"> <core:unit
description="This is a server unit" conceptual=â€trueâ€
displayName="ServerUnit"
name="ServerUnit">
<j2ee:capability.servletContainer description="This is a j2ee
servlet container capability" displayName="J2ee Servlet
Container Capability" name="j2eeServletContainer"
linkType="hosting"/> </core:unit>
<j2ee:unit.j2eeServerUnit description="This is a J2eeServer unit
" displayName="J2ee Server Unit "
name="J2eeServerUnit"
conceptual="false"> <j2ee:capability.j2eeContainer
description="This is a j2ee container capability"
displayName="J2ee Container Capability"
name="j2eeContainer" linkType="hosting"
containerVersion="1.4"/>
<j2ee:capability.servletContainer description="This is a j2ee
servlet container capability" displayName="J2ee Servlet
Container Capability" name="j2eeServletContainer"
linkType="hosting"
containerVersion="2.3"/>
</j2ee:unit.j2eeServerUnit> <core:link.realization
name="ServerUnitRealizedByJ2eeServerUnit"
source="/ServerUnit"
target="/J2eeServerUnit"/> </core:topology> |
The Import type represents view of an imported topology whose contents are
visible by reference to the topology defining the import. It provides a means for
topology abstraction and reuse for different stages of the deployment by providing
a mechanism for composition of topologies and its contents. The topology is the
container for all the imports defined in that topology. The import is contributed
from the http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ namespace defined in the
topology schema. An import instance defined in the topology model is uniquely
identified by its namespace and name with in the scope of a topology. A re-export attribute can also be defined on the import to
indicate whether the content of the import can be made available for reference
from another topology. An import can be created only to topologies within the same
project within a workspace, and only one import reference can be created for an
imported topology in the importing topology. A displayName can also be defined in the import for visual tools. Each valid
import has a default instance configuration that is defined by the config.topology of type InstanceConfiguration that allows setting and persisting of the
overridden values of the imported content.
Notice that an additional pattern attribute is defined for wildcard substitutions of imports and is reserved for future use. The current implementation of the platform requires the pattern to be same as the name of the import.
Listing 3. Import
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default"/> </core:import> |
The import references also drives a need for encapsulation where you might need to control the visibility of the elements of the topology that can be viewed through an import. The requirement for encapsulation in deployment scenarios is not just limited to control the visibility. You also need to customize an imported reference. As an example, an architect may define a topology where the middleware servers are abstracted to provide the conceptual definitions and later are to be customized to provide the physical information of the instance of these servers. The topology model not only provides an ability to encapsulate but also to customize and augment the content of an imported topology with new attributes, relationships, requirements, and capabilities. These encapsulation settings are used by the validation framework in the core platform to report severity status according to the setting. Errors are downgraded to warnings if the status was reported against a model element that has an encapsulation setting that will allow the problem to be resolved later in the planning process.
The following basic encapsulation types are supported by the topology model that can be defined for the topology or its contents:
- Public: Unit, requirement, or a capability that has this setting within the topology is exposed so that it is visible for linking as the source or target within the importing topology. The property values of the public imported contents cannot be overridden.
- Public-Editable: Unit, requirement, or a capability that has this setting within the topology is exposed so that it is visible for linking as a source or target within the importing topology. The property values of the public-editable imported contents can be overridden.
- Private: Unit, requirement, or a capability that has this setting within the topology is not exposed so that it is not visible for linking as a source or target outside the scope of the topology that contains it.
The contract serves a means to expose the topology contents such as unit,
requirement, or capability to other topologies so that the content can be the
source or target of a link. The contract type is defined in the
http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ namespace as ExplicitContract.
The topology can be associated with the contract to control the default
encapsulation settings of its contents or to selectively tune the encapsulation
setting of its content. The defaultPolicy attribute on
the contract defines the default visibility policy for all the units within the
topology. The defaultConceptualPolicy attribute on the
contract provides an ability to further classify the default visibility policy for
all the conceptual units within the topology. Each contract within a topology is
uniquely identified by its name within the scope of the topology. A topology
author will define an appropriate visibility policy to control how the topology
elements are to be used within another topology by default.
As in the example in Listing 4, a contract is defined so that it encapsulates all of the contents of the topology as private.
Listing 4. Contract
<core:contract.explicit
displayName="Make All Units Private By Default"
name="ExplicitContract1"
defaultConceptualPolicy="private"
defaultPolicy="private"/> |
The contract on the topology can be further customized from the default policy
for the individual content of the topology by using an exported.unit element of
type ExportedUnit. The linkable attribute on this type
specified whether the links can be created to the exported unit, and the
configurable attribute defines whether the properties can be overridden in the
instance of the import. For convenience, encapsulation terms are mapped to these
attributes as Table 1 shows.
Table 1. Encapsulation type
| Type | Linkable | Configurable |
|---|---|---|
| Private | false | false |
| Public | true | false |
| Public-Editable | true | true |
As in the example in Listing 5, a public SampleUnit
defined in the topology is exposed for linking even though the default
policy on the topology contract is private for all contents. The specific
public-editable generic capability on the unit is made available for linking and
configurable through the exported.capability element of type
ExportedCapability. The private requirement r0
on the unit is made unavailable for linking through the exported.requirement
element of type ExportedRequirement so that it is not
available for reference in the importing topology.
Listing 5. Topology encapsulation
<core:unit displayName="Unit"
name="SampleUnit" conceptual="false">
<generic:capability.generic displayName="Generic"
name="Generic" linkType="any"/>
<core:requirement name="r0"
linkType="hosting"/> </core:unit>
<core:contract.explicit displayName="Make All Units Private
By Default" name="ExplicitContract1"
defaultConceptualPolicy="private"
defaultPolicy="private"> <core:exported.unit
configurable="false" linkable="true"
path="/ SampleUnit"> <core:exported.capability
configurable="true" linkable="true"
path="/SampleUnit/Generic"/>
<core:exported.requirement configurable="false"
linkable="false"
path="/SampleUnit/r0"/>
</core:exported.unit> </core:contract.explicit>
|
As discussed above, a unit, capability or the requirement of a topology that is marked public is available for linking in the importing topology. A unit may be marked private while its capability or a requirement can be made public. As in the following example, a topology can define an import for another topology containing a public units(s) or capability(s) or requirement(s). The imported content is then available for linking with in the importing topology with respect to the contract policy defined in the imported topology.
Listing 6. Public import
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default"/> </core:import> |
The properties of the imported topology content can also be overridden for the instance of the import without changing the contents of the referenced topology. This allows for the same topology to be imported in different contexts and provide an instance configuration for the specific import context. The unit, capability, or the requirement of a topology that is marked as public-editable is available for linking, and its properties can be overridden in the importing topology. A unit may be marked as public or private while its capability or the requirement can be made public editable. Listing 7 shows an example of the import with a default instance configuration that relies on the contract policy on the imported topology.
Listing 7. Default import instance configuration
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default"/> </core:import> |
Any public-editable content that is defined in the imported topology can be
modified and the settings are stored in the instance configuration that is
contained in the import definition. As in the Listing 8 example, the displayName property of a public editable unit is
overridden as UnitNameOverride and the new value is stored as a property of the
instantiation element of type Instantiation. Similarly,
the displayName property of a public-editable generic
capability as GenericNameOverride is also overridden by
creating an instantiation for that as shown in Listing 8.
Listing 8. Import instance configuration with override
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default"> <core:instantiation
displayName="SampleUnit"
name="Instantiation1"
referenced="/SampleUnit"> <core:property
select="displayName">UnitNameOverride</core:property>
</core:instantiation> <core:instantiation
displayName="Generic" name="Instantiation2"
referenced="/SampleUnit/Generic"> <core:property
select="displayName">GenericNameOverride</core:property>
</core:instantiation> </core:config.topology>
</core:import> |
The public-editable content is not just limited to override the properties but
also allows for the augmentation of the content with new features. The
augmentation not only allows for the addition of new requirements or capabilities
or constraints on the imported unit but also allows for the addition of new
attributes or constraints on the existing public-editable requirements or
capabilities. As an example (Listing 9), a J2EEContainer
capability is added to the instance of the import for the unit in the
import context, leaving the underlying imported topology untouched.
Listing 9. Import instance configuration with augmentation
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default"> <core:instantiation
displayName="SampleUnit" name="Instantiation1"
referenced="/SampleUnit">
<j2eeDeploy:capability.j2eeContainer displayName="J2EE
Container" name="J2EEContainer"
linkType="any">
</j2eeDeploy:capability.j2eeContainer> <core:property
select="displayName">UnitNameOverride</core:property>
</core:instantiation> <core:instantiation
displayName="Generic" name="Instantiation2"
referenced="/SampleUnit/Generic"> <core:property
select="displayName">GenericNameOverride</core:property>
</core:instantiation> </core:config.topology>
</core:import> |
The import instance can also be re-exported from the topology that defines the
import. The Boolean re-export attribute of the import evaluates its encapsulation
to private when set to false and as public when set to true. The
public-editable content when re-exported via the import is made available only for
linking as public. It is not allowed to be configured in the context of the
topology defining the import for the topology re-exporting the import. Any changes
made to the public-editable content in the topology containing the initial import
are applicable when re-exported. As in the example in Listing 10, the SampleUnit and its generic capability are re-exported
through the import definition. The displayName of the
unit that is be visible to the topology that imports the topology containing this
import will be UnitNameOverride instead of SampleUnit as defined in the underlying topology containing
the definition of the SampleUnit.
Listing 10. Re-Export contents of an import
<core:import displayName="Imported
Topology" mutable="true"
name="ImportedTopology" namespace="dw.ibm"
pattern="ImportedTopology"> <core:config.topology
name="default" reexport="true">
<core:instantiation displayName="SampleUnit"
name="Instantiation1"
referenced="/SampleUnit">
<j2eeDeploy:capability.j2eeContainer displayName="J2EE
Container" name="J2EEContainer"
linkType="any">
</j2eeDeploy:capability.j2eeContainer> <core:property
select="displayName">UnitNameOverride</core:property>
</core:instantiation> <core:instantiation
displayName="Generic" name="Instantiation2"
referenced="/SampleUnit/Generic"> <core:property
select="displayName">GenericNameOverride</core:property>
</core:instantiation> </core:config.topology>
</core:import> |
Typically, an architect may define a set of middleware topologies that can then be reused through topology import by application providers to constrain the developed content. The contract of the middleware topology may define the actual server definitions based on the actual datacenter content, or it may contain an abstracted set of middleware servers that define certain constraints to the application. Later, the abstracted middleware topology can be imported by the data center architect who may then realize the conceptual servers to the concrete server definitions of the datacenter.
As an example, a topology called ImportedTopology may
be defined by an architect so that it contains these elements:
- An explicit contract with
defaultPolicyanddefaultConceptualPolicyas private such that all the units are made private by default contract
- A public conceptual
J2EEServer1definition with a publicJ2EEContainer1capability that hascontainerVersionas 1.3
- A public conceptual
J2EEServer2with a public editableJ2EEContainer2capability that has acontainerVersionset as 1.2
- A conceptual
FutureApplicationServer, the definition of which is yet to be fulfilled by the architect and is private by the default policy of the contract
Another topology, ImportingAppTopology, might then be
defined to contains these elements:
- An explicit contract with
defaultPolicyas false anddefaultConceptualPolicyas public so that all the conceptual units are made public by default contract
- An
EARComponent1that has a hosting requirement on aJ2EEServerthat has a J2EEContainer capability withcontainerVersionequal to 1.3
- An
EARComponent2that has a hosting requirement on aJ2EEServerthat has aJ2EEContainercapability with containerVersion equal to 1.4
Notice that, in ImportingAppTopology, the restriction
on the J2EE container capability for a specific containerVersion is done by using an equals constraint (that is
discussed in a later section here).
Because the two J2EE servers are available for linking in the ImportingAppTopology, the Enterprise Java™Beans (EJB) components
can be hosted by a hosting link on each of these. The Java™ 2 Platform,
Enterprise Edition (J2EE) Server1 provides the required capability of the J2EE
container with the specific version. A host link is created between the EAR
Component1 and the J2EE Server1. Because EAR Component2 requires a
containerVersion 1.4 for the topology to be valid, you need to configure the
public J2EE Server2 so that its J2EE Container2 capability containerVersion is set
to 1.4. You can do that, because the J2EE Container2 is marked as public-editable,
which allows for linking as well as configuration. You cannot link to the private
FutureApplicationServer, because it is neither
linkable nor configurable according to the contract of the
ImportedTopology.
An import instance is defined in ImportingAppTopology
to meet these conditions:
- The re-export attribute on the import is set to True so that the imported
contents are exported in the contract of this topology and made available for
references from another topology that imports
ImportingAppTopology.
- The imported topology has only the J2EE Server1 and J2EE Server2 available for linking.
- The public-editable J2EE Server2 that can configured: The J2EE Container2 capability's
containerVersionproperty is changed to 1.4 and is stored in the instance configuration of the import
- A valid hosting link from EARComponent1 to J2EEServer1.
- A valid hosting link from EARComponent2 to J2EEServer2.
The data center architect can also define a topology called DataCenterTopology that provides the realization of the middleware
servers defined in the ImportingAppTopology so that it
contains these elements (see Listings 11, 12, and 13):
- An explicit contract with defaultPolicy and defaultConceptualPolicy as private such that all the units are made private by default contract
- A concrete J2EEServerConcrete1 with a J2EEContainer capability that has a containerVersion set as 1.3
- A concrete J2EEServerConcrete2 with a J2EEContainer capability that has a containerVersion set as 1.4
- an import instance for the ImportingAppTopology that contains,
- The re-exported J2EEServer1
- The re-exported J2EEServer2
- A valid realization link from the J2EEServer1 to J2EEServerConcrete1
- A valid realization link from the J2EEServer2 to J2EEServerConcrete2, where the J2EEContainer2 capability containerVersion is overridden as 1.4 from 1.2 in context of this import
Listing 11. ImportedTopology.topology
<?xml
version="1.0" encoding="UTF-8"?>
<core:topology
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2ee="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
description="This is a topology that has an explicit contract with unit
level exports and will be used in import from another topology"
displayName="ImportedTopology"
name="ImportedTopology"
namespace="developerworks.deploy">
<j2ee:unit.j2eeServerUnit description="This is a J2EEServer1
unit" displayName="J2EEServer1 Unit"
name="J2EEServer1" conceptual="true">
<j2ee:capability.j2eeContainer description="This is a
J2EEcontainer capability" displayName="J2EEContainer1
Capability" name="J2EEContainer1"
linkType="hosting"
containerVersion="1.3"/>
</j2ee:unit.j2eeServerUnit> <j2ee:unit.j2eeServerUnit
description="This is a J2EEServer2 unit"
displayName="J2EEServer2 Unit"
name="J2EEServer2" conceptual="true">
<j2ee:capability.j2eeContainer description="This is a
J2EEcontainer capability" displayName="J2EEContainer2
Capability" name="J2EEContainer2"
linkType="hosting"
containerVersion="1.2"/>
</j2ee:unit.j2eeServerUnit> <j2ee:unit.j2eeServerUnit
description="This is a FutureApplicationServer unit"
displayName=" FutureApplicationServer Unit"
name="FutureApplicationServer"
conceptual="true">
</j2ee:unit.j2eeServerUnit> <core:contract.explicit
displayName="Make All Units Private By Default"
name="ExplicitContract1"
defaultConceptualPolicy="private"
defaultPolicy="private"> <core:exported.unit
configurable="false" linkable="true"
name="J2EEServer1" path="/J2EEServer1">
<core:exported.capability configurable="false"
linkable="true"
path="/J2EEServer1/J2EEContainer1"/>
</core:exported.unit> <core:exported.unit
configurable="false" linkable="true"
name="J2EEServer2" path="/J2EEServer2">
<core:exported.capability configurable="true"
linkable="true"
path="/J2EEServer2/J2EEContainer2"/>
</core:exported.unit> </core:contract.explicit>
</core:topology> |
Listing 12. ImportingAppTopology.topology
<?xml
version="1.0" encoding="UTF-8"?>
<core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2ee="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
description="This is the topology that imports the ImportedTopology to
illustrate imports" displayName="Importing Application
Topology" name="ImportingAppTopology"
namespace="developerworks.deploy">
<j2ee:component.ear description="This is a EARComponent1 with a
hosting requirement" displayName="EAR Component1"
name="EARComponent1" conceptual="true"
configurationUnit="false"> <core:requirement
description="This is a J2EEContainer hosting requirement"
displayName="J2EE Container Hosting Requirement"
name="r1" dmoType="j2ee:J2EEContainer"
linkType="hosting"> <constraint:constraint.equals
name="c1" attributeName="containerVersion"
value="1.3"/> </core:requirement>
</j2ee:component.ear> <j2ee:component.ear
description="This is a EARComponent2 with a hosting requirement"
displayName="EAR Component2"
name="EARComponent2" conceptual="true"
configurationUnit="false"> <core:requirement
description="This is a J2EEContainer hosting requirement"
displayName="J2EE Container Hosting Requirement"
name="r1" dmoType="j2ee:J2EEContainer"
linkType="hosting"> <constraint:constraint.equals
name="c1" attributeName="containerVersion"
value="1.4"/> </core:requirement>
</j2ee:component.ear> <core:link.hosting
name="J2EEServer1HostsEARComponent1"
source="developerworks.deploy.ImportedTopology:/J2EEServer1"
target="/EARComponent1"/> <core:link.hosting
name="J2EEServer2HostsEARComponent2"
source="developerworks.deploy.ImportedTopology:/J2EEServer2"
target="/EARComponent2"/> <core:import
displayName="ImportedTopology" mutable="true"
name="ImportedTopology"
namespace="developerworks.deploy"
pattern="ImportedTopology"
reexport="true"> <core:config.topology
name="default"> <core:instantiation
displayName="J2EEContainer2 Capability"
name="Instantiation_5303"
referenced="/J2EEServer2/J2EEContainer2">
<core:property
select="containerVersion">1.4</core:property>
</core:instantiation> </core:config.topology>
</core:import> <core:contract.explicit
displayName="Make Conceptual Units Public By Default"
name="ExplicitContract1"/> </core:topology> |
Listing 13. DataCenterTopology.topology
<?xml
version="1.0" encoding="UTF-8"?>
<core:topology
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2ee="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
description="This is a datacentertopology that provides concrete
realizations of the servers in the ImportedTopology"
displayName="DataCenterTopology"
name="DataCenterTopology"
namespace="developerworks.deploy">
<j2ee:unit.j2eeServerUnit description="This is a
J2EEServerConcrete1 unit" displayName="J2EEServerConcrete1
Unit" name=" J2EEServerConcrete1"
conceptual="false"> <j2ee:capability.j2eeContainer
description="This is a J2EEcontainer capability"
displayName="J2EEContainer1 Capability"
name="J2EEContainer1" linkType="hosting"
containerVersion="1.3"/>
</j2ee:unit.j2eeServerUnit> <j2ee:unit.j2eeServerUnit
description="This is a J2EEServerConcrete2 unit"
displayName="J2EEServerConcrete2 Unit"
name="J2EEServerConcrete2"
conceptual="false"> <j2ee:capability.j2eeContainer
description="This is a J2EEcontainer capability"
displayName="J2EEContainer2 Capability"
name="J2EEContainer2" linkType="hosting"
containerVersion="1.4"/>
</j2ee:unit.j2eeServerUnit> <core:link.realization
name="J2EEServer1RealizedBy J2EEServerConcrete1"
source="developerworks.deploy.ImportedTopology:/J2EEServer1"
target="/ J2EEServerConcrete1"/>
<core:link.realization
name="J2EEServer2RealizedByJ2EEServerConcrete2"
source="developerworks.deploy.ImportedTopology:/J2EEServer2"
target="/J2EEServerConcrete2"/> <core:import
displayName="Importing Application Topology"
mutable="true" name="ImportingAppTopology"
namespace="developerworks.deploy"
pattern="ImportingAppTopology">
<core:config.topology name="default"/>
</core:import> <core:contract.explicit
displayName="Make All Units Private By Default"
name="ExplicitContract1"
defaultConceptualPolicy="private"
defaultPolicy="private"/> </core:topology> |
The constraint describes a restriction or rule that can be added to any element of the topology model viz., topology, unit, capability or requirement. The constraint can be aggregated to compose a complex constraint that can then be evaluated by the platform to ensure compliance. A constraint is contributed from the http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/ namespace defined in the topology constraint schema. A constraint instance defined in the topology model is uniquely identified by its name with in the scope of a topology model element that contains the constraint. The evaluation of the constraint is done with the context of model element that owns the constraint. The validation framework in the core platform, allows restricting the ownership of the constraint contribution such that a constraint may only be valid with-in the context of a specific model element type. As an example, the collocation constraint can be valid only on a constraint link, but a range constraint can be valid on a unit, requirement, or a capability.
The platform predefines the commonly used constraints that can be added on the model elements of the topology model. The validation framework in the core platform evaluates these constraints and provides statuses based on the applicability of the constraint.
Version constraint
The semantics of the version constraint restricts the value of any version number
attribute on a unit or a capability to be of specific valid version values such as
6.0, 6.1, 6.1+, and so forth. It can be placed on a unit, a requirement, or a
capability. The validation of this constraint is done in the context of a unit or
a capability. As in the example in Listing 14, the
containerVersion of the J2EE Container is constrained by version
constraint to be 1.4+ (1.4 or later),
Listing 14. Version constraint
<j2eeDeploy:component.ear
description="This is a EARComponent1 with a hosting requirement with a
version constraint of 1.4 or greater" displayName="EAR
Component1" name="EARComponent1"
conceptual="true"
configurationUnit="false"> <core:requirement
description="This is a J2EEContainer hosting requirement with a version
constraint of 1.4 or greater" displayName="J2EE Container
Hosting Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting">
<constraint:constraint.version name="c1"
attributeName="containerVersion"
value="1.4+"/> </core:requirement>
</j2eeDeploy:component.ear> |
Type constraint
The semantics of the Type constraint restricts the type of the topology model
element. The validation of this constraint is done in context of a unit or a
capability. It can be placed on a unit, requirement or a capability. As in the
following example (Listing 15) an EARComponent defines
a requirement that constraint the unit to be hosted on a unit that has a J2EEServer capability,
Listing 15. Type constraint
<j2eeDeploy:component.ear
description="This is a EARComponent2" displayName="EAR
Component2" name="EARComponent2"
conceptual="true"
configurationUnit="false"> <core:requirement
description="This is a J2EEContainer hosting requirement on a unit with a
J2EEServer capability" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting"> <constraint:constraint.type
name="c1"
dmoType="j2eeDeploy:J2EEServer"/>
</core:requirement> </j2eeDeploy:component.ear> |
Enumeration constraint
The semantics of the enumeration constraint restrict the value of an attribute on a unit or a capability to one from the given set of values. It can be placed on a unit, a requirement, or a capability. The validation of this constraint is done in context of a unit or a capability. As in the following example, Listing 16, the target of a hosting requirement is constrained by enumeration constraint to a set of allowed values,
Listing 16. Enumeration constraint
<j2eeDeploy:component.ear
description="This is a EARComponent3" displayName="EAR
Component3" name="EARComponent3"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting">
<constraint:constraint.enumeration name="c1"
attributeName="containerVersion">
<constraint:value value="1.2"/>
<constraint:value value="1.3"/>
<constraint:value value="1.4"/>
</constraint:constraint.enumeration>
</core:requirement> </j2eeDeploy:component.ear> |
Exclusion constraint
The semantics of the exclusion constraint restricts the value of an attribute on a unit or a capability not to be one of the given set of values. It can be placed on a unit, a requirement, or a capability. The validation of this constraint is done in context of a unit or a capability. As in Listing 17, the containerVersion of the J2EEContainer is constrained by exclusion constraint to exclude a set of values,
Listing 17. Exclusion constraint
<j2eeDeploy:component.ear
description="This is a EARComponent4" displayName="EAR
Component4" name="EARComponent4"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting">
<constraint:constraint.exclusion name="c1"
attributeName="containerVersion">
<constraint:value value="1.2"/>
<constraint:value value="1.3"/>
</constraint:constraint.exclusion>
</core:requirement> </j2eeDeploy:component.ear> |
Range constraint
The semantics of the range constraint restricts the value of any comparable
attribute (may be nonnumerical) on a unit or a capability to be in the given
range. It can be placed on a unit, a requirement, or a capability. The validation
of this constraint is done in context of a unit or a capability. As in Listing 18,
the containerVersion of the J2EE container is
constrained bythe range constraint to a range of allowed values,
Listing 18. Range constraint
<j2eeDeploy:component.ear
description="This is a EARComponent5" displayName="EAR
Component5" name="EARComponent5"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting">
<constraint:constraint.range name="c1"
attributeName="containerVersion"
maxValue="1.4" maxValueInclusive="true"
minValue="1.2"
minValueInclusive="true"/>
</core:requirement> </j2eeDeploy:component.ear> |
Group cardinality constraint
The semantics of the Group Cardinality constraint restricts the maximum or the
minimum number of a unit type to which the given unit can be member. The
validation of this constraint is done in the context of a unit that contains the
requirement that containing the constraint. It can be placed on membership type of
requirement. As Listing 19 shows, an EJB component defines a requirement that
constrains the unit to member of one or many EAR components (j2eeDeploy:EarModule).
Listing 19. Group cardinality constraint
<j2eeDeploy:component.ejb
displayName="EJB Component"
name="EJBComponent1"
conceptual="false"> <core:requirement
name="r0" dmoType="j2eeDeploy:EarModule"
linkType="member">
<constraint:constraint.groupCardinality name="c1"
minValue="1"/> </core:requirement>
</j2eeDeploy:component.ejb> |
Member cardinality constraint
The semantics of the Member Cardinality constraint restricts the maximum or the
minimum number of a unit that can be member of a given unit. The validation of
this constraint is done in context of a unit that contains the requirement
containing the constraint. It can be placed on membership type of requirement. As
in the following example, Listing 20, an EAR component defines a requirement that
constrains the unit to have only one member unit of type WebComponent (j2eeDeploy:WebModule),
Listing 20. Member cardinality constraint
<j2eeDeploy:component.ear
description="This is a EARComponent6" displayName="EAR
Component6" name="EARComponent6"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting"/> <core:requirement
name="r0" dmoType="j2eeDeploy:WebModule"
linkType="member">
<constraint:constraint.memberCardinality name="c1"
maxValue="1" minValue="1"/>
</core:requirement> </j2eeDeploy:component.ear> |
Attribute propagation constraint
The semantics of the attribute propagation constraint restricts the value of the
source attribute on a capability to be the same as the attribute defined on the
capability on that unit. The validation of this constraint is done in the context
of a unit that contains the constraint. The respectLinkDirection attribute if set to true than the value of the
source acts as the master value to be used. It can be placed on a unit or a
constraint link. As in Listing 21, a Unit1 defines a
constraint so that the value of the attr1 on capability1 should always be consistent with the attr2 on capability2.
Listing 21. Attribute propagation constraint
<core:unit
displayName="Unit1" name="Unit_8944"
conceptual="false">
<constraint:constraint.attributePropagation
name="c_2246" respectLinkDirection="false"
sourceAttributeName="attr1"
sourceObjectURI="Generic"
targetAttributeName="attr2"
targetObjectURI="Capability_9898"/>
<generic:capability.generic displayName="Capability1"
name="Generic" linkType="any">
<core:extendedAttribute name="attr1">
<core:data
xsi:type="xsd:string">a</core:data>
</core:extendedAttribute>
</generic:capability.generic> <core:capability
displayName="Capability2"
name="Capability_9898" linkType="any">
<core:extendedAttribute name="attr2">
<core:data
xsi:type="xsd:string"></core:data>
</core:extendedAttribute> </core:capability>
</core:unit> |
Attribute-defined constraint
The semantics of the attribute constraint restricts that the attribute value must
be defined in the concrete final realization of the conceptual unit defining the
constraint. The validation of this constraint is done in the context of a unit or
a capability that defines the constraint. It can be placed on a unit or a
capability. As in the Listing 22 example, a SampleUnit
defines a attribute-defined constraint for publishIntent that must have a value defined in the realization target
RealizedSampleUnit.
Listing 22. Attribute-defined constraint
<core:unit
displayName="SampleUnit" name="SampleUnit"
conceptual="true">
<constraint:constraint.attrdef name="c1"
attributeName="publishIntent"/>
<generic:capability.generic displayName="Generic"
name="Generic" linkType="any"/>
</core:unit> <core:unit
displayName="RealizedSampleUnit"
name="RealizedSampleUnit"
conceptual="false"> <generic:capability.generic
displayName="Generic" name="Generic"
linkType="any"/> </core:unit>
<core:link.realization
name="SampleUnitRealizedByRealizedSampleUnit"
source="/SampleUnit"
target="/RealizedSampleUnit"/> |
OR constraint
The semantics of the OR constraint represent the Boolean operator OR that is performed on the child constraints. It allows building complex constraint expressions from other constraints. It can be placed on any topology model element except an OR constraint. The validation of this constraint is not restricted to any model element type and is used to validate child constraints. As in the following example an EARComponent defines a requirement that constrains the unit to be hosted on a server with a J2EEContainer capability with containerVersion equal to 1.3 or 1.4,
Listing 23. OR constraint
<j2eeDeploy:component.ear
description="This is a EARComponent7" displayName="EAR
Component7" name="EARComponent7"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting"> <constraint:constraint.or
name="c1"> <constraint:constraint.version
name="c2" attributeName="containerVersion"
value="1.3"/> <constraint:constraint.version
name="c3" attributeName="containerVersion"
value="1.4"/>
</constraint:constraint.or> </core:requirement>
</j2eeDeploy:component.ear> |
AND constraint
The semantics of the AND constraint represent the Boolean operator AND that is
performed on the child constraints. It allows building complex constraint
expressions from other constraints. It can be placed on the OR, NOT, or XOR
constraint. The validation of this constraint is not restricted to any model
element type and is used to validate child constraints. As Listing 24 shows, an
EAR component defines a requirement that constrains the unit to be hosted on a
unit with a J2EE server hosting capability and has a J2EE container capability
with container version equal to 1.4 and a ServletContainer
capability with the container version equal to 2.2.
Listing 24. AND constraint
<j2eeDeploy:component.ear
description="This is a EARComponent8" displayName="EAR
Component8" name="EARComponent8"
conceptual="true"
configurationUnit="false"> <core:requirement
displayName="hosting requirement" name="r0"
dmoType="j2eeDeploy:ServletContainer"
linkType="hosting"> <constraint:constraint.type
name="c1"
dmoType="j2eeDeploy:J2EEServer">
<constraint:constraint.type name="c2"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version name="c3"
attributeName="containerVersion"
value="1.4"/>
</constraint:constraint.type> <constraint:constraint.type
name="c4"
dmoType="j2eeDeploy:ServletContainer">
<constraint:constraint.version name="c5"
attributeName="containerVersion"
value="2.2"/>
</constraint:constraint.type>
</constraint:constraint.type>
</core:requirement> </j2eeDeploy:component.ear> |
XOR constraint
The semantics of the XOR constraint represent the Boolean operator XOR that is
performed on the child constraints. At least one child constraint must be present
for this constraint to be valid. It allows building complex constraint expressions
from other constraints. It can be placed on any topology model element. The
validation of this constraint is not restricted to any model element type and is
used to validate child constraints. As in the example in Listing 25, an EARComponent defines a requirement that constrains the
unit to be hosted on a server that does not have a J2EEContainer capability with container version equal to 1.2 and a ServletContainer capability with the container version
greater than 2.2,
Listing 25. XOR constraint
<j2eeDeploy:component.ear
description="This is a EARComponent9" displayName="EAR
Component9" name="EARComponent9"
conceptual="true"
configurationUnit="false"> <core:requirement
name="r0" dmoType="j2eeDeploy:J2EEServer"
linkType="hosting"> <constraint:constraint.xor
name="c1"> <constraint:constraint.type
name="c2"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version name="c3"
attributeName="containerVersion"
value="1.2"/>
</constraint:constraint.type> <constraint:constraint.type
name="c4"
dmoType="j2eeDeploy:ServletContainer">
<constraint:constraint.version name="c5"
attributeName="containerVersion"
value="2.2"/>
</constraint:constraint.type>
</constraint:constraint.xor> </core:requirement>
</j2eeDeploy:component.ear> |
NOT constraint
The semantics of the NOT constraint represent the Boolean operator NOT that is
performed on the child constraints. Only one child constraint must be present for
this constraint to be valid. It allows building complex constraint expressions
from other constraints. It can be placed on any topology model element except a
NOT constraint. The validation of this constraint is not restricted to any model
element type and is used to validate child constraints. As in the following
example (Listing 26) an EARComponent defines a
requirement that constrains the unit to be hosted on a server that does not have
a J2EEContainer capability with
containerVersion equal to 1.3,
Listing 26. NOT constraint
<j2eeDeploy:component.ear
description="This is a EARComponent10" displayName="EAR
Component10" name="EARComponent10"
conceptual="true"
configurationUnit="false"> <core:requirement
description="" displayName="J2EE Container Hosting
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEContainer"
linkType="hosting"> <constraint:constraint.or
name="c1"> <constraint:constraint.not
name="c2"> <constraint:constraint.version
name="c3" attributeName="containerVersion"
value="1.3"/>
</constraint:constraint.not>
</constraint:constraint.or> </core:requirement>
</j2eeDeploy:component.ear> |
An architect can define a middleware topology that constrains the application components targeted to the servers in that topology. The server definitions may be restricted for specific versions using the version constraint or types using the type constraints. Complex constraints may be composed on these servers to serve the need for multiple targets. Later, the data center architect may realize different versions of this topology, depending on the application components that need to be deployed in the data center.
As an example, a SampleConstraintTopology could be
defined by an architect to contain these elements:
- A conceptual J2EE server that has:
- a J2EE container capability with a range constraint for the container version greater than or equal to 1.3
- A conceptual EAR component that has:
- A
WebModuleCapabilityof member type with member cardinality constraint that allows for a 0 or 2147483647 number of Web components - A hosting requirement of type
J2EEContainerwith a version greater than or equal to 1.4 - A requirement for a
J2EEDatasourcewith an equals constraint for thejndiNameto be "jndi/default"
- A
Listing 27. Constraint domain example
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
description="Created on Sunday, November 23, 2008 2:29:14 PM
EST" displayName="SampleConstraintTopology"
name="SampleConstraintTopology"
namespace="developerworks.deploy">
<j2eeDeploy:unit.j2eeServerUnit displayName="J2EE
Server1" name="J2EEServer1"
conceptual="true">
<j2eeDeploy:capability.j2eeContainer displayName="J2EE
Container" name="J2EE Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="1.3"
minValueInclusive="true"/>
</j2eeDeploy:capability.j2eeContainer>
</j2eeDeploy:unit.j2eeServerUnit> <j2eeDeploy:component.ear
displayName="EAR Component"
name="EarModule_5031" conceptual="true"
initInstallState="not_installed"
publishIntent="publish">
<j2eeDeploy:capability.earModule displayName="EAR
Component" name="EARComponent0"
linkType="dependency" id="EARComponent"
version="1.0"/> <core:requirement
displayName="Web Component"
name="WebComponent"
dmoType="j2eeDeploy:WebModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement name="Hosting
Requirement" linkType="hosting"
use="required"> <constraint:constraint.type
displayName="c1" name="c1"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="1.4+"/>
</constraint:constraint.type> </core:requirement>
<core:requirement displayName="J2EEDataSource
Requirement" name="r1"
dmoType="j2eeDeploy:J2EEDatasource">
<constraint:constraint.equals name="c1"
attributeName="jndiName"
value="jndi/default"/> </core:requirement>
</j2eeDeploy:component.ear> </core:topology> |
A ConstraintLink type is used to constrain the source
and the target unit based on the semantics of the child constraint placed on it.
The validation framework defined in the platform evaluates the constraints defined
on the constraint link and provides the status of the validity of the constraint.
The source of the link is the container of the constraint link. ConstraintLink is contributed from the
http://www.ibm.com/ccl/soa/deploy/core/1.0.0/ namespace defined in the topology
schema. A constraint link instance defined in the topology model is uniquely
identified by its name with in the scope of its container. Different types of
constraint links can be defined by using the predefined constraints that can be
placed on the constraint link. As in the example in Listing 28, a Collocation
constraint link is created between the two units as defined by the collocation
child constraint on the constraint link.
Listing 28. Constraint link
<core:unit
displayName="Unit1" name="Unit1"
conceptual="true"> <generic:capability.generic
displayName="Generic" name="Generic"
linkType="any"/> <core:link.constraint
name="cl1" source="/Unit1"
target="/Unit2">
<constraint:constraint.collocation name="c1"
capabilityType="core:Capability"
type="collocation"/>
</core:link.constraint> </core:unit>
<core:unit displayName="Unit2"
name="Unit2" conceptual="true">
<generic:capability.generic displayName="Generic"
name="Generic" linkType="any"/>
</core:unit> |
'
Similarly, other types of constraint links can be created by placing the Anti-Collocation, ApplicationCommunication, NetworkCommunication, HostingCapacity, or DeferredHosting constraint on the constraint link.
The semantics of the collocation constraint ensure that the source and the target unit of the link should be collocated at a certain level of their hosting stacks based on the test of a selected capability type. The constraint is valid if a capability of the specified type exists in the hosting stacks of both units, and every unit with such capability in the either hosting stack belongs to both hosting stacks. It can only be placed on a dependency or a constraint link. The validation of this constraint is restricted to dependency or a constraint link. As in the following example, Listing 29, a Web component and an EJB component are defined with the collocation constraint link so that these are hosted on the same J2EE server,
Listing 29. Collocation constraint link
<?xml
version="1.0" encoding="UTF-8"?>
<core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
description="Sample Topology"
displayName="CollocationLink"
name="CollocationLink"
namespace="developerworks.deploy">
<j2eeDeploy:component.ejb displayName="EJB Component"
name="EJBComponent" conceptual="falseâ€>
<j2eeDeploy:capability.ejbModule displayName="EJB
Component" name="EJBComponent0"
linkType="dependency" id="EJBComponent"
version="1.0"/> </j2eeDeploy:component.ejb>
<j2eeDeploy:component.web displayName="Web Component"
name="WebComponent†conceptual="falseâ€>
<j2eeDeploy:capability.webModule displayName="Web
Component" name="WebComponent0"
linkType="dependency" id="WebComponent"
version="1.0" contextRoot=""/>
<core:link.constraint name="cl1"
source="/WebComponent"
target="/EJBComponent">
<constraint:constraint.collocation name="c1"
capabilityType="core:Capability"
type="collocation"/>
</core:link.constraint>
</j2eeDeploy:component.web> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract1"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
Anti- Collocation constraint link
The semantics of the Anti-Collocation constraint ensures that the source and the target unit of the link should not be collocated at a certain level of their hosting stacks based on the test of a selected capability type. The constraint is valid if every unit with a capability of the specified type does not exist in the hosting stacks of other units. It can be placed only on a dependency or a constraint link. The validation of this constraint is restricted to dependency or a constraint link. As in Listing 30, a Web component and an EJB component aredefined with the Anti-Collocation constraint link so that these are not hosted on the same J2EE server,
Listing 30. Anti-Collocation constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
description="Sample Topology"
displayName="AntiCollocationLink"
name="AntiCollocationLink"
namespace="developerworks.deploy">
<j2eeDeploy:component.ejb displayName="EJB Component"
name="EJBComponent" conceptual="falseâ€>
<j2eeDeploy:capability.ejbModule displayName="EJB
Component" name="EJBComponent0"
linkType="dependency" id="EJBComponent"
version="1.0"/> </j2eeDeploy:component.ejb>
<j2eeDeploy:component.web displayName="Web Component"
name="WebComponent†conceptual="falseâ€>
<j2eeDeploy:capability.webModule displayName="Web
Component" name="WebComponent0"
linkType="dependency" id="WebComponent"
version="1.0" contextRoot=""/>
<core:link.constraint name="cl1"
source="/WebComponent"
target="/EJBComponent">
<constraint:constraint.collocation name="c1"
capabilityType="core:Capability"
type="anticollocation"/>
</core:link.constraint>
</j2eeDeploy:component.web> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract1"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
Deferred hosting constraint link
The semantics of the deferred hosting constraint ensure that a given unit will be hosted either directly or indirectly on another unit allowing for elements in the hosting stack to be omitted. The constraint is valid if host unit belong to the hosting stack of the hostee unit. It can be placed only on a dependency or a constraint link where the hostee is the source of the link and the host is the target of the link. The validation of this constraint is restricted to a dependency or a constraint link. As in Listing 31, a Web component is defined to have a deferred hosting link to a J2EE server where the actual hosting link is created between the EAR component that has the Web component as the member and the target J2EE server.
Listing 31. Defered hosting constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:javaDeploy="http://www.ibm.com/ccl/soa/deploy/java/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
description="Sample Topology"
displayName="DefferedHostinkLink"
name="DefferedHostinkLink"
namespace="developerworks.deploy">
<j2eeDeploy:unit.j2eeServerUnit displayName="J2EE 1.3 Application
Server" name="J2EEServerUnit_7328"
conceptual="true">
<j2eeDeploy:capability.j2eeContainer displayName="J2EE
Container" name="J2EE Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="1.3"
minValueInclusive="true"/>
</j2eeDeploy:capability.j2eeContainer>
<j2eeDeploy:capability.servletContainer displayName="Servlet
Container" name="Servlet Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="2.3"
minValueInclusive="true"/>
</j2eeDeploy:capability.servletContainer>
<j2eeDeploy:capability.jspContainer displayName="JSP
Container" name="JSP Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="1.2"
minValueInclusive="true"/>
</j2eeDeploy:capability.jspContainer>
<j2eeDeploy:capability.ejbContainer displayName="EJB
Container" name="EJB Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="2.0"
minValueInclusive="true"/>
</j2eeDeploy:capability.ejbContainer>
<j2eeDeploy:capability.jcaContainer displayName="JCA
Container" name="JCA Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="1.0"
minValueInclusive="true"/>
</j2eeDeploy:capability.jcaContainer>
<j2eeDeploy:capability.j2eeServer displayName="J2EE
Server" name="J2EE Server"
linkType="any"/> <javaDeploy:capability.jre
description="" displayName="java JRE"
name="java.JRE" linkType="any">
<constraint:constraint.range name="c0"
attributeName="jreVersion" minValue="1.3"
minValueInclusive="true"/>
</javaDeploy:capability.jre> <core:link.hosting
name="J2EEServerUnit_7328HostsEarModule_2860"
source="/J2EEServerUnit_7328"
target="/EarModule_2860"/>
</j2eeDeploy:unit.j2eeServerUnit> <j2eeDeploy:component.ejb
displayName="EJB Component"
name="EjbModule_4565" conceptual="false"
initInstallState="not_installed"
publishIntent="publish">
<j2eeDeploy:capability.ejbModule displayName="EJB
Component" name="EJBComponent0"
linkType="dependency" id="EJBComponent"
version="1.0"/> <core:requirement
name="Hosting Requirement" linkType="hosting"
use="required"> <constraint:constraint.type
displayName="ejbService_20"
name="ejbService_20"
dmoType="j2eeDeploy:EJBContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="2.0+"/>
</constraint:constraint.type> <constraint:constraint.type
displayName="j2eeService_13"
name="j2eeService_13"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="1.3+"/>
</constraint:constraint.type> </core:requirement>
<core:requirement displayName="May Have Related File
Content" name="r0"
dmoType="os:FileSystemContentUnit"
linkType="member" use="optional"/>
</j2eeDeploy:component.ejb> <j2eeDeploy:component.web
displayName="Web Component"
name="WebModule_8934" conceptual="false"
initInstallState="not_installed"
publishIntent="publish">
<j2eeDeploy:capability.webModule displayName="Web
Component" name="WebComponent0"
linkType="dependency" id="WebComponent"
version="1.0" contextRoot=""/>
<core:requirement name="Hosting Requirement"
linkType="hosting" use="required">
<constraint:constraint.type
displayName="servletService_22"
name="servletService_22"
dmoType="j2eeDeploy:ServletContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="2.2+"/>
</constraint:constraint.type> <constraint:constraint.type
displayName="jspService_11"
name="jspService_11"
dmoType="j2eeDeploy:JSPContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="1.1+"/>
</constraint:constraint.type> </core:requirement>
<core:requirement displayName="Utility Jar Components"
name="ContainedUtilityJarComponents"
dmoType="j2eeDeploy:JarModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement
displayName="May Have Related File Content"
name="r0" dmoType="os:FileSystemContentUnit"
linkType="member" use="optional"/>
<core:link.constraint name="cl1"
source="/WebModule_8934"
target="/J2EEServerUnit_7328">
<constraint:constraint.deferredHosting
name="c1"/> </core:link.constraint>
</j2eeDeploy:component.web> <j2eeDeploy:component.ear
displayName="EAR Component"
name="EarModule_2860" conceptual="false"
initInstallState="not_installed"
publishIntent="publish">
<j2eeDeploy:capability.earModule displayName="EAR
Component" name="EARComponent0"
linkType="dependency" id="EARComponent"
version="1.0"/> <core:requirement
displayName="JCA Connector Components"
name="ContainedJCAComponents"
dmoType="j2eeDeploy:JCAModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement
displayName="Application Client Components"
name="ContainedAppClientComponents"
dmoType="j2eeDeploy:AppClient"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement
displayName="Utility Jar Components"
name="ContainedUtilityJarComponents"
dmoType="j2eeDeploy:JarModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement
displayName="EJB Components"
name="ContainedEjbComponents"
dmoType="j2eeDeploy:EjbModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement
displayName="Web Components"
name="ContainedWebComponents"
dmoType="j2eeDeploy:WebModule"
linkType="member" use="required">
<constraint:constraint.memberCardinality
displayName="AllowedNumberOfMembers"
name="AllowedNumberOfMembers"
maxValue="2147483647" minValue="0"/>
</core:requirement> <core:requirement name="Hosting
Requirement" linkType="hosting"
use="required"> <constraint:constraint.type
displayName="j2eeService_14"
name="j2eeService_14"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="1.4+"/>
</constraint:constraint.type> </core:requirement>
<core:requirement displayName="May Have Related File
Content" name="r0"
dmoType="os:FileSystemContentUnit"
linkType="member" use="optional"/>
<core:link.member
name="EarModule_2860ContainsEjbModule_4565"
source="/EarModule_2860"
target="/EjbModule_4565"/> <core:link.member
name="EarModule_2860ContainsWebModule_8934"
source="/EarModule_2860"
target="/WebModule_8934"/>
</j2eeDeploy:component.ear> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract_3492"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
Network Communication constraint link
The semantics of the Network Communication constraint ensure that two units must
support communication without fully defining the elements necessary to support the
communication. The constraint is valid if the source and the target of the link
have valid network communication defined. It can be placed only on a dependency or
a constraint link. The validation of this constraint is restricted to dependency
or a constraint link. As in the following example, a J2EEServer1 is defined to have a Network Communication constraint link
to a J2EEServer2.
Listing 32. Network communication constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:javaDeploy="http://www.ibm.com/ccl/soa/deploy/java/1.0.0/"
description="Sample Topology"
displayName="NetworkCommunicationLink"
name="NetworkCommunicationLink"
namespace="developerworks.deploy">
<j2eeDeploy:unit.j2eeServerUnit displayName="J2EEServer1"
name="J2EEServer1" conceptual="true">
<core:link.constraint name="cl1"
source="/J2EEServer1"
target="/J2EEServer2">
<constraint:constraint.networkcommunication
name="c1"/> </core:link.constraint>
</j2eeDeploy:unit.j2eeServerUnit>
<j2eeDeploy:unit.j2eeServerUnit displayName="J2EEServer2"
name="J2EEServer2†conceptual="true">
</j2eeDeploy:unit.j2eeServerUnit> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract_8829"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
Application Communication constraint link
The semantics of the application communication constraint ensure that two application units must support communication without fully defining the elements necessary to support the communication. The constraint is valid if the source and the target of the link have valid application communication defined. It can be placed only on a dependency or a constraint link. The validation of this constraint is restricted to a dependency or a constraint link. As in Listing 33, a Web component is defined to have an application communication constraint link to an EJB component.
Listing 33. Application communication constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
description="Sample Topology"
displayName="ApplicationCommunicationLink"
name="ApplicationCommunicationLink"
namespace="developerworks.deploy">
<j2eeDeploy:component.ejb displayName="EJB Component"
name="EJBComponent" conceptual="falseâ€>
</j2eeDeploy:component.ejb> <j2eeDeploy:component.web
displayName="Web Component"
name="WebComponent" conceptual="falseâ€>
<core:link.constraint name="cl1"
source="/WebComponent"
target="/EJBComponent">
<constraint:constraint.applicationcommunication
name="c1"/> </core:link.constraint>
</j2eeDeploy:component.web> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract1"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
Attribute Propagation constraint link
The semantics of the Attribute Propagation constraint restrict the value of the
source attribute on a unit or a capability to be same as the attribute defined on
the target unit or a capability. The validation of this constraint is done in the
context of a unit that is the target of the constraint. The respectLinkDirection attribute if set to true than the value of the
source acts as the master value to be used. As in Listing 34, a Unit2 defines a constraint link with an attribute
propagation constraint such that the value of the displayName on Unit2 should always be
consistent with the displayName on Unit3,
Listing 34. Attribute propagation constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:generic="http://www.ibm.com/ccl/soa/deploy/generic/1.0.0/"
description="Created on Tuesday, November 25, 2008 4:24:24 PM
EST" displayName="AttributePropagationConstraintLink"
name="AttributePropagationConstraintLink"
namespace="developerworks.deploy"> <core:unit
displayName="Unit2" name="Unit2"
conceptual="false"> <generic:capability.generic
displayName="Generic" name="Generic"
linkType="any"/> <core:link.constraint
name="cl1" source="/Unit2"
target="/Unit3">
<constraint:constraint.attributePropagation name="c1"
sourceAttributeName="displayName"
targetAttributeName="displayName"/>
</core:link.constraint> </core:unit>
<core:unit displayName="Unit3"
name="Unit3" conceptual="false">
<generic:capability.generic displayName="Generic"
name="Generic" linkType="any"/>
</core:unit> </core:topology> |
Hosting Capacity constraint link
The semantics of the Hosting Capacity constraint describe capacity requirements
on the target in the hosting stack that can be met when many hostees compete for
resources. The validation of this constraint is done in the context of a unit that
defines the constraint. It can be placed on a unit or a constraint link. The
exclusive attribute determines whether the value given for the capacity attribute
must be exclusively allocated to this constraint or may be shared among others. As
in Listing 35, the EAR component defines the capacity requirement on its host
J2EEServerUnit that is than validated exclusively
against the final host, X86Server. In the following sample, the validation of the
constraint fails as the memorySize of 128 mega bytes
defined on the X86Server unit does not fulfill the capacity requirement of 256
megabytes defined on the EARComponent.
Listing 35. Hosting capacity constraint link
<?xml version="1.0"
encoding="UTF-8"?> <core:topology
xmlns:constraint="http://www.ibm.com/ccl/soa/deploy/core/constraint/1.0.0/"
xmlns:core="http://www.ibm.com/ccl/soa/deploy/core/1.0.0/"
xmlns:j2eeDeploy="http://www.ibm.com/ccl/soa/deploy/j2ee/1.0.0/"
xmlns:javaDeploy="http://www.ibm.com/ccl/soa/deploy/java/1.0.0/"
xmlns:os="http://www.ibm.com/ccl/soa/deploy/os/1.0.0/"
xmlns:server="http://www.ibm.com/ccl/soa/deploy/server/1.0.0/"
description="Created on Sunday, November 23, 2008 7:50:20 PM
EST" displayName="HostingCapacityLink"
name="HostingCapacityLink"
namespace="developerworks.deploy">
<j2eeDeploy:component.ear displayName="EAR Component"
name="EARComponent" conceptual="false"
initInstallState="not_installed"
publishIntent="publish">
<j2eeDeploy:capability.earModule displayName="EAR
Component" name="EARComponent0"
linkType="dependency" id="EARComponent"
version="1.0"/> <core:requirement
name="Hosting Requirement" linkType="hosting"
use="required"> <constraint:constraint.type
displayName="j2eeService_14"
name="j2eeService_14"
dmoType="j2eeDeploy:J2EEContainer">
<constraint:constraint.version
displayName="VersionSpecification"
name="VersionSpecification"
attributeName="containerVersion"
value="1.4+"/>
</constraint:constraint.type> </core:requirement>
<core:link.constraint name="cl1"
source="/EARComponent"
target="/J2EEServerUnit">
<constraint:constraint.capacity displayName="Capacity
Constraint" name="c1"
dmoType="server:Server">
<constraint:constraint.capacityRestriction name="c1"
attributeName="memorySize" exclusive="true"
value="256"/>
</constraint:constraint.capacity>
</core:link.constraint>
</j2eeDeploy:component.ear> <j2eeDeploy:unit.j2eeServerUnit
displayName="J2EEServerUnit"
name="J2EEServerUnit"
conceptual="true">
<j2eeDeploy:capability.j2eeContainer displayName="J2EE
Container" name="J2EE Container"
linkType="any"> <constraint:constraint.range
name="c0" attributeName="containerVersion"
minValue="1.3"
minValueInclusive="true"/>
</j2eeDeploy:capability.j2eeContainer>
<j2eeDeploy:capability.j2eeServer displayName="J2EE
Server" name="J2EE Server"
linkType="any"/> <core:requirement
name="r0" dmoType="os:WindowsOperatingSystem"
linkType="hosting"/> <core:link.hosting
name="J2EEServerUnitHostsEARComponent"
source="/J2EEServerUnit"
target="/EARComponent"/>
</j2eeDeploy:unit.j2eeServerUnit>
<os:unit.windowsOperatingSystemUnit
name="WindowsOperatingSystemUnit"
conceptual="true">
<os:capability.windowsOperatingSystem displayName="Windows
2000" name="Windows2000"
linkType="any" os.type="Windows"
os.version="2000"/> <core:requirement
displayName="Server" mutable="true"
name="Server" dmoType="server:Server"
linkType="hosting"> <constraint:constraint.equals
displayName="cpuArchitecture"
name="cpuArchitecture"
attributeName="cpuArchitecture"
value="intel"/> </core:requirement>
<core:link.hosting
name="WindowsOperatingSystemUnitHostsJ2EEServerUnit"
source="/WindowsOperatingSystemUnit"
target="/J2EEServerUnit"/>
</os:unit.windowsOperatingSystemUnit> <server:unit.serverUnit
displayName="x86 Server"
name="x86ServerUnit"> <server:capability.server
displayName="x86 Server" name="x86Server"
linkType="any" cpu.architecture="intel"
cpu.count="1" memory.size="128">
<core:attributeMetaData attributeName="cpu.architecture"
mutable="false"/>
</server:capability.server> <core:link.hosting
name="x86ServerUnitHostsWindowsOperatingSystemUnit"
source="/x86ServerUnit"
target="/WindowsOperatingSystemUnit"/>
</server:unit.serverUnit> <core:contract.explicit
displayName="Make All Units Public-Editable By Default"
name="ExplicitContract1"
defaultConceptualPolicy="public_editable"
defaultPolicy="public_editable"/>
</core:topology> |
The topology model also allows for the addition of the variables on the topology that can be referenced inside of the topology, and their values can be substituted later when the topology is imported. The topology variable is defined in the contract of the topology as Listing 36 shows.
Listing 36. Topology variable definition
<core:contract.explicit
displayName="Make All Units Public By Default"
name="ExplicitContract1"
defaultConceptualPolicy="public"
defaultPolicy="public"> <core:property
name="serverName"/>
</core:contract.explicit> |
The serverName variable can then be used in the scope of this topology as $serverName and be substituted with a value when the topology is imported elsewhere, for the scope of the import.
The topology model also allows for the addition of custom attributes in the
capabilities so that the capability definitions are not just limited by the
domain. This provides the utmost flexibility in defining the topology model so
that the model can be made aware of the new content with respect to the topology
definition. The scope of the use of these custom attributes is not limited in
any way and can be used in the constraints or contracts. These custom attributes
can also be defined with an understanding with the deployer of the contents of the
topology, who may then act upon these attributes outside of the content defined by
the domain contributor. As Listing 37 shows, a newCustomAttrib is defined
as a string on the generic capability of the unit.
Listing 37. Custom attribute definition
<core:unit
displayName="Unit3" name="Unit_1228"
conceptual="false"> <generic:capability.generic
displayName="Generic" name="Generic"
linkType="any"> <core:attributeMetaData
attributeName="newCustomAttrb"
mutable="true" parameter="true"/>
<core:extendedAttribute name="newCustomAttrb">
<core:data
xsi:type="xsd:string"></core:data>
</core:extendedAttribute>
</generic:capability.generic> </core:unit> |
This second part of the series discussed the advanced concepts of the topology model used in Rational Software Architect deployment architecture platform. Several sample topologies were created to illustrate the usage and significance of import for topology reuse and abstraction. The new types of relationships including, realization links and constraint links, were explained. A sample J2EE domain was used to address the use and semantics of the predefined constraint types, along with constraint links that are available in the platform.
Stay tuned for the next part in the series, that shows how to create the topology and address the concepts discussed so far, using the topology editor available in Rational Software Architect 7.5.
| Description | Name | Size | Download method |
|---|---|---|---|
| Sample topology project used in this article | SampleTopology2.zip | 27KB | HTTP |
Information about download methods
Learn
- Visit the Rational software area on
developerWorks for technical resources and best practices for Rational
Software Delivery Platform products.
- Explore Rational computer-based,
Web-based, and instructor-led online courses. Hone your skills and learn
more about Rational tools with these courses, which range from introductory to
advanced. The courses on this catalog are available for purchase through
computer-based training or Web-based training. Additionally, some
"Getting Started" courses are available free of charge.
- Subscribe to the Rational Edge
newsletter for articles on the concepts behind effective software
development.
- Subscribe to the IBM developerWorks
newsletter, a weekly update on the best of developerWorks tutorials,
articles, downloads, community activities, webcasts and events.
- Browse the technology
bookstore for books on these and other technical topics.
Get products and technologies
- Download trial versions of IBM Rational software.
- Download these IBM product evaluation versions and get your hands on application
development tools and middleware products from DB2®, Lotus®,
Tivoli®, and WebSphere®.
Discuss
- Participate in the discussion forum.
- Check out developerWorks blogs and get
involved in the developerWorks community.
Narinder Makin is a software architect at IBM Research Triangle Park Lab in Durham, North Carolina. He works in the area of Deployment tools for the Rational Software Architect team. He has worked on variety of Model Driven Development/Deployment tools over the past 12 years. He has several patents and published articles. He holds an undergraduate degree in Computer Sc. and Engg. from K.N.I.T, India and also holds a MS in Computer Science from University Of Bridgeport, Connecticut.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
