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

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

My proposal for point 1 is simply the assignment of a name (a URI -- let's
call it serviceURI) to a service implementation (a resource). As with any
resource, there's no reason why you can't change the code that implements
this resource.

In many respects, it is equivalent to assigning a URI to a Web site's home
page. There's nothing stopping you from changing the code behind the Web
page (in fact it happens all the time).

I proposal the serviceURI SHOULD NOT be the same as the endpoint URL of the
service implementation -- for exactly the reason that you may want to change
its implementation some time down the road.

And I think I agree that the new wsdl:service definition looks pretty close
to being right for the definition of a service implementation -- but I
suggest that the resource MUST have a serviceURI name. Given the naming of
the service implementation, I'm not sure we then need targetResource -- or
perhaps it could be added to the service group definition as a means to
identify the relationship among the services in the group.

By naming the service implementation, you also solve the use case where a
single service might implement multiple interfaces -- you would still
maintain the one service/one interface requirement, but you could define
multiple service implementations that reference the same serviceURI.

Anne

----- Original Message -----
From: Ugo Corda
To: www-ws-desc@w3.org
Sent: Friday, June 27, 2003 11:03 PM
Subject: 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
>

Received on Saturday, 28 June 2003 07:57:36 UTC