Using IBM workload Deployer and collaborative Application lifecycle management

The authors explore the complexities involved in trying to create a workable, repeatable collaborative lifecycle Management system (CLM, also known as collaborative Application Lifecycle Management), which can be used in ibm®http://www.aliyun.com/zixun/aggregation /13387.html "runs on >websphere®application Server and uses db2® as a database.

Cloud applications continue to become more complex, making the task of rapidly delivering cloud solutions more difficult, and cloud solutions include: One-off production-level applications, applications within deployment packages, and operating systems, or even a complex virtual application pattern (a cloud component/ Middleware services and a policy for configuration or virtual system mode (one or more virtual images and applications that implement a deployment topology).

To address this challenge and explore this complexity, this article demonstrates how to create a viable, repeatable, collaborative lifecycle management system that runs on top of the WebSphere creator Server and uses DB2 as a database. The IBM workload Deployer and Rational®team concert CLM features are used in this paper. The end result is that testers can reproduce a topology in a daily dynamic build that validates application defects and builds, executes smoke tests (smoke test), and supports other test activities.

Let's get started.

IBM Workload Deployer (IWD) is a hardware device that provides users with an environment that enables them to deploy middleware-repeatable patterns (or repeatable solutions) on a private cloud.

The team's initial problems include how to overcome the complexity challenges of building a viable CLM system that runs on WebSphere, using DB2 as a database provider, in a repeatable, time-saving manner. The parameters of this problem include:

To change this approach, we used IWD and integrated automation (such as bash and Python scripts, and WSAdmin) throughout the development of the IWD script package to provide a repeatable solution. The team spent 60 minutes using the following steps.

Step 1: Build the Basics

The solution pattern topology in this article uses a ready-made Red Hat Enterprise linux®64-bit websphere 8.0.0.1 Receptacle Deployment virtual image (WebSphere ND version preinstalled 8.0.0.1 and IBM installation Manager 1.4.4 virtual images), and with the added script package, CLM is installed, configured, deployed to this virtual image with a ready-made RHEL 64-bit DB2 virtual image. Figure 1 illustrates the CLM topology that IWD VSP maps to, which is the visual representation of the VSP that is discussed in this article.

Figure 1. CLM topology mapped to by IWD VSP

In this case, CLM runs on the WebSphere V8.0.0.1 server, and CLM data is stored on the DB2 V9.7.4 server.

One of the best assets of IWD is that it can establish relationships between different virtual images in the schema. Existing relationships, such as the arrows between virtual system parts, enable you to communicate openly between the CLM data and the application itself, which in turn will lead to a more user-friendly environment for the multiple-server design. Figure 2 shows the relationship established by IWD.

Figure 2. The relationship established by IWD

The arrows show that the WebSphere 8.0.0.1 server identifies the DB29.7.4 server. Therefore, communication between two servers is not a complex battle that users must exploit (through barriers such as firewalls, proxy servers, etc.).

After the foundation of the solution is established, the next step is to prepare the WebSphere server and the DB2 server for the CLM application deployment.