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