i008: Wrapper proposal

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, 13 December 2004 14:03:19 UTC