[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