Dear all,
From time to time, when I'm working on the strawman RDF(S) ontology
realization, I have to
go back and forth to the WS-DAI specification and to the WS-DAIR
realisation specification,
which are by now much like the bible for the "WS-DAIx" designer :-D
And happens again and again that I really get confused when looking at
the sections of the
WS-DAI document regarding to the data service model, interface and
interface composition,
and how they are used in the WS-DAIR realisation.
The first point is that the data service model relies on the notion of
data access services
and data resources. At the same time the notion of data access interface
is tightly coupled
to the notion of interface. And the specifications are defined in terms
of interfaces.
The WS-DAI specification says (section 4.3):
/"This specification does not mandate how interfaces are composed into
data access services;
the proposed interfaces may be used in isolation or in conjunction with
others. Viable compositions
of interfaces will, initially, follow established patterns for data
access [...]"
/
The application of this "principle" is what makes me doubt...
The same document introduces the Core *interface* (section 5). This
interface defines some direct
data access messages. The strange thing is that they are grouped inside
of the interface using different
namespaces (CoreDataAccess and CoreResourceList), which somehow makes me
think of them as
"subinterfaces" :-S
If we have a look at the section 4.1 of the WS-DAIR document, which
contains the definition of the
relational interfaces defined in the WS-DAIR realisation, we see the
following interfaces:
* SQLAccessDescription
* SQLAccess
* SQLAccessFactory
* SQLResponseDescription
* SQLResponseAccess
* SQLResponseFactory
* SQLRowSetDescription
* SQLRowSetAccess
I would be very happy if they were described each one in its own
section, as they are specific interfaces
that can be composed into data access services as desired (see paragraph
above). But that's not the
structure of the document:
1. The interfaces defined are grouped (!?) according to the type of
resource that is the subject of the
messages defined in the interfaces: SQLAccessDescription,
SQLAccess and SQLAccessFactory
are grouped together as all of them are tightly coupled to
relational resources. Something similar
happens for the rest of the interfaces.
2. If we have a look at the WSDL/WSRF grounding of the interfaces
(which are the truly "definitive
interface description" according to section 7.1.1 of the WS-DAI
document) each interface is
defined as a porttype, but again, the porttypes are grouped in
WSDL files following the same
criteria.
My point is the following: it seems to me that the defined /interfaces/
are coupled somehow. They
are coupled to the type of resource they refer to, and therefore by the
related /Description/ interface.
I think that a /Factory /interface needs the /Description /interface as
much as and /Access/ interface does.
I don't know if I have misunderstood the definitions or the whole
specification, or if I've missed any
other document where this is explained. If so, please point me to the
right direction :-D
Having a look at the /Factory/ interfaces and the semantics of the
factory messages we have the
following. Each factory message deals with two types of resources:
* the source resource, it accesses to it in order to get the data
the client asks for.
* the target resource, it creates instances of this type resource
and intializes it with the appropriate data
So, if a /Factory/ interface has *n* messages, it will depend on at most
*n* types of (target) resources.
Therefore any data access service that implements the interface will
have to deal with these *n* resources
and what is more important, it will have to know at runtime which are
the services that implement the
specific access interfaces needed, as their EPRs will have to be
returned to the client...
This makes services depend on other services, well in fact it makes
services depend on certain *access*
interfaces. Let's see this with a sample scenario:
1. A client has the EPR of a service A which implements the
/SQLAccessFactory/ interface.
2. When the client sends a message /SQLAccessFactory::executeFactory
/to the service A, the
service will have to return the EPR of a service B which
implements the /SQLResponse/ interface.
3. Now, the client has the EPR of B, and just knows for sure that B
implements the /SQLResponse/ interface.
4. In case the client wants to explore the derived response with a
finer grain of detail, the client will have to
use the /SQLResponseFactory/ interface, in order to retrieve the
EPR or a service C which
implements the /SQLRowSet/ interface.
How can the client retrieve the EPR of the service C, provided the EPRs
of services A and B?
I have already discussed this with Norman (do you remember our
discussion in Tokyo? :-) And we
came up with the following: just look for a service which implements the
needed interface (using
any service registry available) and use it providing the resource
abstract name.
I think that this solution would work within the same implementation, as
it is the only one that can
ensure that the service found will now about the resource and have
enough privileges for accessing
to the resource. What do you think?
This last means that at the end, it will depend on the implementation
the client is using. Depending
on how the interfaces are composed into services, the client will have
to look for one or another
service, in order to use the appropriate interface. I think that this
might pose interoperability issues...
This takes me back to the original doubt: aren't the interfaces more
coupled than it appears
at first?
Anyhow it seems to me that life would be easier if the realisations
mandate about the interface
composition :-D
Buff. I now this is a more than big e-mail. Sorry about that. Please if
you think that misunderstood
anything or my reasoning is not correct, please point me were I missed
the "yellow path".
Cheers,
Miguel
PS: Has anybody else have that strange feeling of knowing that you are
wrong, but don't
know why? That what happens to me. You have worked a lot on the spec for
a long, long time,
so the problem might be on my side and how I interpret it, not in the
spec itself... :-D
--
/Miguel Esteban Gutiérrez/
*Ontology Engineering Group*
Departamento de Inteligencia Artificial
Facultad de Informática
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19
