- From: Vinoski, Stephen <Steve.Vinoski@iona.com>
- Date: Mon, 8 Nov 2004 13:27:16 -0500
- 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 UTC