[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