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

Hi Steve,

If there are multiple ports then the WSDL in effect provides *multiple
EPRs* for the same service. What you're asking for is a single EPR for
a service with multiple ports, right?

If you model this at the WSDL 1.1 level there's a problem .. basically
the WSDL 1.1 <service> element doesn't really have fixed semantics-
it allows any set of ports of any portTypes to be there and there's
nothing stated about the relationship about the ports offering
different portTypes. (That was part of the reason BTW for WSDL 2.0 to go
with one interface per service.)

The alternative is to look at all the ports with the same portType
and want a single EPR for it. That's analogous to providing a single
EPR for a WSDL 2.0 <service> instead of on a per-endpoint basis.
That I believe makes sense.

Such an EPR would look like an IOR with tagged profiles right? If so
the simplest way to achieve this is to use a policy assertion in the
EPR giving the alternate addresses. Thus the {address} property gives
the address for a given port but the policies may give additional
addresses for alternative ports. All we'd need to do is define a
policy assertion. Oh yeah there's that pesky problem of being a
proprietary spec and all that ;-) .. let's ignore that for a minute
and consider the technical aspects.

Note that WS-Addressing allows the {address} property to be logical
rather than physical. If it is indeed logical then one again would
need the policy assertion giving the alternative addresses, at least
the one physical option!

IIRC the spec currently says the address can be logical but does
not say how things are spsed to work if it is logical. The policy
assertion approach is an approach for making it work.

Sanjiva.

----- Original Message ----- 
From: "Vinoski, Stephen" <Steve.Vinoski@iona.com>
To: "Rich Salz" <rsalz@datapower.com>
Cc: "Martin Gudgin" <mgudgin@microsoft.com>; "Bergersen, Rebecca"
<Rebecca.Bergersen@iona.com>; <public-ws-addressing@w3.org>; "Newcomer,
Eric" <Eric.Newcomer@iona.com>
Sent: Saturday, November 06, 2004 5:44 AM
Subject: 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 Saturday, 6 November 2004 02:56:45 UTC