OGSA-DAI Architecture

The architecture of OGSA-DAI consists of a number of layers each serving a different purpose. A high-level schematic representation of this architecture is shown in Figure 1.

Figure 1: The high-level architecture of OGSA-DAI.

The components in each layer and the interfaces between them are explained below, starting from the bottom layer and working upwards.

Data Layer

The data layer consists of the data resources that can be exposed via OGSA-DAI. Currently these include:

• Relational databases such as MySQL, SQL Server, DB2, Oracle, PostgreSQL.
• XML databases such as eXist, Xindice.
• Files and directories in formats such as OMIM, SWISSPROT and EMBL.

Data Layer ↔ Business Logic Layer Interface

This interface allows information to be communicated between the data layer and the business logic layer in both directions. It is realised by components known as data resource accessors. Each data service resource has its own data resource accessor which controls access to an underlying data resource, as shown in Figure 2.

Figure 2: A data resource accessor provides access to an underlying data resource.

OGSA-DAI includes data resource accessors for relational databases, XML databases and file systems. This component is an extensibility point, so users can develop their own data resource accessors in order to expose new kinds of data resource.

Business Logic Layer

This layer encapsulates the core functionality of OGSA-DAI. It consists of components known as data service resources. As shown in Figure 1, multiple data service resources can be deployed to expose multiple data resources. There is a 1-1 relationship between data service resources and data resources. The responsibilities of a data service resource include:

• Execution of perform documents - a perform document describes the actions that a data service resource should to take on behalf of the client. Each action is known as an activity. OGSA-DAI already includes a large number of activities for performing common operations such as database queries, data transformations and data delivery.
• Generation of response documents - a response document describes the status of execution of a perform document and may contain result data, such as the results from a database query.
• Data resource access - interactions with data resources take place via the data resource accessor component.
• Data transport functionality - data can be streamed in and out of data service resources to and from clients and other data service resources.
• Session management - the creation, access and termination of session objects allowing state to be stored across multiple requests to the data service resource. All perform document requests are processed within a session. Sessions are also used for storing the streams used by the data transport functionality. These are known as session streams.
• Property management - the creation, access and removal of properties associated with the data service resource. These are known as data service resource properties and are generally used for exposing meta-data such as the status of a request or the schema of the underlying data resource.

Several components of the business logic layer are described in further detail in the Interacting with Data Service Resources section.

Business Logic Layer ↔ Presentation Layer Interface

This interface allows information to be communicated between the business logic layer and the presentation layer in both directions. It supports the invocation of OGSA-DAI functionality within the business logic layer in a way that is independent of a particular web environment. In fact, the same interfaces could even be used by a stand-alone client application outside of any web environment.

When SOAP Requests arrive at OGSA-DAI WSRF or WSI data services, this interface is used to pass information and instructions to and from the business logic layer. The flow of information between these two layers is described below.

Presentation Layer → Business Logic Layer

• Data service resource names, data service resource property names, session stream identifiers.
• Client proxy certificates and credentials in a web-independent format.
• Perform documents and data from clients.
• Data service resource configuration information including data resource drivers, data resource URIs, database user names and passwords, information on supported activities, information on data service resources session and concurrency support.

Business Logic Layer → Presentation Layer

• Response documents and result data.
• The status of the request processing within a particular session. This is known as the session request status.
• Data service resource property values such as the schema of the underlying data resource.
• Information about the activities that are supported by the data service resource. These are the activities that can be requested by the user within perform documents.

Presentation Layer

This layer encapsulates the functionality required to expose data service resources using web service interfaces. OGSA-DAI includes two realisations, one compliant with WSRF and the other compliant with WSI (that is a solution that only relies on the specifications mentioned in the WS-I basic profile, i.e. that do not use WSRF). These were schematically shown in Figure 1 as the WSRF and WSI data services. For each realisation there is a WSDL document that describes the interface.

Client Layer

A client can interact with a data service resource via a corresponding data service. Depending on whether a WSRF or WSI data service has been deployed, the client application must be compliant with the WSRF or WSI standards.

OGSA-DAI also includes a Java Client Toolkit which provides a higher-level API for interacting with data services. The Client Toolkit simplifies the development of client applications by providing convenient ways to construct and send requests and interpret the subsequent responses. An additional benefit of the Client Toolkit is the inter-operability it offers between the WSRF and WSI data services. An application written using the Client Toolkit will be able to access and interact with WSRF and WSI data services transparently. The Client Toolkit is described in detail in the Client Toolkit Tutorial.