Hit the ground running with AIDE, Part 3: Touchpoint and managed resource integration

Build a basic touchpoint interface for a managed resource

This tutorial, the third in a series on the IBM® Autonomic Integrated Development Environment (AIDE), describes a basic touchpoint interface for a managed resource. Discover how Eclipse supports the workflows for such development with TODO items and learn how to provide a touchpoint-based platform for arbitrary managed resource management -- a topic that has dogged the telecom and enterprise management arenas for decades.

Stephen B. Morris, CTO, Omey Communications

Stephen is the CTO of Omey Communications in Ireland. For the past 20 years, Stephen has worked for some of the world's largest networking companies on a wide range of software projects, including J2EE/J2SE-based network management systems, billing applications, porting and developing SNMP entities, network device technologies, and GSM mobile networking applications. He is the author of Network Management, MIBs and MPLS: Principles, Design and Implementation (Prentice Hall PTR, 2003) as well as several articles on network management and other topics for InformIT and OnJava.com. You can reach Stephen at stephenbjm@yahoo.com.

27 June 2006

Also available in Chinese

Before you start

Learn what to expect from this tutorial and how to get the most out of it.

About this series

This tutorial is the third in a series that describes techniques for the development of autonomic computing technology using the IBM Autonomic Integrated Development Environment (AIDE) toolkit. The tutorial describes how to integrate Java™ Management Extension (JMX) facilities into a touchpoint. In implementing the code for this tutorial, you see more extensive use of the model-driven approach than was the case in the earlier tutorials. You also use some of the clever facilities that come as part of the Eclipse platform.

The remaining tutorials in the series will describe touchpoint deployment on several platforms, including Linux®, MySql, and Apache. By the end of the series, you should have a sound understanding of the development of touchpoint technology on generic and open source platforms.

Note: No software is perfect. This tutorial series continues to help programmers become as productive as possible as quickly as possible. With this in mind, I openly discuss any problems I encountered with the software and provide workarounds and solutions.

About this tutorial

This tutorial describes how to integrate resource management code into a touchpoint. This goal necessitates digging a little deeper into AIDE than in the earlier tutorials. All required steps are described in detail. Many legacy devices and software systems (such as application servers, databases, and applications) are, in fact, not instrumented with JMX. In many cases, the managed entity instrumentation uses Simple Network Management Protocol (SNMP)-based technology, a command-line interface (CLI), or some other proprietary technology. The tutorial also briefly discusses techniques by which all such entities can be brought into the touchpoint arena.

For this tutorial, the platform continues to be generic: Any platform that supports the Eclipse and AIDE toolkit. For example, Microsoft® Windows® XP is more than adequate. The version of AIDE used was the latest at the time of writing (version 1.1.0).


This tutorial is written for programmers who have a reasonable knowledge of Java programming, Eclipse, and systems management. The ability to use an integrated development environment (IDE) such as Eclipse and the various tools and plug-ins that go with it is helpful but not necessary. Likewise, a basic understanding of the following is useful:

  • SOAP
  • Web Services Addressing (WS-Addressing)
  • Web Services Distributed Management (WSDM)
  • JMX
  • Instrumentation
  • Monitoring and management

The focus of this tutorial is on the touchpoint and managed resource layers (see Figure 1), so a knowledge of the above is useful if only for an appreciation of the various Eclipse console messages you'll see.

You also need the following Java classes, which are available from the Downloads section:

  • Client.java
  • HelloWorld.java
  • Server.java
  • SimpleStandard.java
  • SimpleStandardMBean.java
  • SetOpertion.java

System requirements

To run the examples in this tutorial, the minimum platform requirements are a computer running Microsoft Windows XP on which you've installed the AIDE software and Apache Tomcat V5. The JMX application program interface (API) is included as part of Java 2 Platform, Standard Edition (J2SE) V5.0, so no special installation is required (assuming you have J2SE V5.0).

Note: You can use Apache Tomcat V4, but you must use the compatibility package as well.

The operational context for managed resources

The manageability requirements for autonomic computing technology consist of self-configuration, self-healing, self-optimization, and self-protection -- otherwise known as self-CHOP. Self-CHOP describes the mechanisms by which autonomically equipped entities can automate classical, manually executed management operations. The key word here is automation.

Self-configuration comprises those procedures that automatically update the setup and deployment elements of managed systems. Self-healing is management infrastructure that lets systems automatically respond to component failures by restarting or invoking backup facilities. Self-optimization is one of the toughest nuts to crack; it consists of software that facilitates a managed element in adding resources as and when the imposed load requires it and, conversely, retiring resources when they are no longer needed. Self-protection consists of procedures that let a managed system resist attack from inside and outside the firewall.

The vast bulk of managed devices today have little or no advanced self-CHOP capabilities, which makes information technology (IT) management an expensive, tedious, and error-prone activity. Worse than this, IT infrastructure is inadequately protected, reactively (not proactively) administered, and prone to catastrophic failures. The days are gone when systems and software can be deployed with little or no management capability.

The IBM vision for such management capability consists in large part of the touchpoint concept. This is a relatively thin layer of software that interacts with a managed resource to facilitate the self-CHOP requirements.

So this series is for anyone who knows a bit of programming and who wants to better understand the growing need for manageable systems and software as well as how to create the latter using IBM autonomic computing technology.

Managed resource technologies: JMX, SNMP, and CLI

Traditionally, management facilities are added to products at the end of the development life cycle. This is one reason there are so many different approaches to IT management in the industry. It's arguable that management infrastructure was heretofore considered a necessary evil rather than a source of value.

But that concept is beginning to change. Just look at the post-dotcom telecom world. Many telecom providers are now faced with the unenviable task of reducing their costs by 20 to 30 percent over the next four years to stay profitable. After all the downsizing and consolidation has ended, telecoms will have to look to their IT management infrastructure for increased value.

As IT management infrastructure goes, WSDM itself is but one more addition to the IT management firmament. The merit of WSDM is that it allows for management using standard Web service interfaces. So, WSDM-compliant management solutions fit into the current trend toward Web services and, more generally, service-oriented architecture (SOA).

The WSDM Management Using Web Services (MUWS) specification provides a standard by which you can manage legacy and new IT elements through Web services. The current version of IBM's touchpoint technology supports MUWS.

As you saw in the two previous tutorials, touchpoints are model driven, automatically generated software entities. By enabling Web service capability, touchpoints help bring the entities at the bottom of Figure 1 into the management fold (that is, under the control of the autonomic manager). In this context, you can think of touchpoints as being a kind of bridge between the autonomic manager at the top of Figure 1 and the managed entities at the bottom of Figure 1.

Figure 1. The Web services management layers
The Web services management layers

This illustration shows a few key points:

  • By deploying WSDM infrastructure, you use Web services to facilitate management. This point underlines the fact that Figure 1 describes a MUWS scenario: You use Web services as a tool for management.
  • Touchpoints hide the complexity of the managed resources. This point is important because the complexity of the touchpoint code helps off-load this complexity from the autonomic manager, which reduces the development complexity and cost of the autonomic manager.
  • The more generic the touchpoint interface, the better. This point implies that the autonomic manager's complexity is further reduced if the touchpoints employ generic interfaces. (You'll see more on this later when I show you an interface).
  • Intelligence is distributed across the various layers. This point indicates that each element in Figure 1 performs an important function. When you integrate touchpoint code, you'll see that a degree of care is required not to adversely affect the managed entities.

Modeling and building a touchpoint managed element interface

Start by using the AIDE capability editor to create the touchpoint interface. You could create a completely new project from scratch; however, to minimize the number of tedious steps required, I instead modified our old friend the WeatherStation project from the second tutorial (see Resources for a link) in this series. So, open the model for the WeatherStation project illustrated in Figure 2.

Figure 2. The WeatherStation model
The WeatherStation model

Use EMF to change the model

Recall from the earlier tutorials that the model is used to generate the touchpoint code, so you can automatically merge changes to the model into the generated code using the Eclipse Modeling Framework (EMF). In the steps that follow, you see the productivity enhancement that comes as part of model-driven development.

To use the capability editor to change the model, complete these steps:

  1. Double-click the file WeatherStation.actpca to open the overview window of the capability editor.
  2. Click the Operations tab.

You should now be able to see the Add button. (You may need to scroll down to see it.)

Figure 3 shows where you are now -- ready to add an interface operation.

Figure 3. The capability editor
The capability editor

Add the interface operation

To start the interface addition, complete these steps:

  1. Click Add.
  2. Type the method name, getEntityState.
  3. Accept the return type as void.

You should now see the new method in the Operations window (see Figure 4 ).

Figure 4. The new method in the capability editor
The new method in the capability editor

You have one outline element of the required interface. Now that the model has been modified (remember, this is model-driven development), you want to update the associated project artifacts. To do so, right-click the WeatherStation model file WeatherStation.actpim (see Figure 4) and then click Generate Touchpoint. You've seen this procedure in earlier tutorials, so just accept the default wizard settings. When the generation is complete, open the WeatherStation project and then export the Web Archive (WAR) file. (This file is described in the section Adding the back-end JMX class files). If you don't save prior to exporting the WAR file, you may be prompted to save the capability file of the WeatherStation Model project. If this occurs, just click OK and your changes will be saved.

At this point, you should have a new method in the WeatherStation project. The next section shows where this method resides as well as illustrates how the Eclipse workbench provides a clever facility to assist in the next stage of the development workflow -- namely, productivity enhancement.

A bit of a TODO

You've created an empty method called getEntityState(). Now, you see that a project-specific addition has been made to the Eclipse workbench in the form of a TODO (that is, an unfinished work item). To see the TODOs, open the TODO view by clicking Window > Show View > Other > Basic > Tasks. The TODO view appears on the right-hand side.

The TODO list applies to all projects in the Eclipse workbench. Your new method should be listed as associated with the WeatherStation project. So, you can double-click the method item (the one you just created) to open the associated Java file.

Add code to fill out a TODO

Next, add code to the method you created in the capability editor. To do so, complete these steps:

  1. Double-click the associated TODO.
  2. Paste the code from Listing 1 into the TODO.
Listing 1. The new method code
HelloWorld hello = new HelloWorld();

In this code, you instantiate an object of the HelloWorld class. The writeOutput() method is passed a parameter -- a String private member of the WeatherStationImpl class. Next, add the managedEntityHost data member to the WeatherStationImpl class:

public static final String managedEntityHost = "localhost:9999/server";

I added it at the start of the WeatherStationImpl class, as shown in Listing 2.

Listing 2. The new method code (revised)
public class WeatherStationImpl extends EDataObjectImpl implements WeatherStation
public static final String managedEntityHost = "localhost:9999/server";

public static final String copyrightNotice = 
     "Licensed Materials - Property of IBM " +
     "(c) Copyright IBM Corp. 2005     All Rights Reserved. " +
     "US Government Users Restricted Rights - Use, duplication or " +
     "disclosure restricted by GSA ADP Schedule Contract with IBM Corp.";

Update touchpoint.xml

After you've added the method, you must modify the WeatherStation project file touchpoint.xml. This file resides in the WebContent\WEB-INF folder. To get the new method to work, remove the following two lines, which appear under the name of the method:

<!-- Customize with parameter-specific serializer -->

Removing these lines avoids the occurrence of an exception related to the new method. In case you encounter this problem, the exception looks like this:

Parsing outgoing SOAP body...
Invoking 'http://com.ibm/2005/10/8/getEntityState'...
com.ibm.ws.basefaults.remote.BaseFault: @@@ Unimplemented
-- replace PlaceholderSerializer with a custom serializer in touchpoint.xml;
nested exception is: java.lang.IllegalStateException: @@@ Unimplemented
-- replace PlaceholderSerializer with a custom serializer in touchpoint.xml at
com.ibm.ws.basefaults.WsbfUtils.getBaseFault(WsbfUtils.java:89) at

Mark the generated method @generated NOT

One last code change is required to not lose the code after further model updates. To make this change, complete these steps:

  1. Open the WeatherStationImpl.java file in the JavaSource folder in the \ibm\com\impl sub-folder.
  2. Open the code listing for your method, getEntityState().
  3. Change the @generated tag to @generated NOT.

This change means that the next time you generate the project (assuming you decide to), your code changes remain intact. In other words, the automatic code generation won't overwrite your code. You can now save the file and you're ready to add the required back-end JMX class files.

Adding the back-end JMX class files

You saw the following code addition procedure in Part 2 of this tutorial series, but I list the steps for the sake of convenience. In the present case, you're using a different version of the JMX code because you're defining a touchpoint interface. The nature of the latter is focused in that you require a specific item of functionality -- namely, you're integrating the managed entity access code into the touchpoint rather than simply calling it.

Add the JMX classes to the touchpoint

To add the JMX classes to the touchpoint, complete these steps:

  1. Copy the four downloaded Java classes (HelloWorld.java, Client.java, SimpleStandard.java, and SimpleStandardMBean.java) into the \ibm\com\impl sub-folder (see Downloads for the classes).
  2. Open the JavaSource folder in the \ibm\com\impl sub-folder.
  3. Click File > New > Class.
  4. In the Name field, type HelloWorld.java. The other fields should all provide default values; you can ignore them.
  5. Click Finish. You should now see the new class in the \ibm\com\impl sub-folder.
  6. Repeat steps 3 through 5 for the other Java classes.

Redeploy the touchpoint

Next, redeploy the touchpoint project. To do so, complete these steps:

  1. Click File > Save All.
  2. Select the project name.
  3. Click File > Export.
  4. Select the WAR file, then click Next.
  5. Click the list control, then select the required Web module from those listed.
  6. Browse to the required disk destination.
  7. Select the Overwrite existing file option, then click Finish.
  8. Redeploy the project.

Now, download, build, and launch the server code. To do so, complete these steps:

  1. Copy the downloaded Java class Server.java into a folder on your computer (it doesn't matter where).
  2. Compile the Server.java file, javac Server.java.

Assuming that you didn't get Java errors, you're finally ready to test the new code. In case the Server.java file didn't compile, here are a few pointers:

  • Make sure that you're using J2SE V5.0.
  • Make sure that your Java compiler is the one from J2SE V5.0.
  • To check the compiler version, type javac -version.
  • The version returned should be at least javac 1.5.0_06.
  • If in doubt, check your DOS PATH to see which compiler version is used first.

As mentioned earlier, JMX support is included as part of J2SE V5.0. If, like me, you're a bit lazy about removing old versions of J2SE, now might be time for a bit of machine Spring cleaning!

Testing the new touchpoint code

Gotchas and pitfalls

Typically, when I test this type of code, I like to get it all running in isolation from the Eclipse workbench. Frankly, doing so gives me less to worry about, what with pesky classpaths, folders, package names, and the like. One change you must make if you want to work this way is the Java package name. Because this name matches the directory structure, remember to change the package name as you move the code into and out of the Eclipse project. So, make sure that you change it to match the package in use in the WeatherStation project (that is, ibm.com.impl).

I had a bit of package name-related head-scratching trying to integrate the code into Eclipse. Eclipse does its best to tell you what the problem is, but it's usually a case of information overload. If you do get an error when you run the touchpoint, don't panic. Read the Eclipse message carefully: It should provide you with enough clues to fix the problem.

To sum up, you now have two entities of interest:

  • An operational managed entity (Server.java)
  • A touchpoint equipped with an interface to access the managed entity

Now, let's now exercise the new code.

Exercise the code

To exercise the new code, complete these steps:

  1. Start the rmiregistry program by typing rmiregistry 9999 & at a command prompt.
  2. Start the server code by typing java -classpath . Server.
  3. Run the WeatherStation touchpoint by right-clicking the WeatherStation project name, then clicking Run As > Run on Server.
  4. Click Finish.
  5. Run the deploy.bat file.
  6. Click Create & browse to display the schema and the allowed operations.
  7. Scroll down to the getEntityState() button (see the bottom of Figure 5).
  8. Click getEntityState().
Figure 5. The getEntityState() button
The getEntityState() button

The getEntityState() button is an AIDE-specific productivity-enhancing function. The touchpoint provides this point of access at no charge when you add a new method in the capability editor.

If all is well with your touchpoint, you should now see the following at the top of the Resource window:

Parsing outgoing SOAP body...
Invoking 'http://com.ibm/2005/10/8/getEntityState'...
Result:<?xml version="1.0" encoding="UTF-8"?> 
  >mrt1:getEntityStateResponse xmlns:mrt1="http://com.ibm/2005/10/8"/>

The message in Listing 3 appears in the console window. (You might have to scroll down in the console window to see it.)

Listing 3. The touchpoint contacts the managed entity
*** Creating an RMI connector client and connecting it to the RMI connector server ***
*** Getting an MBeanServerConnection ***
Query MBeanServer MBeans:
	ObjectName = JMImplementation:type=MBeanServerDelegate
	ObjectName = DefaultDomain:type=SimpleStandard,index=1
*** Closing the connection to the server ***
*** Exiting normally ***

This message indicates that your code has been successfully integrated into the touchpoint. You've achieved a lot if you've managed to get this working: You've got the touchpoint talking to the managed entity. It's time to crank up the coffee pot!

Mapping between the touchpoint and the managed entity

Let's take a closer look at what's going on in Listing 3. This code queries the MBean object names that the MBean server (Server.java) supports. This simple operation amounts to dipping into the managed entity and retrieving the relevant data -- namely, a GET operation. Clearly, this GET operation can be much more complex than that depicted in Listing 3. You could use this approach to get the operational state of an application server or the number of tables in a relational database schema. The point is that after the JMX infrastructure is in place, you can do whatever fulfills your IT management requirements (that is, self-CHOP).

Implement a SET operation in the touchpoint (and the managed entity)

You can probably see now that implementing one or more SET operations follows exactly the approach you used above for the GET operation:

  1. Create a new model method called, for example, setEntityState in the capability editor.
  2. Define any required parameters.
  3. Regenerate the code from the model.
  4. Incorporate the Java code into the touchpoint.
  5. Export the WAR file.
  6. Exercise the touchpoint code.

I've included JMX code that implements a simple SET operation. The Java class that invokes this code is included in SetOperation.java (see Downloads); its contents are illustrated in Listing 4. (I've added NOT to the @generated tag.)

Listing 4. A SET operation on a managed entity
 * <!-- begin-user-doc -->
 * <!-- end-user-doc -->
 * @generated NOT
public void setEntityState(String entityName) throws BaseFault
      SetOperation aSet = new SetOperation();

So, to get this working, add this code into the generated method called setEntityState(). After these steps, your touchpoint should look like Figure 6.

Figure 6. The updated touchpoint
The updated touchpoint

Don't forget to modify the touchpoint.xml file as for the GET operation. To do so, delete the following two lines under the setEntityState() method:

<!-- Customize with parameter-specific serializer -->

When you exercise the new setEntityState() method by clicking the associated button, you should see the contents of Listing 5 in the console window.

Listing 5. Correct functioning of the SET operation
*** Creating an RMI connector client and connecting it 
to the RMI connector server ***
*** Getting an MBeanServerConnection ***
	ObjectName = JMImplementation:type=MBeanServerDelegate
*** Setting attributes on the MBeans ***
*** Closing the connection to the managed entity ***
*** Exiting normally ***

The SET operation retrieves each MBean object and sets the state. The display depicted in Listing 5 isn't dramatic, but your touchpoint code is successfully modifying a managed resource.

It's a similar story for incorporating managed entity notifications. In this case, some means of mapping the asynchronous notifications into Eclipse notifications is needed. In other words, building touchpoints is simply a process of methodically adding and testing managed entity access code.

Note: This code is not production standard; it's written purely to illustrate concepts.

The relationship among the autonomic manager, the touchpoint, and the managed entity

Recall from Figure 1 that the touchpoint sits between the autonomic manager and the managed entities. In this context, the touchpoint is a kind of technology adapter. It translates the requests from the autonomic manager into a form suitable for dispatch to the managed entity. And in the reverse direction, the touchpoint translates the messages sent from the managed entity to the autonomic manager.

This process applies regardless of the management instrumentation that the managed entity supports. As noted earlier, the instrumentation may be based on JMX, SNMP, CLI, or some other technology. In all such cases, the touchpoint must provide a bridge between the autonomic manager and the managed entity. If the managed entity supports SNMP (as is the case with some database vendors), the touchpoint must provide SNMP access code. If the only instrumentation is a CLI (as is the case with many telecom device vendors), the touchpoint must implement the terminal access code (for example, using a Telnet class library and a terminal server). For more on these important legacy technologies, see Resources.

So, whatever technology the managed entity uses, the touchpoint is there to translate messages and shuttle them to and from the autonomic manager. The messages passing from the touchpoint to the managed entity are:

  • GET operations: Some number of managed entity variables are retrieved.
  • SET operations: Some number of managed entity variables are modified.

Typically, the messages passing from the managed entity to the touchpoint are responses to GET and SET operations from the touchpoint and notifications, or autonomous messages that reflect the occurrence of some important event in the managed entity.

Even though autonomic computing is a relatively young technology, it's entirely likely that the managed entities will have no knowledge of the autonomic manager. The touchpoint layer takes care of communication with the latter. Indeed, if the touchpoints are well designed in a loosely coupled fashion, it should be possible to swap in and out autonomic managers from different vendors.

Caveat: Touchpoints can be too thin

One of the unwritten principles of IT management is that managed entities should never be subjected to excessive interrogation or configuration. Remember: The managed entities are, in a sense, the service providers for your network. So every time you get or set managed entity data, you may be inadvertently initiating a large amount of computational activity on that entity. While this might not be a big deal when the managed entity is a clustered application server with plenty of resources, it might present a problem if the entity is a simple telecom device (such as a router or a hub). Likewise, if the entity is under heavy load, the last thing you want is for the management system to exacerbate the situation.

In addition, you must always consider the possibility of bugs in the autonomic manager and touchpoint infrastructure. For example, imagine that because of a bug, the touchpoint code began erroneously issuing large numbers of GET requests on big data items in a managed database engine. The result might be that the database engine platform suffers a performance impact. The ultimate consequence might be a loss of service somewhere in the network resulting from a bug in the management code.

So an important element of touchpoint design is resource preservation and self-auditing. In short, in spite of what I say about touchpoints being a fairly lightweight technology, they really shouldn't be too thin. For autonomic computing technology to be effective, each component must play its part fully.


This tutorial presented a programmatic basis for IT management. An important element of IBM autonomic computing technology is its incorporation of model-driven development. This incorporation provides for useful productivity enhancements -- important in improving the cost/benefit ratio of touchpoint development.

Integrating touchpoint support for JMX-instrumented entities is relatively straightforward if a little tedious. In this tutorial, you saw how to implement GET and SET operations: These two operation types reflect retrieval and modification semantics in the autonomic manager. An essential element of these operations is the instrumentation, and for this I chose JMX, an increasingly widely deployed instrumentation technology, though other technologies, such as SNMP, CLI, and Extensible Markup Language (XML), are also available.

Touchpoint technology is, therefore, intimately connected with the managed resource layer. This connection allows a level of potentially dangerous access to this layer. So, be sure that touchpoints don't flood managed entities with requests for data and modifications.


Downloadable classesac-aidetut3source.zip11KB



Get products and technologies

  • Autonomic Computing Toolkit: The Toolkit is a collection of IBM self-managing autonomic computing technology components, tools, scenarios, and documentation designed for users wanting to learn, adapt, and develop autonomic behavior in their products and systems.
  • IBM Autonomic Integrated Development Environment (AIDE): A set of software development tools that embrace the Web Services Distributed Management (WSDM) standard. Includes tools such as the IBM Manageability Endpoint Builder (for building endpoints that allow products to expose manageability interfaces) and the IBM Manageability Endpoint Simulator (previously known as IBM Touchpoint Simulator).
  • Java Management Extensions: Download the Java API for management.
  • Java 2 Platform, Standard Edition: Download this platform and learn more about J2SE, a complete environment for application development and deployment on desktops and servers.
  • Apache Tomcat version 5.0: Go to this site for all the latest releases for Apache Tomcat.
  • IBM trial products for download: Build your next development project with IBM trial software, available for download directly from developerWorks.


  • developerWorks blogs: Participate in developerWorks blogs and get involved in the developerWorks community.
  • Join the discussion: Drop in on the "Autonomic computing: an insider's perspective" discussion forum.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Tivoli (service management) on developerWorks

Zone=Tivoli (service management), Tivoli, SOA and web services, XML, Java technology
ArticleTitle=Hit the ground running with AIDE, Part 3: Touchpoint and managed resource integration