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