Data Access and Integration

OGSA-DAI (Data Access and Integration) is perhaps less well known and understood than some other Globus components. However, it is one of the most useful and successful. Developed in the UK, it provides uniform Web Services interfaces to diverse data resources. These interfaces allow clients not only to "access" data, but also to query, update, transform, and deliver it. In other words, they let you specify some pretty fancy server-side operations.

We've been using OGSA-DAI recently in the new GT4 GRAM audit service, with good results. Audit records generated during job execution are stored in a database and can subsequently be retrieved by (authorized) clients. OGSA-DAI is used to create a virtual database from internal audit and accounting databases. The experience has been positive and has emphasized to me the value of the OGSA-DAI abstractions and implementation.

For more details on OGSA-DAI, visit their Web page. Among other things, they have an inspiring list of projects. And I like the octopus. Funnily enough, I raised the idea of an octopus as a Globus mascot a few years ago, but no-one seemed to like the idea.

Comments

[Stelios Sfakianakis]

Hi Ian,

Regarding OGSA_DAI it seems to me that what you gain by adopting it is the ability to access data through a WS interface. But you don't get any usefull functionality in addition to the plain accessing facilities, for example in order to use OGSA-DAI I have to know beforehand the kind of source database (is it a SQL or XML database?) and the internal schema.

So trying to be provocative I would say that OGSA-DAI seems to be something like WS-JDBC :-D

Regards
Stelios

[Mark Baker]

Ian - can you explain what this offers that a Web based approach does not?

Do the different data sources in such a system at least have an http or ftp URI so that one can easily get at the data with any of the myriad of existing Web clients?

Thanks.

[Ian Foster]

See this reply: http://ianfoster.typepad.com/blog/2006/11/more_on_ogsadai.html.

[Ian Foster]

Mark--thanks for the questions. In response:

OGSA-DAI allows you to do some pretty neat things, for example fancy server-side analyses. OGSA-DAI uses Web Services to encode its requests, and can use WSRF mechanisms to monitor and manage their executio0n. We could also encode those same requests in URIs (which I think is what you are proposing). Which approach is better is arguably just a matter of taste, although I myself like the structure and composition permitted by Web Services.

There is no reason why you can't provide both Web Services and HTTP/FTP interfaces to the same data, although we find that people tend to do either one of the other, as in Earth System Grid (www.earthsystemgrid.org: HTTP and FTP) and caBIG (cabig.nci.nih.gov: Web Services).

[Mark Baker]

Thanks for the response, Ian.

I didn't mean "encode the request in the URI", but instead just wondered whether the actual individual sources of data were named with http or ftp URIs. With such an approach, the HTTP message would form the request, where the URI is just one part of the request - it identifies the logical recipient of the request (the data source).

[leong]

Hello everyone,
what are the differences between Ogsa-Dai wsrf and WS-JDBC? Since WS-JDBC can do the same things like Ogsa-Dai and yet the WS-JDBC performances is better Ogsa-Dai. Could anyone share about this?

[t-di]

Hello,

I'm amazed by OGSA-DAI access and integration, truly it's an extraordinary services.
Then, I'm curious how technically that various data can be integrated?
Actually, I'm looking for any literatures explaining how it works?

Thanks :)