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: Mon, 8 Nov 2004 11:55:50 -0500
To: "Vinoski, Stephen" <Steve.Vinoski@iona.com>
Cc: "David Orchard" <dorchard@bea.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, public-ws-addressing@w3.org, "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>
Message-ID: <OF6558FED4.0B6D11ED-ON85256F45.00741565-85256F46.005D0147@us.ibm.com>




I agree the spec is not clear about how to do this.

Paco



                                                                                                                                        
                      "Vinoski,                                                                                                         
                      Stephen"                 To:       Francisco Curbera/Watson/IBM@IBMUS                                             
                      <Steve.Vinoski@io        cc:       "David Orchard" <dorchard@bea.com>, "Newcomer, Eric" <Eric.Newcomer@iona.com>, 
                      na.com>                   <public-ws-addressing@w3.org>, "Bergersen, Rebecca" <Rebecca.Bergersen@iona.com>        
                                               Subject:  RE: WS-A Issue 28 - Multiple ports needed in an EPR                            
                      11/06/2004 11:56                                                                                                  
                      PM                                                                                                                
                                                                                                                                        




Hi Paco,

I'm aware of the specification's words regarding "logical addresses." I
just don't think it's very clear in this regard, which is why I'm asking
the questions I'm asking. We cannot live without some form of multi-address
EPR. If the current EPR can already do that, as Sanjiva, Dave, and now you
have suggested, then let's augment the spec to make it clear how that is
supposed to work.

thanks,
--steve
      -----Original Message-----
      From: Paco Curbera, Francisco
      Sent: Saturday, November 06, 2004 11:28 PM
      To: Vinoski, Stephen
      Cc: David Orchard; Newcomer, Eric; Martin Gudgin;
      public-ws-addressing@w3.org; public-ws-addressing-request@w3.org;
      Bergersen, Rebecca
      Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR



      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

      (Embedded image moved to file: pic17296.gif)Inactive hide details for
      "Vinoski, Stephen" <Steve.Vinoski@iona.com>"Vinoski, Stephen"
      <Steve.Vinoski@iona.com>

                                                                           
 (Emb (Embedded image moved to file:   (Embedded image moved to file:      
 edde pic29301.gif)                    pic26460.gif)                       
 d                            "Vinoski                                     
 imag                         ,        To: "David Orchard"                 
 e                            Stephen" <dorchard@bea.com>, "Martin Gudgin" 
 move                         <Steve.V <mgudgin@microsoft.com>,            
 d to                         inoski@i "Bergersen, Rebecca"                
 file                         ona.com> <Rebecca.Bergersen@iona.com>,       
 :                            Sent by: <public-ws-addressing@w3.org>       
 pic0                         public-w cc: "Newcomer, Eric"                
 2689                         s-addres <Eric.Newcomer@iona.com>            
 .gif                         sing-req Subject: RE: WS-A Issue 28 -        
 )                            uest@w3. Multiple ports needed in an EPR     
                              org                                          
                                                                           
                                                                           
                              11/06/20                                     
                              04 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


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

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

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

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

Received on Monday, 8 November 2004 16:56:39 GMT

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