Re: NEW ISSUE: EPR comparison rule doesn't support Web services gateways/routers

public-ws-addressing-request@w3.org wrote on 01/26/2005 11:41:05 PM:

> 
> Hi Rich,
> 
> On Wed, Jan 26, 2005 at 11:37:54PM -0500, Rich Salz wrote:
> > > Paco, can you not just use a different URI instead of different
> > > RefParams in order to distinguish between multiple services behind a
> > > gateway?  If not, why?
> > 
> > Because people want to only expose a single endpoint, and then
> > have their infrastructure dispatch or route based on things like 
message
> > content.
> 
> That would be just fine by me, since layering is maintained.  What I
> understood Paco to want is to be able to *identify* services behind a
> gateway using RefParams in the request message.  That would break
> layering.

You can envision the case where due the the ref parms being sent, it 
enables information to be sent that may be independent of the 
application-level data (to aid in routing).

> 
> > There several reasons for doing this; one of the most compelling
> > is that they do not want to expose *anything* about their internal
> > deployment details.  It avoids giving attackers any information.
> 
> Right.  Enforcing layering would avoid giving out that info, while
> breaking layering would reveal it.
> 
> FWIW, URIs vs. RefPs doesn't change the layering, but the reason I asked
> the question above was to find out if the "gateway" could be a proxy,
> in which case there's no layering issue since a proxy works on behalf
> of the sender.

You also have the case where you have the reverse-proxy server (acting on 
behalf of the receiver of the message) working jointly w/the hosting 
service runtime.  E.g., a web server outside a firewall routing the 
requests inside the firewall (using refparms to help w/that).

> 
> Mark.
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> 


Regards... Greg

Greg Truty
WebSphere Architecture/Development,  IBM Austin
EMail:     gtruty@us.ibm.com 
Phone:   (ext)  (512) 838-2828
                (Tie) 678-2828

Received on Thursday, 27 January 2005 14:45:00 UTC