RE: Thoughts on TAG issue EndpointsRef47

+1 to everything Savas says below. This is exactly the kind of scenario
I had in mind.

Gudge

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Savas Parastatidis
> Sent: 07 February 2005 10:28
> To: tom@coastin.com; Jonathan Marsh
> Cc: public-ws-addressing@w3.org
> Subject: RE: Thoughts on TAG issue EndpointsRef47
> 
> 
> Hi Tom,
> 
> 
> > If what Gudge is describing is required, we might consider 
> a multiple
> > Protocol profile structure
> > for the "EPR".   This is what IONA was getting at.  We 
> could represent
> > all the variant
> > transport addresses required in the EPR.
> > 
> > Otherwise I am not at all clear on how the "logical" uri gets mapped
> to
> > the various
> > transport addresses required for the variants desired.
> > 
> 
> There may not be a need to map the "logical" URI to a 
> specific transport
> address. Imagine a service with a logical address
> 'urn:chocolates:service' which sells chocolates. You want to buy a
> chocolate from a peer-to-peer network of services without caring about
> the actual endpoint of the service that will serve you.
> 
> <soap:Envelope>
>   <soap:Header>
>     <wsa:To>urn:chocolates:service</wsa:To>
>   </soap:Header>
>   <soap:Body>
>     <m:OrderForm>
>       <m:noChocolateBars>10</m:noChocolateBars>
>       <m:maxAmmountPerChocolateBar>1000</m:maxAmmountPerChocolateBar>
>     </m:OrderForm>
>   </soap:Body>
> </soap:Envelope>
> 
> All you have to do is just give this message to the P2P network which
> will know how to do deal with it. No need to go from a logical to a
> transport-specific address for this service. But even if you had to,
> there is a use case for using logical addresses as indexes in 
> registries
> where transport-specific endpoints can be found at runtime 
> ("give me all
> the transport endpoints of the urn:chocolates:service service").
> 
> Regards,
> .savas.
> 
> 
>

Received on Monday, 7 February 2005 11:41:40 UTC