[dais-wg] Example based on GGF13 summary
Simon Laws
simon_laws at uk.ibm.com
Fri Apr 8 16:06:20 CDT 2005
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/20050408/980f8172/attachment.html
More information about the dais-wg
mailing list