Skip to main content

If you don't have an IBM ID and password, register here.

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

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

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.

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

All information submitted is secure.

Application environment migration with WebSphere CloudBurst

Preserving the fidelity of application environments through patterns

Dustin Amrhein, Technical Evangelist, IBM
Author photo
Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, Dustin worked on the development of Web services infrastructure and Web services programming models. In addition, Dustin lead the technical effort in the development of a Java RESTful services framework. In his current role, Dustin is a technical evangelist for emerging technologies in IBM’s WebSphere portfolio. His current focus is on WebSphere technologies that deliver cloud computing capabilities, including the WebSphere CloudBurst Appliance.
Ruth Willenborg, Senior Technical Staff Member, IBM
Ruth Willenborg
Ruth Willenborg is a Senior Technical Staff Member in IBM's WebSphere Technology Institute where she is currently working on WebSphere cloud computing and virtual appliance initiatives and is the technical evangelist for the new IBM WebSphere CloudBurst Appliance. Prior to her work on virtualization and appliance initiatives, she was the manager of the WebSphere Performance team responsible for WebSphere Application Server performance analysis, performance benchmarkingm and performance tool development. Ruth has more than 20 years of experience in software development at IBM and is co-author of Performance Analysis for Java Web Sites (Addison-Wesley, 2002) and numerous articles on both WebSphere performance and using WebSphere with virtualization technologies.

Summary:  In this tutorial, the authors demonstrate how to use WebSphere® CloudBurst to build patterns you can use to represent the configuration of both your application and application infrastructure. They also show you how to use these patterns to consistently deploy the application environment as it moves through the four life-cycle stages — development, test, QA, and production. The tutorial offers a complete, step-by-step example of using patterns to handle changing topologies, underlying platform architectures, and configuration properties.

Date:  01 Jun 2010
Level:  Intermediate PDF:  A4 and Letter (908 KB | 36 pages)Get Adobe® Reader®


Migrating the Account Management environment to test

Your development efforts for the Account Management application will now conclude so you are ready to begin testing on the environment. We propose the following goals for the migration:

  1. The custom nodes should each run on their own hosts and not be collocated with the deployment manager.
  2. The application binaries should be retrieved from a different repository.
  3. The data source should be configured to refer to a different database instance.

The changes start by going to the patterns page and selecting the Account Management Cluster — Development pattern you created previously. Clone this pattern to create a new pattern called Account Management Cluster — Test and then navigate to the pattern editor page for the new pattern.

Once in the pattern editor, remove all of the script packages from the deployment manager part. You will be adding some of the script packages back, but you need to make sure you add them in the correct order.

Next, set up the new topology by dragging and dropping a custom node from the part list on the left-hand side to the canvas on the right. The count for the custom node part increases from one to two.

Now you add the script packages back to the deployment manager part. This time start by adding the Add IBM HTTP Server node script package that ships on the appliance. This script package establishes an IBM HTTP Server in the same virtual machine as the deployment manager, thus allowing you to conserve resources in your test environment. Finally, add back the script packages to install the Account Management application and create the necessary DB2 data source.

Figure 13. The new test pattern
The new test pattern

WebSphere CloudBurst invokes script packages in the order that they appear on a pattern part. In this case, it is important to create the IBM HTTP Server instance before installing the application since it allows the application to include the server among its deployment targets, thus allowing requests for the application to route through our IBM HTTP Server instance.

The editing is not complete yet because you need to set up a WebSphere Application Server cluster. In this case though, you will not need a script package. Since you are using custom node parts, you can leverage the ability to define clusters as an advanced option for the pattern. To do this, click Advanced Options and select the Define clusters option.

Figure 14. Defining a WebSphere Application Server cluster
Defining a WebSphere Application Server cluster

As a result of selecting this option, WebSphere CloudBurst will automatically create one or more WebSphere Application Server clusters during deployment of this pattern. You will provide the configuration information that tells WebSphere CloudBurst how many clusters you want and how many cluster members you want to create on each of your custom nodes. This is done either in the pattern or during deployment.

After configuring the pattern to include WebSphere Application Server clusters, you are done with the required changes; click the Done editing link to return to the pattern detail page. At this point, you can optionally lock the pattern. You are ready to deploy.

The deployment is slightly different from last time since your pattern contains two parts. When configuring the deployment manager part for deployment, you still need to provide the necessary configuration for the application installation and data source creation scripts. In this case, change the values for this configuration data to reflect the appropriate values for your test environment.

Figure 15. New configuration data for test environment
New configuration data for test environment

In particular, change the location of the application binaries, the database username, and the database host values (but you could have changed any values necessary to ensure a successful deployment into our test environment).

Unlike the previous deployment, you do not need to provide information to create managed nodes in the cell because you included custom node parts in your pattern. As a result, WebSphere CloudBurst will automatically create the nodes and take care of federating them into the cell. You still have to provide information about the WebSphere Application Cluster you want to create: The only difference is that in this deployment, WebSphere CloudBurst will create the cluster instead of you having to do it, including a script package to carry out that configuration action.

Figure 16. Configuring the WebSphere Application Server cluster
Configuring the WebSphere Application Server cluster

The values in Figure 16 result in the creation of a single cluster which contains one member on each node. In this case, that means your WebSphere Application Server cluster will have two members because your pattern contains two custom node parts.

In this pattern, you also have to configure the custom node parts before you deploy. There are no script packages on this part, so all you need to do is provide password information. Deploy the pattern by clicking the OK button on the deployment dialog. Again, this takes you to the Virtual Systems page and when the deployment process is complete and the virtual system is in the started state, you login to the WebSphere Application Server administration console just as you did last time. The only real difference for this deployment besides the altered application and data source configuration, is that the custom nodes exist on different hosts than the deployment manager.

Figure 17. Node listing for WebSphere Application Server cell
Node listing for WebSphere Application Server cell

The CloudBurstNode and CloudBurstNode1 nodes shown in Figure 17 were created from the two custom node parts in our pattern. The CloudBurstNode0 and nodes represent the deployment manager and IBM HTTP Server instance respectively.

The key point in the migration from your development environment to your test environment is not the differences though — the real key is that the net result of these two deployments is the same. In both environments, the Account Management application runs on a WebSphere Application Server cluster and that application has access to a data source for a DB2 database. Further, you achieved this migration by simply making a few changes in a drag-and-drop interface and providing a very small amount of deploy time configuration.

The migration from one environment to the next took just a matter of minutes.

6 of 11 | Previous | Next


Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

Zone=, WebSphere
TutorialTitle=Application environment migration with WebSphere CloudBurst


Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).