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

[Norman Paton]

Miguel,

Sorry about the slow reply.  Hopefully better late than never.

>     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


What you are saying here seems correct to me. In essence, the 
specifications define a collection of interfaces and don't mandate how 
these should be composed into services. The consequence is that there 
may be variety in the resulting services, and that service designers 
could make surprising decisions (e.g. to provide access to a resource 
without providing the facility to find out what is in the resource). We 
anticipated that services may sensibly be constructed from WS-DAI and 
other GGF specifications, and thus left other constraints on composition 
to later higher level data architecture documents or profiles.

<snip>

> 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?

Let me check that I've got the above.  Surely in the above, B must 
implement a Factory interface, from which the EPR of C can be obtained.

> 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?

The normal mode of operation for factory interfaces will probably for a 
single service to provide both the factory and the means of accessing 
the resource created by the factory. As such, in this setting, I'm not 
sure if your email is as a specification writer or a developer.  If as a 
developer, one might expect a service that implements (say) the WS-DAIR 
spec to support all the interfaces defined by that specification, rather 
than  spreading the interfaces over a collection of services, although 
this is allowed by the specifications. If as a specification writer, one 
might expect you to follow the approach taken in the other specifications. 

> 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...

Yes - this is clearly the down side of the permissive nature of 
composition. As such, applications should be written defensively, as the 
specifications don't provide guarantees as to which interfaces will be 
supported in any one service.

> 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

Of course, we had this debate, and in the nature of debates, there are 
alternatives. I guess that the three points in the spectrum that could 
have been adopted would be:

1. To specifiy that any WS-DAI compliant service MUST implement all the 
interfaces.
2. To specify a partial order on the interfaces (any WS-DAI service that 
implements X MUST implement Y).
3. To specify the interfaces but not how they are composed.

As you have identified, we went with (3). How does this seem with 
hindsight? I think it doesn't look silly, as one could imagine picking 
and choosing WS-DAI interfaces for use in different combinations in 
different settings.  However, it might also have been helpful to provide 
a statement of the form "A DIAS compliant WS-DAI(R|X) service MUST 
implement ..." in each of the specifications, thereby allowing the 
interfaces to be used independently but also providing some 
service-level compliance statement.

Hope this helps.

Regards, Norman