Subject: [OMod] Proposition for OMod identity
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 : xsd:anyURI - the targetNamespace of the binding implemented by the Service Access Point. bindingName : xsd:NCName - the local name of the binding implemented by the Service Access Point. address : 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.