[dais-wg] Fw: WS-DAI progress

Thu Jun 9 08:17:57 CDT 2005

Simon,

I've worked through the specification...very interesting... here are
some comments...

p5 Section 3.1. "There will be situations where data is created in the
context of a DAIS data service alone...". I wasn't sure why the
distinction was being made between this and the case described in the
previous paragraph. In both cases a data resource is managing the data,
and in both cases it is the data resource that is responsible for
managing the lifetime of the data (see comments on p9).

p6. Section 3.2. I didn't understand what a data conduit is, or why it
needs to be introduced. From the description it sounds the same as a
data service (e.g. to give a context within which a data resource is
identified). Section 4.1 says that a conduit is a data resource, but
that isn't stated in Section 3.2.

p6. Section 3.6. To avoid confusion, I wonder if it may be better to
call this a "Data Resource Abstract Name", i.e. to distinguish it from a
service abstract name.

p6 Section 3.7. Similarly, I wonder if it may be better to call this a
"Data Resource Address".

p6 Section 4.1. Type 2 resources. Does it have to be a DBMS? Or could it
be just any data management system?

p7 Section 4.1. Type 3 resources. I wasn't sure why it was necessary to
make a distinction between Types 2 & 3. Could we think of Type 3 data as
being managed by some form of data management system within the DAIS
service? If so then Type 3 is the same as Type 2.

p8. Section 4.7. "The type and behaviour of the new database service and
data resources are determined by the configuration parameters passed in
with the original request." This makes it sound as if it is
possible/normal to create a new service with arbitrary type and
behaviour. Is it instead more likely that the result will be made
available through an existing, already deployed service? This does not
preclude the choice of the service/resource combination being made by
the service to which the request was sent, possibly taking into account
information sent by the consumer in the request.

p9. Section 4.9. Lifetime. As with the comment on p7, Section 4.1. I
couldn't see why there was the need to distinguish between Type 2 and
Type 3 resources. It seems that the distinction is only in the policy of
the data resource regarding lifetime of data. For example, it may be
that for Type 2 data, the policy is that when the resource is removed
then the data is also removed (because the data resource knows that the
data it holds is only accessible through that one service+resource
combination)... in which case the distinction between Types 2 and 3
disappears.

p14. Section 5.2.1. The message patterns look good.

p16. Section 5.3. Earlier, in the definitions part of the spec, this
approach was (I think) referred to as indirect data access. Now it is
described in a "Data Factory" section. As it is not necessary for a new
data resource to be created by indirect data access operations, and all
operations on the service (direct or indirect) can create new data, I
think that it would be clearer if the term "indirect data access" was
used, rather than "factory".

 p15. Section 5.3. It wasn't clear to me what was meant by "such
messages create a new relationship between a data resource and a data
service. Also "In this way a data service may be used to represent the
results of a query or act as a place holder for data to be inserted into
a data resource."... I was expecting this to refer to a data resource
rather than a data service. Similarly, I therefore wasn't sure what it
meant for "a data service to act as a place holder for data to be
inserted into a data resource".

p16. Section 5.3. "The RowSet could be stored as a table in a relational
database or decoupled from the database, but the important distinction
here is that the data is represented as a collection of rows via a data
service that does not implement the SQLAccess portType." I wasn't sure
why this distinction was important.

p17 Section 5.3.1. wsdai:Configuration. See comment on p8. Section 4.7.

p17 Section 5.3.1. I was wondering if it would be useful to include some
metatadata in the response messages from all indirect data access
requests (e.g. data size, number of rows). This would help the consumer
in making decisions regarding what to do with the data (e.g. how much
space would be needed to store the data if it were fetched)

p18 Section 7.1. Will there be a "Mapping to WS-I" section?

So, overall it looks good though I didn't understand the need for:
a)       conduits
b)       a distinction between Type 2 & 3 services

Regards
Paul

________________________________

From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On Behalf Of
Simon Laws
Sent: 08 June 2005 15:34
To: dais-wg at ggf.org
Cc: Susan Malaika; Mario Antonioletti; amrey at epcc.ed.ac.uk; Norman
Paton; Savas Parastatidis
Subject: [dais-wg] Fw: WS-DAI progress

I have previously sent the core spec out to a copy list and missed
people out. This time I worked to get the changes done before going on
leave at the end of May and sent it to the DAIS list and no one got it!
Its getting worse:-) Mario thinks its to do with attaching a zip file.
So I can only apologise but I did try and get this out to you all a week
and a half ago. Now I am adopting the strategy of putting it up on grid
forge. 

The latest core spec 
http://forge.gridforum.org/projects/dais-wg/document/Grid_Data_Service_S
pecification/en/8 

The latest WSDL 
http://forge.gridforum.org/projects/dais-wg/document/Grid_Data_Service_S
pecification_WSDL/en/1 

Simon 

Simon Laws
IBM Hursley - Emerging Technology Services

----- Forwarded by Simon Laws/UK/IBM on 08/06/2005 15:25 ----- 
Simon Laws/UK/IBM 
29/05/2005 13:10 
To
dais-wg at ggf.org 
cc

Subject
WS-DAI progress

Here is the current WS-DAI document and WSDL... 

[attachment "Grid_Data_Service_Specification-v1-27May05.doc" deleted by
Simon Laws/UK/IBM] 
[attachment "wsdl0.7-270505.zip" deleted by Simon Laws/UK/IBM] 

Still not done but gives a good idea about how it could look. I'm out on
leave this week so will pick up again in a week or so. 

Regards 

Simon 

Simon Laws
IBM Hursley - Emerging Technology Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050609/83961a80/attachment.htm 