[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. OK. > [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. OK. > [..WSDM MOWS specification defines endpoints..] > It should say "defines manageability of endpoints". OK. Regards, William
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]