WebSphere eXtreme Scale Best Practices for Operation and Management

Chapter 5. Grid configuration 77

򐂰 To configure client properties as a system property in either a stand-alone or WebSphere

Application Server configuration, use:

-Dobjectgrid.client.props=file_name

The value is the name of a file in the file system (fully qualified or relative to the location of

the script); it cannot be a name based on the class path.

򐂰 To configure client properties as a programmatic override, use the

ClientClusterContext.getClientProperties method. With this method, the data in the object

is populated with the data from the properties files. You cannot configure security

properties with this method.

5.1.5 Externalizing the server XML configuration in WebSphere Application

Server

A common pattern when running WebSphere eXtreme Scale in WebSphere Application

Server is to deploy Java EE applications that include the required configuration files. When

the run time detects the presence of the server XML files in the META-INF directory of a Java

EE module, it launches the WebSphere eXtreme Scale container automatically.

Typically, the Java EE modules are deployed on a cluster, which effectively turns the cluster

members into WebSphere eXtreme Scale containers. The grid that is hosted by those servers

is registered automatically with the default catalog service domain and, therefore, can be

accessed immediately from client applications that are running in the same cell. This method

brings benefit in terms of integration, but changes in the configuration require a rebuild of the

Java EE applications because they contain the XML files.

In this section, we describe an alternative method that allows for a separation of those XML

files and the Java EE application. Although not the default, a number of clients use this

method already and are very satisfied with it.

Overview

Instead of relying on the run time to launch the WebSphere eXtreme Scale container, we use

a simple servlet to launch it. The web module that contains the servlet is deployed as a

standard EAR file on a WebSphere Application Server cluster. Figure 5-2 illustrates the steps

when we started the WebSphere eXtreme Scale container.

78 WebSphere eXtreme Scale Best Practices for Operation and Management

Figure 5-2 Using the servlet life cycle to start the grid container

We used these steps to launch the WebSphere eXtreme Scale container:

1. The servlet is configured to load on start-up, meaning that the servlet’s init() method is

called when the web module is started, which happens when this application .ear is

started.

2. The init() method looks up two URLs that point to the ObjectGrid descriptor XML file and

the deployment policy XML file.

3. The init() method then uses the XML files in a WebSphere eXtreme Scale administrative

API call to launch the grid container.

Servlet implementation

Example 5-5 shows the implementation of the actual servlet. The init() method performs a

lookup of the two URLs that refer to the XML files. It then uses those XML files when it

initializes the grid container. You can use this code as a starting point for your own

implementation. Change the name of the package and the name of the actual servlet class if

you want.

Example 5-5 Implementation details of WXSContainerServlet

package com.ibm.itso;

import java.net.URL;

import javax.naming.InitialContext;

import javax.naming.NamingException;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import com.ibm.websphere.objectgrid.ObjectGridException;

Java build path: For the imports to work, wsobjectgrid.jar must be on the build path of

the integrated development environment (IDE).

WAS Application Server

WebSphere eXtreme Scale

grid container

URL URL

3

2 2

Web application

Servlet.init()

1

file:///config/objectGrid.xml

file:///config/objectGridDeployment.xml