Introduction

The RFID Tracking Kit is a powerful developer toolkit for building RFID Edge solutions. It includes example projects that you can use to build your own RFID applications. In this article, we'll provide a brief overview of the Tracking Kit and the example projects included in it, and give you a bit of background on the IBM RFID middleware framework and the programming model of the MicroBroker Application Framework (MBAF). Then, we'll take you step-by-step through the process of developing a simple RFID Edge application by customizing the example projects. The application we'll develop implements a check-in and check-out use case that behaves as follows:

1. When an object bound with an RFID tag is checked in, its RFID information is sent to the IBM RFID Premises Server.
2. Within certain interval (in this case, 60 seconds), duplicate tag information is filtered on the Edge side. Only if the interval is longer than 60 seconds can objects bound with RFID tags be checked out or checked in again.

To implement this use case, we'll develop several agents based on the example project in the Tracking Kit.

IBM RFID middleware framework

Radio Frequency Identification (RFID) technology uses radio frequency to read code information in RFID tags. An RFID system is designed to carry data in mobile transponders, called tags, and to retrieve that data in a machine-readable format.

WebSphere RFID is an on demand solution for RFID applications, that includes I/O devices, Edge devices, WebSphere Connection Server Micro Edition, and Premises Servers. I/O devices such as light trees, motion sensors, and tag-reading antennae monitor and provide feedback for the physical dock door environment. Edge devices control the I/O devices, filter tag information, and send that information on to the Premises Server for additional processing. WebSphere Connection Server Micro Edition connects the Edge Controllers, I/O devices, and Premises Server. The Premises Server provides additional processing for tags and tools that operators can use to configure and manage the RFID system. These devices compose the different domains of the IBM RFID middleware framework as shown in Figure 1.

Some of the components of the framework that we'll be concerned with are:

• Edge Controller: The Edge Controller is the device located at the edge of the RFID system. The Edge software consists of various agents that are delivered as OSGi bundles and activated on the Edge device. These agents facilitate the delivery of tag information, which is captured by the Edge device from the I/O devices, and delivered to the Premises Server using WebSphere Connection Server Micro Edition.
• WebSphere Connection Server Micro Edition: WebSphere Connection Server Micro Edition (hereafter called Connection Server) is one of the most important technologies of the WebSphere RFID device Infrastructure. It takes a publish/subscribe engine for messaging. Connection Server runs standalone as OSGi bundles. The two most important components of Connection Server that provide this messaging infrastructure are MicroBroker Bus and MicroBroker Bridge. See RFID Handbook: A Solution Guide for more information on these two components.

RFID comes with a set of example agents, all of which publish and subscribe to topics through the Connection Server. Developers can use the set of example agents as is or customize them to fit their specific business needs. To understand how the agents coordinate with each other to make the RFID application work, you need to first understand the publication and subscription model of MicroBroker.

The MicroBroker Application Framework

The following sections describe the MicroBroker Application Framework (MBAF).

The MicroBroker

The MicroBroker is intended to be a horizontal publish-subscribe (pub-sub) engine appropriate for a wide variety of vertical applications. Following are some of the key concepts in MicroBroker:

• Topic: A topic is simply the key that describes the published data. It can comprise substrings, known as levels, whic are delimited by a forward slash. An RFID application might include topics such as:
  • device/light/P1/command/readoccurred
  • device/reader/P1/signal/status
• Subscribing Client: A subscribing client connects to the MicroBroker, and then proceeds to subscribe to one or more topics. Once subscribed, matching topic publications are delivered to the client.
• Publishing Client: A publishing client connects to the MicroBroker, and then proceeds to publish data. A published topic, and its accompanying data, flow over the MicroBroker and is delivered to each of the clients that have subscribed to receive the topic.

It's common for a client to both subscribe to and publish topics. Sometimes a subscribed topic is unrelated to any topics that the client publishes, and sometimes the delivery of a subscribed topic causes the client to publish a topic and data back to the MicroBroker.

The MicroBroker Application Framework

The MBAF provides an abstract class BaseMicroBrokerAgent from which subclasses derive their own agent classes. MBAF defines an agent simply as an abstraction of an object that uses the MicroBroker. The BaseMicroBrokerAgent class encapsulates many of the functions of using the MicroBroker, including:

• Creating a MicroBroker client.
• Connecting the client to the MicroBroker.
• Maintaining the client's connection to the MicroBroker.
• Automatically subscribing to topic publications.
• Automatically decoding the data of a subscribed topic as it arrives.
• Performing publication requests on a private thread. This is important because it allows an agent to publish a topic directly from the MicroBroker thread that delivered a subscribed topic publication.
• Automatically encoding data when it's published.
• Disconnecting the client from the MicroBroker.

The most important public APIs are the start() and stop() methods described below:

• When the start() method is called, the following hook methods, which are often implemented by agents, are called:
  • starting() is called to allow the agent to perform behavior before connecting to the MicroBroker.
  • connected() is called to allow the agent to perform behavior immediately after connecting to the MicroBroker. Once this method has been called an agent can publish topics.
  • started() is called once the agent started. Since the inherited start() method is final, this method is implemented by agents that want to perform behavior as soon as they have been started.
• When the stop() method is called, the following hook methods, which are often implemented by agents, are called:
  • stopping() is called to allow the agent to perform behavior just before disconnecting from the MicroBroker.
  • disconnected() is called to allow the agent to perform behavior immediately after disconnecting from the MicroBroker. Once this method has been called, an agent must not publish topics.
  • stopped() is called once the agent stopped. Since the inherited stop() method is final, this method is implemented by agents that want to perform behavior as soon as they have been started.

Using MBAF in a Tracking Kit agent

All of the agents in the RFID Tracking Kit are inherited from BaseMicroBrokerAgent. Listing 1 shows an example of a simple agent:

				
public class SimpleAgent extends BaseMicroBrokerAgent {
    protected String[] getSubscriptions() {
      return new String[] {
        "device/switch/P1/command/on",
        "device/switch/P1/command/off" 
      };
    }
	
    protected void handlePublishArrived(String topic, Object data) {
      if (topic.equals("device/switch/P1/command/accepted")) {
        // Handle the P1 switch on command
        publish("device/light/P1/command/on") 
      } else if (topic.equals("device/switch/P1/command/off")) {
        // Handle the P1 switch off command
        publish("device/light/P1/command/off")
      } else {
        super.handlePublishArrived(topic, data);
      }
    }
  }

This agent subscribes to two topics:

• device/switch/P1/command/on
• device/switch/P1/command/off

and publishes another two topics when the subscribed topics arrive:

• device/light/P1/command/on
• device/light/P1/command/off

The RFID Tracking Kit

The Tracking Kit is a plug-in of WebSphere Studio Device Developer. As mentioned previously, it provides developers with a set of example projects that work together to implement a typical RFID application use case. You can customize these example projects to implement your own logic. The RFID Tracking Kit Developer Guide provides detailed information on developing with the RFID Tracking Kit, including:

• How to install the RFID Tracking Kit and the example projects
• An example Dock Door Receiving use case using the example projects
• A description of the example agents used in the example use case.

About Agents

An agent is the representation of a device or processing node connecting to the MicroBroker. It presents a common interface across the pub/sub system to all devices of that common type. For example, the SAMSys Reader Agent has the same interface as the Intermec Reader Agent.

Each example project in the Tracking Kit corresponds to a certain agent. To implement the Dock Door Receiving use case, these agents undertake different functions, including communicating with various device and controlling logic of the use case.

Each agent project consists of three packages: the agent package, the bundle activator package, and the constant package. The agent package has two classes:

• xxxAgent class: implements the main function of this agent project. It extends the AbstractAgent class, which extends BaseMicroBrokerAgent. xxxAgent uses either doPublish(String, Object) or doPublishWithLogging(String, Object), which are both implemented in the AbstractAgent class. All the agents override the following methods of AbstractAgent to implement their own logic:
  • getClientId() returns a unique String identifier that is used to identify individual agent instances.
  • getSubscriptions() are called by the framework when the agent is being started and returns a String array of topics that the agent would like to subscribe to.
  • handlePublishArrived(String, Object) receives messages published on subscribed topics from WebSphere Connection Server Micro Edition.
• xxxAgentManager Class extends the AbstractAgentManager class, which provides an infrastructure for creating multiple instances of its corresponding agent. Each agent instance can be customized using different properties that are set by the user in the Edge configuration XML file. Most subclasses of the AbstractAgentManager override the following two methods:
  • getPropertySetName() returns a unique String identifier that is used in the configuration XML files to specify what type of agent should be created.
  • createAgent(Properties) creates and returns an agent using the passed-in properties.

For more information about the example agents, refer to the RFID Tracking Kit Developer Guide.

Develop agents with the Tracking Kit

An easy way to develop your RFID application is to customize the example agents provided by the Tracking Kit. Although the RFID Tracking Kit Developer Guide provides general information on the Tracking Kit, it's useful to have a step-by-step guide to customizing the example projects to implement your own application. In this section, we'll elaborate on how to develop related agents by creating extension service projects using WebSphere Studio Device Developer to implement a simple check-In and check-out use case.

Our scenario

The customized use case we'll develop is a check-in and check-out process of an object passing an entrance as follows:

1. A simulated switch is pressed. It sends a switch event to the Connection Server.
2. The controller agent subscribes to these switch events and sends a command to the portal reader agent to begin reading tags.
3. The reader agent receives the signal to begin reading, starts reading, and sends the found tags to the Connection Server.
4. The filter agent receives the tag information from the Connection Server, and then removes duplicate reads in a certain interval; in this case, 60 seconds.
5. A filtered set of tags is sent to the Connection Server and then to the Premises Server.

The tag information is received by the Event Server application running on the Premises Server. A related enterprise application is triggered to record the check-in and check-out status of the object. However, in this article we won't discuss the application running on the Premises Server, but will focus instead on the application on the Edge side.

To simplify the use case, we'll use only the Samsys Reader and a simulated switch, discarding all the other I/O devices. The event model of the use case is illustrated in Figure 2:

To implement our use case, we'll customize the example ControllerAgent, SwitchAgent and DuplicatesFilter, and leverage the ReaderAgent and FilterAgent directly from the example projects, as described in the following sections.

Back to top

Customize MyControllerAgent

The controller agent is the key agent in the example projects. It coordinates events between the I/O, filtering, and monitoring agents. It accomplishes this by publishing data to another topic; that is, it issues commands based on the status it receives. The data is sent to another agent that performs the actual work. To develop the MyControllerAgent of the use case, we'll customize the KimonoControllerAgent of the example projects by simplifying the ControllerAgent class.

As the event model of the check-in and check-out use case shows, MyControllerAgent subscribes to three topics:

• ReaderStatusSignal: published topics arrive when reader status changes. Upon receiving this topic, MyControllerAgent does nothing, but logs the current reader status.
• ReaderTag: published topics arrive when RFID tags are read and tag information is sent in the accompanying data. Upon receiving this topic, MyControllerAgent does nothing, but logs the tag data.
• SwitchCommand: published topics arrive when the switch is pressed on or off. Upon receiving this topic, MyControllerAgent publishes another topic ReaderStatusCommand to the Connection Server, as described below.

And it publishes one topic:

• ReaderStatusCommand: Upon receiving the switch topic, MyControllerAgent publishes this topic to the Connection Server. ReaderAgent subscribes to this topic. It changes the reader status accordingly when this topic arrives.

To create the MyControllerAgent project, complete the following steps:

1. Click File => New => Project. In the prompt window, select Extension Services in the left pane and Extension Services Bundle Project in the right pane.
   
   Figure 3. Create Extension Services Bundle project
   
   
   
2. Click Next, then specify MyControllerAgent as the project name in the Extension Services Bundle window.
   
   Figure 4. Specify project name
   
   
   
3. Click Next until you get to the Java Settings window. Select the Libraries tab, and click Add Variable.
   
   Figure 5. Add variable
   
   
   
4. Select the DEVICEKIT folder and click Extend.
   
   Figure 6. DEVICEKIT variable
   
   
   
5. Expand the bundlefiles folder, select Rfid.jar, and click OK.
   
   Figure 7. Add variables: Rfid.jar
   
   
   
6. Repeat steps 3 through 5 to add the following three variables:
   • MBAF_HOME\bundlefiles\MBAF.jar
   • MICRO_BROKER_HOME\bundlefiles\wmqtt.jar
   • OAF_HOME\bundlefiles\OAF_Base.jar
   
   
   Figure 8. Add four variables
   
   
   
7. Click Finish.

For the KimonoControllerAgent project, we'll create the following packages and classes in MyControllerAgent project:

• com.ibm.my.controlleragent package
  • ControllerAgent class: subscribe and publish-related topic to implement the target use case
  • ControllerAgentManager Class: controls the life cycle of ControllerAgent
• com.ibm.my.controlleragent.bundle package
  • Activator class: the bundle activator
• com.ibm.my.controlleragent.constants package
  • ControllerAgentConstants class: the constants used in this project
  
  
  Figure 9. Package organization of MyControllerAgent
  
  
  

We'll customize the ControllerAgent class according to the target use case. The most important method is handlePublishArrived(String, Object) shown below, which controls the event model of the use case:

				
protected void handlePublishArrived(String topic, Object data) {
		synchronized (this) {
//log the arrived topic and accompany data
LogUtility.logInfo(this, "Publish Arrived: " + topic + " = " + data); 
if (readerSignalTopic.equals(topic)) {
//this method just logs the reader status and does nothing
	 handleTopicReaderStatusSignal(topic, data);
	 }
else if(switchSignalTopic.equalsIgnoreCase(topic)){
//this method calls another method to activate the portal and 
//reader
	 handleTopicSwitchSignalOrPortalCommand(topic, data);
	 }
else if(portalCommandTopic.equals(topic)) {
				handleTopicSwitchSignalOrPortalCommand(topic,
 data);
			}
else if (readerTagsTopic.equals(topic)) {
// this method just logs the read tag data and does nothing
handleTopicReaderTags(topic, data);
	 }
else {
	  super.handlePublishArrived(topic, data);
	 }
}
}

We'll leverage the other classes of the KimonoControllerAgent project in MyController project. You can find all of the source code in the sample code provided in the Download section.

Now that we've generated the source code of MyControllerAgent, we'll modify the MANIFEST.MF file of the project as follows:

1. Specify the bundle activator as com.ibm.my.controlleragent.bundle.Activator.
   
   Figure 10. Set bundle activator
   
   
   
2. Expand the Import Services section, and click Add. Select com.ibm.kimono.edge.configuration.service.EdgeConfigurationService and clickAdd.
   
   Figure 11. Set bundle activator in MANIFEST.MF
   
   
   

Back to top

Customize MySwitchAgent

Unlike the KimonoSwitchAgent project, we'll create an extension services bundle project named MySwitchAgent to simulate the switch action. The simulated switch is a window widget that has two buttons: Start Reader and Stop Reader.

The package and class organization of MySwitchAgent is like those in MyControllerAgent, except that there is a window class in the com.ibm.my.switchagent package.

• com.ibm.my.switchagent package
  • SwitchAgent class: subscribes to and publishes related topic to implement the target use case
  • SwitchAgentManager class: controls the life cycle of SwitchAgent
  • SwitchWindow class: the simulated switch window
• com.ibm.my.controlleragent.bundle package
  • Activator class: the bundle activator
• com.ibm.my.controlleragent.constants package
  • SwitchAgentConstants class: the constants used in this project

The SwitchAgent class subscribes to no topic, and publishes the switchsignal topic only when the Start Reader button or the Stop Reader button is selected. The SwitchWindow is implemented via swt widget. Since swt is not the main focus of this article, we won't dive into the detail of this class. If you're interetsed, you can download the source code from the Download section.

Back to top

Customize MyDulplicatesFilter

This step of the check-in and check-out use case requires removing duplicate reads within 60 seconds. We'll leverage the KimonoFilterAgent project as the filter agent, but create our own duplicate filter to implement the use case logic.

In the MyDuplicatesFilter project, the DuplicatesFilter class maintains a hash table for RFID tags. Each element in the hash table includes the RFID data and the time when the tag is read. Whenever a tag is read, DuplicatesFilter retrieves the RFID data as the key in the hash table. If no record is found, it will add the new RFID tag and its read time into the hash table. If a duplicate RFID tag is found, the DuplicateFilter will compare the read time of the tag. If the interval between the two tags is longer than 60 seconds, the filter updates the read time of the tag. Otherwise, it filters filter out this duplicate tag.

The logic of the DuplicatesFilter is implemented by the filter(RfidMap) method of this class as shown below:

				
public RfidMap filter(RfidMap tags) {
	RfidMap result = new RfidMap();
	Enumeration enum = tags.keys();
	long currentTime = new Date().getTime();
	while (enum.hasMoreElements()) {
		Rfid rfid = (Rfid) enum.nextElement();
		if (!cachedTags.containsKey(rfid)) {
			cachedTags.put(rfid, new Long(currentTime));
			Object value = tags.get(rfid);
                  result.put(rfid, value);
LogUtility.logInfo(this,"RFID Tag:"+rfid.toString()+
" accepted");

		} else {
			Long time = (Long) cachedTags.get(rfid);
			if ((currentTime - time.longValue()) > (1000 * 60)) {
				cachedTags.remove(rfid);
				cachedTags.put(rfid, new Long(currentTime));
				Object value = tags.get(rfid);
				result.put(rfid, value);
LogUtility.logInfo(this,"RFID 
Tag:"+rfid.toString()+" accepted");

			}
		}
	}
	return result;
}

The other classes of MyDuplicatesFilter project are the same as those in KimonoDuplicatesFilter.

Run the check-in and check-out application

To facilitate the bundle loading of our use case, we'll create a bundle loader project named MyCheckInLoader, which contains only an activator class. We'll override the getBundleNames() method, listing the bundle names thare are to be installed on the SMF runtime, as follows:

				
protected String[] getBundleNames() {
		return new String[] {
			"LogService", 
			"KimonoConfigAdminBootstrap", 
			"MBAF_Admin", 
			"MBAF_Bridge_Admin", 
			"KimonoEdgeConfiguration", 
			"KimonoMicroBrokerConfigurationAgent", 
			"RfidSamsysMp9320epcTransport", 
			"RfidSamsysChumpDevice",
			"KimonoSamsysReaderAgent", 
			"MySwitchAgent",
			"KimonoFilterAgent", 
			"MyDuplicatesFilter", 
			"KimonoCaseTagsFilter", 
			"MyControllerAgent"
			}; 	
	}

Back to top

Submit and import the bundles

To submit and import the bundles, do the following:

1. Start SMF bundle server in WebSphere Studio Device Developer, by selecting Run => Run from the main menu of Device Developer.
2. In the prompt window, select SMF Bundle Server, then click New, and then Run.
3. Select all Kimono packages and the projects we created, then right-click SMF, then Submit Bundle.
   
   Figure 12. Start SMF bundle server
   
   
   
4. Check Submit jar and Replace Bundles and highlight the bundle server in the Target Submission dialog.
   
   Figure 13. Submit bundles to target
   
   
   
5. Click Finish.
6. Import the necessary bundles as follows:
   1. Switch to the Services Management Framework perspective and click the SMF Bundle Server tab.
   2. Right-click on your bundle server and select Import Bundles.
      
      Figure 14. Import bundles
      
      
      
   3. Click Add directory in the Import Bundles dialog box.
   4. Specify the directory: C:\Program Files\IBM\DeviceDeveloper\wsdd5.0\technologies\mbaf\bundlefiles
   5. Click OK to add this directory to list of bundle files.
   6. Check the checkboxes for all seven bundles and select Replace Bundles.
   7. Click Finish.
      
      Figure 15. Import and replace bundles
      
      
      
   8. Make sure all Kimono bundles and our created bundles are available in the bundle server.

Back to top

Configure and run the Edge runtime and simulated Premises Server

In this section, we'll configure two SMF runtimes to debug the created projects. One runtime acts as the Edge Controller using our created agents, the other acts as a simulated Premises Server using the KimonoPremisesSimulator example project.

1. Start with two machines (A and B) with WebSphere Studio Device Developer and RFID Tracking Kit fully installed. The Edge runtime runs on machine A and the simulated Premises Server runs on machine B.
2. Configure the Edge Runtime on machine A as follows:
   1. In WebSphere Studio Device Developer, expand com.ibm.kimono.premises.simulator.servlet in the KimonoPremisesSimulator package and open an Edge configuration XML file.
   2. Verify that the property tag with key=transport.host in the KimonoPremisesSimulatorServlet property set has a value equal to the IP address of the Samysys reader being tested.
   3. Verify that the property tag with key=server.ip in the MicroBrokerConfigurationAgent property set has a value equal to the IP address of machine B (the simulated Premises Server).
   4. Save this configuration and re-submit the KimonoPremisesSimulatorServlet bundle.
3. Configure the simulated Premises Server on machine B.
   1. In WebSphere Studio Device Developer, expand com.ibm.kimono.premises.simulator.agent in the KimonoPremisesSimulatorAgent package and open asnTags.dat.
   2. Modify the tag IDs as needed for testing.
   3. Save the list and submit the KimonoPremisesSimulatorAgent bundle.
4. Run the simulated Premises Server on machine B.
   1. In WebSphere Studio Device Developer, click Run => Run from the menu.
   2. Select SMF Runtime, and click New to create the simulated premise Runtime.
   3. Under the SMF tab, select the Bundle Server tab, and then enter the IP address of machine A, the SMF bundle server.
      Figure 16. Create Premises simulator runtime
      
      
      
   4. From the SMF tab, click the Platform tab, and check Reset File before launch.
      
      Figure 17. Create Premises simulator runtime: Reset File before launch
      
      
      
   5. On the Arguments tab, verify that the Program arguments are -ide -platform::reset and the VM arguments are -Xalwaysclassgc -Xgc:stringconstantGC -noverify -Xint.
   6. Click Apply and then Run.
      
      Figure 18. Set arguments of Premises simulator runtime
      
      
      
   7. Install the KIMONO_PREMISES_SIMULATOR_LOADER bundle.
      
      Figure 19. Install KIMONO_PREMISES_SIMULATOR_LOADER bundle
      
      
      
5. Run the simulated Edge on machine A.
   1. In WebSphere Studio Device Developer, click Run => Run from the menu.
   2. On the Arguments tab, verify that the Program arguments are -ide -platform::reset and the VM arguments are -Xalwaysclassgc -Xgc:stringconstantGC -noverify -Xint -Dpremises.ip=<ip of the premises> and -Dedge.id= E1 -Dkimono.console.log.threshold=<Error|INFO|DEBUG>
   3. On the SMF tab, click the Platform tab, and check Reset File before Launch
   4. Click Apply and then Run
   5. Install the KimonoConsoleLog bundle and MyCheckInLoader bundle.
   6. When all the bundles are started, a switch window displays. Click Start Reader to activate the reader.
      
      Figure 20. Switch window
      
      
      
6. You can view the runtime log to check the agent status and RFID tag information.

Back to top

Conclusion

In this article, we demonstrated how you can use the RFID Tracking Kit to easily develop a check-in check-out RFID application, including detailed steps showing how to create the customized agents, as well as steps for configuring and debugging the runtimes for Edge controller and the Premises simulator for the project. You can use what you learned in this article customize the example projects in the Tracking Kit to create your own RFID applications.

Back to top

Download

Description	Name	Size	Download method
Sample code for the agent projects	SampleCode.zip	46KB	FTP|HTTP

Information about download methods

Resources

Learn

• WebSphere RFID Handbook: A Solution Guide explains the key products and components included in the WebSphere RFID solution, with a focus on WebSphere RFID Premises Server and device infrastructure. It describes how to install and configure the Premises Server, connect and communicate with your Edge devices, and implement the Dock Door Receiving Starter Kit.
  
  
• IBM RFID Tracking Kit Developer Guide provides an overview of the Tracking Kit, descriibes how to install and configure it, and describes the example projects in the Tracking Kit.
  
  
• Information Center PDF for IBM WebSphere RFID 1.0 provides support information for the WebSphere RFID Premises Server and RFID Tracking Kit.
  
  
• Proof of Concept Walk-through for RFID Version 1.0, fix pack 1 provides detailed steps on running and configuring the Dock Door Receiving use case of the example project.
  
  

Get products and technologies

• Get a trial version of WebSphere Studio Device Developer from the IBM Workplace Client Technology, Micro Edition V5.7.1 download page.
  
  

About the author

Yang Liu is a software engineer at IBM China Software Development Lab in Shanghai, China. She works in the Shanghai Globalization Lab, and focuses on RFID technology, Web services and globalization technologies. You can reach her at elainel@cn.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Develop agents with the Tracking Kit
• Customize MyControllerAgent
• Customize MySwitchAgent
• Customize MyDulplicatesFilter
• Submit and import the bundles
• Configure and run the Edge runtime and simulated Premises Server
• Conclusion
• Download
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers