[dais-wg] DAIS Mapping Options

[Norman Paton]

The DAIS Working group hopes to submit its specifications as proposed 
recommendations around GGF14, and thus needs to make a decision about 
mappings shortly. By "mappings" we mean the use made of other 
specifications to support things like naming and lifetime management. 
Sources of relevance to this topic include:

- Scenarios for Mapping DAIS Concepts:
[1] 
https://forge.gridforum.org/projects/dais-wg/document/draft-ggf-mappings-ggf12/en/1 


- The current specification drafts:
[2] 
https://forge.gridforum.org/projects/dais-wg/document/Grid_Data_Service_Specification/en/7 

[3] 
https://forge.gridforum.org/projects/dais-wg/document/Relational_Realisation/en/5 

[4] 
https://forge.gridforum.org/projects/dais-wg/document/XML_Realisation/en/11

This message provides a high-level summary of the mapping options. 
Following the terminology from Susan Malaika's message summarising 
discussions at DAIS Session 2 from GGF13, the following types of 
resource are of relevance to DAIS:

Type (1): Resources that describe and provide access to other resources. 
An example of a property such a resource might have is the names of 
available resources.  The recent postings by Simon Laws and Susan 
Malaika on the results of the second DAIS Session at GGF13 describe a 
"conduit" that might be considered a Type (1) resource.

Type (2): Those resources managed by a DBMS, specifically databases.

Type (3): Those resources managed by a DAIS implementation, specifically 
result sets that persist for subsequent delivery.

The current DAIS specifications do not directly support Type (1) 
resources. In terms of Type (2) resources, the DAIS specifications have 
never contemplated representing data model constructs (such as tables or 
indexes) as first-class resources at the service level. The following 
mapping options have all been floated at some time or other in the DAIS 
setting:

Mapping Approach 1. Use WSRF for all three types of resource. In such a 
setting, WSRF provides facilities for resource naming, lifetime 
management and access to properties. Availability: such a mapping is 
provided in the current DAIS specifications [2,3,4].

Mapping Approach 2. Use WSRF for none of the types of resource. In such 
a setting, resource names (existing or created within DAIS) would be 
passed in message bodies, and mechanisms would be developed for managing 
lifetime (where necessary) and property access. Availability: certain 
scenarios are discussed in [1].

Mapping Approach 3. Use WSRF for some types of resource but not for 
others. The recent posting that describes the proposal discussed at 
GGF13 used WSRF to represent Type (3) resources, but did not use WSRF to 
represent Type (2) resources.  The motivation for drawing this 
distinction is that Type (2) resources are generally created and 
destroyed outside the services space, and thus are associated with 
existing naming schemes and lifetime models that may not map comfortably 
to WSRF. By contrast, Type (3) resources are created and have their 
lifetimes managed within the services space, and both naming and 
lifetime management requirements seem to map naturally to WSRF. 
Availability: only discussed in Susan's Simon's recent emails to the list.

Mapping Approach 4. Adopt a twin track approach, whereby the 
specifications support two mappings for all types of resource. 
Availability: no concrete proposal has been developed.  One might 
anticipate that the WSDL would often define identical messages for both 
mappings, but with optional name elements for resource identification.

The discussions around the above issues have addressed both technical 
and political topics; at times it has sometimes been difficult to tell 
which points have been technical and which political!

As pros and cons matter, here are a few; there is a further list in 
[1].  We probably don't want to enumerate all possible pros/cons, but it 
may be useful to iterate to an agreed list of key issues.  Where a Pro 
of one approach is an obvious Con of another (or vice versa), it has 
been listed only once.

Mapping Approach 1:
Pros: Consistent representation across all resource types; able to 
exploit standard mechanisms for naming and resource properties.
Cons: Some technical challenges mapping Type 2 resources (existing 
names, external management); not all potential adopters are committed to 
WSRF.

Mapping Approach 2:
Pros: Minimal external dependencies.
Cons: Need to reinvent some of the WSRF machinery for resource 
properties and lifetime management.

Mapping Approach 3:
Pros: Allows mappings that reflect the different characteristics of 
different kinds of resources; could be written to have a core that only 
has dependencies on WS-I.
Cons: May involve reinventing some of the WSRF machinery for resource 
properties for Type (2) resources.

Mapping Approach 4:
Pros: Allows for natural selection.
Cons: Larger specifications and implementations; interoperability issues.

Please feel invited to comment on any or all of the above, either on the 
list or by participating in the calls scheduled to discuss this topic. I 
am assuming that, on the forthcoming call, we will start by discussing 
the Mapping Approach 3 that emerged from DAIS Session 2 at GGF13, but 
this message is, of course, broad enough to prompt rather wider discussion.

Regards, Norman