[OMod] Proposition for OMod identity

["VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>]

Hello,

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.

Regards,

William



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.
 

Notes:

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