Level: Intermediate Balan Subramanian (bsubram@us.ibm.com), Advisory software engineer, IBM
04 Sep 2007 Get an introduction to the Managed Agent Explorer, a test tool to help with the
development of your endpoint using the Eclipse TPTP tooling and a test and introspection
tool for already deployed endpoints. This article explains how to automatically invoke
the Managed Agent Explorer when building an endpoint in the tooling and also how to
connect to a deployed endpoint. You learn how to use the various views in the Managed Agent Explorer
and how to do basic operations such as setting properties and invoking operations.
Introduction
The Web Services Distributed Management: Management (WSDM) open standard is supported by two open source projects: a reference
implementation in the Apache Muse project and tooling in the Eclipse TPTP project.
Existing developerWorks’ articles referenced in Resources
explain how to build WSDM endpoints either directly interfacing with the Apache run time
or using the tooling integrated in the Eclipse IDE. The intent of the tooling is to
support a complete build-deploy-test cycle for the development of WSDM endpoints while
relieving you from the nitty-gritty details of Web services and the Apache Muse run time. This enables an iterative approach to development of endpoints.
An important component of the Eclipse TPTP tooling is the Managed Agent Explorer. In
this article, you learn how the Managed Agent Explorer can help you test endpoints you are
building with the tooling as well as with testing and introspecting endpoints built
outside of the tooling, including ones that are already deployed. The basics of the Managed Agent Explorer this
article covers include:
- How it is launched automatically
- How you can perform basic testing tasks
- How to change resource properties and invoke resource operations
- How to connect to an endpoint deployed outside the Eclipse workbench
- How to explore service groups
To follow along with the tasks in this article, you should be familiar with the WSDM
standard, including concepts such as the resource framework, topics, notifications, service
groups, and relationships. You should also have some working knowledge of the Eclipse
IDE.
In this article, you will use the sample
endpoint you built in the "Create a
WSDM endpoint using Build to Manage tooling from the Eclipse TPTP project” tutorial to
show how to test with the Managed Agent Explorer. However, if you do not want to follow the
instructions in the tutorial, you can download the code for
the Eclipse projects built in that tutorial.
To begin, install Eclipse TPTP 4.4, which contains the Managed Agent Explore using the instructions at:
http://www.eclipse.org/tptp/monitoring/documents/tutorials/tptp_wsdm_setup_4.4.html.
Install the Apache HTTP Server and Apache Tomcat (preferably version 5.0 or higher).
The Managed Agent Explorer framework
The Managed Agent Explorer framework is a set of plug-ins in the Eclipse TPTP tooling
that provides a graphical tree-based navigation for the introspection of different types
of managed resources using various protocols. It builds upon the TPTP agent framework
and provides a consistent user experience with the rest of TPTP. The framework does not
use any remote agents to communicate with the resources because in many cases the
resources themselves are instrumented for a particular management protocol and no agents
are required. A key feature of The Managed Agent Explorer framework is its ability to
talk different protocols to different types of resources. The framework is pluggable and
different protocols can be supported through different agent implementations that extend
the abstract Managed Agent defined in the core Managed Agent Explorer framework.
Currently, JMX (Java Management eXtensions) and WSDM are supported; the former as part
of the TPTP project download and the latter through additional plug-ins installed
separately on top of the Managed Agent Explorer framework.
The framework adds a notification broker to the Eclipse workbench, which allows
plug-ins within the workbench to subscribe to different kinds of notifications.
Different types of notifications are supported by different notification providers. As
you would expect, the WSDM extension to the Managed Agent Explorer includes a
WS-Notification (WS-N)-based provider to the workbench, which is an OSGi-based WS-N
consumer endpoint deployed onto the Eclipse Workbench (which is OSGi/Equinox based). The
notification broker is efficient at handling multiple subscriptions from different
plug-ins that route to a single resource by consolidating those subscriptions into one subscription from the workbench itself and then internally broadcasting received notifications.
Specific to WSDM, the Managed Agent Explorer provides the following features:
- Connect to a WSDM endpoint given its endpoint reference (EPR)
- Visualize service groups in a tree-based Resource Topology view
- Sort and filter service group members
- Connect to individual members of the service group
- Look at the properties and operations of the resource
- Sort the properties and operations
- Inspect property values and change values, if allowed by the resource
- Provide parameters to the operation, invoke the operation, and look at the results
- Subscribe to property change notifications; on property change notifications, the property values are updated and an indication of the update is provided
- Look at the different topics provided by the endpoint in addition to the ones for property change notifications
- Subscribe to different topics; the notification messages are displayed in the Eclipse PDE Error log
- Look at the various relationships that a resource has
- Traverse relationships and connect to the related resources
- Copy the EPR of the resource to the clipboard as an XML fragment
- Allow extension points for new actions to be made available on the context menu for the resource displayed in the Resource Topology view
- Automatic launching on deployment of Java™ Platform, Enterprise Edition (Java EE)-based endpoints within the workbench (for example on an Embedded Apache Tomcat instance)
 |
Launching the Managed Agent Explorer
The tutorial “Create a WSDM endpoint using Build to Manage tooling from the Eclipse TPTP
project” (see Resources) explains how to create a WSDM endpoint
for an Apache HTTP server. By default, the tooling specifies one instance of the defined
resource type to be created at startup. When you deploy the endpoint within the Eclipse
Workbench, the Managed Agent EXplorer is started automatically. The first step you need
to take in this article is to build the endpoint for the Apache HTTP server as specified
in the tutorial, or use the .zip file included with this
article to import the Eclipse projects just as if you had followed the steps in the
tutorial.
To import the projects from the .zip file, in the Eclipse workbench:
- Choose File > Import > Existing Projects into Workspace.
- Select the General node in the tree view.
- Choose the Select Archive file option.
- Select the location where you downloaded the .zip file on your machine.
- Choose all the projects and click Finish. Your workspace should resemble Figure 1.
The APACHE_LOCATION property reflects the setup of your Apache HTTP server
installation. If you are using the projects from the .zip file, you can change the
APACHE_LOCATION property by editing the muse.xml file found under the
ApacheHttpServerImpl project at WebContent/WEB-INF/classes/. If you have instead
followed the referenced article and built your own projects, you can set the APACHE_LOCATION property in your implementation code.
Figure 1. Eclipse SDK
Now you can deploy and run this endpoint using the Apache Tomcat installation on your
machine. Right-click on the web project and choose to run it on the server as shown in Figure 2.
Figure 2. Running the endpoint within the Eclipse workbench
This launches the window shown in Figure 3 that lets you define a new server instance.
Figure 3. Run on server dialog
Select Apache Tomcat v5.5 server.
In the window in Figure 4, provide the installation folder of your Apache Tomcat setup and choose the appropriate JRE. Note that for Apache Tomcat 5.5 you need JRE 1.5 or you will need to get the JRE 1.4 compatibility package.
Figure 4. Details of Apache Tomcat installation
You can click Finish at this point or click Next to go one screen further
as shown in Figure 5 to confirm which Web project is to be deployed. This step is not
necessary if you started the deployment by right-clicking on the Web project. However, you may want to do this step in future deployments if you want to remove other projects that you may have previously deployed. Click Finish.
Figure 5. Choosing endpoints to deploy
Your endpoint is now deployed as a .war file (Web archive) and Tomcat is started. You
should be able to see progress on the console. The Servers view shown in Figure 6 opens
and you can see if the server has completed the startup process. Pay attention to the right bottom part of the status bar and wait until the Starting server… message disappears.
Figure 6. Eclipse view of configured and running servers
The Managed Agent Explorer is automatically launched with a connection created to the
endpoint. The workbench switches to the Profiling and Logging perspective as shown in Figure 7.
Figure 7. Eclipse profiling and logging perspective
Before you continue, you should clean up this perspective and remove the views that you
do not need. On the menu bar, choose Window > Reset Perspective as shown in
Figure 8. This cleans up the workbench
Figure 8. Resetting current perspective
A connection to the endpoint is created in the Profiling Monitor view, which is typically shown on the left and has focus by default. Expand the tree to find the newly created agent as shown in Figure 9. Hover over a node or expand the view to see the creation time of the agent.
Figure 9. Profiling Monitor view
To start the Managed Agent Explorer, you may double-click on the agent. Or, right-click
on the agent to display the pop-up context menu and choose Open With > Managed Agent Explorer as shown in Figure 10.
Figure 10. Opening profiling agent with the Managed Agent Explorer
The Managed Agent Explorer has three sections as shown in Figure 11: a Resource
Topology view, a Details view, and a Value editor.
Figure 11. Managed Agent Explorer view
The Resource Topology view shows the topology of a service group if the connected
endpoint is a service group or shows the details of the resource if the endpoint is a
non-service group endpoint. Expand the tree as shown in Figure 12 to see the properties
and operations provided to manage the resource. Because you did not explicitly define
this resource to be a notification producer or a relationship resource, you do not see any topics or relationships in the tree.
Figure 12. Viewing properties and operations
Now, take a look at how to change resource properties using the Details view and the Value editor.
Changing resource properties
You want to be able to change the resource state, such as the table size of a database,
by setting its properties. Here, I'll show you how to do that. First, expand the Resource Topology tree further as shown in Figure 13 to see the actual properties.
Figure 13. Viewing list of properties
In addition to the properties that you explicitly defined as part of the resource’s custom capabilities, you see the properties that come from the standard WSDM capabilities included in the resource type definition.
As shown in Figure 14, click on a property and its current value is displayed in the
Details view. If the property is of a complex type, the serialized form of the value is displayed.
Figure 14. Viewing property values
To edit the value, click on the property in the Details view. The value appears in the
Value editor. The reason the Managed Agent Explorer does not allow direct editing in the
Details view is that some values may be complex values, which are typically shown as XML
fragments. It's easier to edit them in a bigger text area than a smaller table cell.
Change the value in the Value editor and click Applyas shown in Figure 15.
Figure 15. Setting property values
Clicking Apply causes a setResourceProperty operation to be
called on the endpoint. If the operation is successful you see the new value in the Details view. You can verify that the value is changed by choosing the property in the Resource Topology view and clicking Refresh on the toolbar, as shown in Figure 16.
Figure 16. Refreshing the view
Now try to do the same for the ServerName property. You may
notice that the set operation does not happen and on refresh the old value shows up as shown in Figure 17. Can you guess why?
Figure 17. Unchanged property value after
setResourceProperty operation
The ServerName property is set to be read-only, so the
Managed Agent Explorer cannot set the property to the new value. To see the errors, open
the Eclipse PDE error log by selecting Window > Show View > PDE Runtime >
Error Log from the menu bar. Selecting the error log from the Show View window
is shown in Figure 18.
Figure 18. Opening the PDE error log
As shown in Figure 19, you can see the errors in the error log. You can then display the
details by double-clicking on each error.
Figure 19. Error message in the PDE error log
You may see different errors in the log. If you defined the cardinality of ServerName to be [1..1] in your capability definition, you see an
exception about the maximum number of values being exceeded. You see this error because
the Managed Agent Explorer tries to do an insert action instead of an update action. The
first validation that the Apache Muse run time performs is to see if the cardinality rule is violated. If you have not defined your cardinality as [1..1], you see an exception about remote clients not being allowed to change the value of the property.
Now you will explore the start and stop operations.
Invoking operations
You need to be able to invoke resource operations so that you can manage the resource
through its WSDM interface. Operations are a key component of WSDM, and resource
management in general, because they let you change the state of the resource and perform
a management action on the resource. To begin this section, first expand the Operations node in the Resource Topology view as shown in Figure 20.
Figure 20. Viewing the list of operations
All operations are listed, including operations from the standard WSDM capabilities used in your resource type definitions as well as ones from your custom capabilities.
Now, you'll try to start the Apache HTTP server through its WSDM endpoint. For your
installation of the Apache HTTP server, you will probably see an Apache Monitor icon
running in the notification area of your taskbar, showing the server’s status (as shown
in Figure 21).
Figure 21. Apache services monitor in the system tray
Make sure the instance is stopped; otherwise, stop it using the Apache Monitor.
Double-click on the icon to see a detailed status of the HTTP server instance and to stop it. You can verify that the server is stopped by entering http://localhost/ in a Web browser’s address bar. If the server is stopped, you see a 404 error page.
Now you are ready to start the server using the Managed Agent Explorer. Choose the
start operation from the Resource Topology view as shown in Figure 22. You can see the
operation’s expected parameters and return type in the Details view. To start the
operation, right-click on the node and select Invoke or use the Invoke button in the middle of the Managed Agent Explorer page.
Figure 22. Invoking an operation
Now invoke the http://localhost/ address from your browser and you should see text
saying “It Works!” as the response confirming that the server is started. You will not
see the status updated in the Apache Monitor because, with the current Apache Muse
implementation, it doesn’t automatically refresh with the latest state of the server.
Now try the stop operation. Select the stop operation and you see its parameter and return type in the
Details view. As shown in Figure 23, a parameter named delay
of type int is required. Click on the parameter in the
Details view and provide a value in the Value editor. Use 10,000 for this example, which represents the number of milliseconds to wait before stopping the server. Click Invoke.
Figure 23. Invoking an operation with parameter values
Unfortunately, the endpoint is not properly threaded because this implementation did
not account for the delays of a synchronous call. You would need to allow for the
synchronous calls in your own implementation. In this example, the workbench will be
stuck waiting for a return for the stop operation, which
causes the workbench to freeze until the synchronous operation is completed. When you
think the operation should be complete (typically 10 seconds or so), check that the
server is stopped by using the browser to connect to http://localhost:8080/. If you do
not provide the required parameters or if the operation invocation fails for any other
reason, the error is shown in the error log (see Figure 24). If the error log view is
already present in your perspective it is brought to focus automatically if you have an error.
Figure 24. Errors shown in the PDE error log
For operations that have return values, the return value is shown similar to property
values in the Details table and can be viewed in detail. The last returned value is persisted until the operation is invoked again or the connection to the endpoint, specifically the TPTP Agent, is ended. You can end a connection by right-clicking on the agent and choosing Detach from Agent as shown in Figure 25, then delete the agent using the Profiling Monitor view.
Figure 25. Detaching from the profiling agent
Connecting to deployed endpoints
You have seen how to use the Managed Agent Explorer to test endpoints under
development. Now you will use it to introspect and interact with endpoints that are
already deployed on containers outside of the Eclipse workbench. This enables you to use
the Managed Agent Explorer to debug endpoints and check their behavior against your
expectations on the endpoint’s function. Hence, the Managed Agent Explorer can be used
to test endpoints under development as well as deployed endpoints created either with
the tooling or manually.
Your experience with this task should be consistent with the typical TPTP launch agent
mechanism that lets you define a profile that launches an agent that defines the
connection details to the target endpoint. The agent in this case is only an abstraction of the interaction with the target endpoint and is physically manifested as a new object within the workbench – not as a remote entity.
For an endpoint that you have previously developed outside the tooling, you need to
first deploy the endpoint. To deploy the endpoint, you must first create the .war file
that you then deploy on your Tomcat installation. Right-click on the Web project and
choose Export, as shown in Figure 26.
Figure 26. Export the endpoint
As in Figure 27, choose WAR file under Web and click Next.
Figure 27. Project Export window
In the window in Figure 28, provide the location where the .war file will be created.
The .war file must be placed in the webapps folder of your Apache Tomcat installation.
Browse to the webapps folder under Destination, as shown in Figure 26. Accept the
default name for the .war file, which is the same as the name of the Web module shown and, in this example, the same as the name of the web project you are exporting. Click Finish.
Figure 28. WAR Export window
The .war file will be created and placed in the webapps folder. Make sure that the
Apache Tomcat instance that you started within the Eclipse workbench is stopped. If not,
stop it by navigating to the Servers view, selecting the server, and clicking
Stop, as shown in Figure 29.
Figure 29. Stopping the server in the workbench
To start the Apache Tomcat instance, open a command prompt window and navigate to the bin folder
of your Apache Tomcat installation. Enter the catalina run
command at the command prompt. The Apache Tomcat instance starts and a server started message is displayed, as shown in Figure 30.
Figure 30. Starting Apache Tomcat from the command line
You have now completed the deployment of your endpoint.
You are now ready to create a Launch Configuration in the Eclipse workbench. Select
Profile from the toolbar (next to the Run button) and choose Open Profile
Dialog , as shown in Figure 31.
Figure 31. Eclipse menu option to open the profiling dialog
As shown in Figure 32, right-click on Managed Resource and choose New to create a new launch configuration for the WSDM endpoint.
Figure 32. Profile window
The configuration page for the newly created managed resource is displayed. You can
change the name of the profile in the Name field, as shown in Figure 33. Use
MyHttpServer for this example. All supported protocols are shown. Select WSDM
Resource and click Edit Options.
Figure 33. Creating a new Managed Agent configuration
The WSDM Managed Agent Configuration page is shown in Figure 34. The only configuration
detail you need to provide for the endpoint is its endpoint reference (EPR). You can
either construct the EPR in the Design tab by providing the URI and the individual
reference parameters, or in the Source tab by providing the XML fragment that represents
the EPR by copying and pasting it into the text area. The data in the Design and Source
data are automatically kept in sync. For this example, provide a URI in the Design tab as shown.
Figure 34. WSDM Managed Agent
configuration window
Switch to the Source tab to see the corresponding EPR XML, as shown in Figure 35. Click
Finish to close the window.
Figure 35. Source view of endpoint reference
Now in the Launch Configuration window, click Profile at the bottom of the page.
The Managed Agent Explorer connects to the WSDM endpoint and the Profiling and Logging
perspective takes focus. In the Profiling and Logging view you can see the new agent as shown
in Figure 36. Double-click on it to open the Managed Agent Explorer to introspect this deployed endpoint.
Figure 36. Managed Agent Explorer view in Profiling and Logging perspective
Now that you have connected to the endpoint, you can introspect and interact with it to
change the resource state or invoke operations.
Exploring WS-Service groups
Service groups are WSDM endpoints that serve as a logical collection of other WSDM
endpoints whose membership is constrained by a set of membership rules associated with the service group. This allows system architects to define logical groupings of related endpoints, which can be manifested physically as a service group endpoint so that the group of resources can be easily located.
The example used so far does not contain a service group endpoint, so let’s use the
endpoints provided as part of the Apache Muse samples. Download Apache Muse 2.2 from
http://www.apache.org/dist/ws/muse/2.2.0/bin/. Select the download image appropriate for
your platform. If you are using the .zip file, download the .zip file and extract it in
a location of your choice such as c:\muse. Navigate to the samples\j2ee\wsrf samples
folder, as shown in Figure 37.
Figure 37. wsrf sample from Apache Muse
The WSRF sample specifies a service group, an instance of which will be created at startup, along with simple WS-RF resources, instances of which will be created every 10 seconds. Muse adds all created endpoints to the service groups that are defined within the same scope, specifically muse.xml, as long as they meet the membership rules of the service group. By sampling the service group at regular intervals you can find all the created resources.
To build the sample WSRF endpoint, you will run the Apache Ant build.xml file provided
in the sample. Download, extract, and install Apache Ant from
http://ant.apache.org/bindownload.cgi. If Ant is installed in c:\ant\, the following
commands set up the environment on Windows®:
Listing 1. Setting up the environment on Windows
set ANT_HOME=c:\ant
set JAVA_HOME=c:\jdk-1.5.0.05
set PATH=%PATH%;%ANT_HOME%\bin
|
For other operating systems, follow the instructions at http://ant.apache.org/manual/install.html#installing
After Apache Ant is set up, open a command prompt window and navigate to the
samples\j2ee\wsrf folder of your Muse installation. See Figure 38.
Figure 38. Building the wsrf sample using Apache Ant
Run the ant command from the command line. The classes for
the sample are compiled and the endpoint is created. As shown in Figure 39, a new build
folder is created under samples\j2ee\wsrf. It contains the wsrf.war file that is the physical manifestation of the endpoint.
Figure 39. Output of the Apache Ant build
Copy the wsrf.war file to the Apache Tomcat webapps folder. Based on your Apache
Tomcat configuration, a restart may be necessary. When you copy the wsrf.war file, if an
Apache Tomcat instance is running, pay attention to its console. If you see a message
about the wsrf.war file being deployed such as is shown in Figure 40, a restart is not
needed. If a restart is needed, stop the Apache Tomcat instance by closing the command window where it is running, then restart it.
Figure 40. Automatic deployment in Apache Tomcat
Now you are ready to connect to this endpoint. Follow the instructions in Connecting to deployed endpoints to connect to the endpoint until you
get to the WSDM Managed Agent configuration window where you can enter the EPR. Enter
the EPR for this example (http://localhost:8080/wsrf/services/ServiceGroup), as shown in Figure 41.
Figure 41. WSDM Managed Agent
configuration window
The Profiling and Logging perspective opens and a new agent is added to the Profiling
Monitor view. Double-click on it to open the Managed Agent Explorer. Initially, the
service group is empty because the creation of resource instances begins only after the
first invocation to Muse has been made. In this example that happens when the Managed
Agent Explorer tries to collect metadata about the target endpoint. The endpoint you
have connected to is a WS-ServiceGroup endpoint, but because it also is a WSDM endpoint,
it has properties and operations. The Managed Agent Explorer recognizes that this is a
service group rather than simply a WSDM endpoint and, instead of displaying the
properties and the operations, the Managed Agent Explorer displays the current members
of the service group. Select the root node in the Resource Topology view, then click Refresh Properites, as in Figure 42.
Figure 42. Refresh Resource Topology view
The new members of the service group are displayed. Depending on how long you waited
between first bringing up the service group in the Managed Agent Explorer and clicking
Refresh, you will see more or less new members shown under the service group, as seen in Figure 43.
Figure 43. New service group members
This sample is a little uninteresting because all the members are of the same resource type and don’t provide differentiating captions in the Resource Topology view.
The WSDM standard specifies that the ResourceId provided
through the Identity capability, which is a mandatory
capability for endpoints, serves to differentiate one resource instance from another.
Click on a member resource to see its resource ID in the Details view, as shown in Figure 44. Notice that each of the children has a different resource ID, and represents a different instance of the same endpoint type.
Figure 44. Resource topology view showing service group members
In addition to looking at the service group members, you can connect to them. There are
two ways to connect. You can either right-click on the resource instance you want to
connect to or choose Launch Agent, as shown in Figure 45.
Figure 45. Connecting to a service group member
Refer to Figure 46 to see the new agent shown in the Profiling Monitor view representing the chosen endpoint instance. Notice the difference in the names of the agent. One is a ServiceGroup and the other is a Ws Resource. The name of the agent is derived from the caption of the resource unless the resource has no caption. If the resource has no caption, the URI of the resource is used.
Figure 46. New agent in the profiling monitors view
When you open the Managed Agent Explorer on that agent by either double-clicking on the
agent name or by using the context menu, the Managed Agent Explorer displays the details
of the endpoint and lets you interact with it as shown in Figure 47.
Figure 47. Managed Agent Explorer view
If you want to switch back to looking at the service group, open the agent in the
Managed Agent Explorer.
A less direct way to connect to a resource instance is to copy its EPR to the clipboard
and connect through an explicitly defined launch configuration. To copy the EPR,
right-click on the resource instance and select Copy EPR, as shown in Figure 48.
The EPR of the resource instance is retrieved and placed in the clipboard as an XML fragment.
Figure 48. Copy endpoint reference to the clipboard
Now create a new launch configuration as described in Connecting to
deployed endpoints. When you get to the WSDM Managed Agent configuration window,
switch to the Source tab and paste the contents of the clipboard. The contents may be
displayed as one long string instead of a tidy XML fragment. But if you do a quick
switch to the Design tab and back to the Source tab, the XML fragment is formatted
properly, as shown in Figure 49.
Figure 49. WSDM Managed Agent configuration
Now switch to the Design tab. As shown in Figure 50, the tooling separately displays
the URI portion of the EPR from the reference parameters and their values. There is only
one parameter in this case. You could have constructed the EPR by specifying the
appropriate values in the Design tab, and you would have ended up with the same EPR
except that the EPR created using the Design tab would have been created as an EndpointReference rather than as a MemberServiceEPR.
Figure 50. WSDM Managed Agent
configuration window’s Design view
You are now ready to save and run this launch configuration profile to connect to the individual resource instance.
Summary
In this article, you were introduced to the Managed Agent Explorer, a test tool to help
with the development of your endpoint using the TPTP tooling, and a test and
introspection tool for already deployed endpoints. The Managed Agent Explorer provides
quick and easy interaction with the endpoint. If you are building a WSDM endpoint
without using the Apache Muse run time, you can still use the Managed Agent Explorer to verify specification compliance of your endpoint and the logical behavior of the endpoint against your expectations.
You learned how to invoke the Managed Agent Explorer automatically when building an
endpoint in the tooling and also how to connect to a deployed endpoint. You learned how
to use the various views in the tool and how to do basic operations such as setting
properties and invoking operations. You were also introduced to introspecting service
groups. You are now ready to explore more advanced topics such as notifications and
relationships in the Managed Agent Exploer, so look for more articles in this series for
information on advanced topics.
If you would like to have some influence on the evolution of the Managed Agent
Explorer, please provide your feedback on the Eclipse TPTP mailing list as explained in
the article “Why Open Source for the WSDM Open Standard?” (see Resources).
Download | Description | Name | Size | Download method |
|---|
| Code sample | ac-manexp1source.zip | 8KB | HTTP |
|---|
Resources
About the author  | 
| | Balan leads the Web Services Distributed Management (WSDM) development team in the Tivoli Autonomic Computing group at IBM in Research Triangle Park, delivering run times and tooling for WSDM. His team delivers the open source Apache Muse WSDM run time and the tooling for WSDM in the Eclipse TPTP project to which he is a committer. Balan earned a Master's degree in Computer Science from George Mason University and has been with IBM since 2002. He is interested in Web services, grid computing, autonomic computing, social networking and robotics. He has published several articles and filed multiple patent applications, particularly in the areas of problem determination, autonomic computing and Web services. |
Rate this page
| 
