[DAIS-WG] Some comments about the WS-DAI and WS-DAIR

Thu Nov 23 06:00:34 CST 2006

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20061123/36900afe/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 8407 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dais-wg/attachments/20061123/36900afe/attachment.gif 