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] minutes of the extra call on Thu, Nov 13, 4-5 EST


Title: Message
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.
 
To cut it short,
1. I don't mind address being added to the identitfication property list. So it is 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.
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.
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).

-- 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: 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]