480 likes | 584 Vues
This summary outlines key points from the perfSONAR workshop led by Jeff Boote on February 11, 2010. It emphasizes the importance of developing robust client applications for perfSONAR, which are vital for successfully consuming measurement data. The workshop covered various client interactions such as Echo requests, MetadataKeyRequests, and SetupDataRequests, along with the role of Lookup Services and APIs available in the perfSONAR-PS packages. A focus was also placed on the need for effective communication with services via SOAP over HTTP and the management of XML responses for performance measurements.
E N D
February 11th 2010, APAN 29 – perfSONAR Workshop Jeff Boote, Assistant Director R&D perfSONAR Client Construction
Outline • Motivation • Types of Client Interaction • Echo • MA • MetadataKeyRequest • SetupDataRequest • LS • XQuery • Discovery • API Tour
Motivation • Development of client applications is crucial to the success of perfSONAR • External applications will consume the measurement data • Researchers will find new users for performance measurements through client applications • Client development requires knowledge of: • Service operation • Framework interaction • Available APIs • Data formats
Types of Client Interaction • There are different types of client interaction • Echo Request • Check the ‘liveness’ of a service • MA Specific Messages • MetadataKeyRequest • Request a replayable ‘key’ to get measurement data • SetupDataRequest • Request measurement data • LS Specific Messages • Xquery • Raw interface to LS databaes – using the XQuery interface • Discovery • Structured discovery queries
Echo Request • The Echo request is a simple message that checks to be sure a service is ‘alive’.
Echo Request • Client must be prepared to: • Communicate with services using SOAP over HTTP • Send a request message to a given service URL • Parse the XML response from the service • Record the results of the Echo • Success in the form of an EchoResponse • Failure in the form of an EchoResponse • Service timeout • Alternate response (anything but an EchoResponse message should be viewed as a failure)
Measurement Archive • The MA derived services have two messages that are interest to client applications: • MetadataKeyRequest • Given a (partial) metadata description, the service will check if this exists in the database • If it does exist, return a replayable ‘key’ to have a fast access to measurement data • SetupDataRequest • Given a (partial) metadata description, the service will check if this exists in the database • If it does exist, return measurement data
Measurement Archive • Each message has the ability to apply what is called a ‘filter’. • Filters are a way to limit the returned data set: • By Time • By Type (e.g. in the case of RRD data select which ‘consolidation function’ is applied) • Filters are applied to a metadata in the message by using the ID fields
Measurement Archive • Different measurement archives will have different metadata formats • SNMP MA • Layer 3 Interface description • perfSONAR BUOY • Endpoint pair (2 Layer 4 hosts) • PingER • Endpoint pair (2 Layer 4 hosts) • Status MA • Layer 3 or Layer 2 Interface description • Consult the protocol and service documentation for specific formats • Your client should be prepared to parse the XML to find useful information
Measurement Archive Requests • Client must be prepared to: • Communicate with services using SOAP over HTTP • Send a request message to a given service URL • Parse the XML response from the service • Be prepared to deal with key elements • Understand the data format of the returned measurement data • In the event of an error: • Interpret a result code from the service • Fail gracefully
Lookup Service • The gLS and hLS have two messages that are interest to client applications: • LSQueryRequest (XQuery Based) • The metadata subject will contain an XQuery statement • The XQuery will be applied to the Lookup database. • The success or failure will be passed back • LSQueryRequest (Discovery Based) • A well formed metadata block will contain items to search for • Domains • Keywords • IP Ranges • Data Types • The summary database will be consulted • A list of services to consult further (either hLSs or services depending if you asked at the gLS or hLS layer) will be returned
API Tour • There are several client APIs available in the perfSONAR-PS packages: • perfSONAR_PS::Client::Echo • Package for performing echo tests against services • perfSONAR_PS::Client::MA • Package for contacting any MA using general calls • perfSONAR_PS::Client::PingER • Package for interacting with PingER servers • perfSONAR_PS::Client::LS • Package for contacting the LS infrastructure, could be used for hLS or gLS • perfSONAR_PS::Client::gLS • Package for contacting the gLS infrastructure, could also be used to contact hLS instances
perfSONAR Client Construction February 11th 2010, APAN 29 – perfSONAR Workshop Jeff Boote, Assistant Director R&D For more information, visit psps.perfsonar.net
perfSONAR_PS::Client::Echo • Module designed to send a simple EchoRequest to a given service • Object Oriented • Built in use of: • SOAP over HTTP transport • XML Parsing • Evaluation of result codes for success or failure • More information available via perldoc
perfSONAR_PS::Client::MA • Module designed to send a generic MetadataKey/SetupData requests to services • Object Oriented • Built in use of: • SOAP over HTTP transport • XML Parsing • Support for error codes • General construction accepts XML for subjects • Requires that clients have knowledge of the service they are contacting • Returns XML (metadata and data) in perl objects • Requires clients to parse out much of the meaning • More information available via perldoc
perfSONAR_PS::Client::PingER • Module designed to send queries to PingER services • Object Oriented • Built in use of: • SOAP over HTTP transport • XML Parsing • Support for error codes • General construction accepts XML for subjects • Returns structured objects that contain data • Used in several GUI applications • More information available via perldoc
perfSONAR_PS::Client::LS • Module designed to query (and perform other operations) on LS type services • Works with gLSs and hLSs • Object Oriented • Built in use of: • SOAP over HTTP transport • XML Parsing • Support for error codes • Main query mechanism is to support arbitrary XQuery statements • Requires knowledge of XQuery to be effective
perfSONAR_PS::Client::gLS • Module designed to query gLSs, namely the discovery component • Will work on the summary set of an hLS also • Object Oriented • Built in use of: • SOAP over HTTP transport • XML Parsing • Support for error codes • Supports both raw (XQuery type) operation as well as discovery queries: • IP Addresses • Domains • Data Types • Keywords
perfSONAR Client Construction February 11th 2010, APAN 29 – perfSONAR Workshop Jeff Boote, Assistant Director R&D For more information, visit psps.perfsonar.net