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: [OMod] Endpoint identity (Was: RE: [wsdm] [Omod] minutes of the extra call on Thu, Nov 13, 4-5 EST)


Title: Message
William,
 
What you are saying is that there is no way to tell two endpoints from each other unless we look at what messages go to and from which adddress. I don't agree that one needs to aggregate such information to obtain the identity. That is the purpose of identity not to have to look at the entity itself.
 
For example, if you have
 
package abc.def;
class A : implements B { void foo(int b); }
 
The identity of the class should be abc.def.A, and what you are saying is that it also has to include method signatures, interface definitions, etc. to become a good enough identity, and that is where we disconnect.
 
Also you are proposing that if MUWS defines a property e.g. myResourceIdentity: URI it will be good enough to tell people to support MUWS and explain that it is actually a URI identifying an endpoint and that they always have to remember that when delaing with manageable endpoints. In other words if the user of the manageable information writes an expression like manageableResource.myResourceIdentity == "something" they have to remember if the manageableResource is an endpoint or not and what that property actually means. I would much ratrher prefer them to write manageableResource.endpointIdentity == "something" if that is what is meant.
 

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788

 


From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com]
Sent: Saturday, November 15, 2003 3:09 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: [OMod] Endpoint identity (Was: RE: [wsdm] [Omod] minutes of the extra call on Thu, Nov 13, 4-5 EST)

Hi Igor,
 
Please see comments inlined in red.
 
-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Saturday, November 15, 2003 6:19 AM
To: VAMBENEPE,WILLIAM (HP-Cupertino,ex1); wsdm@lists.oasis-open.org
Subject: RE: [wsdm] [Omod] minutes of the extra call on Thu, Nov 13, 4-5 EST

William,
 
First of all to make sure we don't slide into 'what is a web service' discussion once again, let us not mix identity with equivalence. I'd like to tie identity to WSDL *components* (not elements!) because that is the only practical reference that lets us do the job instead of discussing abstract matters. The example that you have given is an example of equivalence, not the same identities.
 
While it would be nice if we could equate endpoint with port component (and get identity for free), what I am trying to explain is that it just does not do it. I am trying to be very concrete here, not "discussing abstract matters". As a down-to earth IT manager, the concrete thing I care about is my stockquote endpoint at URL http://william.com/stockquote. This is as concrete as it gets in software. And this is the endpoint I care about, not the different WSDLs that represent it. My container might generate a WSDL for this endpoint that uses a certain port name and the development tool I used might generate another WSDL for it, with a different port name. Those would be two different WSDL components. And yet I only see one endpoint and this is what I want to manage.
 
I understand what you are saying about the difference between identity and equivalence. True, one possible approach would be to ignore the fact that there is no 1-1 correspondance between a port and an endpoint and, for the sake of identity, pick one port and make this port the identity of the endpoint. And then we find ourselves with a mess on our hands to handle the other ports that represent the same endpoint, or endpoints that don't have a port representing them (one example: a notification system in which the binding of the callback endpoint is well-known and one only provides the address of the endpoint at registration time). At this point we could engineer a complex equivalence system to express the fact that these ports relate to the same endpoint. What I am trying to do is prevent us from getting into this mess by really considering what an ednpoint is before we express its identity. The closest we can be from the concrete endpoint in our representation of its identity, the less we'll have to worry about mechanism to express equivalence left and right.
 
To cut it short,
1. I don't mind address being added to the identitfication property list. So it is ok. 
 
OK
 
2. I don't believe that MUWS generic resource identifier has to be the same as (or replace) an endpointIdentifier. I believe that if I wanted to support EndpointIdentification capability I must be able to do so without necessarily being in the realm of MUWS immediately. endpointIdentifier pertains to endpoint and bears the semantic load this way. I do not want to interpret generic ID as being an endpointIdentifier and explaining it to implementors. That is a bad practice. Both could be present. 
 
Then you are just repeating what is in the other fields, as Bryan said. I agree that in addition to the generique ID provided by MUWS we need to have more identity information specific to an endpoint. But I don't see the need of duplicating it.
 
3. I strongly object to having a list of WSDL locations in the Indentification because (1) it is NOT constant and (2) it has nothing to do with identification. It may be heplful, but it is not identification of any sorts. I can have WSDL at a URL generated by the container, WSDL doc in my UDDI, same WSDL doc on a public website, etc. I can split my WSDL according to visibility concerns and the same endpoint will appear in docs that look very different and may not even be located at a URL. 
 
Exactly! You are right on target when you say "I can split my WSDL according to visibility concerns and the same endpoint will appear in docs that look very different". This is exactly why we can't use one WSDL component as the basis to identify an endpoint. Because there can be many such components for the same endpoint. What you describe here is one example, the piece of WSDL I put in my previous message is another. Both point to the fact that an endpoint it defined by a set of accepted messages and an address, not a WSDL port.
 
With regards to where to put the link to description documents, I am ok with this not being linked to identity (even though I believe a lot of the identity properties are not very useful if you can't get hold of a WSDL doc). As long as it is available somewhere.
 
4. Binding itself has really nothing to do with the identification of an endpoint. It may be helpful, but definitely NOT part of identification. If we go this route, why don't we just simply include the whole WSDL right there (or repeat it all in our Identification model property by property). The thing that could really be an identifier in that case would be a set of GEDs for in/out, but then you get to MEPs and it becomes so complicated that we will never climb back to the surface. Let's stick to something solid like WSDL component model and its way of identifying the component that we're interested in managing (an endpoint). 
 
If you agree that an endpoint is defined by the set of messages it accepts (and by what they look like on the wire) than this is exactly what a binding represents. A lit of GEDs for in/out would not be sufficient because it would be missing on-the-wire information that could differentiate between two endpoints.
 
Here is a proposal for a compromise:
 
Assuming MUWS provides us with a uniqueID property that is of type anyURI and that, as far as MUWS go, is opaque, let's define in MOWs how this URI should be built. Assuming there is at least one WSDL port component that represents this endpoint, let's design a way to build the URI so that it unikely identifies that port. This should satisfy your requirement of being able to represent an endpoint by a port and it won't prevent the MUWS people from still treating it as an opaque URI if they don't understand how it is built. Then, the other properties needed for identification of the endpoint are its address, the binding QName (or its namespace and local name as two properties, I don't really care), a list of service QNames, and an optional version property. The list of description documents can be left for something other than identity if this is a real concern for you.
 
How does this sound?
 
William
 
 

From: VAMBENEPE,WILLIAM (HP-Cupertino,ex1) [mailto:vbp@hp.com]
Sent: Friday, November 14, 2003 10:10 PM
To: Sedukhin, Igor S; wsdm@lists.oasis-open.org
Subject: RE: [wsdm] [Omod] minutes of the extra call on Thu, Nov 13, 4-5 EST

Hi all,
 
Sorry I couldn't make it for the extra conf call on Thursday, I was at a WS-I meeting. Thanks for sending minutes. I would like to comment on them. I am concerned by how the "identification" properties completely tie our view of endpoints to an actual WSDL port element. It seems to me, the real definition of an endpoint is something that accepts a certain set of messages at an address. In WSDL terms, it is the combination of a binding and an address. This is what an endpoint really is.
 
Now it is true that this is what a port element also happens to describe (linking a binding with an address) and sometimes there will be a 1 to 1 relationship between an endpoint and a port. But not always. And it can't ever be guaranteed. Look at the following WSDL elements, all defined in the same targetNamespace:
 
<service name="partialService">
  <port name="buyPort binding="myns:buyBinding" address="http://myco.com/buy"/>
</service>
 
<service name="completeService">
  <port name="buyPort binding="myns:buyBinding" address="http://myco.com/buy"/>
  <port name="sellPort binding="myns:sellBinding" address="http://myco.com/sell"/>
</service>

The two ports called "buyPort" have the same portType, binding, namespace and address. They describe the same messages sent at the same address. The only difference is the name of the service that contains them. The same endpoint will process the message independently of whether the client used one port or the other. In fact in the general case there is no way on the receiving end to tell which port was used and in this case this is not a problem because it is the same endpoint. So we should take this into account when defining the identity properties of an endpoint.
 
Another comment I have is that we should be leveraging whatever MUWS comes up with in order to provide a uniqueID for each resource and this should replace endpointIdentifier. This should be an opaque ID defined by MUWS. I don't have a problem making its type anyURI. But as long as you don't define precise rules about how this URI should be built it is nothing more than an opaque ID. As long as this is clear I am OK leaving this in as a placeholder until we have a MUWS uniqueID property to replace it with.
 
Finally I think we also need to provide the URL(s) of descriptions for the endpoint.
 
As a result, here is the modified set of identity properties that I propose:
 
 
endpointIdentifier[1] : xsd:anyURI {ro, const} - an opaque URI identifying the endpoint (to be replaced by the MUWS resource identifier when MUWS provides it).
 
bindingTargetNamespace[1] : xsd:anyURI {ro, const} - the targetNamespace of the binding implemented by the endpoint.
 
bindingName[1] : xsd:NCName {ro, const} - a name of the WSDL component representing the acceptable wire formats of the messages received by the endpoint.
 
Address[1] : xsd:anyURI {ro, const} - the address at which the endpoint accepts functional messages.
 
serviceName[0..n] : xsd:QName {ro, const} - a list of names of the WSDL component representing the services which the endpoint belongs to.
 
endpointVersion[0..1] : xsd:string {ro, const} - 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.
 
DescriptionLocation[0..n] : anyURI {ro, const} - a list of URLs pointing to documents describing the endpoint.
 
Regards,
 
William
 
 
 
-----Original Message-----
From: Sedukhin, Igor S [mailto:Igor.Sedukhin@ca.com]
Sent: Thursday, November 13, 2003 2:25 PM
To: wsdm@lists.oasis-open.org
Subject: RE: [wsdm] [Omod] minutes of the extra call on Thu, Nov 13, 4-5 EST

AGENDA
1. Roll.  
BryanM, Alexando, Fred
 
ISSUE 9: UML models: need to reconcile WS-Manageability and WSMF expressed similarily
Have to start the model and throw in the props/ops/events/metadata per each manageability 'category'.
http://lists.oasis-open.org/archives/wsdm/200310/msg00067.html

Bryan's input: http://lists.oasis-open.org/archives/wsdm/200311/msg00028.html  

We will be discussing every category (subsections of section 3 in MOWS spec), fill out the prop/op/evt list and represent it in a UML with accompanying text.

The first is Identification.

Discussed whether to group properties in data types e.g. EndpointIdentification or just list them as part of the capability model itself. Decided to list them in the capability model as this is merely definition of the sematics for now and it may be properly rendered into XML Schema at the later time.

After a very lengthy discussion we came to the following set of Idenitification properties

  1. endpointIdentifier[1] : xsd:anyURI {ro, const} - a URI of a WSDL component representing (describing) the endpoint being managed
  2. endpointName[1] : xsd:NCName {ro, const} - a name of the WSDL component representing the endpoint being managed. This name is unique among endpoints in the realm of the serviceName + targetNamespace.
  3. serviceName[1] : xsd:NCName {ro, const} - a name of the WSDL component representing the service which endpoint belongs to. This name is unique among services in the reals of the targetNamespace.
  4. targetNamespace[1] : xsd:anyURI {ro, const} - a namespace in which WSDL components such as an endpoint and the service are defined. According to WSDL both service and its endpoints must be defined in the same targetNamespace.
  5. endpointVersion[0..1] : xsd:string {ro, const} - 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.

BryanM had a concern that endpointIdentifier URI is a mix of other properties and therefore the information is duplicated.

Igor: there are use cases when this information could be used in queries and conditions (e.g. XPath in BPEL). Also there is no one mandatory way how to represent the enpointIndetifier URI. W3C TAG listed more than 10 possible choices. In general it is a bad practice to assume URI schema and try to parse infrormation from there. The best so far was to represent information in XML and use it that way.

Bryan/Fred/Igor discussed it and so far we seem to be good with the above set of properties. We agreed to carry on with it onto discussing other categories.

THE IDENTIFICATION IS CLOSED, for those who did not attend this call :)

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788



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