- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Mon, 08 Nov 2004 10:58:52 -0800
- To: tom@coastin.com
- CC: "Vinoski, Stephen" <Steve.Vinoski@iona.com>, David Orchard <dorchard@bea.com>, public-ws-addressing@w3.org, "Newcomer, Eric" <Eric.Newcomer@iona.com>
Tom Rutt wrote: > > 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?" > My reading of the spec says -- yes. Here is why: An EPR allows one to specify the service qname (the portname attribute being optional). A service qname refers to a service element which may contain multiple ports. The EPR also allows one to specify the portType. The way I'm interpreting this to mean that any port in the service that has the same portType as specified in the EPR can be used. If my interpretation is correct, I don't understand why we should make the wsa:Address a logical address and have some unspecified (by the spec) way of dealing with how to map the logical address to a physical address. It seems unnecessarily complex to me. It seems to me that wsa:Address is an invention that isn't strictly necessary. The wsa:ServiceQname and wsa:PortType seem to do the job quite well (yes I'm aware that wsa:PortType, wsa:ServiceQname are optional -- but we are debating the design of the EPR itself here) Comments? -Anish -- > 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 >> >
Received on Monday, 8 November 2004 18:59:46 UTC