The new IBM WebSphere Application Server (WAS) v6.0 software introduces the concept of Server Profiles. Profiles can be thought of as a specific server runtime environment operating within a separate instance of the JVM.

Each runtime environment has its own configuration files, logs, properties, and other attributes. Profiles can make each Java 2 Enterprise Edition (J2EE) application server runtime unique and separate from the server binaries and from other profiles. The separation of static binaries from configuration files provides a number of benefits for system administrators.

The WAS v6.0 profiles are similar to the wsinstance tool provided with WAS v5.x, but with some important differences. The wsinstance tool creates configuration files for separate JVM instances, but shares other information across instances of WAS v5.x. In contrast, profiles draw a sharp degree of separation, so much so that each profile is separately administered with its own configuration, logs, J2EE applications, and other attributes. The separation that profiles provide allows for a unique instance of WebSphere that has not been available in previous releases of WAS.

Easier Than Multiple Installs
More than one instance of the same IBM WAS product may be required on the same machine. This is often the case if the administrator desires to keep a degree of separation between applications and environments. This may be the case if you have a development group sharing the same WebSphere install instance. When using the WAS profiles, each profile runs as its own 1.4.2 JVM instance, thus providing a physical as well as a logical separation between instances of the product. This offers an advantage over multiple installs because it saves space. In addition, service updating is simpler since an administrator only needs to maintain a single set of product binaries. Profiles can also be created and deleted more easily than with whole product installs. With the separation of product binaries and profiles, it's possible for a system administrator to allow groups to have access to the profile information that defines their application server, while at the same time locking down the WAS runtime binaries.

Easier Application Updates
Another useful aspect of profiles is the staging of application updates. In this scenario, you have updated an application and wish to test it on the targeted WebSphere Application Server. The problem is that an older version of your application is already running and being used. You could uninstall the application and reinstall the new update, yet that would require you to take the application offline and then reinstall if your test fails. A solution would be to create a new profile and test it there. The test profile will be operating in its own instance of WAS and will be logically separated, thus giving you a level of security and separation should your tests fail. Of course, it only protects you while running in the context of WAS, and not if the two applications are sharing the same database or any other shared resource the two applications may access.

Figure 1 shows a typical WebSphere Application Server Network Deployment topology running with two profiles. The first is a default profile for a WAS Base instance; this profile contains information for one server. The second is a WAS Deployment Manager instance that contains two servers in the profile. Both are logically grouped within a node. A node normally corresponds to a physical computer system with a specific IP address. Associated with the application server is the embedded HTTP server, which directs requests to the application server. The embedded HTTP can be associated with a production HTTP server such as IBM's HTTP Server product based on Apache, or another third-party product.

The profile defines the characteristics of the WAS instance that is running in the context of the JVM. The profile contains all of the information that makes the server instance unique, such as port mappings, available services, data sources, JDBC providers, etc. The profile information is contained in the <WAS_ROOT>/profiles directory. Table 1 illustrates the contents of the profile directory and their functions within the WAS. A default profile is created for you when you initially install WAS v6.0.

Creating New Profiles
For one reason or another, you have decided to create a new WAS Profile. Perhaps you have two development groups that share the same install instance but have different configuration environments. Or perhaps you wish to have two versions of the same application running, but with different environments. WAS v6 supports two ways of creating a new profile: the profile creation wizard and command line.

Profile Creation Wizard
The easiest way to create a new profile is to run the Profile creation wizard tool located in the <WAS_ROOT>/bin/ProfileCreator directory. Figure 2 shows the profile creation tool that will step you through the process of creating a profile. You will need to decide the name of the profile, the directory of where the profile information will be stored, the node and hostname of the server, and any changes to the default ports. The wizard will attempt to avoid WAS port conflicts by looking at the existing configured ports. It does not attempt to look at services outside of WebSphere that may already be running on those ports during the profile creation.

Creating Profiles with the Command Line
Another way to create a profile is via the wasprofile command line. The wasprofile creation tool is located in the <WAS_ROOT>/bin directory of the application server. For Linux, the file is wasprofile.sh and for windows it's wasprofile.bat. The wasprofile command is the primary tool used to manage profiles and provides the greatest amount of flexibility. Listing 1 creates a profile called MyNewProfile.

The -profilePath specifies the location in which the profile directory should reside. Normally, profiles are placed in the profile repository directory located in <WAS_ROOT>/profiles, but this can be overridden.

The parameter -templatePath specifies the location of profile templates that will be used in creating the new profile. The profile templates directory contains a number of Ant scripts and default configurations that act as a starting point for the tool in creating a new profile. Which template is used is important when considering what instance of WebSphere you wish to create. As an example, the WAS ND version of the product supports running in three modes: standalone base application server, a managed base application server, or as a deployment manager. The specific example uses the default profile to create a standard application server.

The profile tool only supports executing one instance at a time. If you try to start another instance of wasprofile while the first one is still completing, you will receive an error message.

The -nodeName and -cellName specify the name of the node and the name of the WAS cell. A node is a grouping of servers, while a cell is a logical grouping of nodes.

The -hostName is the name of the machine on which that the profile resides.

When the profile is created, the directory structure described in Table 1 will be created in the directory location that you specified. The default profile repository is <WAS_ROOT>/profiles/. Once the profile is created, you will need to start the application server. If you used the profile creation wizard, you will have the option of starting the FirstSteps application when the profile creation is complete. FirstSteps is an easy tool to start and test your profile. You can later rerun the FirstSteps tool by going into the firststeps directory of where your profile was created.

Another way of starting your application server using your new profile is via the command line. WebSphere provides two ways of starting the application server; it is with the same command but from two different locations. The first location is the <WAS_ROOT>/bin directory. Contained here is a helper script called startServer.cmd on Windows, and startServer.sh on Linux. When starting the application server from here, you will need to specify the profile to be started. For example, if your profile was called MyNewProfile, then the command would be:

startServer.sh server1 -profile MyNewProfile

server1 is the default server name given to Application Server when the profile was created. There are a number of other commands that are contained in this directory. If you have a specific profile that you want to change the state of, then you will need to specify the -profile command. The system administrator can use the commands in the <WAS_ROOT>/bin directory to control all of the profile instances. The commands in the <WAS_ROOT>/bin directory are intended for system administrators to execute.

The other location is within the bin directory of the profile you created. If you created the profile MyNewProfile, then the startServer.sh command would be located in <WAS_ROOT>/profiles/MyNewProfile/bin. The difference here is that all of the executables stored in this directory run in the context of the newly created profile. The -profile MyNewProfile is not required to start the application server.

The reason for the difference is that the profiles can be owned by a different group aside from the system administrator who is controlling the WAS. As the owner of MyNewProfile, I may have the need to start and stop the servers in my profile, but at the same time not have the authority to start and stop servers for another profile.

Managing Profiles
The wasprofile command also supports managing profiles as well as creating them. The description below contains some of the commands that the wasprofile provides.

Deleting a Profile
When you delete a profile, it removes the named profile and its contents from the directory. Any customization or additional scripts that you may have added to the profile directory may also be deleted as well. You should use this tool rather than deleting the profile directory manually since this will prevent corruption of the profile information that WAS maintains.

./wasprofile.sh -delete -profileName profile_name | - profilePath profile_path [-debug]

Listing Additional Profiles
To list the profiles that WAS knows about, use the following command:

./wasprofile.sh -listProfiles [-debug]

To check the integrity of a profile registry:

./wasprofile.sh -validateRegistry [-debug]

Get the path of an existing profile from the name:

./wasprofile.sh -getPath -profileName profile_name [-debug]

Conclusion
Profiles in WAS v6 offer flexibility to meet growing changes in environments. With profiles it is possible to create new application servers that have a degree of separation between other J2EE applications that might be running on the server. When you create a profile, you are creating a new instance of the WebSphere Application Server that shares the same runtime binaries, yet can have a unique configuration that is separate from another WebSphere instance. The separation has advantages for setting up and maintaining your WebSphere installation.

Resources