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

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

From: <paul.downey@bt.com>
Date: Mon, 8 Nov 2004 15:01:51 -0000
Message-ID: <2B7789AAED12954AAD214AEAC13ACCEF2709DD01@i2km02-ukbr.domain1.systemhost.net>
To: <tom@coastin.com>, <Steve.Vinoski@iona.com>
Cc: <dorchard@bea.com>, <public-ws-addressing@w3.org>, <Eric.Newcomer@iona.com>
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.

	-----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
	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:02:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC