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] Proposition for OMod identity


Managing the "Service Access Point" could very well be a way to the consensus, however

1. The crisp definition is necessary. Service Access Point (AP) could not be equal to the WS-Arch definition of endpoint because endpoint is AN association and an AP could be represented as a SET OF associations.

2. Following the same argument that you are making about rewriting WSDL, address+binding is not an invariant against a given AP. One could write many bindings (and even interfaces) that would translate to the same message exchanges with one given AP. The only invariant would be address + messages + exchange patterns. See my other e-mail for more details on this proposal.

3. Why do you think that descriptionLocation[0..n] belongs to Identification? What does it identify exactly? It may help finding descriptions of AP, but it certainly does not identify AP in any way. Also this is a variant, and could change, therefore how could it belong to the Identification?

4. Same argument applies to ports[0..n]. It is totally not necessary for Identification of an AP. The reason is that it is never a closed list, and it changes. This list is only what the provider knows and it does not help and isn't useful at all. One could very easily use other identification properties to infer this one.

If we can address the above concerns and the TC feels it is worth going for such expense, I would not have any problem defining manageability capabilities of a Service Access Point. I would also suggest to rename the spec to Management of Services (strike out Web). I would actually very much like that to happen.

-- 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: Friday, December 05, 2003 5:42 PM
To: wsdm@lists.oasis-open.org
Subject: [wsdm] [OMod] Proposition for OMod identity


Following-up on the discussions at the F2F on Wednesday and on the action item assigned to me, here is a proposal for handling identity in OMod. I hope this email shows that the proposal is simple, perfectly aligned with the Web services architecture and most importantly pinpoints exactly what our customers need to be able to manage. Please let me know if any part of this is unclear or if additional explanations would be useful on any part.



The W3C WS-architecture glossary defines an endpoint as "an association between a binding and a network address, specified by a URI, that may be used to communicate with an instance of a service". At the other end of the spectrum, what users care about is managing a service that they deploy on a server and that will handle messages from consumers. Both views (WS-architecture view and customer view) point us to the fact that what we need to manage is entities that receive and emit a certain set of messages at a certain address. In WSDL terms, it is the implementation of a binding at an address. To avoid any confusion, let's avoid the overloaded term "endpoint" and call this thing a Service Access Point for now. This Service Access Point is the basic building block for WSDM MOWS.

This is how I propose to identify a "Service Access Point":
bindingTargetNamespace[1] : xsd:anyURI  - the targetNamespace of the binding implemented by the Service Access Point.
bindingName[1] : xsd:NCName - the local name of the binding implemented by the Service Access Point.
address[1] : xsd:anyURI - the address at which the Service Access Point accepts functional messages.
ports[0..n] : wsdm:portIdentity - a list of ports that describe the Service Access Point (wsdm:portIdentity is a complex type containing the service namespace, the service local name and the port local name).

descriptionLocation[0..n] : anyURI - a list of URLs pointing to documents describing the Service Access Point.
version[0..1] : xsd:string - an optional string representation of a version of the endpoint being managed. This could be used to query change management systems, presented to human users, etc.


- I didn't show any generic MUWS identifier or MOWS-specific identifier in this list as this is a different question and I'd rather not mix both discussions. I think the decision on this proposal needs to be made first and then, once we know exactly what it is that we are managing, we can come to conclusion on what identifier(s) are needed. In any case, this opaque identifier would be the real identifier, the properties listed above are just useful information to document the identity.

- This proposal doesn't in any way prevent two different Service Access Points to use the same binding and the same address. Concretely, if the provider has a reason to create two descriptions (two ports) with the same binding and address (for example with different policies) and if the provider is confident s/he can distinguish messages addressed to one or the other somehow then nothing stops the provider from having two different Service Access Points, one attached to each of the descriptions.

- Finally, I stayed away from the word "endpoint" in this proposal to prevent confusion but I think we would be perfectly justified to use it instead of "Service Access Point". What I am proposing to manage is exactly what the W3C WS-architecture glossary defines as an endpoint. The confusion I believe comes from the fact that WSDL 2.0 is planning to rename the WSDL
1.1 port component into "endpoint". But this doesn't change the meaning of "endpoint". For one thing the WSDL spec does not provide any semantic for this component. For another thing, the reason this component is called "endpoint" is because it DESCRIBES an endpoint. WSDL is the web services DESCRIPTION language, it deals with description not identity. A WSDL port (or endpoint) component does not identify and endpoint, it describes it. And there is nothing preventing more than one description for any entity, including an endpoint. Having more than one description (i.e. more than one WSDL port/endpoint component) doesn't mean there is necessarily more than one endpoint. But if this makes it more acceptable to people I am ok using another word than endpoint, like "Service Access Point" or something else.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.

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