Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003

I also agree with Mark's concerns and with your approach to point 2.

Regarding your point 1, I am still concerned about bringing implementation details into the interface. If targetResource represents a particular service implementation, what happens if I rewrite the implementation from Java to C#? What if I rewrite the implementation to optimize it, but the semantics of the service remain the same? Do I get different targetResources? 

I think one of the basic advantages of Web services is that you can decouple the interface and associated semantics from the actual implementation(s).

The new wsdl:service definition associated with a single interface looked to me as being about right. It describes the fact that I can access the same service using different alternative bindings endpoints. Combined with a service group (your point 2) it should provide everything that was covered by the old wsdl:service definition. We could also improve on the old wsdl:service grouping by allowing a service to belong to more than one service group (supporting the case where the service is engaged in multiple types of relationships with other services instead of just one).

Ugo


----- Original Message -----
From: "Anne Thomas Manes" <anne@manes.net>
To: "Mark Baker" <distobj@acm.org>, <www-ws-desc@w3.org>
Date: Fri, 27 Jun 2003 09:30:24 -0400
Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003



+1.

Yes Mark. I am agreeing with you!  ;-) At least for the most part.

But perhaps I still don't really grok the reasoning behind targetResource
and/or single interface per service. (I realize that these are different
issues, but somehow I think they are tightly related -- and I'm still
uncomfortable with the design on the table.)

I see two issues:

1 -WSDL is all about defining interfaces and the bindings to interfaces, and
it does a really good job of hiding all implementation details behind the
interface. The interface provides access to a resource, which is a service
implementation. But currently we have no mechanism to identify this
resource. We provide endpoint URLs, but a service implementation resource
may expose multiple endpoints, and as Sanjiva said, we need a mechanism that
let's us determine whether multiple endpoints provide access to the same
service implementation. If this is the purpose of targetResource, then I'm
all for it. The service implementation is an "important" resource, therefore
it should have a URI. My issue with the discussion, though, is that people
seem to be suggesting that targetResource refers to the resource that the
service implementation acts upon (the printer rather than the print queuing
service). In this case I agree completely with Mark that this is an
implementation detail, and if we expose this information in the WSDL, we
will produce a maintenance nightmare. And -- if this is the case, we still
aren't naming the service implementation resource.

2- At the same time I can understand the desire to have a mechanism that
tells me that the print queuing service and the print management service are
somehow related, e.g., they both work with the same set of printers. My
proposal for this solution would be to include these two interfaces in a
single printing service group.

I'm beginning to think that we need to put in another layer of abstraction:
- Define a service implementation
   - it is a resource with identity
   - it supports an interface via one or more ports
- Define a service group
   - it consists of one or more related service implementations

Perhaps we should rename targetResource to serviceId or serviceURI?

Anne


----- Original Message -----
From: "Mark Baker" <distobj@acm.org>
To: <www-ws-desc@w3.org>
Sent: Friday, June 27, 2003 8:29 AM
Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003


>
> On Fri, Jun 27, 2003 at 06:06:11PM +0600, Sanjiva Weerawarana wrote:
> > This raises an interesting process question for me- as far as I
> > can tell there is no new information now from the time we made
> > the decisions that are currently spec'ed. So should we be
> > discussing it etc. etc.? Some people don't like it, but if we
> > don't have some process then its a waste of time going to the
> > F2Fs as those decisions are likely to be much more contentious
> > in the wider group as F2F has like 10-20 people and this list
> > has a lot. So if we re-open everything clearly its non-productive
> > to go to the F2F.
>
> Well, prior to my bringing it up, I hadn't heard it mentioned that
> targetResource introduces an implementation detail into an interface.
> I think DavidB's printer example showed the maintenance issue that
> arises because of that.  Some people even agree with me on that
> point (gasp! 8-).
>
> Not that I feel that targetResource needs to be removed though; I just
> think it needs to be constrained to identify something other than a
> runtime resource (i.e. the implementation detail), perhaps like a
> "serviceGroup" or something, which has no relationship to the resources
> manipulated, but instead just serves to tie together services via a
> common name.
>
> MB
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>