[dais-wg] A simple Data Access service

[Dave Berry]

Folks,

I'm bemused by discussions of "lifetime management" that are reducing
the issue to "delete" messages.  What about the soft-state
functionality?

Dave.


> -----Original Message-----
> From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On 
> Behalf Of Savas Parastatidis
> Sent: 19 April 2005 12:21
> To: dais-wg at gridforum.org
> Subject: FW: [dais-wg] A simple Data Access service
> 
> Dear all,
> 
> This is my 3rd attempt to sending the files... I just 
> realised that the
> other messages were failing silently to appear due to the zip
> attachments...
> 
> You can download an updated version of the files from here:
> 
> http://savas.parastatidis.name/dais/dais2.zip (this link is not
> permanent and it will disappear after a few weeks or so).
> 
> Here are some changes to the files since my original post (copied from
> one of my failed posts)...
> 
> I have an updated version of the WSDL and XSD files. This time, I have
> included a 'Delete' message to demonstrate how one could include
> DAIS-specific 'lifetime' management capabilities. It took me 
> a great one
> line of code to implement this functionality :-)))
> 
> The WSDL operation expects the name of the data resource to delete.
> Extending this to support multiple or no data resource names 
> is trivial.
> 
>  
> 
> Talk to you all this afternoon (or morning to some).
> 
> Regards,
> --
> Savas Parastatidis
> http://savas.parastatidis.name
>  
> 
> > -----Original Message-----
> > From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On Behalf
> Of
> > Savas Parastatidis
> > Sent: Tuesday, April 19, 2005 12:25 AM
> > To: dais-wg at gridforum.org
> > Subject: [dais-wg] A simple Data Access service
> > 
> > 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
> > 
> > 
> > 
> 
> 
>