- From: Martin Gudgin <mgudgin@microsoft.com>
- Date: Wed, 24 Nov 2004 12:00:03 -0800
- To: "David Booth" <dbooth@w3.org>, "Francisco Curbera" <curbera@us.ibm.com>
- Cc: "David Orchard" <dorchard@bea.com>, <public-ws-addressing@w3.org>
> -----Original Message----- > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Booth > Sent: 24 November 2004 19:48 > To: Francisco Curbera > Cc: David Orchard; public-ws-addressing@w3.org > Subject: RE: i0001: EPRs as identifiers > > > Paco, > > On Mon, 2004-11-22 at 13:31, Francisco Curbera wrote: > > Just to add one comment to DaveO's answer. Different > customerKeys could > > perfectly be associated with different policies, so I don't > think your > > argument against them appearing as reference properties is valid. > > DaveO's example was supposed to illustrate the need for Reference > Properties. > > I agree that it is *possible* for different customerKeys to have > different policies that would require them to be processed by > different > service endpoints. But in most cases, it would more natural and usual > for requests to be processed by the *same* service endpoint even if > their customerKeys or policies differ (though I suppose that > depends on > your definition of "policy"). Policy to me covers things like security requirements, quality of service requirements etc. > > In other words, the use of different customerKeys (or even different > policies) does not adequately *motivate* the need for Reference > Properties. It would be far more instructive to use an example that > logically requires a different interface. Why? Reference properties can be used to distinguish between services that differ by something other than interface/porttype... Gudge
Received on Wednesday, 24 November 2004 20:00:37 UTC