[dais-wg] Round the loop again

[Simon Laws]

Apologies that this is so last minute. Here are some notes produced 
following our last call that I sent out but neglected to copy the list (as 
has just been pointed out to me).  I have received some comments on these 
but haven't caught up on these yet. Hopefully we can do this on the call 
today.


The scope of the WSDL Savas has produced is as follows ( I've summarised 
the input and output message XML based on Savas' WSDL)

Service
    DaisCorePortType
        <lPropertiesResponse>
                       <Readable> ...
                </PropertiesResponse> Properties ( <Properties/> )

                <EndPointReference/> Resolve 
(<Resolve><name>string</name></Resolve> )

                <DeleteResponse/> Delete ( 
<Delete><name>string</name></String> )
 
    DaisRelationalPortType
        <RelationalPropertiesResponse>
                       <RelationalSchema> ...
                </RelationalPropertiesResponse>    RelationalProperties ( 
<RelationalProperties/> )

                <ExecuteSqlResponse/> ExecuteSql  ( <ExecuteSql>
                            <sql>string</sql>
                    </ExecuteSql> )

                <ExecuteSqlResultByRefResponse> 
 <sqlExecuteAndStoreResultResult>string</sqlExecuteAndStoreResultResult>
                </ExecuteSqlResultByRefResponse>      
ExecuteSqlResultByRef ( <ExecuteSqlResultByRef> 
      <sql>string</sql>
      <AccessInterface>Rowset|XML</AccessInterface>
  </ExecuteSql> )

                 <WebRowsetRowCountResponse>
 <DataResourceCountResult>int</DataResourceCountResult>
                 </WebRowsetRowCountResponse>       WebRowsetRowCount ( 
<WebRowsetRowCount><name>string</name></WebRowsetRowCount> )

The things we covered during our mapping discussion tuesday were:

1/ We don't need to build every message in DAIS to demonstrate the mapping
2/ Optional resource names should appear in the messages of our 
realisations
3/ Input resource names could be URIs
4/ The result of messages that imply the factory pattern are more 
problematic
        A - a URI which relies on the resolve message to retrieve the 
endpoint
        B - a complex type so mulitple names and end points can be 
returned
5/ Properties
6/ Lifetime
7/ We should use common terminology between WSRF / non WSRF where we can
8/ Service level messages (as opposed to messages targetted ar resources)

Have I missed anything?

These issues affect Savas' WSDL in the following way

2/ Resource names
<ExecuteSql>
    <sql>string</sql>
</ExecuteSql>

should become

<ExecuteSql>
     <ResourceName>string</ResourceName> (Where this is an optional 
element.  Also see point 3 and point 4)
    <sql>string</sql>
</ExecuteSql>

3/  Format of input names. 
The names we are talking about here are the abstract names that uniquely 
identify a data resource,. You can get to an abstract name from a human 
readable name via something like RNS.  The big question is (and this is 
the question that WSRF side stepped) what type should the name be. 

My feeling is that we should not commit to any particular scheme. In order 
to do this we need to decide how, in a running service, we indicate what 
name type is expected and what is provided. Some approaches
- Assume a single name scheme
                Problematic if the scheme chosen is not the scheme that 
people find useful in all occasions. 
-  A string representation. 
                 Alows for the likes of URI, LSID, Handle.net, JDBC URLs 
and string encodings of XML. Could required name type be indicated using 
the 
                namespace of  the message element containing the name 
(would need to think about this in more detail)? Could rely on exceptions 
if name is not 
                understood. There is the danger that a name is 
missinterpreted.
-  An XML type
                 A complext type could be created to hold each name type. 
Could use specialisation to abstractly define the message. Valid name 
types would 
                 have to be advertised or would have to rely on exceptions 
to indicate incorrect types. 
-  An XML wrapper 
                 Build an XML structure that wraps names generally 
providing an element describing the name type and an element holding the 
name itself. Again
                 would have to advertise valid types or rely on 
exceptions. 

I think we should investigate if we can simply associate a namespace with 
a string based name and use this as a simple wrapper. We could fall back 
on URI as the default representation. 

4/ Response for messages that imply the factory pattern. 

The neat solution is to take Savas' approach to just return a name. But my 
concern is still that two pieces of information are potentially required, 
the name and the endpoint(s) that that name can be accessed through. Of 
these two the endpoint is mandatory and, in theory by taking the WSRF 
approach, the name is optional. We could make the abstract naming of data 
resouces mandatory of course. I don't think we add any extra complication 
by constructing a type which allows both the endpoint information and the 
name to be returned. If we were to rely on "resolve" we would still need a 
type that could handle plain URLs or EPRs

5/ Properties

Properties are defined as XML types and a collection of properties can be 
constructed by aggregating complex types. For compatibility it would be 
handy to use the WS-ResourceProperties approach to forming this 
aggregation. We can then use the resulting type in numerous places as 
required. 

- In a realisation specific message such as GetRelationalPropeties ( 
ResourceName ) 
- In a generic message such as GetResourceProperties ( PropertyName )
- In a resource speific generic message such as GetResourceProperties ( 
ResourceName, propertyName )

Question: Do we provide entended version of the WS-ResourceProperties 
messages?
                    Do we provide realisation specific properties 
messages?

6/ Lifetime

As a first pass we can take the WS-ResourceLifetime messages and extend 
them with ResourceName elements.

8/  Service level messages

In the WSRF case we invent the idea of the DAIS conduit as the target of 
the WSRF message set. The DAIS conduit is simply the construct which 
contains the data resources that the service knows about. Thus 
GetResourceProperties() returns properties such as a list of data 
resources the service knows about. Exactly the same is true on the non 
WSRF case except that we make the assumption that there is only a single 
DAIS conduit. I.e. any messages sent to the non WSRF DAIS service are 
intended to be interpreted at the service level. Hence Destroy() could 
mean remove all references to services or it could be destroy all the data 
resource depending on the stated (In the help pages!) semantics of the 
service)


So in summary we should try and devise a simple set of rules to help us as 
we rebuild the specs

The abstract names of data resource will always be described in 
specification in term of the structure (types to be defined)
Messages to resources will always include the abstract name of the resouce 
in question
Message to the service will, fairly obvously, omit a resource name
Messages which cause a new data resource to be created will return both 
the name of the resource and endpoint information where that name is valid 
(type to be defined)
Properties will be defined in structures that can either be returned by 
realisation specific messages or by the generic WSRF resource messages.
Etc, Etc, 


Simon Laws
IBM Hursley - Emerging Technology Services

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050426/d15a84c8/attachment.htm