W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

AI: why Service QName is required if client has WSDL + engaged in conversation?

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 08 Nov 2004 11:53:23 -0800
Message-ID: <418FCEB3.5040209@oracle.com>
To: public-ws-addressing@w3.org


I took an action to send out the rationale as to why service 
qname/portType is needed in an EPR if the client and the 
service/endpoint/service instance have access to the WSDL and are 
already communicating with each other within a context.

IOW, if the communicating parties already know all the information that 
is available in the WSDL, why is it necessary to include the service 
qname/portType in the EPR that is sent by the service to the 

Here is why I think it is necessary to have the service Qname and 
portType information in an EPR:

To deference an EPR and to communicate with a service, it is necessary 
to know the message format, schema, bindings, features, properties etc 
of that service. service Qname/portType references in an EPR provide the 
ability to get to that information. This is not to say that every 
consumer of the EPR will deference the serviceQname/portType information 
available in an EPR. For example, a client that expects an EPR to a 
particular portType may just verify that the portType that is expected 
and the wsa:PortType in the EPR are the same. Please note that this is 
not the same as including the WSDL document or WSDL components in the 
EPR, the serviceQname/portType are just QName references.

I agree that if the communicating parties have a context and know 
everything about each other then perhaps it is possible in certain 
scenarios that the only thing that is needed is the URI (the 
wsa:Address). But this makes EPR tightly coupled, and they cannot be 
passed around outside the context. This is quite bad for 
interoperability. If the client and the service are already in a 
conversation and have a context then they don't even need an EPR, they 
can just pass around the URI or just the refps. We are defining an EPR 
to allow for good tooling and interoperability. Are we going to allow 
someone to send a relative URI in wsa:Address? I would suspect that many 
are going to say -- no wsa:Address should be an absolute URI. If the 
above argument of context/conversation holds then it seems logical to 
think of relative URIs instead of absolute URIs. To make the case even 
more extreme -- if the client and the service have a context and are 
engaged in a conversation should the service be allowed to send an EPR --


Where, somehow the client knows to map "42" to 

Such usage does not promote interoperability. EPRs should be robust. In 
the cases where, because of the context, the consumer of the EPR does 
not need information, such as service qname/portType, the consumer can 
just ignore it (or verify that the serviceQname/portType matches what is 

Another advantage of making the service Qname/portType required (without 
making wsa:Address logical) is that it allows one to provide the ability 
to specify multiple ways to get to the same service. This is because a 
service Qname refers to a service element that can have multiple ports. 
The minter of the EPR then would be essentially saying -- here are the 
multiple ports (associated with possible multiple 
bindings/protocols/message formats), choose the one that makes sense to 
you. This is quite useful in asynchronous communication where the 
consumer of the EPR may have different capabilities at different times. 
For example, the consumer may or may not be behind a firewall, may or 
may not be on a cellphone/mobile device at different times. This is also 
very much in line with the WSDL 2.0 spec [1] which says in section 2.13.1:

"A Service component describes a set of endpoints (see 2.14 Endpoint) at 
which a particular deployed implementation of the service is provided. 
The endpoints thus are in effect alternate places at which the service 
is provided."

I think, for interoperability, robustness, and to easily provide the 
ability to specify multiple ways to get to the same thing, it makes 
sense to require the serviceQname/portType in an EPR.



[1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Service
Received on Monday, 8 November 2004 19:54:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC