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
- From: "Sedukhin, Igor S" <Igor.Sedukhin@ca.com>
- To: "VAMBENEPE,WILLIAM (HP-Cupertino,ex1)" <vbp@hp.com>,<wsdm@lists.oasis-open.org>
- Date: Sat, 15 Nov 2003 09:18:47 -0500
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
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
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
-
endpointIdentifier[1] :
xsd:anyURI {ro, const} - a URI of a WSDL component representing
(describing) the endpoint being managed
-
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.
-
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.
-
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.
-
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]