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 Friday, 27 June 2003 09:31:14 UTC