ShowTable of Contents
Introduction and proposed architecture
Managing clients and their plug-ins in an open environment
It sometimes makes sense to leave users completely in charge of their workstations, giving them complete latitude on installation and product and software versions. However, it can turn into an IT administration headache when direct management is required, for example, to make sure that a certain component has been brought to a required service-pack level to ensure compatibility with a company server.
This is particularly true for modular client software such the IBM® Sametime® client which, through its underlying Eclipse and Lotus® Expeditor platform, offers infinite customization possibilities through the addition of new plug-ins or extension of existing ones.
To mitigate this problem, this article describes and implements a lightweight and extensible framework to track and manage the configuration information of the Sametime client and plug-ins inside an organization.
Framework architecture
Figure 1 illustrates the framework architecture.
Figure 1. Framework architecture
The proposed framework is composed of two parts:
- An extensible client-side component, whose role is to gather information about the Sametime client in which it is installed, and to transmit this information to the server side component.
- A server-side component, whose role is to gather the information sent by the various client components, store it, and make it available to any kind of administrative application to generate reports, trigger upgrade reminder emails to users, etc.
In this implementation, the framework is used to track the various clients, their installation platform (operating systems) and the plug-ins installed on them. Reports are generated, giving the Sametime administrator an overview of the Sametime client usage in his/her organization.
Let's now have a detailed look at how the client component is implemented.
Client-side component
The client-side component takes advantage of the Eclipse and Expeditor platform on which the Sametime client is built to offer extensibility of its own. It is implemented as a plug-in that provides an extension point allowing other plug-ins to receive information about the configuration of the Sametime client on which they're installed.
This allows any number of other plug-ins to receive the information and use it for whatever they want. We propose a number of possible extension scenarios later in this article. Also, for our purposes here, we have implemented a second plug-in that uploads the information to the server-side component, where it is used to generate reports.
The com.ibm.sametime.configurationwalker plug-in
The configurationwalker plug-in is the core of our framework. It collects the configuration information about the client on which it is installed, and defines the “com.ibm.sametime.configurationwalker” extension point that allows other plug-in to receive it.
The logic to collect the client information is encapsulated in the
AbstractConfigurationWalker class of the plug-in. In its startWalk() method (see listing 1).
The plug-in starts by collecting generic information about the client platform, such as the operating-system name, the hardware architecture (for example, CPU type and bitness). It also retrieves the client version by reading the “Bundle-Version” header of the com.ibm.collaboration.realtime.core plug-in, which is the main plug-in of the Sametime client.
Listing 1. Collecting the client basic information
String clientVersion = Platform.getPlugin("com.ibm.collaboration.realtime.core").getBundle().getHeaders().get(BUNDLE_VERSION_HEADER_NAME).toString();
int pos = clientVersion.lastIndexOf('.');
clientVersion = clientVersion.substring(0, pos);
fireConfigurationWalkStarted(Platform.getOSArch(), Platform.getOS(), Platform.getWS(), clientVersion);
In a second step, the component requests from the platform the list of installed plug-ins, iterates over it and, for each installed plug-in, reads the plug-in ID and its version (see listing 2.). As it is collected, this information is transferred to any other plug-in that may be listening to it.
Listing 2. Collecting the installed plug-ins information
IPluginDescriptor descriptors = Platform.getPluginRegistry().getPluginDescriptors();
for (IPluginDescriptor descriptor : descriptors) {
try {
Plugin plugin = descriptor.getPlugin();
if (plugin != null) {
Version version = new Version(plugin.getBundle().getHeaders().get(BUNDLE_VERSION_HEADER_NAME).toString());
firePlugin(plugin, version);
}
The last responsibility of the configurationwalker plug-in is to define the mechanism by which other plug-in can receive the configuration information to use it. For this purposes, it uses a Listener design pattern by defining an interface named ConfigurationWalkerListener which must be implemented by any plug-in wishing to receive the configuration information (see listing 3.).
Listing 3. The ConfigurationWalkerListener interface
public interface ConfigurationWalkerListener {
public void configurationWalkStarted(String osArch, String os, String windowSystem, String clientVersion);
public void plugin(Plugin plugin, Version version);
public void configurationWalkCompleted();
}
By invoking the method of the class implementing this interface in the receiving plug-ins, the configuration plug-in can send them the information, as well as notify them that the “configuration walk” has started or is complete. We discuss how such a receiving plug-in can be implemented in the following section.
The com.ibm.sametime.configurationemitter plug-in
The role of the configuration emitter is to send the configuration information it receives from the configuration walker to the server component. To do this, the ConfigurationEmitter class of the plug-in implements the ConfigurationWalkerListener interface defined by the configuration walker plug-in as follows:
When configuration information is passed to it through the configurationWalkStarted() and plugin() methods, it is stored in a SerializedConfiguration object (see listing 4).
Listing 4. Receiving and storing the configuration information
@Override
public void configurationWalkStarted(String osArch, String os, String windowSystem, String clientVersion) {
config = new SerializedConfiguration(osArch, os, windowSystem, clientVersion);
}
@Override
public void plugin(Plugin plugin, Version version) {
config.addPlugin(String.valueOf(plugin.getBundle().getBundleId()), version.toString());
}
Once the configuration collection is complete, the configurationWalkCompleted() method is called. This method turns the SerializedConfiguration object into an XML stream and sends its via HTTP to the server application (see listing 5).
Listing 5. Sending the configuration information to the server
public void configurationWalkCompleted() {
try {
URL url = new URL("http://dubxpcvm610.mul.ie.ibm.com:9080/SametimePluginChecker/PluginChecker");
HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setDoOutput(true);
connection.setRequestMethod("POST");
connection.setRequestProperty("Content-Type", "text/xml");
OutputStream out = connection.getOutputStream();
config.xmlSerialize(out);
out.close();
connection.getInputStream().close();
In its plugin.xml, the configurationemitter plug-in declares that it extends the “com.ibm.sametime.configurationwalker” extension point, and that the class implementing the ConfigurationWalkerListener interface is ConfigurationEmitter.
This allows the configurationwalker plug-in to send to the configurationemitter plug-in the configuration information, which it, in turn, sends to the server component.
We next look at what the server component does with this information.
Server-side component
The server-side component is a simple servlet packaged in a Java
TM EE (JEE) enterprise application. Its role is twofold:
- First, to receive the configuration information sent to it by the various Sametime clients that have the configurationwalker and configurationemitter plug-ins installed and store it in a database.
- Second, to generate reports based on that information, to be displayed on Web pages to the administrator.
Receiving the configuration information
As shown in listing 6, the configurationemitter plug-in sends the data to the server by POSTing it as an XML stream. On the server side, our PluginCheckerServlet servlet must therefore implements its doPost() method to handle the data.
The doPost() method implementation receives the XML representing the configuration information, transforms it back into a SerializedConfiguration object, and saves it in a database.
Listing 6. Receiving configuration information on the server
// Get the configuration information from the client
SerializedConfiguration serializedConfiguration = SerializedConfiguration.xmlDeserialize(request.getInputStream());
// Add or update it in the db
if (! getPluginCheckerDbClient().addSametimeClientInstance(serializedConfiguration)) // Add it, or if it was there already ...
getPluginCheckerDbClient().updateSametimeClientInstance(serializedConfiguration); // ... update it
// Clear the associated plugins and add the new ones
getPluginCheckerDbClient().clearClientPluginList(serializedConfiguration);
for (int i=0 ; i<serializedConfiguration.getPluginCount() ; i++) {
getPluginCheckerDbClient().addSametimePlugin(serializedConfiguration.getPlugin(i));
getPluginCheckerDbClient().addPluginToClient(serializedConfiguration, serializedConfiguration.getPlugin(i));
}
Over time, as the Sametime clients publish their configuration information to this application, the database represents a snapshot of the various clients deployed in the organization as well as the plugins installed on them. This information is ready to be exploited by the Sametime administrator.
Generating report based on configuration information
Depending on their needs, administrators can manipulate the data stored in the database to generate any kind of report. One example could be a report stating which workstation runs a certain version of a plug-in whose support in the component is being sunsetted, so that the administrator can notify end users.
The code provided with this article implements a couple of example reports, such as the list of Sametime client versions currently used in the organization, divided by the operating system on which they're installed.
This report can be accessed at the following address---after deploying the server-side component and substituting “yourserver.yourdomain.com” with the fully qualified name of the server on which it is deployed (instructions for deploying are provided in Section 3.2:
To generate the report, the PluginCheckerServlet implements the doGet method to make it query the database for the information it needs. The formatting of the report is then done by use of a JavaServer Pages (JSP) page.
Figure 2. An example report
Building and deploying the code provided with this article
All the code presented in this article is available in the accompanying attachment. Step-by-step instructions on how to set up or modify the development environment are beyond the scope of this article; however, here are a few pointers if you wish to do so:
- The code was written and tested using Eclipse 3.7 with the Web Tools Platform (WTP) tools, which you can obtain by downloading “Eclipse IDE for Java EE Developers” from the Eclipse Downloads site.
- The third-party libraries used are the JEE 5 SDK, available from Oracle and Apache Derby (an open-source Java database).
- The archive provided with this article contains the Eclipse workspace. You need to unzip it, open it using Eclipse, and update the location of the Java EE 5 SDK and Apache Derby JARs in the User Libraries panel (via Window --- Preferences --- Java --- Build Path --- User Libraries).
You can deploy the client-side component in the Sametime client by installing the pre-built update site (com.ibm.sametime.configurationchecker.updateSite), using the Tools --- Plug-ins --- --- Install Plug-ins from the Sametime client menu.
You must also add the following entry to the plugin_customization.ini file of the Sametime client (located in
/rcp/plugin_customization.ini), setting its value to the URL of the server where the server-side component can be accessed (for example, http://myserver.mycompany.com:9080):
com.ibm.sametime.configurationemitter/serverUrl=<server fqdn>
You can deploy the server-side component by exporting the SametimePluginCheckerApp enterprise application as an EAR file (File --- Export --- Java EE --- EAR File menu in Eclipse) and deploying it on your application server.
Debugging the Sametime plug-ins requires that the Sametime client is installed on the workstation (at version 8.5 or later) with the matching Lotus Expeditor toolkit.
Scenarios for extension and customization
This framework can be leveraged to do much more than simple reporting. In particular, the following extension scenarios come to mind:
- The server-side component could be customized to allow the administrator to take some action based on the information in the report; for example, by allowing him to send an email to all the users running a version of the client that is about to be sunset in the organization. The recipients of the email could be selected via a custom query (for example, all users running this version of the Sametime client on that operating system).
- The client-side component can also be extended to take automatic action based on the current user configuration, for example, by issuing a warning message to the user via a dialog box if he is running an obsolete version of a given plug-in. You could to this by writing a plug-in that implements the extension point described in this article to listen to the user configuration, check it, and react if it doesn't meet certain criteria.
Conclusion
In this article, we have shown how it is possible to take advantage of IBM Sametime's extensible platform to create a lightweight and customizable framework that collects information about the various Sametime clients deployed inside an organization, as well as the plugins installed on those clients, for the purpose of generating reports for an administrator.
Tell us what you think
Please visit this link to take a one-question survey about this article:
Resources
- The Apache Derby homepage describes Derby, the open-source Java database.
About the author
Olivier Bernin is a Software Architect based at the IBM's Dublin Software Lab, Ireland. He is currently in charge of the Microsoft Office Integration and Proxy Server components of the IBM Sametime product. Prior to this assignment, he was involved in the development of Sametime Advanced. Olivier can be contacted at obernin@ie.ibm.com.