home > documentation > scenarios > behind application-specific service >

Using OGSA-DAI Behind an Application-specific Service

In many web-service or Grid applications clients access the data through application-specific services. In scenarios where clients access the data using application-specific services it is sometimes unclear whether there is a role in the application architecture for a generic data access service such as OGSA-DAI. The following diagram shows two possible architectures:

In architecture A there is no generic data access service. The application specific service communicates directly with the data resource. In architecture B the application service communicates with the data resource via an OGSA-DAI service. When architecture A is used there will be an additional SOAP request and response message pair between the application-specific service and OGSA-DAI. It is likely that the response from the OGSA-DAI service will contain a large data set which can be particularly expensive to transfer. Thus the naive inclusion of OGSA-DAI within the architecture may lead to performance degradation.

This section presents a number of situations where the use of OGSA-DAI may be beneficial even when used behind an application-specific service.

Use OGSA-DAI Delivery Activities

When using architecture B, data moves between OGSA-DAI and the application-specific service and between this service and the client. One of these potentially expensive data movements could be eliminated by using OGSA-DAI's delivery activities as shown below:

In the upper diagram OGSA-DAI's deliverToURL activity is being used to deliver the data to a to the client's FTP server. The data will therefore be written to a file in the client's own file space. In the lower diagram OGSA-DAI deliverToStream activity delivers the data to a servlet from which the client can directly pull the data using HTTP. In these cases the result data does not pass via the application specific service but is instead delivered by, or obtained from, the OGSA-DAI service. Clients do not need to know about OGSA-DAI for this to work. In the FTP cases the client simply needs to provide an FTP server. In the deliverToStream case the client simply accesses a URL using HTTP. The fact that is URL is a servlet on the OGSA-DAI server is irrelevant to the client - it is just a URL pointing to the data.

Because the data obtained from the database is not returned via the application-specific service you may have to develop some application specific activities to process the data you obtain from the data resources. It is very easy to write application specific activities.

The main advantage of adopting an approach such as this is that OGSA-DAI has implemented the delivery mechanisms for you. This therefore reduces the about of development work you have to do especially if you wish to experiment with a variety of different delivery options or want to allow the clients to choose from a set of delivery methods.

Using OGSA-DAI to Access Multiple Resources

If the application-specific service has to access multiple distributed data resources then using OGSA-DAI services to hide many of the DBMS specific access details (such as JDBC driver etc.) makes a lot of sense as show in the architecture below:

If the OGSA-DAI service is providing more functionality than simple access to a single data resource then its role in the architecture is crucial. For example, if OGSA-DAI exposes a data federation of multiple data resources, as shown in the diagram below, then it makes sense for OGSA-DAI to provide this functionality rather than to implement it within the application-specific data service.

If any of the architectures in this section are being used then the hints regarding efficient use of OGSA-DAI's delivery activities given above remain valid and are highly recommended.

Abandoning the application-specific service

The solutions suggested above require that much of the application-specific processing is performed as an OGSA-DAI activity. This has the advantage of potentially moving the processing closer to the data and hence possibly eliminating expensive data movement. If the application-specific data processing is written as OGSA-DAI activities then you may wish to re-evaluate the role of the application-specific service in your architecture.

Would it be possible for clients to access OGSA-DAI directly and use your application-specific activities in this way? Although doing so would place an extra burden on the clients to construct OGSA-DAI perform documents it may offer them greater flexibility in their choice of delivery methods rather than imposing a single delivery option via your application-specific interface.

Whilst in many cases it may not be possibly to remove the application-specific service it is worth at least considering the implications doing so and allowing clients direct access to the OGSA-DAI service. This service would probably have a a limited set of application-specific activities and set of appropriate delivery activities. It would also be advisable to ensure that clients did not have access to the raw data accessing activities such as as sqlQueryStatement. This is easy done by removing references to these activities in the data resource's activity configuration file.