Re: Composibility problems with refps

A few comments inline below.

On Nov 22, 2004, at 7:26 PM, Christopher B Ferris wrote:
>>
>> What are the advantages of subjecting ref props's and param's to SOAP
>> Processing Model? And what exactly do we lose by going the opposite 
>> way.
>
> <snip/>

> Now, the fact that the ref props/params become SOAP header blocks is
> important and
> quite useful. For instance, an endpoint that knows it resides behind a
> gateway/firewall
> could design and publish an EPR that took this fact into consideration 
> by
> including
> ref props/params that would aide in the gateway's routing of the 
> messages
> received.
> For instance, the gateway could be an HTTP endpoint, targetted by the
> wsa:Address
> and one of the ref props/params could be an MQSeries queue name that 
> the
> ultimate
> recipient will be using to dequeue messages addressed to it.
>
> That use case seems quite reasonable to me. The EPR would probably look
> something
> like this:
>
> <wsa:EndpointReference>
>   <wsa:Address>http://my.gateway.ibm.com/queuea</wsa:Address>
>   <wsa:ReferenceProperties>
>     <mq:QueueId soap:actor="http://www.ibm.com/gateway/"
> soap:mustUnderstand="true">queuea</mq:QueueId>
>   </wsa:ReferenceProperties>
> </wsa:EndpointReference>
>
> Now, if I somehow misdirected to the wrong gateway service, the one 
> that
> knows about
> MQSeries, then the sender would never get a SOAP MustUnderstand fault
> indicating that
> in fact the message could not be processed if the ref prop were 
> wrapped in
> some generic
> wsa:Warpper element.
>
I see what you are getting at but I'd think it would make as much, if 
not more, sense for the (wrong) gateway service to return one of the 
standard addressing faults like Destination Unreachable rather than a 
mustUnderstand fault. The problem with using mustUnderstand is that the 
sender isn't the one that requested the not-understood header to be in 
the message, that was the responsibility of the EPR minter so the 
sender will get back a somewhat mysterious fault indicating that some 
part of the message that is (supposedly) opaque to the sender was not 
understood rather than a fault indicating that there's been an 
addressing problem.

If instead we include the reference props and params inside the wsa:To 
then we can define the processing model of the wsa:To header to do the 
right thing (like send a destination unreachable if there's an unknown 
component to the address). After all, ref props and params are supposed 
be be sub-addresses rather than a means to invoke arbitrary ws 
functionality at the receiver, putting them in the wsa:To seems a lot 
closer to that intention to me.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Tuesday, 23 November 2004 18:48:35 UTC