GT 3.9.5 WS MDS Aggregator: Developer's Guide
- Introduction
- Architecture and design overview
- Public interface
- Usage scenarios
- Tutorials
- Feature summary
- Tested platforms
- Backward compatibility summary
- Technology dependencies
- Security considerations
- Debugging
- Troubleshooting
- Related Documentation
Introduction
The aggregator framework allows pluggable data sources and sinks to be written and connected together. Generally a source collects data from or about a particular grid resource, and passes it to a sink which does something interesting with it.
The aggregator sinks supplied with the toolkit implement the WS MDS Index Service and WS MDS Trigger Service. The aggregator sources supplied with the toolkit collect information using resource property queries, subscription/notification, and execution of external programs.
This document describes the programmatic interfaces to the aggregator framework. General Globus Toolkit coding guidelines and best practices can be found in the Globus Toolkit general documentation.
Architecture and design overview
The WS-MDS Aggregator is the software framework on which WS-MDS services are built. The aggregator framework collects data from an aggregator source and sends that data to an aggregator sink for processing. Aggregator sources distributed with the Globus Toolkit include modules that query service data, acquire data through subscription/notification, and execute programs to generate data.
The Aggregator framework is designed to facilitate the collecting of information from or about WS-Resources via plugin aggregator sources and the feeding of that information to plugin aggregator sinks, which can then perform actions such as re-publishing, logging, or archiving the information.
Aggregators work on a type of service group called an
AggregatorServiceGroupRP.
Resources may be registered to an AggregatorServiceGroupRP using the
service group add operation, which will cause an entry
to be added to the service group. The entry will include configuration
parameters for the aggregator source; when the
registration is made, the appropriate aggregation source and sinks will be informed; the aggregator source will begin collecting data and inserting it into
the corresponding service group entry, and the aggregator sink will begin
processing the information in the service group entries.
The method of collection by source and processing by the sink is dependent on the particular instantiation of the aggregator framework.
The aggregator sinks distributed with the toolkit
(org.globus.mds.aggregator.impl.ServiceGroupEntryAggregatorSink and
org.globus.mds.trigger.impl.TriggerResource) are described in the
following table.
| Aggregator Sink | Service Implemented | Description |
|---|---|---|
ServiceGroupEntryAggregatorSink |
Index Service | The servicegroup sink (used by the Index Service) publishes received data as content in the AggregatingServiceGroup entry used to manage the registration. This data can therefore be retrieved by querying the index for its 'entries' resource property. |
TriggerResource |
Trigger Service | The trigger service provides an aggregator sink which receives data, applies tests to that data, and if the tests match, runs a specified executable. See the trigger service documentation for more information. |
The aggregator sources supplied with the toolkit are listed in the
following table. Note: all aggregator sources listed in this table
are in the org.globus.mds.aggregator.impl package, so for
example the aggregator source listed as QueryAggregatorSource
is actually
org.globus.mds.aggregator.impl.QueryAggregatorSource
| Aggregator Source | Description |
|---|---|
| QueryAggregatorSource | The query source collects information from a registered resource by using WS-Resource Properties polling mechanisms (the GetResourceProperty, GetResourceProperties and QueryResourceProperties operations). Polls are made periodically, with both the period and target Resource Properties specified in the registration message. |
| SubscriptionAggregatorSource | The subscription source collects information from a registered resource using WS-Notification mechanisms. Data is delivered when property values change, rather than periodically. |
| ExecutionAggregatorSource | The execution source collects information about (not necessarily from) a registered resource by execution of a local executable, which is passed as input the identity of the registered resource. Details of the interface between the execution source and local executables are in the domain specific interfaces section of the Aggregator Framework Public Interface Guide. |
Public interface
The semantics and syntax of the APIs and WSDL for the component, along with descriptions of domain-specific structured interface data, can be found in the public interface guide.
Usage scenarios
The aggregator framework is used to create MDS services, linking an aggregator source (a java class that implements the AggregatorSource interface to collect data) to an aggregator sink (a java class that implements the AggregatorSink interface to process data, e.g., by providing a service interface for it). The AggregatorSource and AggregatorSink interfaces are documented in the aggregator Public Interface Guide.
Tutorials
There are no tutorials available at this time.
Feature summary
Features new in release GT 3.9.5
- Ported to use WSRF mechanisms (previously used OGSI).
- Additional sources which collect information by polling and by execution of local scripts.
- Management of aggregations is now performed over the wire through WS ServiceGroup APIs.
Other Supported Features
- Collects information from grid resources using pluggable aggregation sources.
- Delivers collected information to pluggable sinks.
- Manages creation and destruction of individual aggregation registrations.
Tested platforms
Tested Platforms for WS MDS Aggregator Framework
- Linux on i386
- Windows XP
Backward compatibility summary
Protocol changes since GT version 3.2
- The aggregator framework is a complete reimplementation of the MDS3 aggregator framework using WSRF rather than OGSI protocols.
- No wireside compatibility with MDS3 aggregator framework.
- Architectural similarity should make porting straightforward.
API changes since GT version 3.2
- APIs entirely rewritten, so no API compatibility.
- Architectural similarity should make porting straightforward.
Exception changes since GT version 3.2
- See API changes above.
Schema changes since GT version 3.2
- Registration interface uses WSRF rather than OGSI schemas.
- New per-source and per-sink configuration schemas.
Technology dependencies
MDS-Aggregator depends on the following GT components:
- Java WS Core
MDS-Aggregator depends on the following 3rd party software:
- None
Security considerations
By default, the aggregator sources do not use authentication credentials -- they retrieve information using anonymous SSL authentication or no authentication at all, and thus retrieve only publicly-available information. If a user or administrator changes that configuration so that a service's aggregator source uses credentials to acquire non-privileged data, then that user or administrator must configure the service's aggregator sink to limit access to authorized users.
Debugging
See the Debug section of the Java WS Core Developer's Guide for general information on logging, including which files to edit to set logging properties.
To turn on debug logging for the Aggregator framework, add the line:
log4j.category.org.globus.mds.aggregator=DEBUG
to the appropriate properties file.
Troubleshooting
General troubleshooting information can be found in the GT 3.9.5 Java WS Core Developer's Guide.
Related Documentation
Specifications for resource properties, service groups, and subscription/notification are available at http://www.globus.org/wsrf/.