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
			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