[dais-wg] A simple Data Access service

[Savas Parastatidis]

Dear all,

Please allow me to contribute to the discussions the metadata for a
simple data access service that I put together in a couple of hours. The
service is based on approach 4 which was discussed at the teleconference
last week. It uses only WS-I Basic Profile specs (apart from the
'resolve' response message which returns the XML representing a
WS-Addressing EPR).

I have implemented two WSDL portTypes: DaisCore and DaisRelational. I
have exposed them as two ports of the same service (the wsdl:service
element) but the messages from the two namespaces could have been
included in the same portType. As a result, only one port would have
been necessary. This is an implementation detail.

The DaisCore portType is supposed to provide access to the wrapped DBMS.
It can return Properties (the XML Schema of the properties document is
visible to the consumers) and it can resolve names of data resources to
EPRs.

The DaisRelational portType describes the messages supported for
relational data resources. It allows SQL queries to be sent and a)
either a WebRowSet is returned or b) a name to a WebRowSet data
resource. I have included a WebRowSetCount message which, given a name
for a data resource, will result in a message with the number of rows in
the rowset to be returned. Other relational-related messages can also be
provided. You'll also notice that I have a RelationalProperties message.
This is to allow for relational-specific properties to be returned
together with the DaisCore properties. The two could be different if
necessary.

If the name for the data resource in the WebRowSetCount message is made
optional, then the same message could be used with WSRF. The difference
would be that an EPR would be required. I think such an approach can act
as a bridge between approaches 3 and 4.

Messages for the lifetime management of the data resource created from
the ExecuteSqlResultByRef message would have to be defined. WSRF
implementations won't need such messages.

The attached WSDL and schema files were automatically created from my
implementation. They should work with any WS-I-compliant tooling.
However, if there are any mistakes, this is because I had to clean them
up from policy-related metadata and format them for readability.

The cool thing about the implementation is that it only uses something
between 100-200 lines of code. I use a hashtable to maintain the
resulting data resources from the queries although a database could
easily be used as well in order to allow for scalability of the
implementation.

Please note that I don't make a distinction between type 2 and type 3
resources. If you feel strongly about making the distinction at the
portType-level, I am open to suggestions.

The service uses SQL Server 2005 beta 2 at the backend (although any
other DB could have been used) and exposes the SLOAN Digital Sky Survey
(SDSS) database. Unfortunately, I can't deploy the service anywhere for
you to try since the necessary tools are only installed on my laptop and
I don't have another machine at the University from which I can make the
service available :-( I'll see if something can be done though.

Let me know what you think.

Best regards,
--
Savas Parastatidis
http://savas.parastatidis.name