In TPTP 4.2, we introduced an Agent Controller based on new technology. This resulted in two Agent Controller API's (i.e. the original Agent Controller, and the new technology Agent Controller). With TPTP 4.4, we are only shipping the new technology Agent Controller. While some developers may want or need to continue using the original Agent Controller, there are good reasons why most developers should begin migrating to the new technology Agent Controller. This guide defines the differences between the two Agent Controller versions, and gives developers decision criteria for when to migrate to the new technology Agent Controller.
In TPTP 4.4 the new technology Agent Controller is supported on the Windows IA32, IPF, and EM64T platforms as well as on the Linux IA32, IPF, and EM64T platforms. Additionally, the Integrated Agent Controller is now identical to the standalone new technology Agent Controller. (Note: In TPTP 4.4, the Integrated Agent Controller is offered as a technical preview on 64-bit systems.) The new technology Agent Controller supports backward compatibility and can be used with earlier versions (TPTP 4.3.1 is recommended) of the original Agent Controller on the following platforms: Linux PowerPC/64-bit, Linux zSeries, z/OS zSeries, OS/400 iSeries, AIX RISC System/6000, Solaris SPARC, and HP-UX RISC.
The new technology Agent Controller includes a backwards compatibility layer that allows existing clients and agents to communicate with it in the same way they did with its predecessor. Anyone familiar with the previous agent controller can install a package with the new agent controller in it and continue to use it as they did before. Thus, while different platforms will contain different implementations of the agent controller, all platforms can continue to use the agent controller in the same fashion (when using the old interfaces).
The new technology Agent Controller implements a new API that is richer and easier to use. In addition to its remote application launching and file transfer services, it provides the ability to dynamically discover agents (such as data collectors), allows multiple instances of the agent controller to run, and allows extensions of the command set using XML fragments. Using the new API, a client application can dynamically discover which agents are installed on the system where the Agent Controller is running. It can therefore adjust the services it offers to a user according to what is available on the system the user chooses to connect to. The new API is available in both C++ and Java implementations.
The new technology Agent Controller design is a significantly different evolution of its predecessor. While it includes a compatibility layer that maintains the old APIs, adopters interested in additional functionality and performance improvements in the future should be using the new APIs and removing any dependence on the compatibility layer.
The new technology Agent Controller provides the same basic functionality for launching applications, locally or remotely, as its predecessor. It performs the platform-specific work of starting collector or service agents and setting up command and data channels so that a client can communicate with the agents. The goal of the redesign is to make the agent controller flexible so that it can be easily extended to meet more needs. One such change was replacing the use of binary and custom commands for exchanges between clients, agent controller, and agents to standardizing on the use of XML fragments for all commands. Agent writers can easily define their own command set without impacting the agent controller and clients can create and send all commands in a uniform fashion. Another change towards flexibility was implementing the communication layers as replaceable units so that others can drop in their own version to meet a particular platform or performance need.
With the new technology Agent Controller comes new programming interfaces for both client and agent writers. These API’s are available in both C++ and Java, whereas only Java was available in the past. The concept of agents and collectors (specialized agents with the purpose of collecting data) have been formalized into classes of objects with base implementations that do the standard tasks expected of an agent or collector agent, so that the focus of development is on the unique purpose of the agent.
There are differences in the services available through the old and new agent controller APIs. Those features that are currently only available through the old API are expected to be added to the new API in coming releases. (For information on features going into a particular release, please refer to the release plans which are developed and posted on the TPTP home page http://www.eclipse.org/tptp).
Additional functionality available through the new APIs:
Functionality only available through the old APIs:
If you are implementing an agent application that will interact with the Agent Controller, you have a choice of using the new API or the old API. Following are the things to consider when making that choice.
If you are limited by platform support of the old or new API, check the TPTP published plan for the upcoming release (http://www.eclipse.org/tptp) to find out when the new Agent Controller will be available on the platforms of interest, before choosing to write to the old interface. You can influence the order in which platforms are supported by submitting enhancement requests to bugzilla naming the platforms of interest and time frame needed, or simply voting for the enhancement of interest if a bugzilla already exists.
SDKs for each platform are available from the Downloads page at http://www.eclipse.org/tptp/home/downloads/downloads.php .
C++ and Java reference specifications for the new API can be accessed through the TPTP Data Collection Framework document. Refer to the Extending the Agent Controller and Integrated Agent Controller document to find the Java reference specification for the old API.
Copyright (C) 2005, 2007 Intel Corporation.