Data Service Resources

In the OGSA-DAI Architecture page the way in which OGSA-DAI supports interactions with data resources via perform documents directed at OGSA-DAI services was described.

A data service resource implements the core of the OGSA-DAI functionality. It accepts perform documents from data services, parses and validates them, executes the data-related activities specified within them and constructs response documents.

Data service resources can also cache data for retrieval by third-parties via the data transport operations of data services. Similarly, data service resources can also receive data from clients via these operations.

These interactions are described in more detail in the interacting with data service resources pages.

Data Service Resources and Data Resources

Each data service resource can support interaction with a single data resource. It does this via the use of a single data resource accessor. The configuration of the data service resource specifies the accessor to use, the configuration of the accessor specifies information such as the location of the data resource.

Data resource accessors are described here.

Special Data Service Resources

Data service resources need not necessarily expose data resources. They can also be used to support the transport or manipulation of data where the data is provided by third parties rather than being accessed from a data resource.

We currently support three such resources:

• Factory resources :
  • These provide the capability for other data service resources to be created via perform documents (rather than via the operations of a configurable data service which allow an existing data service resource to be associated with a data service).
  • A factory resource is one configured to interact with a demo factory data resource accessor.
  • Configuration files for the created resources will be written server-side so that the new resources will continue to exist after a Web services container shutdown and restart.
• Transient factory resources :
  • These are similar to factory resources except that the instance resources they create do not have associated configuration files written server-side. This means that transient instances will not continue to exist after a Web services container shutdown and restart.
• Relational multi-resources:
  • These resources aggregate relational data service resources that are hosted on the same server or on other servers. They allow an SQL query to be run over all the aggregated resources.

Data resource accessors for each of these resources are described here

Resource properties

All data service resources expose the following properties:

• {http://ogsadai.org.uk/namespaces/2005/10/properties}activityTypes - the names of the activities, possibly with associated descriptions, that the data service resource can be requested to perform on the data resource on behalf of the client - the legal activities in perform documents that can be sent to the data service resource via a data service.
• {http://ogsadai.org.uk/namespaces/2005/10/properties}performDocumentSchema - an XML Schema specifying the legal structure of perform documents that can be sent to the data service resource via a data service.
• {http://ogsadai.org.uk/namespaces/2005/10/properties}requestStatus-N (where N is a session identifier) - status of execution of the current or the most recent perform document executed within the context of a current session known to the data service resource.

In addition to these properties each data service resource will expose properties provided by their data resource accessors. These properties are described on the pages for each data resource accessor. Data resource accessors are described here.

Configuration

Every data service resource is configured using a collection of configuration files. Every data service resource uses the following types of configuration file:

• An activity configuration file specifies the activities which the data service resource allows clients to execute (i.e. submit via perform documents).
• A data resource accessor class configuration file specifies the name of the Java class that provides the implementation of the data resource accessor.
• A session configuration file specifies properties of clients' sessions with the data service resource.

In addition to these files each data service resource also has the configuration files for the data resource accessor it uses associated with it. These are described on the pages for each type of data resource accessor here.

All these files are constructed automatically by the tools provided to deploy data service resources. However, if you are interested, a detailed description of these files can be found on this page.

Concurrency

Each data service resource provides support for concurrency:

• A data service resource can process one or more requests concurrently.
• A data service resource can maintain a queue of one or more requests. If the resource has reached the maximum number of requests it can process concurrently then subsequent requests are queued up to the maximum queue size. Any subsequent requests will be rejected. When a processing request completes the first request on the queue begins execution.

Currently within OGSA-DAI these settings are specified when a data service is deployed. All resources exposed by the service inherit the same settings.

Sessions

Data service resources support sessions. Multiple requests can be executed within the scope of the same session. Actions specified within one perform document may store some state. Actions specified in subsequent perform documents may read, update or remove that state.

The provision of data to a data service resource or retrieval of data from a data service resource via a data service's data transport operations always takes place within the context of an existing session.

Lifetimes

At present data service resources are created in-memory when the data service that exposes them is created (or, if the data service supports this, from when they are dynamically deployed). They live until the server hosting the associated Web services is shut-down.

Benefits

Though the functionality currently supported by data service resources is limited and only have a subset of what you might find in other database connectivity infrastructures such as that provided by JDBC, the power of the data service resources, and the OGSA-DAI data services which expose them, lies in its exposure of a consistent interface regardless of underlying technology. In addition, using a document to describe data-related operations allows requests to be analysed and optimised.

Furthermore the activities supported by a data service resource is an extensbility point of OGSA-DAI. Users may write their own application-specific activities and change the configuration of their data service resources to support these, thereby allowing clients to specify these in their perform documents.