Anatomy of a topology model used in IBM Rational Software Architect Version 7.5: Part 2: Advanced concepts

Part 1 of this series showed the basic concepts of the topology model that is used in the IBM® Rational® Software Architect deployment architecture platform. This part focuses on the advanced concepts of the topology model, such as constraints, realization links, constraint links, and imports that are used to compose topologies for reuse and abstraction.

Narinder Makin, Software Architect, IBM Rational SOA tools, IBM

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.



30 December 2008

Introduction

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.

Updated topology model

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
complex diagram of topology mode.
Figure 2. Constraint model
complex diagram of 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"/>

Domain use

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>

Import

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>

Encapsulation

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.

Contract

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
TypeLinkableConfigurable
Privatefalsefalse
Publictruefalse
Public-Editabletruetrue

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>

Public import

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>

Import override

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

Click to see code listing

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>

Import augmentation

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>

Re-export

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>

Domain use

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 defaultPolicy and defaultConceptualPolicy as private such that all the units are made private by default contract
  • A public conceptual J2EEServer1 definition with a public J2EEContainer1 capability that has containerVersion as 1.3
  • A public conceptual J2EEServer2 with a public editable J2EEContainer2 capability that has a containerVersion set 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 defaultPolicy as false and defaultConceptualPolicy as public so that all the conceptual units are made public by default contract
  • An EARComponent1 that has a hosting requirement on a J2EEServer that has a J2EEContainer capability with containerVersion equal to 1.3
  • An EARComponent2 that has a hosting requirement on a J2EEServer that has a J2EEContainer capability 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 containerVersion property 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>

Constraint

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.

Predefined constraint

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>

Domain use

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 WebModuleCapability of member type with member cardinality constraint that allows for a 0 or 2147483647 number of Web components
    • A hosting requirement of type J2EEContainer with a version greater than or equal to 1.4
    • A requirement for a J2EEDatasource with an equals constraint for the jndiName to be "jndi/default"
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>

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>

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>

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>

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>

Topology variable

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.


Custom attributes

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>

Conclusion

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.


Download

DescriptionNameSize
Sample topology project used in this articleSampleTopology2.zip27KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, Sample IT projects
ArticleID=361006
ArticleTitle=Anatomy of a topology model used in IBM Rational Software Architect Version 7.5: Part 2: Advanced concepts
publish-date=12302008