[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrf] GGF DAIS and WSRF
Dear Susan, Since no one else has replied to your message, let's see whether my response will generate some discussion :-) > 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) > I think your definition of a singleton pattern here is slightly different from that given by Steve Graham in a previous post. According to Steve's definition it's not that a service does not need a method to distinguish between different resources. According to Steve, the singleton resource pattern suggested that there was no additional information necessary because that information was part of the service's address (e.g., URL). However, that means that the service will have to parse the address and extract resource-specific information from there. To my mind, this approach is protocol-specific and still maintains the same model of resource-orientation since resources continue to be the logical recipients of the messages. > * (2) Where there are multiple databases accessible through the > DAIS Web Service and the service has to direct the request to a particular > database > Agreed! Let me use an example of how this could be the general case (the same one I used in a private exchange with you and some others) A message of the form <xsd:element name="request-to-access-database"> <xsd:complexType> <xsd:sequence> <xsd:element name="database-name " type="xsd:string" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> </xsd:element> Can capture all possibilities and is more general than what is achievable with WS-RF today. Here are some examples of messages according to the above schema... <soap:Body> <request-to-access-database /> </soap:Body> (what I think you see as the singleton resource pattern) <soap:Body> <request-to-access-database> <database-name>databaseA</database-name> </request-to-access-database> </soap:Body> (the equivalent of what WS-RF achieves today) <soap:Body> <request-to-access-database> <database-name>databaseA</database-name> <database-name>databaseB</database-name> ... <database-name>databaseN</database-name> </request-to-access-database> </soap:Body> (what WS-RF cannot model today without introducing the concept of resource-collections but which is a natural message to the WS folks) > * (2.1) The service extends the service URL or uses some other > protocol specific mechanism to identify the target database I think this is the "singleton resource pattern" according to Steve Graham (I may have misunderstood). However, as you rightly identify, this approach has the disadvantage of being protocol specific. > * (2.2) The service uses reference properties to identify the > target database > The WS-RF approach and you already know my feelings about that :-) > > Questions: > ---------------- > Here are some questions for the experts (I am just trying to learn): > Trying to answer to these is by no means a suggestion that I am an expert. I am just someone who's trying to understand and start interesting discussions. > * 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? I don't see why using names for databases (preferably logical names) in the SOAP body is a bad thing. We do it all the time... Order identifiers, credit card numbers, travel booking references, etc. > * Q2. Would you expect the structure of reference properties to be > described in the DAIS specification? > If the DAIS specification was to use WS-RF (which I assume it will), then I believe that it shouldn't describe the structure of the reference properties since those are usually implementation-specific. > > ------------------------------------------------------------------------ -- > ------------------------------------------------------------------------ -- > ----------------------------------- > > 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 How do you define a "grid infrastructure"? Is a Grid infrastructure one that uses WS-RF? If interoperability is what we want for the Grid, my suggestion would be to use plain, vanilla Web Services without any dependence on WS-RF until the point WS-RF becomes a widely accepted standard, adopted by all major WS vendors, with commercial tooling available. But that's just me :-) > > 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) > Why couldn't the abstract names appear in the SOAP bodies? > > 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 However, you are restricting the service consumers on how they reason about the architecture. Their messages have to be targeted to specific resources (one at a time) despite the fact that they don't have to deal with their names explicitly. > * Consenting service implementations within a > single infrastructure could agree on their reference properties usage and > formats and take advantage of the agreement According to the WS-Addressing specification the contents of the reference properties should be opaque to consumers even if there is a common agreement about their structure. > > * 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) > My assumption is that the latter should be true. > * that the contents of the SOAP body > refer to the 'database style names' > I personally prefer this option or abstract names in the body. > > 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? > I believe the two are compatible since it's the implementation's responsibility to reason about the contents of both the headers and the contents. However, I believe that the two should not be mixed. Please treat these as my opinions. Again, I am not an expert in WSRF so others may disagree with my comments (actually, I am expecting that others will probably disagree :-)) Best regards, .savas.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]