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