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