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

The point is, you have a choice. If you want multiple business cards, that's fine, and if I want only a single one, that's fine too. You wouldn't want to be forced to have only a single business card with all possible means of contacting you listed on it just because someone decided that all business cards shall provide multiple means of contact. Similarly, I don't want to be forced to use multiple business cards just because someone decided a business card shall list only a single means of contact.
 
Also, I'm not talking about just SMTP and HTTP. That's way too simple. How about a service with both a SOAP binding and a CORBA binding? Or one with a CORBA binding, a Tuxedo binding, and an MQ Series binding? Our customers have such services in production today. In our world, multi-protocol multi-format applications are pretty much commonplace -- this is pure reality in the brownfield integration world -- and for communication mechanisms that differ as much as these do, different addresses are absolutely required. I invite you to read [1] to get a better feel for what I'm talking about.
 
Note that your approach of requiring multiple EPRs to represent multiple mechanisms just pushes the problem to a place that's way harder to deal with, because it requires higher levels to always be prepared to handle multiple EPRs where instead they might expect only a single one. This WG cannot control that, but it can certainly control whether or not a single EPR can represent multiple mechanisms.
 
I see that in another email Sanjiva has suggested ways of doing this -- I will need to study that in more detail.
 
--steve
 
[1] http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Integration_With_Web_Services.pdf

-----Original Message-----
From: Martin Gudgin [mailto:mgudgin@microsoft.com]
Sent: Saturday, November 06, 2004 5:15 AM
To: Vinoski, Stephen; Bergersen, Rebecca; public-ws-addressing@w3.org
Cc: Newcomer, Eric
Subject: RE: WS-A Issue 28 - Multiple ports needed in an EPR


Steve,
 
I didn't mean to imply that all services would only be accessible via a single mechanism, just that if I only tell you about one mechanism then you only have that one mechanism. If my service is available via multiple mechanisms I might indicate that by giving you multiple EPRs. That said, I'm unconvinced that just because I'm available over SMTP and HTTP that I'd actually provide two addresses. Whether I send a letter via Royal Mail or FedEx I write the same address on the envelope.
 
And I often wish I had multiple different business cards. One of which would ONLY have my home page on it, because I don't *ALWAYS* want to give someone my phone number. 
 
Gudge (off to order a several sets of business cards)
 
  _____  

From: Vinoski, Stephen [mailto:Steve.Vinoski@iona.com] 
Sent: 05 November 2004 21:50
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
 <mailto:rebecca.bergersen@iona.com> 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