Re: i008: Wrapper proposal

The proposal A is actually three for the price of one ;-)
It also solves issue i013. Such a To header allows implementations to 
not only use the wsa:Address, wsa:Action headers to make 
routing/processing decisions but also the information in service 
Qname/port etc from the EPR (if present).

Between the two proposals I prefer proposal A.

-Anish
--

Glen Daniels wrote:
> 
> To complete my AI, here's the proposal for the wrapper-based solution to
> issues 8, 16, and 18.  In fact it's two proposals for the price of one!
> Both proposals refer to the following abstract EPR ("refps" is a
> placeholder for ref properties and/or ref parameters):
> 
> <epr>
>   <to>http://address</to>
>   <refps>
>     <objectID>5</objectID>
>     <clusterKey>4f7g</clusterKey>
>   </refps>
> </epr>
> 
> Both proposals involve removing the current SOAP binding of refP's
> directly to SOAP headers (section 2, SOAP binding).
> 
> PROPOSAL A : IT'S ALL ABOUT THE EPR, BABY
> 
> This proposal is based around the idea that other addressing headers
> (ReplyTo, From, etc) are EPRs, so why not To as well? (this was issue
> 16)  We change the type of <wsa:To> from anyURI to EPR, and then
> reference properties associated with the destination EPR will naturally
> serialize inside the wsa:To header.  The EPR above would end up
> serializing like this (ns declarations are assumed):
> 
> <soap:Header>
>  <wsa:To>
>   <wsa:Address>http://address</wsa:Address>
>   <wsa:RefPs>
>     <objectID>5</objectID>
>     <clusterKey>4f7g</clusterKey>
>   </wsa:RefPs>
>  </wsa:To>
> </soap:Header>
> 
> This serialization makes it clear to anyone reading/processing the
> message that the refp's are associated with WSA, and in fact with the To
> address in particular.  The problems with the "meaning" of inserting
> first-order headers go away, as do issues with knowing which headers are
> RefPs and therefore might require different security signatures, etc.
> 
> PROPOSAL B : WRAPPER'S DELIGHT
> 
> This proposal leaves <wsa:To> the way it is, and adds a new top-level
> header <wsa:RefPs> (depending on any decisions about merging/removing
> refProps and refParams, this might really be two headers
> <wsa:ReferenceProperties> and <wsa:ReferenceParameters>) to contain the
> refPs.  The EPR above would serialize like this:
> 
> <soap:Header>
>  <wsa:To>http://address</wsa:To>
>  <wsa:RefPs>
>    <objectID>5</objectID>
>    <clusterKey>4f7g</clusterKey>
>  </wsa:RefPs>
> </soap:Header>
> 
> I think there are pros and cons to each of these approaches, but I would
> be happy with either as they both solve all three issues.  I am
> currently of the opinion that proposal A is slightly cleaner, and it
> would more easily allow composition of multiple EPRs in a given message,
> for itinerary/routing-based purposes or some other scenario we haven't
> yet thought of.
> 
> I believe that implementing either of these proposals would simply
> require changing the SOAP binding to describe the mappings above.
> 
> Thanks,
> --Glen
> 
> 
>

Received on Monday, 20 December 2004 18:50:18 UTC