OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


> 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?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]