[dais-wg] Example based on GGF13 summary

[Norman Paton]

Prior to your message I did make several approaches to people I felt 
were relevant to the discussion, but who are not necessarily actively in 
the DAIS list to indicate that this discussion would be taking place.  
Please feel free to approach others or to forward messages to people you 
are confident would be interested, as we are open to receiving input and 
want to reach a conclusion soon. 

Norman

Dave Berry wrote:

> 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
>