Using the IBM Pattern Development Kit to build virtual application patterns, Part 2: Create a component link and a scaling and intent policy

Virtual application patterns in IBM® PureApplication System™ provide easy and powerful capabilities to construct Platform as a Service Pattern. This 3-part article series shows how to use the IBM Pattern Development Kit to build virtual application patterns to deploy several classic web platform topologies. To demonstrate these capabilities, open source software Apache Tomcat, Apache HTTP server, and LiveJournal Memcached are included in this pattern.

Share:

Qiang Wang (wqwqbj@cn.ibm.com), Software Engineer, IBM

Photo of Qiang WangQiang (Ace) Wang is a Staff Software Engineer in the PureApplication Pattern Enablement and Pattern Development Kit team in IBM Software Group. He has participated in many industry solutions, which include digital media, banking, healthcare, and so on. Currently, he is working in the cloud computing area.



Scott Walden (sw@us.ibm.com), Software Engineer, IBM

Photo of Scott WaldenScott Walden works on the enablement team for IBM PureApplication System. The team charter includes customer enablement and internal enablement for various teams. Previously, he was the technical lead for IBM Business Monitor on the AIM Early Programs team that managed early design programs, beta programs, customer acceleration programs, and skills transfers.


developerWorks Contributing author
        level

Qi Liu (lqliulq@cn.ibm.com), Software Engineer, IBM

Photo of Qi LiuQi (Colin) Liu is a Software Engineer leading the IBM Pattern Development Kit (PDK) development from Version 1.0.1.0. Previously, he worked as a key developer on the Composite Application Pattern (CAP) project and the lead for BPM Process Server plug-in development.



Wei Feng Li (lwfli@cn.ibm.com), Software Engineer, IBM

Photo of Wei Feng LiWei Feng (Banny) Li is a key developer of the PureApplication System Pattern Development Kit. He has rich experience in pattern development and is now mainly responsible for the PDK Eclipse user interface part. He is a key contributor in such projects as Application Delivery Pattern (ADP) and Composite Application Pattern (CAP). He also participates in Digital Media Management (DMM) and Knowledge Driver Application (KDA) accelerators development.



04 December 2013

Also available in Japanese

Introduction

In Part 1, you created HTTPD and Tomcat components without any connection. However, HTTPD and Tomcat servers should work together to build a cluster that can dynamically adopt different workload and intent. Links and policies in a virtual application pattern provide these capabilities.

A link establishes connections between components. For example, it provides a dependency between the HTTPD component and the Tomcat component. A policy represents a quality of service level for application artifacts in the virtual application. A policy can be applied globally at the application level, or only for an individual component. In this article, HTTPD and Tomcat links, the scaling policy, and the intent policy are separated into three plug-in projects. Separate policies are more flexible and easy to extend to support other components.


Link HTTPD and Tomcat

This section describes how to create a link from the Tomcat component to the HTTPD component, which makes the HTTPD component dependent on the Tomcat component.

HTTPD and Tomcat link design

The link between HTTPD and Tomcat registers Tomcat to HTTPD as a worker. Figure 1 shows the topology. In this topology, Tomcat is the application server, and HTTPD is the HTTP proxy and load balancer for Tomcat. HTTPD transfers the requests received from users to Tomcat, and returns the response received from Tomcat to users.

To register the Tomcat server to the HTTPD server, Tomcat has to export the parameters to HTTPD after the installation is complete. In virtual application patterns, a role dependency (or link) can transmit data between roles and create a watchdog script for specific parameters. For Tomcat and HTTPD components, the role for HTTPD should depend on the role for Tomcat. Then the exported parameters or status changes in Tomcat will pass to the role in HTTPD, which depends on Tomcat.

Figure 1. Target architecture of the link
Target architecture of the link

Create a link the plug-in project

To create a link plug-in project, follow these steps:

  1. Use the plug-in development kit to open the workspace from Part 1 of this series.
  2. Create an IBM Workload Plug-in project with the following name: plugin.com.ibm.samples.httpdtomcat. Select patterntype.samples.apache version 1.0 as the primary pattern type.
  3. Open the config.json the under the plugin folder:
    1. In the Package section of the Overview tab, rename role HTTPDTOMCAT to HTTPD_INSTALL (this is the same name as the role name defined in plugin.com.ibm.samples.httpd plug-in) and remove all script files under it.
    2. Under the HTTPD_INSTALL folder, create a folder named TOMCAT_INSTALL, which has the same name as the role name defined in the plugin.com.ibm.samples.tomcat plug-in. Then, create a script file called changed.py under the TOMCAT_INSTALL folder. In Figure 2, notice the role tag (R) for HTTPD_INSTALL and the dependency tag (D) for TOMCAT_INSTALL. This means that the HTTPD_INSTALL role will receive data from the TOMCAT_INSTALL role and will execute the changed.py script.
      Figure 2. Link plug-in packages and Project Explorer structure
      Link plug-in packages and Project Explorer structure
    3. Switch to the config.json tab. Change the package by renaming HTTPDTOMCAT to HTTPD_TOMCAT. This is used in the component transformer.
    4. Switch to the Application Model tab. Add a new link with the ID of link_httpd_tomcat as shown in Figure 3. For the Source, select the plug-in component name of samplesTomcat. For the Target, select the plug-in component name of samplesHttpd.
      Figure 3. Link metadata details
      Link metadata details
  4. Switch to the metadata.json tab. Add the values to sampleValue for all the attributes. Those sample values are displayed in the Virtual Application Builder in PureApplication System.
  5. To internationalize, create the strings in messages.json and update patterntype.json. See Part 1 of the series for more information.
    Listing 1. messages.json in link
    {
    	LINK_TOMCAT_HTTPD_LABEL:Link for httpd and tomcat,
    	LINK_TOMCAT_HTTPD_DESC:Link for httpd and tomcat,
    	LINK_TOMCAT_IP_LABEL:Tomcat IP  variable name,
    	LINK_TOMCAT_IP_DESC:Tomcat IP  variable name,	
    	LINK_TOMCAT_PORT_LABEL:Tomcat Port  variable name,
    	LINK_TOMCAT_PORT_DESC:Tomcat Port  variable name,
    }
  6. Create an OSGI Service Component as shown in Figure 4. Select menu File > New > Other… > IBM Workload Plug-in Development > OSGI Service Component. For the name, enter link_httpd_tomcat. For the service type, select Topology Provider (java based). For the implementation class, enter com.ibm.samples.transform.httpdtomcat.HttpdTomcatTransformer.
    Figure 4. Link the OSGI component
    Link the OSGI component

Link the plug-in implementation

Implement HttpdTomcatTransformer

HttpdTomcatTransformer extends the com.ibm.maestro.model.transform.TopologyProvider class and overrides its two methods:

  • transformComponent: This transforms a component from the application model into objects of the topology document. It will be called when the component is initialized.
  • transformLink: This transforms a link from the application model by updating the topology document content associated with the source and target components. The Components are transformed before the links.

In this link plug-in project, the transformLink method takes effect since only a link is defined in metadata.json. In this method:

  • sourceFragment is the partial topology document associated with the source component.
  • targetFragment is the partial topology document associated with the target component.
  • applicationUrl is the URL of the root of the application artifacts (within the PureApplication System Storehouse).
  • applicationLink is the link object from the application model.

Implement this method as follows:

  1. Print out the sourceFragment (HTTPD role fragment) and the targetFragment (Tomcat role fragment) for reference.
  2. Add the HTTPD_TOMCAT package to the Httpd vm-template.
  3. Add the HTTPD_INSTALL dependency on the TOMCAT_INSTALL definition in the VM template JSON part. Then the Python script, HTTPD_INSTALL/TOMCAT_INSTALL/changed.py, can receive the changes (add, remove, update) from the TOMCAT_INSTALL role.
  4. Add the parameters to HTTPD_INSTALL. These parameters can later be used in Python scripts.

Implement changed.py

The HTTPD_INSTALL/TOMCAT_INSTALL/changed.py script will execute in the HTTPD_INSTALL role of the HTTPD component. After execution of start.py in the HTTPD_INSTALL role, the changed.py script will execute every time there are changes in the TOMCAT_INSTALL role. There are two prerequisites to run changed.py:

  1. Execution of start.py in the current role has finished.
  2. Data or status changes are transmitted from the dependent roles.

Also note that changed.py may run many times in one deployment process as shown in Figure 5.

Figure 5. Sample script execution flow
Sample script execution flow

Printing the maestro parameters, as shown in Listing 2, in every lifecycle script can help you to debug scripts. Then when an instance is deployed, PureApplication System logs the values of these parameters for every lifecycle script. Keep in mind that different life cycle scripts use different parameters.

Listing 2. Inside parameters in changed.py
logger.debug('maestro.node:'+str(maestro.node))
logger.debug('maestro.role:'+str(maestro.role))
logger.debug('maestro.parms:'+str(maestro.parms))
logger.debug('maestro.xparms:'+str(maestro.xparms))
logger.debug('maestro.operation:'+str(maestro.operation))
logger.debug('maestro.updated:'+str(maestro.updated))
logger.debug('maestro.added:'+str(maestro.added))
logger.debug('maestro.removed:'+str(maestro.removed))
logger.debug('maestro.depends:'+str(maestro.deps))

As changed.py may be invoked many times, it needs to take the right action according to the type of change (add, remove, update) of the dependent role instance. One special invocation process is the restart operation (Figure 6).

Figure 6. Restart the operation script execution flow
Restart the operation script execution flow

To differentiate every invocation, changed.py should contain script to check the exported data from the dependent roles in the current virtual machine. For example, in Table 1:

  • For newly added role instances, the full names will be added to maestro.added.
  • For dependencies, its role exported parameters are in maestro.deps under its full name.
  • For newly removed role instances, the full names will be listed in maestro.removed.
  • For dependencies, maestro.deps does not contain removed role instances.
  • For updated role instances the full names will be put in maestro.updated, and for dependencies, its exported parameters are in maestro.deps.
Table 1. Changed role instance information
maestro.added (full name)maestro.removed (full name)maestro.updated (full name)maestro.deps (exported parameters)
New added role instances exist exist
New removed role instances exist
New updated role instances exist exist

Generally, every dependent role instance change will cause changed.py to run once. Sometimes, different instances with the same role will have the same change at the same time. In this case, instance names are put together and changed.py is called only once. For this reason, maestro.added, maestro.removed, and maestro.updated are lists that may contain more than one instance name (see Listings 3 and 4).

Listing 3. Content in maestro.added
[u'Tomcat_Server-tomcat.11372783844723.TOMCAT_INSTALL',
u'Tomcat_Server-tomcat.21372783844724.TOMCAT_INSTALL']
Listing 4. Content in maestro.deps
{u'Tomcat_Server-tomcat.11372783844723.TOMCAT_INSTALL':
	{u'TOMCAT_READY':
		{u'TOMCAT_HOME': u'/opt/apache/tomcat7',
		 u'TOMCAT_PORT': u'8080',
		 u'TOMCAT_IP': u'172.20.107.11',
		 u'COMPONENT_NAME': u'TomcatServer'}},
 u'Tomcat_Server-tomcat.21372783844724.TOMCAT_INSTALL':
	{u'TOMCAT_READY':
		{u'TOMCAT_HOME': u'/opt/apache/tomcat7',
		 u'TOMCAT_PORT': u'8080',
		 u'TOMCAT_IP': u'172.20.107.4',
		 u'COMPONENT_NAME': u'TomcatServer'}}}

These are some of the checks in the changed.py script:

  • If the installation complete flag is set, then this is a restart operation so you do not need to run anything.
  • Otherwise, check if the changed node name is in the role dependent information (maestro.deps). If so, check if it is an add operation (ch_info is from maestro.updated or maestro.added). If so, then call the write_conf and export_flag functions for the first write to the change the configuration file (FLAG_FILE does not exist), or call the chang_conf function to add a new line to the configuration file.
  • If the changed node name is not in the in the role dependent information (maestro.deps), then check if it is a remove operation (ch_info is from maestro.removed). If so, then call the chang_conf function to remove a line from the configuration file. Note that every time there is an operation on the configuration file, you need to restart HTTPD (call restart_httpd).

Listing 5 shows the content that needs to be added to the httpd.config file in the HTTPD server. This content can register the Tomcat server (for example, the IP is 192.168.0.4 and the port is 8080) to the HTTPD server.

Listing 5. Configuration content in the httpd.conf file
ProxyPass /images !
ProxyPass /css !
ProxyPass /js !
ProxyPass / balancer://cluster/
<Proxy balancer://cluster/>
BalancerMember http://192.168.0.4:8080/ loadfactor=1
</Proxy>

The complete scripts for registering the Tomcat server to the HTTPD server are included in the provided source project with this article. The changed.py script supports the addition and removal of TOMCAT_INSTALL, which is required in the scaling policy and the usage intent policy.


Add the scaling policy to Tomcat

This section shows you how to create a scaling policy for the Tomcat component. Tomcat is the main processing component for all user requests, so the scaling policy is created only for Tomcat, but not for HTTPD.

Scaling policy design

The scaling policy can automatically create or destroy Tomcat virtual machines, depending on the CPU usage. Figure 7 shows that the scaling policy can add more Tomcats to HTTPD. More than one Tomcat server can make use of the balancing function of HTTPD.

Figure 7. Target architecture of scaling
Target architecture of scaling

In the scaling target architecture, one HTTPD connects to many Tomcat servers for load balancing. Each Tomcat server will have about 1/n of the workload, where "n" is the number of Tomcat servers. This type of scaling is also known as horizontal scaling. Another type of scaling is known as vertical scaling, which adjusts CPU count and memory to match the workload. For more information about vertical scaling, see Monitoring service for plug-ins.

Create the scaling policy plug-in

  1. Create the plugin.com.ibm.samples.scaling project with patterntype.samples.apache as the primary pattern type.
  2. The scaling policy does not need any role, so open config.json under the plug-in folder. On the Overview tab, in the package section, remove the SCALING role.
  3. Switch to the Application Model tab. Add a new policy type metadata with an ID of policy_tomcat_scaling. Add the plug-in component name as samplesTomcat to the "Applicable to" list as shown in Figure 8.
    Figure 8. Scaling policy metadata details
    Scaling policy metadata details
  4. Add three required attributes to the policy. The CPU.Used.Basic.Primitive attribute defines the CPU range for scale out (maximum value) and scale in (minimum value). If the CPU usage percentage exceeds this range, then a scale in or scale out is performed. The triggerTime1 attribute is the trigger time (in seconds) for scale out or scale in. The scaleInstanceRange1 attribute is the virtual machine instance number range for scale out (maximum value) and scale in (minimum value).
  5. When the virtual application starts, it creates the minimum number of application instances. The virtual application is then monitored at a regular interval, and the CPU usage of all the application instances is sampled and averaged. If the calculated average falls outside the specified range at every monitoring interval for a total elapsed time beyond the trigger time, a scaling action is triggered, assuming the instance count is within the allowable instance range (see Figure 9).
    Figure 9. Scaling policy attributes
    Scaling policy attributes
  6. Switch to the metadata.json tab. Add a group part. The content (see Listing 6) of this group part will be shown as a drop-down menu in Virtual Application Builder of PureApplication System. Add the transformAs: linked property, which allows the scaling policy to work as an independent policy component. Then, add the sample values to all the attributes.
    Listing 6. Scaling policy attributes in metadata.json
    groups: [
             {
                category: scaling policy type,
                id: Basic,
                label: CPU base scaling policy,
                defaultValue: true,
                attributes: [
                   CPU.Used.Basic.Primitive,
                   triggerTime1,
                   scaleInstanceRange1
                ],
                description: CPU base scaling policy type
             }
          ],
  7. Update messages.json to internationalize as shown in Listing 7.
    Listing 7. messages.json in the scaling policy
    {
    	POLICY_SCALING_TOMCAT_LABEL:Scaling Policy for Tomcat,
    	POLICY_SCALING_TOMCAT_DESC:Scaling Policy for Tomcat,
    	POLICY_SCALING_CPU_USED_LABEL:CPU used,
    	POLICY_SCALING_CPU_USED_DESC:CPU used percentage range,
    	POLICY_SCALING_TRIGGER_TIME_LABEL:Trigger time,
    	POLICY_SCALING_TRIGGER_TIME_DESC:Trigger time for scaling,
    	POLICY_SCALING_INSTANCE_RANGE_LABEL:Scale instance range,
    	POLICY_SCALING_INSTANCE_RANGE_DESC:Scale instance range,
    }
  8. Create an OSGI Service Component with the policy_tomcat_scaling name. This name must be the same as the scaling policy metadata ID. For the service type, select Topology Provider (java based). For the implementation class, enter com.ibm.samples.transform.scaling.ScalingTransformer as shown in Figure 10.
    Figure 10. Scaling policy for the OSGI component
    Scaling policy for the OSGI component

Scaling the policy plug-in implementation

The scaling policy does not contain roles or scripts. ScalingTransformer implements the com.ibm.maestro.model.transform.TopologyProvider abstract class and overrides two methods: transformComponent and transformLink.

In the policy plug-in, both transformComponent and transformLink methods are called. In transformComponent, it transforms from the metadata attributes format to the scaling attributes format. The metadata attributes format is defined in metadata.json. The scaling attributes format is shown in Listing 8.

Listing 8. Scaling attributes format in the topology document
scaling:{
     triggerEvents:[{
         metric:CPU.Used,
         scaleOutThreshold:{value:40,type:CONSTANT,relation:>=},
         conjection:OR,
         scaleInThreshold:{electMetricTimeliness:historical,
         value:20,
         type:CONSTANT,
         relation:<=}],
    min:2,
    max:9,
    triggerTime:300,
    role:TOMCAT_INSTALL
}

The settings shown in Listing 8 enable the TOMCAT_INSTALL role to perform auto scaling. When attributes such as triggerEvents and triggerTime are included in the scaling part, they enable an auto scaling capacity for the cluster. Also, there is an attribute minimum to define the lower limit of the instance numbers, and there is attribute maximum to define the upper limit.

The scaling attributes part must be added to the vm-template that has the target role in it. Then the corresponding role in the vm-template will be enabled with the auto scaling feature.

In the transformLink method, it adds the scaling attributes part to the vm-template with the TOMCAT_INSTALL role in the topology document.

  • sourceFragment is the applicable component in the topology document.
  • targetFragment is the scaling policy topology document that is generated by transformComponent.

When adding the scaling attributes to the applicable component topology document, it is important that max and min values under the scaling attributes are pre-defined. However, the values may conflict, so there is a correctScaleInstanceRange function to correct the value.

Note that the changed.py script in the link plug-in is designed to support scaling with multiple VM instances.


Add a usage intent policy to the pattern

The usage intent policy can control the initial number of instances for the HTTPD and Tomcat servers. You can use this policy separately or in conjunction with the scaling policy.

Intent policy design

The intent policy can change the virtual machine number at deployment time. There are two options of the policy: testing and production. Figure 11 shows the "Testing" topology, which provides deployment with one HTTPD server and two Tomcat servers.

Figure 11. Topology of the testing intent
Topology of the testing intent

In this target architecture, one HTTPD connects two Tomcat servers. Each Tomcat server will have a 50% workload.

Figure 12 shows the "Production" topology. Production deployment provides an environment with two HTTPD servers and four Tomcat servers.

Figure 12. Topology of the production intent
Topology of the production intent

In this target architecture, two HTTPD servers connect four Tomcat servers. Usually, two Tomcat servers are used as high availability (HA) servers. One HTTPD server is a backup for the other HTTPD server. Each Tomcat server will have a 25% workload.

The Testing intent policy used in conjunction with the scaling policy is the same as using just the scaling policy. The Production intent policy plus the scaling policy make a more complex system that is shown in Figure 13.

Figure 13. Topology of the production intent plus the scaling policy
Topology of the production intent plus the scaling policy

In this target architecture, two HTTPD servers connect many Tomcat servers. Each Tomcat server has 1/n of the workload.

Create a usage intent policy plug-in project

  1. Create the plugin.com.ibm.samples.scaling plug-in project with patterntype.samples.apache as the primary pattern type.
  2. Open config.json under the plugin folder. The intent policy does not need any role. On the Overview tab, remove the INTENT role in the Package section.
  3. Switch to the Application Model tab. Add a new policy type metadata with an ID of policy_httpd_tomcat_intent. For "Applicable to", add samplesHttpd and samplesTomcat to the list as shown in Figure 14.
    Figure 14. Intent policy metadata details
    Intent policy metadata details
  4. Add four attributes as shown in Figure 15. httpdNumber1 and tomcatNumber1 are for the testing type intent policy. httpdNumber2 and tomcatNumber2 are for the production type intent policy.
    Figure 15. Intent policy attributes
    Intent policy attributes
  5. Switch to the metadata.json tab. Add a group part, so there will be a drop-down menu in Virtual Application Builder. Add the transformAs: linked property, then the intent policy can work as an independent policy component. Add the sample values to all the attributes.
  6. Update messages.json to internationalize as shown in Listing 9.
    Listing 9. messages.json in intent policy
    {
    	POLICY_SCALING_TOMCAT_LABEL:Scaling Policy for Tomcat,
    	POLICY_SCALING_TOMCAT_DESC:Scaling Policy for Tomcat,
    	POLICY_SCALING_CPU_USED_LABEL:CPU used,
    	POLICY_SCALING_CPU_USED_DESC:CPU used percentage range,
    	POLICY_SCALING_TRIGGER_TIME_LABEL:Trigger time,
    	POLICY_SCALING_TRIGGER_TIME_DESC:Trigger time for scaling,
    	POLICY_SCALING_INSTANCE_RANGE_LABEL:Scale instance range,
    	POLICY_SCALING_INSTANCE_RANGE_DESC:Scale instance range,
    }
  7. Create an OSGI Service Component with a name of policy_httpd_tomcat_intent. For the service type, select Topology Provider (java based). For the implementation class, enter com.ibm.samples.transform.intent.IntentTransformer as shown in Figure 16.
    Figure 16. Intent policy OSGI component
    Intent policy OSGI component

Intent policy plug-in implementation

The IntentTransformer class in the intent policy is similar to the ScalingTransformer class in the scaling policy. In the intent project, both transformComponent and transformLink methods are called. In transformComponent, it transform metadata attributes format to intent attributes format. The intent attributes are a subset of scaling attributes with the same format (see Listing 10). There are only max and min attributes under the scaling attribute. Note that the attribute max value is the same as min, because it is only used to control the initial number.

Listing 10. Intent attributes format in topology document
scaling:{
   min:2,
   max:2,
   role:TOMCAT_INSTALL
}

In transformLink, it adds the scaling attributes part to the vm-template, recognizing that the scaling attribute may already exist since the scaling policy may execute first. There is also a function to correct the min and max value. In this function, it uses the maximum value of the max property in the topology document, and the scaling policy as the max property's value in the scaling policy. It uses the minimum value of the min property in the topology document and the scaling policy as the min property's value in the scaling policy. The scaling policy will replace the scaling property in the topology document.


Conclusion

Part 2 showed you how to develop a virtual application pattern that includes a link, a scaling policy, and a usage intent policy. This allows you to scale your topology based on workload performance and target usage scenarios.

In Part 3, you will create shared services to provide a singleton Memcached server pool shared by multiple Tomcat server instances.

Download files

See the provided sample code for samples.apache. Download the package and select from the menu, File > Import... > IBM Workload Plug-in Development > IBM Workload Pattern type Package, to import the projects.


Download

DescriptionNameSize
Code samplepatterntype.samples.apache-1.0.0.0.zip209KB

Resources

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 Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing
ArticleID=955538
ArticleTitle=Using the IBM Pattern Development Kit to build virtual application patterns, Part 2: Create a component link and a scaling and intent policy
publish-date=12042013