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

I *think* that the issue raiser wants to have the ability to normatively
specify how multiple network addresses are represented by value in the
EPR, rather than by ref.

Dave

> -----Original Message-----
> From: paul.downey@bt.com [mailto:paul.downey@bt.com]
> Sent: Monday, November 08, 2004 7:02 AM
> To: tom@coastin.com; Steve.Vinoski@iona.com
> Cc: David Orchard; public-ws-addressing@w3.org; Eric.Newcomer@iona.com
> Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR
> 
> i'm puzzled where the requirment for multiple EPRs is coming from.
> 
> The Informational Model for Endpoint references section in our
> spec states:
> 
> """
> [address] : URI (mandatory)
>    An address URI that identifies the endpoint.
>    This may be a network address or a logical address.
> """
> 
> so if the URI can be abstract it may be used by an agent to lookup a
> series of network address from config, a directory service or even
> a WSDL document.
> 
> Paul
> 
> 	-----Original Message-----
> 	From: public-ws-addressing-request@w3.org on behalf of Tom Rutt
> 	Sent: Mon 08/11/2004 14:14
> 	To: Vinoski, Stephen
> 	Cc: David Orchard; public-ws-addressing@w3.org; Newcomer, Eric
> 	Subject: Re: WS-A Issue 28 - Multiple ports needed in an EPR
> 
> 
> 
> 
> 	A CORBA IOR references an implemntation of a CORBA IDL defined
> 	interface, which may be accessable via more than one protocol.
Thus
> 	the need for multi-profile IORs.
> 
> 	If the EPR is referencing more than a single port access to a
web
> 	service (i.e. there may be an smtp way to bind a wsdl port
> 	type in addition to the soap/httpPost way) then it should have
some
> way
> 	to pass the access parameters required for
> 	each of those bound ports.
> 
> 	I guess this is a fundamental question,
> 	"Is an EPR intended to reference more than one bound port for a
WSDL
> 	port type?"
> 
> 	Tom Rutt
> 	Fujitsu
> 
> 	Vinoski, Stephen wrote:
> 
> 	> Hi Dave, one other thing: you asked how many CORBA vendors
might
> have
> 	> wanted a single profile IOR design. I believe the answer in
the
> 	> beginning might have been a couple vendors, but today the
answer
> is
> 	> zero. I can honestly say that I personally have never heard
anyone
> 	> complain about the existence or complexity of the
multi-profile
> IOR --
> 	> Jeff or Tom might chime in if they have any data on this. I
also
> don't
> 	> know of any vendor who has not taken advantage of the multi-
> profile
> 	> IOR capability for one reason or another at some point.
Numerous
> 	> CORBA-based research projects have also taken advantage of the
> 	> multi-profile IOR over the years as well.
> 	> --steve
> 	>
> 	>     -----Original Message-----
> 	>     *From:* David Orchard [mailto:dorchard@bea.com]
> 	>     *Sent:* Saturday, November 06, 2004 8:24 PM
> 	>     *To:* Vinoski, Stephen; Martin Gudgin; Bergersen, Rebecca;
> 	>     public-ws-addressing@w3.org
> 	>     *Cc:* Newcomer, Eric
> 	>     *Subject:* RE: WS-A Issue 28 - Multiple ports needed in an
EPR
> 	>
> 	>     It is a trade-off between complexity and simplicity. We
have
> found
> 	>     over and over again that we cannot build the kinds of
systems
> we'd
> 	>     like to with just URIs. We can build the systems we want
with
> URIs
> 	>     + ref properties (or in parallel incarnation of HTTP
cookies).
> 	>     Turns out not having echoing capabilities is too simple.
> 	>
> 	>     But I have a feeling that you aren't seriously suggesting
> dropping
> 	>     Ref props. Or are you? Perhaps you are suggesting that
your
> 	>     priority is: 1) multi-port EPRs; 2) URI only EPRs; 3) EPRs
as
> they
> 	>     exist today wrt ports/ref props? This might now be the 2nd
> time
> 	>     that somebody has proposed a mandatory or new feature that
> I've
> 	>     pushed back on, and the counter-argument has been to
remove an
> 	>     existing mandatory feature. The previous being the
suggesting
> of
> 	>     making address optional if Service Qname can't be made
> mandatory.
> 	>
> 	>     I believe we can build multi-address structures on top of
or
> using
> 	>     EPRs. EPRs have extensibility that seem to enable things
like
> EPRs
> 	>     within EPRs even (similar to IOR Profiles?). And many
specs,
> like
> 	>     ws-rm and ws-rf etc. are making their own structures that
> contain
> 	>     EPRs. I find it interesting that not many of those derived
> works
> 	>     have created a multi address/port structure. Perhaps there
> isn't
> 	>     much demand?
> 	>
> 	>     I agree that cases for multi-EPRs will require a spec and
> 	>     interoperability tests and so forth. The same argument
goes
> for
> 	>     just about every kind of functionality though. There's a
> reason
> 	>     why the WS-A working group isn't defining wsdl and
> 	>     metadataexchange and policy and reliablemessaging and
> universal
> 	>     EPR lifecycle and pub/sub and uddi and ... Our charter
takes
> into
> 	>     account layering and picking the smallest piece that
delivers
> the
> 	>     most bang for the buck, sometimes called 80/20. Now I also
> know
> 	>     full well that one person's 80/20 is another's
> 	>     worthless/wasteoftime, so I hesitate to use it but it
seems to
> fit
> 	>     in this scenario.
> 	>
> 	>     I think it would make my users life more complicated by
> forcing
> 	>     every EPR minter and user to have to deal with multi-EPR
> 	>     scenarios. Obviously I could be wrong, but I do find the
> 	>     simplicity of EPRs to be compelling.
> 	>
> 	>     I am interested in learning more about CORBA IORs and
profiles
> 	>     though. Could you send link(s) on them and their usage? I
also
> 	>     idly wonder how many CORBA vendors/users would have wanted
> single
> 	>     profile IORs rather than the current IOR design.
> 	>
> 	>     Cheers,
> 	>
> 	>     Dave
> 	>
> 	>
--------------------------------------------------------------
> ----------
> 	>
> 	>     *From:* Vinoski, Stephen [mailto:Steve.Vinoski@iona.com]
> 	>     *Sent:* Saturday, November 06, 2004 1:54 PM
> 	>     *To:* David Orchard; Martin Gudgin; Bergersen, Rebecca;
> 	>     public-ws-addressing@w3.org
> 	>     *Cc:* Newcomer, Eric
> 	>     *Subject:* RE: WS-A Issue 28 - Multiple ports needed in an
EPR
> 	>
> 	>     Hi Dave,
> 	>
> 	>     I understand the desire for simplicity. But if it's
simplicity
> 	>     that you want, why not forego the EPR entirely and use a
URI?
> You
> 	>     stated your opinion for why we need an EPR over just a URI
in
> a
> 	>     separate thread. By what criteria do you judge your need
for
> an
> 	>     EPR rather than just a URI to be acceptable, while judging
our
> 	>     need for multi-address EPRs to be too complicated?
> 	>
> 	>     Obviously you can raise all kinds of hypothetical
> complications
> 	>     regarding multi-address or multi-mechanism services. In
> practice,
> 	>     it's really not that complicated. Middleware has supported
> such
> 	>     constructs for well over a decade now, the best example of
> which
> 	>     is probably the CORBA IOR. IORs may consist of one or more
> 	>     profiles, where each profile may contain a separate
address,
> but
> 	>     all profiles in the same IOR "point" to the same target
> object. In
> 	>     practice, most IORs consist of only a single IIOP profile,
but
> the
> 	>     flexibility for multiple profiles is there, and it's
amazingly
> 	>     handy when you need it.
> 	>
> 	>     If you want to keep the EPR simple, as you stated, are you
> instead
> 	>     proposing that this WG also standardize some kind of
composite
> EPR
> 	>     as well? Because if this WG doesn't address the
multi-address
> 	>     issue, then the layering you're proposing will be strictly
> 	>     proprietary and non-interoperable, and will proliferate
the
> 	>     complication. I already pointed out the problem with the
> layering
> 	>     approach in my reply to Gudge, and that is that it just
pushes
> the
> 	>     problem into the higher levels of software where it has to
be
> 	>     handled again and again and again, which makes it less
likely
> that
> 	>     it will be handled at all, which will result in rigid
> inflexible
> 	>     systems that cannot deal with protocol, format, and
service
> 	>     evolution. Imagine, for example, if all IORs could contain
> only a
> 	>     single profile. That would force all CORBA applications to
be
> able
> 	>     to accept sequences of IORs in all the places they would
> normally
> 	>     just accept a single one-or-more-profile IOR. It forces
all
> the
> 	>     complication up into the applications. Do you really want
to
> make
> 	>     your users' lives more complicated?
> 	>
> 	>     --steve
> 	>
> 	>         -----Original Message-----
> 	>         *From:* David Orchard [mailto:dorchard@bea.com]
> 	>         *Sent:* Saturday, November 06, 2004 3:31 PM
> 	>         *To:* Vinoski, Stephen; Martin Gudgin; Bergersen,
Rebecca;
> 	>         public-ws-addressing@w3.org
> 	>         *Cc:* Newcomer, Eric
> 	>         *Subject:* RE: WS-A Issue 28 - Multiple ports needed
in an
> EPR
> 	>
> 	>         Steve,
> 	>
> 	>         I agree that in some indeed many cases there may be a
need
> for
> 	>         multiple "addresses" for a service. But don't we need
an
> 	>         atomic address at some point? I think we do have a
pretty
> good
> 	>         handle on what the minimum is to address a single
"thing".
> I'd
> 	>         suggest that any kind of multi-address construct can
be
> 	>         layered on. And there will be lots of complexity:
What's
> the
> 	>         order of precedence? Are there any commonalities, like
> policy
> 	>         across all the address? Are there policies specific to
an
> 	>         endpoint? Are there different bindings/required
properties
> per
> 	>         endpoint? I propose that multi-address information
should
> be
> 	>         layered on top and EPRs remain as simple as we can
keep
> them,
> 	>         rather than pushing the multi-stuff into EPRs.
> 	>
> 	>         By analogy, I agree that molecules are great. And
> sometimes
> 	>         just atoms are the thing we want, like gold or oxygen.
The
> 	>         universe deals well with both constructs, but they do
have
> a
> 	>         layering/composition model.
> 	>
> 	>         Another saying I like for standards is "you know your
> standard
> 	>         is successful when people go great, but can you add
foo,
> bar,
> 	>         baz..". That means it hit the minimum necessary for
> success.
> 	>
> 	>         Cheers,
> 	>
> 	>         Dave
> 	>
> 	>
----------------------------------------------------------
> --------------
> 	>
> 	>         *From:* public-ws-addressing-request@w3.org
> 	>         [mailto:public-ws-addressing-request@w3.org] *On
Behalf Of
> 	>         *Vinoski, Stephen
> 	>         *Sent:* Friday, November 05, 2004 1:50 PM
> 	>         *To:* Martin Gudgin; Bergersen, Rebecca;
> 	>         public-ws-addressing@w3.org
> 	>         *Cc:* Newcomer, Eric
> 	>         *Subject:* RE: WS-A Issue 28 - Multiple ports needed
in an
> EPR
> 	>
> 	>         Gudge, take a look at your own business card. Does it
have
> 	>         your address, work phone number, fax number, mobile
> number,
> 	>         email address, instant message ID, and your home page
all
> 	>         listed on it, or do you actually have multiple
business
> cards,
> 	>         one listing your address, a separate one listing your
work
> 	>         phone, another listing your email address, etc.?
> 	>
> 	>         You seem to imply that an endpoint is accessible via
only
> a
> 	>         single transport and protocol. 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.
> 	>
> 	>         --steve
> 	>
> 	>             -----Original Message-----
> 	>             *From:* Martin Gudgin
[mailto:mgudgin@microsoft.com]
> 	>             *Sent:* Thursday, November 04, 2004 2:35 PM
> 	>             *To:* Bergersen, Rebecca;
public-ws-addressing@w3.org
> 	>             *Cc:* Newcomer, Eric; Vinoski, Stephen
> 	>             *Subject:* RE: WS-A Issue 28 - Multiple ports
needed
> in an EPR
> 	>
> 	>             I take issue with the assertion "where there are
> different
> 	>             protocols/transports/formats available for the
same
> 	>             service, the "access to a Web service endpoint"
> requires
> 	>             the client to choose among alternatives".
> 	>
> 	>             If I, the service, give you, the client, a single
EPR
> then
> 	>             as far as you are concerned, there is only one
> mechansim
> 	>             with which you can communicate with me. So you
don't
> need
> 	>             to make any choices ( except whether to
communicate or
> 	>             not, I guess ).
> 	>
> 	>             If I am available on multiple EPRs, then I'll
provide
> you
> 	>             with multiple EPRs (perhaps in a WSDL document),
> *then*
> 	>             you have to choose one from the set.
> 	>
> 	>             Gudge
> 	>
> 	>
------------------------------------------------------
> ------------------
> 	>
> 	>             *From:* public-ws-addressing-request@w3.org
> 	>             [mailto:public-ws-addressing-request@w3.org] *On
> Behalf Of
> 	>             *Bergersen, Rebecca
> 	>             *Sent:* 04 November 2004 11:53
> 	>             *To:* public-ws-addressing@w3.org
> 	>             *Cc:* Newcomer, Eric; Vinoski, Stephen; Bergersen,
> Rebecca
> 	>             *Subject:* WS-A Issue 28 - Multiple ports needed
in an
> EPR
> 	>
> 	>                 Issue 28 - Multiple ports needed in an EPR
> 	>
> 	>                 According to the ws-addressing submission,
> "Endpoint
> 	>                 references convey the information needed to
> 	>                 identify/reference a Web service endpoint, and
may
> be
> 	>                 used in several different ways: endpoint
> references
> 	>                 are suitable for conveying the information
needed
> to
> 	>                 access a Web service endpoint...." However, in
the
> 	>                 situation where there are different
> 	>                 protocols/transports/formats available for the
> same
> 	>                 service, the "access to a Web service
endpoint"
> 	>                 requires the client to choose among
alternatives,
> each
> 	>                 accessible in the standard manner through a
port -
> but
> 	>                 there are different ports for each
> 	>                 protocol/transport/format alternative. When
such
> 	>                 alternatives exist, the EPR must be able to
> identify
> 	>                 those multiple ports.
> 	>
> 	>                 Rebecca Bergersen
> 	>                 Principal Architect, Middleware Standards
> 	>                 rebecca.bergersen@iona.com
> 	>                 <mailto:rebecca.bergersen@iona.com>
> 	>
--------------------------------------------------
> -----
> 	>                 IONA Technologies
> 	>                 200 West Street Waltham, MA 02451 USA
> 	>                 Tel: (781) 902-8265
> 	>                 Fax: (781) 902-8001
> 	>
--------------------------------------------------
> -----
> 	>                 Making Software Work Together ^TM
> 	>
> 
> 	--
> 	----------------------------------------------------
> 	Tom Rutt        email: tom@coastin.com; trutt@us.fujitsu.com
> 	Tel: +1 732 801 5744          Fax: +1 732 774 5133
> 
> 
> 
>

Received on Monday, 8 November 2004 15:31:05 UTC