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 14:17:33 UTC