RE: Sample SOAP message on the wire with Reference Properties and Parameters (without a wrapper!)

Savas,

You are going to hear that, you should use different qnames for Props
and Params and THEN you will know which policy to apply :)

-- dims

-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Savas
Parastatidis
Sent: Tuesday, November 23, 2004 11:32 AM
To: Rich Salz; Martin Gudgin
Cc: public-ws-addressing@w3.org
Subject: RE: Sample SOAP message on the wire with Reference Properties
and Parameters (without a wrapper!)


<snip />

> 
> But more importantly, if the only entity that can distinguish between
a
> prop and a param is the server, then I don't see why the spec has both

> types.  We should be able to drop one (flip a coin:) without any
impact
> on the installed base -- servers already have the requisite internal 
> config and magic to distinguish between the two -- and greatly
simplify
> things.

Hey Rich,

I think the reason the authors decided to have both is because of the
need to compare EPRs and associate different metadata with different
EPRs but still allow different Params to be sent to a single EPR.

The two ReplyTo headers may have different policies associated with
them...

<ReplyTo>
  <Address>http://service1.com</Address>
  <RefeferenceProperties>
    <customer>urn:id</customer>
  </ReferenceProperties>
  <ReferenceParameters>
    <account>urn:id</account>
  </ReferenceParameters>
</ReplyTo>

<ReplyTo>
  <Address>http://service1.com</Address>
  <RefeferenceProperties>
    <customer>urn:id</customer>
    <account>urn:id</account>
  </ReferenceProperties>
</ReplyTo>

The first one allows a service provider to have policies for specific
customers while the other to have policies for the specific account of a
customer.

An interesting question is how the receiving endpoint is to know in this
case which of the two set of policies to apply based on the headers in
the SOAP message.

Best regards,
.savas.

Received on Tuesday, 23 November 2004 16:35:40 UTC