W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

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

From: Vinoski, Stephen <Steve.Vinoski@iona.com>
Date: Mon, 8 Nov 2004 13:27:16 -0500
Message-ID: <13AC4E67178F4D4EA31BB1BA64530313037703@amereast-ems2.boston.amer.iona.com>
To: <paul.downey@bt.com>
Cc: <public-ws-addressing@w3.org>, "Newcomer, Eric" <Eric.Newcomer@iona.com>
Yes, dealing with multiple concrete EPRs would be a pain, as I described in a previous message. That's why having a single EPR that can contain one or more addresses/mechanisms simultaneously is preferable.

I'm not sure what to make of your 1000 endpoints example. It's definitely extreme, perhaps to the point of being outside the realm of useful discussion. But if someone were to take 1000 different endpoints with different policies and try to cram them together into a single EPR structure in order to somehow treat them all as the "same" endpoint, I'd say they'd likely get the pain they deserved. Regardless, extreme examples like that don't take away from the fact that there are practical endpoints in production today that are reachable over several different protocols/transports/data formats, and an addressing mechanism needs to be able to handle these efficiently IMO.

--steve

-----Original Message-----
From: paul.downey@bt.com [mailto:paul.downey@bt.com]
Sent: Monday, November 08, 2004 11:02 AM
To: Vinoski, Stephen; dorchard@bea.com; tom@coastin.com
Cc: public-ws-addressing@w3.org; Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR


seems to me that sending multiple concrete EPRs in each message is likely to be 
far more complex and less performant than sending a single abstract EPR whose 
meaning could be cached. 
 
Also taking this to an extreme, if i actually have 1000 endpoints scattered around 
the world with different policies attached (reliability, uptime, cost, response time, etc) 
i'd rather the negotiation and resolution was performed out of band rather then 
encoded in each message.
 
Paul

	-----Original Message----- 
	From: Vinoski, Stephen [mailto:Steve.Vinoski@iona.com] 
	Sent: Mon 08/11/2004 15:33 
	To: David Orchard; Downey,PS,Paul,XSJ67A C; tom@coastin.com 
	Cc: public-ws-addressing@w3.org; Newcomer, Eric 
	Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR
	
	

	Yes, Dave's exactly right. If the multiple address information is included by reference only, then our performance goes down the drain -- you'd need to perform multiple network operations just to obtain the addressing information necessary to send a single message to a target.
	
	--steve
	
	-----Original Message-----
	From: David Orchard [mailto:dorchard@bea.com]
	Sent: Monday, November 08, 2004 10:29 AM
	To: paul.downey@bt.com; tom@coastin.com; Vinoski, Stephen
	Cc: public-ws-addressing@w3.org; Newcomer, Eric
	Subject: 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 18:28:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT