- From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
- Date: Tue, 23 Nov 2004 16:32:28 -0000
- To: "Rich Salz" <rsalz@datapower.com>, "Martin Gudgin" <mgudgin@microsoft.com>
- Cc: <public-ws-addressing@w3.org>
<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:33:29 UTC