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

["Sedukhin, Igor S" <Igor.Sedukhin@ca.com>]

William,

[
In any case, the way to know if you have the same "thing"
is to compare the opaque unique resource ID provided by MUWS.
]

Let's not shift the dicussion. We need to come up with what properties there should be in the MOWS thing manageability capability. That itself has to be meaningful and sufficient to identify what MOWS thing is being managed in the subject domain of Web Services. MUWS can do similar thing to the MUWS thing.

[
What you are saying in that in many cases there will only be one description and some tools make this an assumption.
]

Some tools?? Can you give me an example of a development tool or a platform that does not make this assumption?

[
case #1 and #2 are really the same, they give you the same information
]

No they don't give the same information. We would not have this discussion if they did.

[
The difference is that the day you need to tweak your WSDL to use the endpoint as part of a BPEL process or to make it accessible by people using a different version of WSDL you won't be forced to create a new management representation
]

And I'm just not worried about this. The provider of manageability returns information about what IT THINKS it is managing and it says service->endpoint and points to WSDL(s) where to get the rest of the information from. If someone rewrites the WSDL, why is it the manageability provider's problem? It does not even know about it...

And second, why do you think that #2 will solve the "rewritting WSDL" problem? Is there anybody who can mandate only one way of rewritting the WSDL? Especially with WSDL 2.0 I would be very tempted to rewrite the binding as well, so #2 solution will just not help in any way.

[
> One description component! Yes, that is my intention and as far as I 
> can tell an intention of at least a few other in the WSDL WG. We have 

Once again, what is the benefit of adding this restriction?
]

To fix the problem with WSDLs/WSs, I guess... The "insustry" tries hard to fix what can be fixed. Should we help or should we resist?

WSDL 2.0 single interface per service is one such thing that was intended to fix what can be fixed the way "platform" vendors think it could.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

-----Original Message-----
From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com] 
Sent: Monday, December 08, 2003 7:01 PM
To: Sedukhin, Igor S; WSDM TC
Subject: RE: [wsdm] What are we managing: analysis and proposals


Hi Igor,

> 1. is managing the thing as IDENTIFIED by the endpoint description 
> component according to WSDL 2. is managing the thing as IDENTIFIED by 
> the address (URI) and the binding description component according to 
> WSDL 3. is managing the thing as IDENTIFIED by the address (URI), 
> messages (XML payload elements) and exchange patterns
> (sequences&directionality)
> 
> What did I misinterpret/misrepresented? :)

The description in your PDF doc was a little less neutral-sounding than this one. :-)

Also, your description of #2 implies that if you have the same binding and the same address you know that you have the same thing. This is not necessarily true. In any case, the way to know if you have the same "thing"
is to compare the opaque unique resource ID provided by MUWS.

> My subjective judjement is that #1 is at least good to cover 80% of 
> cases. Take an existing WS development tool or toolkit, deploy a WS on 
> an existing WS platform of your choice, take a look at the WSDL that 
> it generates and see if it is ever different than the case #1. That is 
> my first preference.

What you are saying in that in many cases there will only be one description and some tools make this an assumption. This is probably true, but it doesn't help us decide between #1 and #2 since in this case #1 and #2 are really the same, they give you the same information. If your tool assumes that there is only one description for each endpoint then #2 will list only one port and you can do everything the way you do it for #1. The difference is that the day you need to tweak your WSDL to use the endpoint as part of a BPEL process or to make it accessible by people using a different version of WSDL you won't be forced to create a new management representation...

> If we are to manage Service Access Points and to properly answer your 
> question [So my question is, what is the benefit or restricting an 
> endpoint to only one description?] then I say it must be #3. It is not 
> very complex, in fact the identification capability is quite simple.
> 
> > The implementation of a binding at an address, as defined by WS-Arch

Sure.

> According to http://www.w3.org/TR/ws-gloss/#endpoint there is nothing 
> about implementation as defined by WS-Arch. It is an association as 
> defined by a WS-Arch.
> 
> > What you are proposing is to add a constraint that an
> endpoint can only have one description.
> 
> One description component! Yes, that is my intention and as far as I 
> can tell an intention of at least a few other in the WSDL WG. We have 
> to fix it and reduce the number of variations that people can have 
> using WSDL. It affects everyone, WSDM TC is not the only one 
> struggling through this. When WSDL group started I remember a 
> discussion when all these variations were put on the board and then we 
> started to think how to make it better. It didn't get much better so 
> far because WSDL 1.1 created enough misuse already.

Once again, what is the benefit of adding this restriction?

Regards,

William