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

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

From: Francisco Curbera <curbera@us.ibm.com>
Date: Sat, 6 Nov 2004 23:27:56 -0500
To: "Vinoski, Stephen" <Steve.Vinoski@iona.com>
Cc: "David Orchard" <dorchard@bea.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, "Martin Gudgin" <mgudgin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org, "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>
Message-ID: <OF30BAA975.0E04AB25-ON85256F45.0017E3E5-85256F45.001886BF@us.ibm.com>





One possible approach is to  architect embedded metadata into the EPR that
allows encoding alternative addresses for each protocol - somehow using the
address field as a logical address in this case. This is a possible use
case of the embedded metadata I was asked to rationalize and a possible
alternative for  this issue.  Comments?

Paco



                                                                                                                                               
                      "Vinoski, Stephen"                                                                                                       
                      <Steve.Vinoski@iona.com>        To:       "David Orchard" <dorchard@bea.com>, "Martin Gudgin" <mgudgin@microsoft.com>,   
                      Sent by:                         "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>, <public-ws-addressing@w3.org>        
                      public-ws-addressing-req        cc:       "Newcomer, Eric" <Eric.Newcomer@iona.com>                                      
                      uest@w3.org                     Subject:  RE: WS-A Issue 28 - Multiple ports needed in an EPR                            
                                                                                                                                               
                                                                                                                                               
                      11/06/2004 04:54 PM                                                                                                      
                                                                                                                                               




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
             -------------------------------------------------------
             IONA Technologies
             200 West Street Waltham, MA 02451 USA
             Tel: (781) 902-8265
             Fax: (781) 902-8001
             -------------------------------------------------------
             Making Software Work Together TM




graycol.gif
(image/gif attachment: graycol.gif)

ecblank.gif
(image/gif attachment: ecblank.gif)

pic10825.gif
(image/gif attachment: pic10825.gif)

Received on Sunday, 7 November 2004 04:28:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT