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] [OMod] William's AI: endpoint -> service

Hi Igor,

Thanks for the review. See below for responses...

> -----Original Message-----
> From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com] 
> Sent: Wednesday, October 29, 2003 8:01 AM
> To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); wsdm@lists.oasis-open.org
> Subject: RE: [wsdm] [OMod] William's AI: endpoint -> service
> William,
> I think your text is just fine with the exception of the 
> following statement.
> [The presence of a collection mechanism will also allow a 
> manager to access  a set of endpoints (representing a 
> service) as one entity. Finally, the MOWS specification will 
> identify  in a non-normative way capabilities of a service 
> and how they can be derived from the capabilities of  the 
> endpoints that compose them.]
> I think it is too early to presume that we do collections and 
> non-normative spec of managing web services in addition to 
> endpoints before january 2004. May be we need to discuss this 
> with a larger group. I propose that we don't include those 
> statements so far and adopt the rest of your text now.

I think support for collections is important but I agree that this is a
separate question from how endpoints map to services and that this is to be
discussed by the overall group. How about rewording this as:

"One way a manager can be allowed to access a set of endpoints (representing
a service) as one entity would be through a collection mechanism".

This way we don't say in this text whether or not there will be a collection
mechanism, but this reminds us to be careful, when we define endpoints, to
not do anything that would make it impractical to group endpoints into
services when and if a collection mechanism is defined.

> Also a few minor corrections:
> [dereferencable URL] 
> I think URL is always "dereferencable", URN may not be. So 
> saying just URL is sufficient.


> [Nevertheless, the notion of endpoint is  relatively unambiguous.]
> I think it is just unambiguous per WSDL pec, isn't it? One 
> important point is missing here is that an endpoint is 
> uniquely idenifiable by a URI and that counts towards being 
> unabiguous.

Well, then the notion of service is just as unambiguous, per WSDL as well,
isn't it? How is an endpoint uniquely identified by a URI? I could have 2
endpoints listening at the same address. And in some cases (see the
conversation on unique wire signatures that took places in WS-I BP and is
now taking place in W3C WS-desc) there is no way to tell what endpoint a
message is intended for. If endpoints were really so unambiguous, this
wouldn't be the case, would it?

> [... such as UDDI, that do not use the same mechanism.]
> I think one important thing that is missing in that paragraph 
> is the following. I propose to add it.
> "For visibility and other concerns, many WSDL documents may 
> include descriptions of the same service with different 
> endpoints. In certain cases WSDL document may include a 
> description of a service with endpoints offered by different 
> providers." This applies to both WSDL 1.1 and WSDL 2.0 
> equally. I believe this to be very important.


> [..WSDM MOWS specification defines endpoints..]
> It should say "defines manageability of endpoints".




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