[dais-wg] Example based on GGF13 summary - Version 2

Savas Parastatidis Savas.Parastatidis at newcastle.ac.uk
Sun Apr 17 07:21:25 CDT 2005


Dear Simon,

Many thanks for this. It's great.

Some comments...

<snip />

> 
> Service A - DAIS Conduit exposed as a ws resource (or as a non WSRF
web
> service - in this case there can be only one conduit per service end
> point)
>        <DAISProperties>
>                <AbstractName>DAISConduit1</AbstractName>
>                <DAISVersion>1.0</DAISVersion>

My guess would be that the DAISProperties message will be defined in a
particular namespace. So, when the DAIS version changes, that namespace
will also change. Unless a namespace for messages is kept fixed and used
to return which DAIS version is supported, such a 'property' may not be
necessary.

<snip />

> 
>        // Messages targeted at the DAIS conduit
>        XML GetResourcePropertyDocument ()
>                   // Get the entire resource properties document
> 
>        XML GetResourceProperty ( PropertyName )
>                 // Get a named property of the conduit
>                 // If a WSRF implementation is used the WSDL indicates
>                 // the static structure of the properties document
>                 // If a non WSRF implementation is used then there is
no
> specified
>                 // way of determining the structure of the properties
> document.
>                 // we would have to invent one.

It is not true that the structure of the properties document is not
shown in the non-WSRF case. I will post some examples from my
implementation that illustrate how this is possible.

>        DestroyResponse Destroy ( )
>                // Destroy DBMS conduit only
> 

If this is a deployed service providing access to a DBMS, what does it
mean to destroy it?

> 
> Messages required to add WSRF function to non WSRF services (we do
have to
> worry about these, but where?)
>        XML GetResourcePropertyDocument ( DataResourceName?)

This is very very simple to implement :-D

>        XML GetResourceProperty(  DataResourceName?, PropertyName )

This as well. We had an XPath-based implementation for querying a
properties document with less than 10 lines of code.

>        DestroyResponse Destroy (  DataResourceName? )
>        ...

No comment :-DD. It depends on what needs to be done. It could be a
single hashtable.Remove() method to an SQL query in a database.


> 
> 8 - Savas made some style comments about replacing the factory
messages by
> extending the messages that return results directly with
options/switches.
> I haven't included this here as keeping them separate lets me deal
with
> the factory aspects explicitly.
> 

After seeing the specs, I have more comments on this one. In case I
misunderstood, please forgive me. Your SQLExecuteFactory could return an
EPR or an abstract name pointing directly to the generated data
resource. There is no need to employ a data access factory. The
functionality of the two factories could be combined, hence saving two
messages.

> 9 - Savas also made some suggestions about how to handle requests
targeted
> at multiple resources. This comes down to the detailed structure of
the
> input and output messages. I haven't included this here as this adds
> another level to the debate.
> 

Agreed. This is not important at this stage.

> 10. Given an EPR that someone passed you how do you know whether to
pass
> the data resource name or not. To put it another way how do you know
> whether the WSRF or Non WSRF models are being followed? If you have a
name
> you know what you have to do. If you have and EPR you are not sure.
> 

I am afraid I haven't completely understood the issue here.

<snip />

> Artifacts/Resources of concern to DAIS (See Sues's summary note)
> ................................................................
> Type 1 - A DAIS defined conduit to data resources
> Type 2 - Data resources not managed by DAIS and hence not suitable for
> representation using WSRF
> Type 3 - Data resources managed by DAIS and hence suitable for
> representation using WSRF
> 
> The scenario
> ............
> DAIS (Type 1 resource) that acts as a conduit to data resources of
> interest
>         DBMS1 (Type 2 resource) already exists and contains
>              Database1 (Type 2 resource) already exists and contains
>                    Table1 (Type 2 resource)
> Rowset1 (Type 3 resource) will be created following a SQL query
against
> Database1
> 

This relates to my comment during the last teleconference. Why is a type
3 resource necessary here? Why is there a difference between how a Table
(type 2) is managed (delete, access, etc.) and a rowset (type 3)? They
are both manageable data resources. They can be modified, deleted,
accessed, etc. A table, for example, could be the result of an SQL
expression.

<snip />

> 
> Service Templates
> .................
> These demonstrate how a web service would appear at runtime.

How do you define 'runtime' here? Do you mean the subset of all
supported messages which can be accepted for a specific data resource?  

> 
> For further discussion
> ----------------------
> 1/ It is clear that Type 3 resources could be handled by the conduit
> in the same way as type 2 resources
>        We would have to implement lifetime management messages that
>        pass through the conduit
> 

Agreed!

<snip />

> 4/ With the inclusion of data resource properties in the DAIS conduit
> properties document we have a potentially large number of nested
levels.
> 

I don't think that this is necessarily true. There is no need to expose
a hierarchical properties structure. The requests to get the properties
of data resource 1 and 2 can be directed to the same service even though
there may be a containment relationship between the two resources.


<snip />

> 
> 6/ Given an EPR to the DAIS service a consumer of the service is
> unable to tell the difference between a web service which represent
> the DAIS conduit as a ws resource and a web service which does not use
> wsrf but only represents a single DAIS conduit
> 

Isn't it the case that with WSRF you can get the metadata for the
'pointed' resource? Couldn't you then dynamically discover its
capabilities?


Regards,
.savas.





More information about the dais-wg mailing list