[dais-wg] Example based on GGF13 summary
Dave Berry
daveb at nesc.ac.uk
Tue Apr 12 05:22:37 CDT 2005
Just a thought - would it be a good idea to CC some of the OGSA WSRF
people on this discussion?
Dave.
_____
From: owner-dais-wg at ggf.org [mailto:owner-dais-wg at ggf.org] On
Behalf Of Simon Laws
Sent: 08 April 2005 22:06
To: dais-wg at gridforum.org
Subject: [dais-wg] Example based on GGF13 summary
The following is a brief example I constructed to help me
understand the notes that I have read summarising the DAIS 2 session at
GGF13. May be useful for discussion and I may of course have
misunderstood.
The GGF13 DAIS2 meeting discussed two categories of data
resource. Those, such as DBMS and Databases within them, that exist
irrespective of the web services infrastructure that we are interested
in and those that can be managed by the web services infrastructure,
such as result sets.
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
The web services
................
Web Service A - DAIS Service which presents a conduit for
accessing the existing DBMS and its databases e.g. DBMS1 and Database1
(we currently consider the DBMS functions, e.g. creating and dropping
databases, out of scope of DAIS so will concentrate on database access
here)
Web Service B - DAIS Rowset Service which exposes a dynamically
created rowset data resource
Service Templates
.................
These demonstrate how a web service would appear at runtime.
This is not intended to demonstrate how the DAIS specification would
group messages into port types. DAIS currently doesn't mandate how its
specified port types should be combined into services but its hard to
envisage the model here without making some suggestions. So what I have
done for Service A and Serivce B is list some indicative proerpties and
a selection of messages that each service might support. These service
interfaces are not intended to be complete.
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>
<Capabilities>capability info over and above
WSDL</Capabilities>
<DataResource>
<DataResourceName>Database1</DataResourceName>
// CIM properties go here
</DataResource>
</DAISProperties>
// 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.
DestroyResponse Destroy ( )
// Destroy DBMS conduit only
// Messages targeted at a data resource within the
conduit
XML GetResourceProperty( DataResourceName?, PropetyName
)
// not sure this is required as the message
targeted
// at the conduit could be used to navigate down
to
// properties of the data resource. However
there may be a
// a requirement for messages that retrieve
specific properties
// of a data resource.
Data SQLExecute ( DataResourceName?, SQLExpression )
// as with DAIS currently, the result is returned
synchronously
EPR SQLExecuteFactory ( DataResourceName?,
SQLExpression, RequiredInterface )
// assumes that the result is always managed by
DAIS
GenericResponse GenericOperation ( DataResourceName?,
GenericRequest )
// a mechanism for passing generic document based
requests to
// the conduit
Service B - Rowset1 exposed as a database resource
<RowsetProperties>
<AbstractName>Rowset1</AbstractName>
<Schema>...</Schema>
<NumberOfRows>
etc.
</RowsetProperties>
// Messages targeted at the rowset
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML getResourceProperty( PropertyName )
// Get a property of the rowset
DestroyResponse Destroy ( )
// Destroy the rowset data resource
GetTuplesResponse getTuples ( GetTuplesRequest )
Using the services
...................
Here Ref[DAISConduit1] means a reference to DAISConduit1.
A reference could be represented in several ways, for example,
an erp containing discrimination
information required to identify a ws resource, an epr with just
the endpoint
of a web service (in the case where there is only one conduit at
that endopoint) or just the URL of
web service endpoint (again in this case there can only be one
conduit at that endpoint)
1/ Initiation
The administrator of the web service server deploys Service A
configuring it with the appropriate conduits which in turn
reference
existing data resources
2/ Getting properties of the DBMS and Database
PropertiesDoc = Ref[DAISConduit1]->GetResourceProperties
("DAISVersion")
3/ Getting data directly
Data = Ref[DAISConduit1]->SQLExecute ( "Database1",
<SQLExpression>SELECT * FROM Table1</SQLExpression> )
4/ Getting data indirectly
EPR[Rowset1] = Ref[DAISConduit1]->SQLExecuteFactory(
"Database1", <SQLExpression>SELECT * FROM Table1</SQLExpression>,
dais:PortTypeForServiceB )
Data = EPR[Rowset1]->GetTuples( 2 )
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
2/ How to express interfaces/capabilities of the conduit. What
more information
is required over and above WSDL?
We haven't considered the conduit to date so we haven't
defined
capabilities at this level necessarily. Do the
properties we have defined
such a Readable, Writeable, ConcurrentAccess etc. work
at this level
3/ Do we provide facilities for the consumer to choose where a
result
set is a type 2 or type 3 resources
We have discussed dependent/independent resources before.
It
would seem sensible at this stage to take the simple
approach and
assume that all dynamically generated data resources are
independent
4/ With the inclusion of data resource properties in the DAIS
conduit
properties document we have a potentially large number of nested
levels.
5/ The WSRF resource properties can be used to retrieve
properties
from the DAIS conduit concerning the conduit itself or
concerning the
data resources it contains. There will be other properties of
the
data resources that are not contained in the properties
document. Data
resource specific messages will be used for retrieving these
properties.
I included XML GetResourceProperty( DataResourceName?,
PropetyName )
but its not clear that this general message is
appropriate
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
7/ Should we specify messages for managing the conduit?
Simon Laws
IBM Hursley - Emerging Technology Services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050412/3c0d1d69/attachment.htm
More information about the dais-wg
mailing list