RE: [wsdm] What are we managing: analysis and proposals

["VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>]

Hi Igor,

I copy/pasted out of your PDF so it is easier to discuss. The first two
proposals in your summary are as follow, where (1) represents what you
proposed at the F2F and (2) (mis-)represents what I proposed:

> 1. Use 80%/20% rule and manage endpoints as described by
> WSDL 1.1 port components. This is how WSs published
> with existing tools and platforms are and this is
> reinforced by changes in WSDL 2.0.
>
> 2. Cover a few more cases (e.g. 10% more) by managing
> AccessPoint/ProtocolStack/ServiceImplementation <aggregate>s.
> Define such thing, name it, and identify by address (URI) + WSDL
> binding component pair. Note that this does NOT cover 100% cases
> and therefore does not solve the problem.

I completely agree with this part of (1), your proposal: "endpoints as
described by WSDL 1.1 port components". WSDL 1.1 port components do indeed
describe endpoints. But they do not IDENTIFY endpoints. WSDL is a
description language. As I said in my original proposal, both WS-Arch and
WSDL consistently define an endpoint as the implementation of a binding at
an address. A WSDL port is a description of such an endpoint. Period. What's
not clear here?

What you are proposing is to add a constraint that an endpoint can only have
one description. Why? What is the benefit? Being able to construct the
resourceID by using XML properties of the port element? You can do this with
more than one description, just pick one of the ports and do the same. Your
ID wouldn't be guaranteed to be the same if built by two different people
anyway because there are different ways to build the ID with the XML
properties of a port element. And in any case we all agreed at the F2F that
it is bad practice to try to guess how to write the resourceID of someone
else. It is an opaque ID and they way you get it is by it being passed to
you through references.

Adding constraints to make things simpler make sense sometimes, but there
has to be a benefit otherwise why impose the constraints. I could say that
80% of portType have less than 6 operations but why would I make this a
constraint if there is no benefit? So my question is, what is the benefit or
restricting an endpoint to only one description? I asked this several times
at the F2F and never got an answer.

In your description of (2), you say it is "managing
AccessPoint/ProtocolStack/ServiceImplementation <aggregate>s". Then you
challenge us to
> Define such thing

The implementation of a binding at an address, as defined by WS-Arch

> name it

This is an endpoint but as I said earlier we could name it something else if
it help.

> and identify by address (URI) + WSDL binding component pair

Actually, identify by an opaque ID like any other resource and then provide
some description like the address and the binding. The opaque ID could of
course be constructed by using XML properties of a port that describes this
endpoint (the QName of the service and the local name of the port).

Regards,

William

-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] 
Sent: Saturday, December 06, 2003 12:41 PM
To: WSDM TC
Subject: [wsdm] What are we managing: analysis and proposals


<<What to manage for MOWS.pdf>> 
-- Igor Sedukhin .. (igor.sedukhin@ca.com) 
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788