Introduction

Before starting development of a Service-Oriented Architecture (SOA) project, you need to make the development environment ready. There are a variety of environments that you may need to prepare in a project development life cycle, including developer, integration, test, solution demo, and customer production environments. In each environment, you need to properly install and configure a variety of software.

Assume that there's an XYZ project, which requires 12 engineers (nine developers and three testers) and 16 machines (each engineer has one machine, two machines are integration servers, and the other two machines are test servers). In this example, the XYZ project is an integrated case management solution for social service, which is built on the IBM SOA technology stack. The software required by the XYZ project includes:

• IBM Rational® Software Architect
• IBM WebSphere® Integration Developer
• IBM WebSphere Process Server
• IBM DB2® Universal Database™
• IBM Content Manager

In this scenario, almost all of the five applications should be installed and configured properly on almost all of the 16 machines. Such repeatable tasks are time-consuming and error-prone, which has been a major challenge in most large engagements.

An automatic deployment toolkit, named Automatic-DT, can handle this problem. Automatic-DT is written mostly with Python scripts. It helps you install and configure deployment nodes with several automatically installed and configured IBM software products. It also helps testers and developers refresh a build in their daily tests or integration life cycle. Plus, after proper packing, you can use it in a customer environment for solution deployment.

This article series covers the following topics:

• Part 1 provides an overview of Automatic-DT.
• Part 2 and Part 3 demonstrate how to build automatic management scripts for IBM WebSphere Application Server, DB2, and Content Manager.
• Part 4 introduces a subtoolkit, named Automatic-BT, which enables automatic build-deploy-Build Verification Test (BVT) on SOA projects.

Back to top

Deployment toolkit overview

As shown in Figure 1, the Automatic-DT is divided into several components:

• Repository server: Stores software installation images. It can be an HTTP/FTP server or a local file folder.
• Controller: The script's execution entry. In the controller, a list is used to store all software needed to be installed and uninstalled by sequence. The list can be modified (for example, adding or removing its elements, changing the elements order, and so on).
• Specific components for software installation and uninstallation: In charge of installing, uninstalling, and configuring specified software. The example in this article uses the specific components shown in Table 1.

Usage

Figure 2 shows the steps required to use Automatic-DT.

The steps are:

1. An infrastructure architect must design an operation model based on project requirements. The design operation model shows which software products should be installed on which machine and on which operating system. For example, in the XYZ project, the design operation model shows that Content Manager, DB2, WebSphere Process Server, and Tivoli Directory Server need to be installed on 16 machines, and among them four machines are IBM Power PC® with IBM AIX®, while others are ThinkCentres with Microsoft® Windows® XP.
2. A deployment engineer (who is the user of Automatic-DT) modifies Automatic-DT configuration files based on the design operation model.
3. The deployment engineer executes the Automatic-DT scripts, then everything is ready after the scripts are successfully finished.

You can see that Automatic-DT is useful if you're installing the same software on a large number of machines. For example, in the XYZ project you only need to prepare two different Automatic-DT configuration files: one for testers and one for developers. Then repeat executing Automatic-DT scripts until all machines are prepared.

Back to top

Extensions

Automatic-DT is written with Python. Python has several features that are helpful to Automatic-DT:

• Python is an object-oriented (OO) programming language, so you use an OO design on Automatic-DT.
• Python provides multiplatform support, so Automatic-DT can run on different platforms easily.
• The most important feature about Python is that it's a script language, which means it can be executed directly and doesn't need to be compiled. So Automatic-DT can be modified arbitrarily.

Automatic-DT is designed in a flexible way, which makes extension easy. To extend Automatic-DT to support the installation, removal, or configuration of a new software product, you must complete two steps:

1. Write the new software product's management scripts.
2. Integrate it to the controller.

Figure 3 shows an example of this for DB2. In this sample of the Automatic-DT directory structure, the DB2 management scripts are packaged in the DB2 directory.

The config directory contains the DB2 silent installation's response files. DB2Properties.py contains other configuration properties, such as the DB2 installation destination directory, shown in Listing 1.

##########################################################
##Installation configuration for DB2 Enterprise Edition ##
## Must be modified to correct path                     ##
##########################################################
DB2SrcExecutableFile = 
  r"C:\backup\cm\db2\Db2Enterprise\setup.exe"

DB2FixpackExecutableFile = 
 r"C:\backup\cm\db2\DB2Fixpack\fixpack\ESE\setup.exe"

#DB2 Installation Destination Dir
DB2InstallDestinationBaseDir = "C:\\"

DB2InstallDestinationDir = 
  os.path.join(DB2InstallDestinationBaseDir, 
   "IBM", "SQLLIB")

The functions of installation/uninstallation/configuration of DB2 are implemented in DB2.py (see Listing 2).

class SampleDB2():
 def executeDB2Installation(self):
  #operation implementation
 def executeDB2UnInstallation(self):
  #operation implementation
 def createDatabase(self, dbName):
  #operation implementation
 def deleteDatabase(self, dbName):
  #operation implementation
 def executeSQLScripts(self, sqlScriptFile):
  #operation implementation

After the DB2 directory is ready, add new control sentences into XYZProject.py, like what's shown in Listing 3, which causes DB2 installation functionality to come into effect, as do other functionalities.

def installProduct(self):
 db2 = SampleDB2()
 log('Begin to install DB2.')
 if not db2.executeDB2Installation():
  log('Failed to install DB2.')
  sys.exit()
 log('Begin to create and populate database SampleDB.')
 db2.createDatabase('SampleDB')
 db2.executeSQLScripts('Sample1.sql')
 db2.executeSQLScripts('Sample2.sql')
 db2.executeSQLScripts('Sample3.sql')
 self.db2 = db2
 log('End of creating and populating database MERGE.')
 # other software installation
def uninstallProduct(self):
 if self.db2:
  log('Begin to uninstall DB2.')
  if not self.db2.executeDB2UnInstallation():
   log('Failed to uninstall DB2')
   sys.exit()
  log('End of uninstalling DB2.')		
 #other software uninstallation

Back to top

Conclusion

This article introduced an automatic deployment toolkit named Automatic-DT. Automatic-DT has three functionalities:

• Installs and configures software stack: You can use Automatic-DT to silently install and configure a list of IBM software, such as WebSphere Application Server or WebSphere Process Server, IBM DB2 Universal Database, Content Manager, Rational Software Architect, and WebSphere Integration Developer. Automatic-DT is comprised of an online repository server and the installation scripts. The repository is an HTTP server storing software installation images and sample configuration files. When running on the deployment node, the scripts fetch the software installation images from the server, unpack it, and perform the installation and configuration as programmed.
• Fetches and deploys project build: Automatic-DT periodically fetches the specified project build from the build server, then deploys the build upon the application server.
• Notifies you of project BVT and results: After the specified build is deployed, the Automatic-DT automatically runs the specified BVT to make sure that the current build is completed and available for further Functional Verification Tests (FVTs) or System Verification Tests (SVTs). After the BVT is completed, the test result is sent out for notification by e-mails.

Automatic-DT is built in a flexible way, and clients can easily make their own specific configurations or extensions. Stay tuned for the following three parts of this series, which will show the details of the management script implementations of the WebSphere Application Server, DB2, Content Manager, and the Automatic-BT subtoolkit.

Resources

Learn

• Learn more about Python.
  
  
• Visit the DB2 Information Center.
  
  
• Learn more about Information Integrator for Content and eClient, both components of IBM Content Manager.
  
  
• Browse the IBM Content Manager Information Center and the IBM Content Manager product page.
  
  
• Visit the IBM WebSphere Application Server Information Center.
  
  
• Learn more about IBM Tivoli Directory Server.
  
  
• Learn more about IBM WebSphere® Integration Developer.
  
  
• Learn more about IBM WebSphere Process Server.
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• Play in the IBM SOA Sandbox! Increase your SOA skills through practical, hands-on experience with the IBM SOA entry points.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• Check out a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

Discuss

• Participate in the discussion forum.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  

About the authors

HeQing Guan (Hawking) is a senior software engineer on the IBM Global Business Solution Center team. He has a doctorate from the Chinese Academy of Sciences and has worked in the SOA field for almost 5 years.

Qiang Bai has worked as a software engineer with the Global Business Solution Center in CSDL. In addition to focusing on software configuration management (SCM) products, he is responsible for developing the solution assets built on IBM's Service-Oriented Architecture (SOA) methodology.

YuLin Chen is a software engineer in the IBM Global Business Solution Center. He is responsible for developing the solution assets built on IBM's Service-Oriented Architecture (SOA) methodology.

YaoFei Zhu (Richard) joined the IBM China Development Lab in 2005 and has worked in Linux on POWER and on Global Business Solution Center (GBSC) teams as a system developer, application developer, and infrastructure architect. He has more than 6 years of experience in AIX, Linux, System p, System x, storage, and SOA.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Deployment toolkit overview
• Usage
• Extensions
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: DB2 Enterprise
• Demo: DB2 serving ATOM feed
• Webcast: A smarter way to successful SOA - Information as a trusted strategic asset
• Briefing: Information on Demand
• Buy: DB2 Enterprise

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers