[dais-wg] RE: [ogsa-d-wg] New version of architecture document

[Mario Antonioletti]

Hi,
    Cc'ing this to the DAIS list in case anyone else wants to pitch in.
For context Dave is referring to the Data Access section in the OGSA
Data Architecture document which contains a section on data access
that comes from the DAIS perspective.

> 1. Derived data resources.  WS-DAI has properties that show whether
> updates to a child are reflected in the parent and vice-versa.  I think
> we mention derived data in passing; we could say more about it and treat
> it more consistently.

This is related to one  the suggested access patterns mentioned in 
section 7.1 (the Factory pattern). If you promote this section to
a more general place in the document the discussion of the patterns
and consequences of it could be put there.


> 2. Concurrent access and local transaction support.  ByteIO deliberately
> says nothing about concurrent access; we should at least mention this.
> Possible we should consider these issues across all data services?  The
> discussion of distributed transactions in 3.9 should mention the WS-DAI
> support for local transactions.

Some of the properties could certainly be generic service properties,
or OGSA data specific, etc. In this instance concurrent access and local
transaction support I think are probably generic properties even though
in most cases it may well be to say that local transaction support is
not available.

> 3. The WS-DAI CoreResource interface handles mapping from abstract names
> to addresses. We need to understand how this relates to the OGSA naming
> scheme.

In a way this was to try and keep both the pro- and anti- WSRF community
happy. The OGSA WS-Naming was not advanced enough for us to use it at 
the time of writing - the ability to have the name of the data 
resource that a message was targetting either in the body of the 
message and/or the header and the ability to map between these two 
usages ... an abstract name in DAIS is a URI. Not sure 
if that fits in with the OGSA Naming effort. The naming thing was 
big issue in DAIS and it would be a long discussion to go over it. Also, 
you really mean CoreResourceList here and not CoureResource - right?

> 4. WS-DAI defines properties for the name of a resource and a
> human-readable description of the resource.  These seem reasonably
> generic properties - we (or even the OGSA WG) might want to consider
> whether they are more widely useful.  (Or perhaps we should ask the DAIS
> WG to explain why they are necessary in WS-DAI if they are not needed
> anywhere else).

I think they could be more generic. At the time the DAIS specs were 
being written though I'm not sure if anyone else was using these. It
might be good to have such a generic set of properties recommended
by OGSA ... I don't think there was anything specific to DAIS in
these.

> Finally, I note that section 11.3 mentions enhanced access operations
> that would ease the federation of a data resource.  This is worth a
> forward mention from the data access section itself.

Or does it constitute a pattern in itself? Not looked in detail at this 
... otherwise a forward reference is possible ....

Hope this helps and if anyone from DAIS wants to pitch in or read the 
OGSA Data Architecture document (and comment then please do so).


 			Mario

> Dave.
>
>
> -----Original Message-----
> From: owner-ogsa-d-wg at ggf.org [mailto:owner-ogsa-d-wg at ggf.org] On Behalf
> Of Dave Berry
> Sent: 29 June 2006 23:34
> To: ogsa-d-wg at gridforum.org
> Subject: [ogsa-d-wg] New version of architecture document
>
>
> I've uploaded a new version of the architecture document -
> https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-
> d-wg/docman.root.working_drafts/doc13621/2.
>
> Changes:
>
> - I've moved some generic description out of the data access section
> into the introductory sections.
> - I've tidied the data access section.  At least, I think it's tidier;
> please could the authors take a look and tell me what I've messed up?
> - I've made the discussion of policies and agreements more consistent
> throughout the document.  This includes moving a list of example
> policies from the federation section into section 2.
> - I've tidied the glossary, removing unused items and ensuring that
> certain other terms are used consistently in the text.
>
> Note: where I've copied chunks of text from one place to another, I
> switched off change tracking because such large deletions and additions
> don't tell you much.  Instead, I've highlighted the text in yellow where
> it now appears.
>
> Still to do (at least):
> - Add a discussion of interfaces to the data caching section.
> - Ditto for the replication section.
> - Revise the metadata catalog section.
> - Tidy the appendix list of standards.
>
> I'm about to go on holiday for a week, so these tasks won't get done for
> a while.
>
> Dave Berry
> Deputy Director, Research & E-infrastructure Development National
> e-Science Centre, 15 South College Street
> Edinburgh, EH8 9AA           Tel: +44 131 651 4039
>
>

+-----------------------------------------------------------------------+
|Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3JZ.   |
|Tel:0131 650 5141|mario at epcc.ed.ac.uk|http://www.epcc.ed.ac.uk/~mario/ |
+-----------------------------------------------------------------------+