WebSphere CloudBurst plus Rational Automation Framework for WebSphere

Make your middleware application environments simple, quick, and easy to recreate

Building, deploying, configuring, then recreating middleware application environments are critical tasks for IT organizations, but inefficiency often surrounds this set of tasks. It can take too long to build and deploy; require too much experience to configure; be next to impossible to consistently recreate middleware application environments. In this article, the author shows you how WebSphere® CloudBurst and the Rational® Automation Framework for WebSphere can be combined to harden your dynamic WebSphere cloud application infrastructure.

Share:

Dustin Amrhein, Technical Evangelist, IBM

Author photoDustin Amrhein joined IBM as a member of the development team for the WebSphere Application Server. While in that position, Dustin worked primarily on web services infrastructure and web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role Dustin is a WebSphere Client Technical Professional.



16 July 2010

Also available in Chinese Russian Japanese Spanish

Constructing, deploying, and configuring WebSphere® middleware application infrastructure and the applications that run on the infrastructure are often core tasks for enterprise IT organizations. Traditional approaches to accomplish these tasks can be problematic and lead to inefficiencies and waste. These problems include

  • Long lead times to get environments set up and configured.
  • An inability to consistently recreate environments as necessary.
  • A requirement for too much infrastructure expertise among test and development staff.

An integrated solution using the IBM WebSphere CloudBurst Appliance and the Rational® Automation Framework for WebSphere provides for a virtualized, automated, data-driven approach that tackles many of these inefficiencies.

WebSphere CloudBurst delivers an easy way to model your application environments in the form of WebSphere CloudBurst patterns. These patterns, which you can build using a graphical interface, are based on IBM® Hypervisor Edition virtual images. These images encapsulate much of the infrastructure expertise you need to build WebSphere middleware environments; they allow the deployment and initialization of complete, enterprise-ready environments to happen in a matter of minutes. Best of all, these patterns are saved on the appliance which means that it is easy to consistently recreate the same environment when necessary.

While WebSphere CloudBurst addresses many of the requirements needed to quickly and consistently deploy a WebSphere application infrastructure, Rational Automation Framework for WebSphere provides similar benefits in the area of configuring your application and its dependencies atop said infrastructure.

Rational Automation Framework for WebSphere ships with over 500 out-of-the-box WebSphere configuration actions. These include actions such as configuring JDBC resources, setting up JMS queues, tuning application containers, deploying applications ... you can almost name it.

You build Rational Automation Framework for WebSphere projects that contain any number of configuration steps and once built, you can automate the invocation of that project against a target WebSphere cell. The result is the configuration and deployment of your application and its dependencies all without the need for you to supply any scripting.

While there may be functional overlap (Rational Automation Framework for WebSphere can be used to install WebSphere products though it does not enable the patterns-based approach or rapid deployment capability provided by WebSphere CloudBurst), the effective integration of WebSphere CloudBurst and Rational Automation Framework for WebSphere clearly highlights the best characteristics and capabilities of each product. The result is a fast, efficient, automated, and repeatable process for setting up your application environments.

Figure 1 shows you the individual responsibilities of each software.

Figure 1. Delineation of responsibility for WebSphere CloudBurst and Rational Automation Framework for WebSphere
Delineation of responsibility for WebSphere CloudBurst and Rational Automation Framework for WebSphere

How and when you should integrate

Now that we established the why of WebSphere CloudBurst and Rational Automation Framework for WebSphere, let's examine the how and when of the integration of these two solutions.

Achieving integration between WebSphere CloudBurst and Rational Automation Framework for WebSphere is quite straightforward — essentially you build your WebSphere CloudBurst pattern that represents the desired WebSphere topology and attach the special script package shipped with the Rational Automation Framework for WebSphere product.

The script package is the glue between the WebSphere CloudBurst deployment and Rational Automation Framework for WebSphere. During deployment, WebSphere CloudBurst invokes the integration script package; this invocation results in the execution of a Rational Automation Framework for WebSphere project against the WebSphere cell created by CloudBurst. Figure 2 shows the integration interplay between the two programs.

Figure 2. WebSphere CloudBurst and Rational Automation Framework for WebSphere integration diagram
WebSphere CloudBurst and Rational Automation Framework for WebSphere integration diagram

The Rational Automation Framework for WebSphere project that is invoked, as well as the Rational Automation Framework for WebSphere environment used by that project, are among the parameters defined by the script package. This means that you can lock these values into the pattern or provide the values shortly before deployment. (I'll discuss more about the script's parameters as well as how you should provide their values a bit later in the article.)

Important to note:

Integrating WebSphere CloudBurst and Rational Automation Framework for WebSphere means that you can encapsulate your entire application environment in a pattern without writing any of your own scripting.

Instead, you can leverage the more than 500 out-of-the-box WebSphere configuration actions supplied by Rational Automation Framework for WebSphere.

Beyond the benefits of the out-of-the-box WebSphere expertise, this integrated solution is applicable to other key scenarios such as creating patterns for existing WebSphere environments and configuring changes to a WebSphere cell and then being able to capture and reuse that configuration.

Creating patterns for your existing WebSphere environments

Consider this: You have existing WebSphere environments that you want to "import" as a pattern in your WebSphere CloudBurst Appliance. The appliance does not provide a feature that allows you to point it at an existing environment and bring that environment in as a new pattern.

But you can point Rational Automation Framework for WebSphere at your existing WebSphere cell and use its environment-generation tool to create a new Rational Automation Framework for WebSphere environment from the existing cell, effectively storing the configuration of your WebSphere setup.

You can then create a pattern, use the special script package, and point it at a Rational Automation Framework for WebSphere project that applies the configuration data in the Rational Automation Framework for WebSphere environment you created during the import. This allows you to create a WebSphere CloudBurst pattern that is exactly like an existing WebSphere cell (Figure 3).

Figure 3. Point-and-click patterns for existing WebSphere environments
Point-and-click patterns for existing WebSphere environments

Configure, capture, reuse

In some cases, you may manually apply configuration changes to your WebSphere cell and then want to capture and reuse the resulting configuration.

For instance, perhaps during testing of your application you discover certain configuration tweaks that produce optimal behavior — you never want to waste anything like that.

Another example: For the first setup of a given application environment, you may prefer to quickly deploy the cell using WebSphere CloudBurst and then manually configure the application and its resources.

In either case, you might like to capture the updated configuration and then reuse it as necessary. Again, you can use Rational Automation Framework for WebSphere to capture the configuration and integrate the deployment of a WebSphere CloudBurst pattern with a Rational Automation Framework for WebSphere project that applies said configuration. This is similar to the first scenario except in this case, legacy environments are not the target (Figure 4).

Figure 4. Configure, capture, reuse
Configure, capture, reuse

Migrate environments across virtual and physical domains

Maybe your application promotion cycle spans both the virtual and physical domains. For example, you might deploy everything from test to pre-production environments using WebSphere CloudBurst, but once you move to production you may want to set up the same environment on physical hardware.

The leap from virtualized WebSphere environments using WebSphere CloudBurst patterns to traditional WebSphere environments installed directly on hardware can be difficult. You cannot deploy WebSphere CloudBurst patterns directly to a physical server. This can make it hard to ensure you are putting the exact same environment into production that you have already tested and verified.

However, if you store the configuration of your WebSphere application environment as a Rational Automation Framework for WebSphere environment, you can apply that configuration to either virtual or physical WebSphere cells using the exact same Rational Automation Framework for WebSphere project. This gives you peace of mind that you are putting an environment into production that you know works (Figure 5).

Figure 5. Spanning virtual and physical domains
Spanning virtual and physical domains

Putting it to work

Now that you understand how WebSphere CloudBurst and Rational Automation Framework for WebSphere integrate and when to use this integration, it is time to step through a sample scenario.

Let's consider a use case that follows the configure, capture, reuse scheme I introduced in the last section. In particular, we will manually set up the Apache DayTrader J2EE application environment, capture it as a Rational Automation Framework for WebSphere project and environment, and then reuse it as a WebSphere CloudBurst pattern.

Deployment of the pattern will result in the construction of the WebSphere Application Server cell and the invocation of the Rational Automation Framework for WebSphere project in order to setup the Apache DayTrader application environment. The integration will allow you to completely automate the process from the deployment and configuration of the WebSphere Application Server cell to the deployment and configuration of the Apache DayTrader application environment.

In order to accomplish this work, you have to do the following steps:

  1. Create a custom WebSphere CloudBurst pattern with the Rational Automation Framework for WebSphere integration script package.
  2. Deploy the WebSphere CloudBurst pattern to create a WebSphere Application Server cell.
  3. Manually install, configure, and verify the Apache DayTrader application.
  4. Use Rational Automation Framework for WebSphere to capture the configuration of the WebSphere Application Server cell.
  5. Set up the Rational Automation Framework for WebSphere to apply the captured configuration and deploy the Apache DayTrader application.
  6. Deploy a WebSphere CloudBurst pattern which uses the new Rational Automation Framework for WebSphere project and environment to automate the construction of the Apache DayTrader application.

Oh, and I almost forgot to mention — you will be able to do all of this without writing one single line of custom scripting!

Creating a new pattern

The first step is to create a new WebSphere CloudBurst pattern that contains the Rational Automation Framework for WebSphere integration script package. Before you do that though, you need to load the Rational Automation Framework for WebSphere integration script package into the catalog of your WebSphere CloudBurst Appliance.

Again, you can get the script package from your Rational Automation Framework for WebSphere installation (in the Rational Automation Framework for WebSphere_HOME/framework/wca directory). Once you have the archive (ZIP) file, navigate to the Script Package section of the WebSphere CloudBurst catalog and upload the new content. When the upload process is complete, click the refresh button in the top right-hand toolbar. (Figure 6 shows the integration script package.)

Figure 6. The integration script package
The integration script package

Once you hit the refresh button, you should see the data that describes the script package due to the inclusion of the cbscript.json file in the archive. This data tells WebSphere CloudBurst what to invoke (in this case a shell script included in the script package) and it defines various environment variables. You can lock the value for these variables into the pattern or supply them during the deployment process; they provide such important integration information as:

  • RAFW_SERVER_HOST: The hostname for the Rational Automation Framework for WebSphereserver.
  • RAFW_SERVER_USER: The user name used to login to the Rational Automation Framework for WebSphere server.
  • RAFW_SERVER_PASSWORD: The password used to login to the Rational Automation Framework for WebSphere server.
  • RAFW_AUTOMATION_PLAN: The name of the Rational Automation Framework for WebSphere project to invoke during deployment.
  • RAFW_ENVIRONMENT: The name of the Rational Automation Framework for WebSphere environment used by the Rational Automation Framework for WebSphere project. The environment contains the configuration data for the WebSphere Application Server cell.
  • RAFW_HOME_PATH: The file system location to unzip Rational Automation Framework for WebSphere binaries on the virtual machine. This value should match the value of the LINUX_RAFW_HOME in the RAFW_HOME/configure.properties file on the Rational Automation Framework for WebSphere server. These libraries are included in the script package for convenience.
  • RAFW_AUTOMATION_TIMEOUT: This is the maximum amount time, in minutes, that WebSphere CloudBurst will wait for the specified Rational Automation Framework for WebSphere project to complete. If the timeout occurs before the Rational Automation Framework for WebSphere project is complete, the Rational Automation Framework for WebSphere project will continue to run, but WebSphere CloudBurst will report that the virtual system is in the started state.

Once the script package is in the catalog, you can build your new custom pattern. Navigate to the Patterns page and either clone an existing pattern or create an entirely new one. For this scenario, you will configure a pattern with Deployment manager, custom node, and IBM HTTP Server parts as seen in Figure 7.

Figure 7. Custom DayTrader pattern
Custom DayTrader pattern

Before leaving the Pattern Editor, click the Advanced Options link. Uncheck the Enable messaging option, but keep the Define clusters option checked. WebSphere CloudBurst updates this pattern to include the necessary configuration to create WebSphere Application Server cluster during deployment.

After you click OK on the Advanced Options panel, you will see a Cluster configuration badge added to the Deployment manager part. Click the configuration icon next to this badge and provide configuration data for the cluster as shown in Figure 8.

Figure 8. Cluster configuration data
Cluster configuration data

From this configuration data, WebSphere CloudBurst will automatically create a WebSphere Application Server cluster containing one member on each custom node. Use TradeCluster as a prefix for the cluster name and WebSphere CloudBurst creates and tunes the cluster without the need for user-supplied scripting.

The initial deployment

Before you attempt to integrate WebSphere CloudBurst pattern deployments and Rational Automation Framework for WebSphere, you need to ensure that the machine hosting your Rational Automation Framework for WebSphere server can make successful network connections to the virtual machines which WebSphere CloudBurst creates. In addition, ensure that the Rational Automation Framework for WebSphere server has the necessary keys to make SSH/SFTP connections to these virtual machines or configure the machine hosting the Rational Automation Framework for WebSphere server to automatically accept new keys upon the initiation of such connections. Be aware that configuring the automatic acceptance of new keys is a potential security risk.

Once you are finished building this pattern, you can proceed to the initial deployment. When configuring the Deployment manager part during the deployment process, you will provide integration information for the Rational Automation Framework for WebSphere.

Figure 9 shows the deployment of the DayTrader pattern.

Figure 9. Deploying the DayTrader pattern
Deploying the DayTrader pattern

This deployment targets the Rational Automation Framework for WebSphere server at eastgrand.austin.ibm.com and logs in with the username and password of cloudburst. Since we are going to manually configure this environment for the first deployment, the name of the Rational Automation Framework for WebSphere project (RAFW_AUTOMATION_PLAN) is not important. The Rational Automation Framework for WebSphere runtime will automatically generate a project that we can reuse. The Rational Automation Framework for WebSphere environment name in this case is DayTrader and we take the defaults provided for the timeout.

For the RAFW_HOME_PATH you use the /opt/IBM/WebSphere/Profiles/RAFW directory. You use this location instead of taking the default path because Rational Automation Framework for WebSphere will attempt to create directories and files on each virtual machine in our virtual system as the virtuser operating system user.

You need to ensure that the location in which Rational Automation Framework for WebSphere attempts to create files and directories is accessible to virtuser. You can also do this by using a custom image in which you have set up the appropriate file permissions.

In either case, you must also change the value of the LINUX_RAFW_HOME parameter in the RAFW_HOME/configure.properties file on the Rational Automation Framework for WebSphere server to match the RAFW_HOME_PATH value you used during deployment.

Once your new virtual system is in the started state, you can access the WebSphere Application Server administration console to setup the Apache DayTrader application environment.

Before you do that, let's look at the Rational Automation Framework for WebSphere artifacts generated as part of the deployment process. Log into the Rational Automation Framework for WebSphere console (in this case by opening the URL http://eastgrand.austin.ibm.com) and click the Environments link. You should see an environment with the name RAFW_DayTrader_CloudBurstCell0. You can click on the link to see what Rational Automation Framework for WebSphere created for you (Figure 10).

Figure 10. Automatically generated Rational Automation Framework for WebSphere environment
Automatically generated Rational Automation Framework for WebSphere environment

The integration script package created this new environment by using data made available to script packages in WebSphere CloudBurst deployments. You will update this environment once you have installed and configured the DayTrader application environment to contain the updated information.

In addition to the Rational Automation Framework for WebSphere environment, if you click the Projects link, you should see a newly created Rational Automation Framework for WebSphere project. It has the same name as the generated Rational Automation Framework for WebSphere environment (Figure 11).

Figure 11. Automatically generated Rational Automation Framework for WebSphere project
Automatically generated Rational Automation Framework for WebSphere project

Initially, the project contains a single step which is actually a call to the RAFW_WAS_70_ND_Configure library. This library ships with the Rational Automation Framework for WebSphere product, and you can use it to apply or import configuration for an entire WebSphere Application Server 7.0 cell. You will use this project to import the configuration of the cell after you set up the DayTrader environment.

After importing the configuration, you will slightly modify the project to apply only the necessary configuration to reduce the overall deployment time. However, you will still make use of shipped libraries and you will not need to write one line of custom scripting.

Set up and verify DayTrader

The Apache DayTrader application is a performance benchmark application that models an online stock trading system. The application is made up of servlets, JSPs, multiple types of Enterprise JavaBeans, a back-end data source, and more. Figure 12 is a diagram taken from the Apache DayTrader website that describes the layout of the application environment.

Figure 12. Apache DayTrader architecture
Apache DayTrader architecture

Instead of stepping through the installation steps for deploying the DayTrader application, just go to the website where you can find the application source as well as build and deployment instructions (see Resources).

By the end of this article, you will have mapped this environment and the infrastructure it depends on to a WebSphere CloudBurst pattern integrated with a Rational Automation Framework for WebSphere project. A WebSphere CloudBurst pattern will represent the WebSphere Application Server cell that maps to the JavaEE Application Server part of the diagram. The setup of the database is not included in the current WebSphere CloudBurst pattern, though in WebSphere CloudBurst 2.0 you could have easily included a DB2® part in your pattern to encapsulate the database server of the environment as well.

The Rational Automation Framework for WebSphere environment will contain configuration data for the application, its resources, and its dependencies. This will ensure the correct deployment of the application and its servlets, JSPs, and Enterprise JavaBeans. In addition, the Rational Automation Framework for WebSphere environment will contain data needed to correctly configure components for integration among the DayTrader application, application clients, and back-end data sources.

Based on the pattern that you constructed and deployed earlier in the article, you should set up the Apache DayTrader application to run within a WebSphere Application Server cluster. This cluster will contain one member on each of the custom nodes in the deployment. Figure 13 depicts the desired deployment result.

Figure 13. DayTrader in WebSphere Application Server cell
DayTrader in WebSphere Application Server cell

Once you have installed the application, configured the necessary resources and dependencies, and successfully started the application, you can verify that it is working by navigating to the http://<host>:9080/daytrader URL. Once there, click the Configuration tab and you should see the following page (Figure 14):

Figure 14. DayTrader configuration page
DayTrader configuration page

To begin verification, click the (Re)-create DayTrader Database Tables and Indexes and then once done with the steps on that page, click the (Re)-populate DayTrader Database. Once you create and populate the database tables, you can test the application by clicking the Test DayTrader Scenario link and following instructions on the page.

Once you're satisfied that you have the environment correctly configured, you can proceed to update the Rational Automation Framework for WebSphere environment with this new configuration.

Capture the DayTrader configuration

Now that you have gone through the process of manually configuring and verifying the Apache DayTrader environment, it is unlikely you'll want to do it all over again (much less every time you need a new deployment). You want to capture the setup that you know works and use that configuration as demand dictates. That is exactly what you are going to do; it starts with capturing your existing configuration using Rational Automation Framework for WebSphere.

During the initial pattern deployment, the integration script package caused the automatic generation of a Rational Automation Framework for WebSphere project (as shown in Figure 10). You can use this project to import the existing configuration of your DayTrader environment by running it in Import mode.

To do this, log into the Rational Automation Framework for WebSphere console, click the Projects link, and then click the RAFW_DayTrader20_CloudBurstCell0 project. Once on the project details page, click Start Project on the top toolbar to create a new job. On the job details page, simply change the Mode field to Import as shown in Figure 15.

Figure 15. Starting the project in import mode
Starting the project in import mode

At this point, simply click Execute and a Rational Automation Framework for WebSphere job will commence. This will begin the execution of the RAFW_WAS70_ND_CONFIGURE library against the WebSphere Application Server cell on which you deployed the DayTrader application.

Notice that the location of the WebSphere Application Server environment and other pertinent details, such as cell and node names, already exist in the project's environment. Again, the integration script package does this automatically when it creates the DayTrader environment during the initial deployment.

After clicking Execute, Rational Automation Framework for WebSphere redirects you to the details page for the job you started. You can monitor the progress of the import task and when it is complete, you should see the same status as shown in Figure 16.

Figure 16. The completed import job
The completed import job

Capture the DayTrader application

Now the DayTrader environment is up-to-date with the latest configuration information from your Apache DayTrader application environment. This includes configuration for JDBC resources, JMS queues, messaging engines, and more. However, you still need to import the actual application and store it in the DayTrader environment.

To do this, you create a simple Rational Automation Framework for WebSphere project that imports the application binaries and creates a properties file that Rational Automation Framework for WebSphere will use later to install the application.

Click the Projects link in the left-hand toolbar and once on the projects page, click Add Project at the top. At the bottom of the screen, the details section for the new project appears. Enter Import DayTrader Application as the new project name and select RAFW_DayTrader_CloudBurstCell0 as the environment for the new project. You also need to make sure you have the right Selector defined based on your Rational Automation Framework for WebSphere configuration. When you are done, click Save (Figure 17).

Figure 17. Adding the new application import project
Adding the new application import project

This new project consists of three steps, designed to accomplish the following:

  1. Create a properties file used to deploy the DayTrader application.
  2. Update the properties file with an application name key-value pair.
  3. Import the application binaries from the existing WebSphere Application Server cell.

To create a new step, click the Import DayTrader Application project and then click Add Step in the top toolbar. When the step details panel appears at the bottom of the screen, enter Create properties file as the name of the first step. Figure 18 shows the complete command for this step.

Figure 18. Creating the DayTrader properties file
Creating the DayTrader properties file

The second step updates the properties file created in the first step with a key-value pair that provides the application name. This is necessary for successful deployment of the Apache DayTrader application. Click Add Step and create a new step called Add application name. Figure 19 shows the command for this new step.

Figure 19. Adding the application name
Adding the application name

The third step will actually import the DayTrader application binaries and store them locally on the Rational Automation Framework for WebSphere server. Click Add Step again and create a new step with the name Get application binaries. Figure 20 shows the command for this new step.

Figure 20. Retrieving the DayTrader application binaries
Retrieving the DayTrader application binaries

Before running the project, you need to ensure the correct folders exist on the Rational Automation Framework for WebSphere server. On the machine hosting the Rational Automation Framework for WebSphere server instance you are using, make sure the <RAFW_HOME>/users/environments/DayTrader/cells/<CELL_NAME>/clusters/<CLUSTER_NAME>/apps/properties folder exists. After verifying or creating that folder on the Rational Automation Framework for WebSphere, simply click Start Project and then click Execute to begin the job. Rational Automation Framework for WebSphere will direct you to a details page where you can monitor the status of each step in the project.

When the project is complete, you can verify that it had the intended results by checking for the presence of the following two files:

  • <RAFW_HOME>/users/environments/DayTrader/cells/<CELL_NAME>/clusters/<CLUSTER_NAME>/apps/properties/DayTrader2-EE5.properties
  • <RAFW_HOME>/users/environments/DayTrader/cells/<CELL_NAME>/apps/media/DayTrader2-EE5.ear

Note that the name of the properties and EAR file may vary based on the application name you used during the manual installation earlier in this process.

Updating the Rational Automation Framework for WebSphere project

You could use the existing DayTrader Rational Automation Framework for WebSphere environment and RAFW_DayTrader_CloudBurstCell0 project to reapply the Apache DayTrader application configuration to subsequent WebSphere CloudBurst pattern deployments. First, though, you are going make two changes to the existing project.

Add a step to deploy the application you imported. To do this, click the Projects link in the left-hand toolbar of the Rational Automation Framework for WebSphere console, then click the RAFW_DayTrader_CloudBurstCell0 project. Once on the project details page, click Add Step and enter Deploy DayTrader as the name for the step. Figure 21 shows the command to deploy the application.

Figure 21. Deploying the DayTrader application
Deploying the DayTrader application

Now, you are going to replace the composite RAFW_WAS70_ND_CONFIGURE library call in the project with calls to individual libraries. While you certainly could keep the single step to call the RAFW_WAS70_ND_CONFIGUE composite library, replacing this single step with multiple steps allows you to perform only the necessary configuration actions for the Apache DayTrader application environment. You will still be using shipped configuration libraries, so you will not have to supply any scripting of your own.

The benefit of breaking the project up into multiple steps that only perform the configuration actions you need is that you can significantly decrease the overall deployment and configuration time for your application environment.

Specifically for the setup of your Apache DayTrader application environment, you will make use of the following, pre-defined Rational Automation Framework for WebSphere libraries:

  • RAFW_was_common_configure_environments
  • RAFW_was_common_configure_resources
  • RAFW_was_common_configure_security
  • RAFW_was_common_configure_servers
  • RAFW_was_common_configure_service_integration
  • RAFW_was_common_configure_users_and_groups

You will create six new steps to use these six libraries. Each of the steps will have an Inline property whose value maps to one of the libraries above. Figure 22 shows the step declaration for using the RAFW_was_common_configure_environments library.

Figure 22. Using the RAFW_was_common_configure_environments library
Using the RAFW_was_common_configure_environments library

The Inline property is set to RAFW_was_common_configure_environments, thus ensuring the step will result in a call to this library. Notice the echo statement in the Command field. Rational Automation Framework for WebSphere requires you to supply a valid command for each step. When executing this step in the project, Rational Automation Framework for WebSphere will first invoke the command and then call the library specified in the Inline property.

There is one more step to add to your project. The final step in the project will start all the processes in the cell including the Deployment manager, node agents, and application server cluster. To do this, simply add a new step named RAFW_start_cell. In the Inline property of the new step, select the RAFW_start_cell library and remember to provide a valid command (echo 'calling RAFW_start_cell' to follow our model). That is all you have to do in order for Rational Automation Framework for WebSphere to start the cell's processes.

When you finish creating the steps, you should end up with a project similar to the one in Figure 23.

Figure 23. The updated Rational Automation Framework for WebSphere project
The updated Rational Automation Framework for WebSphere project

In the project we just finished, the initial step which calls the RAFW_WAS_70_ND_Configure library is simply disabled. If you decide later to return to simply applying all of the configuration, not fine-tuning with several steps, you can enable that step again and disable or remove steps 2-6.

If you wish, you can further tune the project by selecting exactly which configuration actions execute for each of the libraries in use. To do this, click the Libraries link in the left-hand toolbar of the Rational Automation Framework for WebSphere console and select the desired library. You will see a list of different configuration actions at different scopes; you can selectively enable or disable each of those steps. In this case, we will keep the default behavior and leave all of the actions enabled.

At this point, you have completed the necessary setup for your Rational Automation Framework for WebSphere environment and project.

Kick off a new deployment

Now you are ready to deploy the WebSphere CloudBurst pattern you created earlier. The difference is that this time both the Rational Automation Framework for WebSphere project and Rational Automation Framework for WebSphere environment exist and they reflect the information and configuration actions necessary to completely automate the construction of the Apache DayTrader application environment.

This time when you deploy the WebSphere CloudBurst pattern, the next thing you should see is an up and running WebSphere Application Server cell with the DayTrader application installed, started, fully configured, and ready to use.

To start the deployment, log back into the WebSphere CloudBurst console and navigate to the Patterns page. Select the pattern you created earlier, the one with the Rational Automation Framework for WebSphere integration script package, and then click the deploy icon in the upper right-hand toolbar. Just as you did last time, you will go through the process of configuring each pattern part for deployment. Figure 24 shows the configuration data for the integration script package.

Figure 24. Script package configuration data
Script package configuration data

Notice that the only difference between the first deployment and this one is that the RAFW_AUTOMATION_PLAN (or the project name) changes. This project did not exist before the first deployment, but the script package automatically created it during the first deployment. Since then, you updated the Rational Automation Framework for WebSphere project (and the environment) and you want to ensure that this deployment results in the invocation of the updated project. This set of configuration data does just that.

It is worth noting that at this point you could lock the information for the integration script package into the pattern. This prevents data-entry errors during deployment and essentially ties a particular pattern to the specified Rational Automation Framework for WebSphere project and environment. However, if you lock these values into the pattern and then lock the pattern itself, you cannot change the reference to the Rational Automation Framework for WebSphere project and environment unless you clone the pattern.

Once you configure each part, simply click OK and let the deployment process begin. When the deployment is complete, the WebSphere CloudBurst interface should show that the virtual system is in the started state as seen in Figure 25.

Figure 25. The started DayTrader virtual system
The started DayTrader virtual system

If you log into the Rational Automation Framework for WebSphere console, you should see that two jobs successfully completed (like in Figure 26):

Figure 26. Successfully completed Rational Automation Framework for WebSphere jobs
Successfully completed Rational Automation Framework for WebSphere jobs

The first job, in this case WCA_ENV_UPDATE_52, updated the Rational Automation Framework for WebSphere DayTrader environment with information about the new WebSphere Application Server cell. This ensures that for information that varies from deployment to deployment (such as host names, cell names, and node names), the Rational Automation Framework for WebSphere environment contains the correct, updated data. The project used to create this job, WCA_ENV_UPDATE, ships with the Rational Automation Framework for WebSphere product and the Rational Automation Framework for WebSphere integration script package in the WebSphere CloudBurst pattern automatically invokes it during deployment.

At this point, you can login to the WebSphere Application Server administration console. In the enterprise applications listing, you should see the DayTrader2-EE5 application in the started state.

Figure 27. The started DayTrader application
The started DayTrader application

As before, you should be able to access the DayTrader configuration page, set up and populate the databases, and verify the application is working.


In conclusion

You have finished setting up WebSphere CloudBurst and Rational Automation Framework for WebSphere for the Apache DayTrader application environment:

  • You started by deploying a WebSphere CloudBurst pattern with the special Rational Automation Framework for WebSphere integration script package.
  • Once the WebSphere Application Server cell was ready, you manually installed, configured, and verified the Apache DayTrader application and its dependencies.
  • You then imported the configuration of the setup and updated the automatically generated Rational Automation Framework for WebSphere environment.
  • You modified the Rational Automation Framework for WebSphere project to apply only the configuration actions necessary, deployed the DayTrader environment, and started all the cell's processes.
  • Finally, you deployed a WebSphere CloudBurst pattern with the integration script package, pointed it at the previously configured Rational Automation Framework for WebSphere environment and project, and saw the automated construction of both the cell and Apache DayTrader application environment.

You now have a WebSphere CloudBurst pattern and a Rational Automation Framework for WebSphere project that you can use to reliably and rapidly reconstruct the entire Apache DayTrader environment whenever it is necessary.

Setting up non-trivial J2EE application environments can be time-consuming, complex, and nearly impossible to do in a consistent manner but if you leverage WebSphere CloudBurst to deliver WebSphere Application Server cells, you can do it with unprecedented speed and use the out-of-the-box WebSphere configuration actions from Rational Automation Framework for WebSphere to configure complex application environments within those cells.

Best of all, WebSphere CloudBurst patterns and Rational Automation Framework for WebSphere projects codify the end-to-end process of setting up a WebSphere Application Server cell and configuring an application environment in the cell. This means you can be confident in your ability to repeatedly set up the same application environment whenever it is necessary.

Simply put, WebSphere CloudBurst and Rational Automation Framework for WebSphere combine to make setting up J2EE application environments easier, faster, and more consistent than ever before.

Acknowledgments

I'd like to acknowledge Ruth Willenborg, David Brauneis, and Leigh Williamson for their contributions to this article.

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 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, WebSphere, Rational, Java technology
ArticleID=500976
ArticleTitle=WebSphere CloudBurst plus Rational Automation Framework for WebSphere
publish-date=07162010