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

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Anish Karmarkar
> Sent: 08 November 2004 19:53
> To: public-ws-addressing@w3.org
> Subject: AI: why Service QName is required if client has WSDL 
> + engaged in conversation?
> 
> 
> All,
> 
> 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 
> client/consumer?
> 
> 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, 

By 'dereference' do you mean 'send a message to'?

> it is 
> necessary 
> to know the message format, schema, bindings, features, 
> properties etc 
> of that service. 

Yup, you need to know what the body should look like and what headers
need to be there.

>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. 

Seems like a reasonable thing to check if the information is present. I
don't see a major problem if this check isn't done though, I'll just get
a fault back, right ( or nothing ).

> 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). 

Plus any ReferenceProperties/Parameters needed to address the endpoint.

> But this makes EPR tightly coupled, and they cannot be 
> passed around outside the context. 

Agreed they can't be passed around outside the context ( or if they are
passed around, at least as much context must be provided ).

> This is quite bad for 
> interoperability. 

Why? I don't see the *interoperability* concern. I understand that if I
walk into a bar and find an EPR sitting on a bar stool, that EPR might
not contain enough information to successfully construct and send a
message to the endpoint. I'm not sure that's an interoperability issue
though. I don't think it's a goal of WS-Addressing that an EPR in and of
itself carry enough information to communicate with a service. 

There are cases in some protocols where the context of an address really
is scoped such that it doesn't make sense out of context. And I think
that's OK. There will also be other cases where there are addresses that
*do* make sense outside of the context in which they were originally
issued. We should support both cases ( and I think the current EPR
design does support both ).

>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. 

An EPR *is* just a way of passing the URI and Reference
Properties/Parameters. The meaning of the wsa:EndpointReference type is
'this contains information needed to address messages to an endpoint'.
It *might* also contain other information that the EPR consumer can use
to construct messages to send to the endpoint. 

> We are 
> defining an EPR 
> to allow for good tooling and interoperability. 

I agree that we are defining the EPR construct as an interoperable way
of serializing the addresses of endpoints. I don't agree we're defining
that construct to allow for good tooling, although that might well be a
nice benefit of what we end up with.

> 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 --
> 
> <wsa:EndpointReference>
>    <wsa:Address>42</wsa:Address>
> </wsa:EndpointReference>
> 
> Where, somehow the client knows to map "42" to 
> mailto:douglas.adams@hitchhikers-guide.com

I think that resource has expired :-(

> 
> 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 
> expected).

But there are protocols where the port type is known in advance ( and a
service QName is not needed or available). For example, in WS-Eventing
the SubscribeResponse message contains the EPR of a subscription
manager; an endpoint that implements the wse:SubscriptionManager port
type. To come back to your tooling argument, I can automatically create
the right proxy to send subscription management messages to this
endpoint.

I think that EPRs define an interoperable way to ship around endpoint
addresses. They are not intended to necessarily convey all the
information needed to communicate with the endpoint.

> 
> 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. 

Not all endpoints have service QNames. I agree that in cases where one
exists this could be useful, but I don't see a reason to mandate it.

> 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.

As I think you've gathered by now, I disagree. Not all endpoints have a
service QName so I don't see how we can mandate one. In certain
protocols the port type of a given EPR is already known, so the
information would be redundant. 

I'm not against people putting service/port type info into EPRs, but I
don't think we should mandate it.

I think one of the fundamental distinctions for me is that I see an EPR
as just the address of the endpoint. Whereas I think you see an EPR as
being a way of getting at *all* the information needed to communicate
with the endpoint. While I think that there are cases where EPRs will
fit (what I think is) your view, I don't think all of them will or
should.

Gudge

> 
> Comments?
> 
> -Anish
> --
> 
> [1] http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Service
> 
> 
> 
>

Received on Monday, 15 November 2004 13:11:15 UTC