GGF DAIS and WSRF - Resending in monospace font

[Susan Malaika <malaika@us.ibm.com>]

DAIS:
-----


                            DAIS Web      
Client ---------------->    Service Impl. ----> WS-Resource ----> Resource (Database)
   Request     SOAP Body: SQL query string                          
   Reply       SOAP Body: SQL result string      

In GGF (Global Grid Forum) DAIS (Data Access and Integration) group we are defining the WSDL that describes how a variety of database systems are accessed through Web Services. We have two basic scenarios for accessing databases (resources) through a query (currently XPath, SQL, XQuery) in a Web Service
     

• (1) Where there is exactly one database accessible through the DAIS Web Service
  • A service implementation needs no method to distinguish databases (singleton resource pattern)
• (2) Where there are multiple databases accessible through the DAIS Web Service and the service has to direct the request to a particular database
  • (2.1)  The service extends the service URL or uses some other protocol specific mechanism to identify the target database  
  • (2.2) The service uses reference properties to identify the target database

Questions:
----------
Here are some questions for the experts (I am just trying to learn):

• Q1. Is it consistent with the implied resource pattern (of which the singleton resource pattern is a special case)  to expose the names of resources such as databases as explicit  (optional?) parameters in the WSDL?
• Q2. Would you expect the structure of reference properties to be described in the DAIS specification?

--------------------------------------------------------------------------------------------


A Motivating Use Case:
----------------------
Here is an attempt at describing a motivating use case for the questions. There may be other motivating use cases.  

M1. Goals
---------

• To specify a single Web service interface (WSDL) for DAIS that supports both Web services and grid infrastructures, that can be used by grid-unaware clients with Web Service stubs

M2. An Approach
---------------

• 'Grid style names' are placed in SOAP headers
• 'Database style names' are placed in SOAP bodies

M3. Set Up  
----------                                                                                                                                 
                                                           [Resource Manager]                                                                                                                                                                   Client ------> Service Implementation----->   WS-Resource ------> Resource
              (Uses 'grid style names' for resources)      (Uses 'database style names' for resources)

• We have a collection of consenting service implementations (e.g., a grid infrastructure collection of services) that have architected a naming scheme for resources, (e.g., via addresses, handles, or abstract names, or whatever, with an agreed name resolver mechanism). I've called these kinds of names 'grid style names'
• The resource managers that manage the resources being accessed (e.g., database managers) have their own existing naming schemes. I've called these kinds of names 'database style names'.  Note these names appear in query strings such as SQL (therefore they will appear in the SOAP body)  

M4. Reasons for having resource names in SOAP headers and in SOAP bodies
------------------------------------------------------------------------

• SOAP header:  
  • Reference properties allow the 'grid style names' to be communicated in a way that is opaque to clients in general (they are just echoed by clients)  but that would be compatible across consenting services.
• SOAP body:
  • The explicit resource names in the SOAP body refer to the 'database style names', e.g., database name, table name, collection name.  
• Benefits:
  • The client application side software is not burdened with understanding the service implementation name resolver.
  • The service implementation is not compelled to parse SQL, XQuery etc strings to pick out resource names
  • Consenting service implementations within a single infrastructure could agree on their reference properties usage and formats and take advantage of the agreement
  • In other words in the DAIS documents, we specify:
    • that the contents of the SOAP header refer to 'grid style names'
      • (Depending on the answer to Q2 from the experts, we may not need to say anything about the reference property formats and SOAP headers in DAIS at all)
    • that the contents of the SOAP body refer to the 'database style names'

M5. A Supplementary Question - the 'blahblah' scenario
------------------------------------------------------
 It is possible that the SOAP body could include a "connect to database 'blahblah'"  whereas the SOAP header includes a reference to database 'blahblah'. i.e., the SOAP header  and body both refer to resources of type database. Because of separation of concerns, there would be no easy way of policing or preventing the 'blahblah' scenario. It may not matter, if the answer to Q2 above is 'no' as the DAIS specification would refer to SOAP body content only, and would be silent on SOAP header content. The specific service implementation decides how to use reference properties and that determines whether overlap is possible. Inconsistency is possible too, e.g., SOAP header could refer to database 'blah' and the SOAP body could refer to database 'blahblah' - but that can happen today with protocol specific mechanisms such as http parameters.

• Q3. Is this 'blahblah' scenario compatible with WSRF?

M6. Finally
-----------
I would like to thank the many people who took time out to discuss many of the points in this note with me at weird times of the day and night. I am just trying to help identify the best approach for DAIS. Please forgive me if none of this makes sense.  I do hope that on this mailing list the length of a question is inversely proportional to length and number of answers :-) Last time I posted a  one line question on this mailing list,  at least 20 messages were generated on the same topic.

Susan Malaika