Re: Multiple Addresses in an EPR

But how would you specify the other information such as 
RefParams/MetaData that may need to be defined for each optional URI? My 
concern is that we would define a mechanism that is not sufficient to 
satisfy the 80/20 case because of the way in which the whole 
WS-Addressing EPR is supposed to be used. It's one thing to say that in 
some cases the URIs are independent of the RefParams (for example), but 
that may not be the case elsewhere.

Even if the EPR was only a URI (i.e., we'd not added RefParams etc.) I'd 
still caution against simply allowing multiple such URIs to be defined 
within the basic addressing mechanism because of what I mentioned 
previously: how the alternate is selected by a user is often as 
important as the ability to define an alternate.

You could tackle this in other ways without waiting for something like 
WS-Group to define a logical EPR. For instance, I've seen users define 
alternate EPRs within the service description and accessible via UDDI. 
OK, this has some overhead if you are duplicating information between 
EPRs, but I don't believe that's such a drawback. If it is, then what 
about an intermediate binding service, where the user only ever sees a 
single EPR at a time and has to fault back to this binding service to 
get an alternate. Again, there are disadvantages, but it can offer 
better scalability.

Mark.



Conor P. Cahill wrote:

>I will grant that there are situations in which one would not
>want to have multiple addresses in a single EPR.  Just like
>there are situations where reference parameters shouldn't
>be used or could even be rejected by the recipient of the
>EPR.
>
>However, there are at least a few cases where multiple
>addresses can be used.  It doesn't make sense to prohibit
>such cases because there may be or are other cases where
>it doesn't make sense.
>
>I am not asking that the generator of an EPR be obligated
>to send multiple physical address in the same EPR.  Only
>that in the cases where it make sense the generator is
>*allowed* to do so.
>
>Conor
>
>Mark Little wrote on 10/16/2005, 10:02 AM:
>
> >
> > The Address element (URI) cannot necessarily be taken in isolation from
> > the rest of the information within the EPR, in particular the
> > ReferenceParameters. I don't know how likely it is that the same
> > RefParams within an EPR will be useable with different URIs, but I'd
> > guess that they're going to be tied to a specific URI - certainly that's
> > the way I've seen them used in practice so far. This means that although
> > it's a necessary condition to have multiple URIs for the same logical
> > EPR, it's not a sufficient condition: you need to have at least the
> > RefParams and maybe even the MetaData.
> >
> > In your specific implementation it may be possible to say that the
> > RefParams/MetaData are the same between multiple Address URIs. But
> > that's an implementation choice and seems to point towards what I said
> > earlier: this is better handled above the baseline WS-Addressing
> > specification.
> >
> > Mark.
> >
> >
> > Conor P. Cahill wrote:
> >
> > >
> > >Mark Little wrote on 10/16/2005, 7:33 AM:
> > >
> > > >
> > > > I agree with the requirement. I just disagree that it's so
> > fundamental
> > > > that it has to be within WS-Addressing.
> > >
> > >As far as I can tell, if you don't do this, you end up with either
> > >
> > >    a) requiring multiple EPRs,
> > >    b) having some elements defined in Metadata to
> > >       carry the same information
> > >    c) forcing it into a layer above addressing such
> > >       as within DNS or within a router
> > >
> > >a) is a pain for both the generator and expecially for the
> > >conumer of the EPR as they somehow have to recognize that
> > >the two EPRs are otherwise equal.
> > >
> > >b) is placing essentially equivalent data in two different
> > >locations within an EPR -- something that just seems wrong
> > >to me.
> > >
> > >c) can be done anyway, but then all of WS-Addressing can
> > >(and already is) done outside of the SOAP layer.  I presume
> > >that someone believes having this information in the SOAP
> > >layer is advantageous.
> > >
> > >WS-Addressing has chosen to define an EPR format that carries
> > >an address for an endpoint.  If someone is to profile that
> > >there are multiple physical endpoints associated with the
> > >logical endpoint described by the EPR, then WS-A needs
> > >to at least provide a location where this information is
> > >to be carried -- hence my request for allowing the Address
> > >element to be multi-occurance.
> > >
> > >Conor
> > >
> > >
> > >
> > >
> > >
> >
>
>
>  
>

Received on Sunday, 16 October 2005 14:51:09 UTC