RE: WS-A Issue 28 - Multiple ports needed in an EPR

Hi Rich,

In systems that I'm familiar with, once the particular choice of protocol/transport/whatever for reaching the target is chosen, only that choice is indicated in the message. This is pretty much what Greg Truty was talking about in [1]. However, that's only for the target. What gets shipped around generally as an address always contains all choices, since you can't know a priori which of the choices will be preferred or required by any given application that wants to use the address.

--steve

[1] <http://lists.w3.org/Archives/Public/public-ws-addressing/2004Nov/0028.html>

-----Original Message-----
From: Rich Salz [mailto:rsalz@datapower.com]
Sent: Friday, November 05, 2004 5:48 PM
To: Vinoski, Stephen
Cc: Martin Gudgin; Bergersen, Rebecca; public-ws-addressing@w3.org;
Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR


> Where I come from, endpoints can be accessed
> over any number of transports and protocols. Why limit an EPR to
> describing only a single path to an endpoint? There is much middleware
> prior art in exsitence that proves that such a limit is completely
> unnecessary.

Do all the choices have to be enumerated in every *instance* of a message?
Does it often happen that the middleware layer tries a variety of
transports, choosing which ones dynamically on a per-message basis?

In my (limited) experience, deciding which of many transports/paths
is done at the sender-side, at message initiation time.  If it fails,
the middleware lets the sender know, and the sender then says "okay, try
this one."  Thnis would argue for multiple paths in the server
description, and not in each message instance.  Are there many
counter-examples?  Enough to justify the complexity?
	/r$

-- 
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html

Received on Friday, 5 November 2004 23:45:52 UTC