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

Hi,
   I had a discussion with Mark Nottingham this week in which we were 
discussing whether this working group had much of anything to do with 
making architectural decisions for the web community. I argue it does 
and it is fundamental. Furthermore this discussion is an example of 
having to make that kind of decision.
   I think this exchange is a symptom of this community never having 
actually come to an agreement on defining exactly what is meant by a 
"web service", a "web service instance", etc. --Pretty fundamental 
architectural issues IMO.

   If I have a web service (whatever that really is) that is going to 
accept a soap message delivered to it via SMTP on port (is it?) 23, 
HTTP on port 80, HTTPS on port 8080, or <fill in your favorite 
protocol> on port nnnn. How many web services are there? How many 
web-service-addresses (aka EPRs) should there be. Gudge's argument is 
that it is "obvious" that i would have 4 different web service 
addresses.  Rebecca/Steve are arguing i could have one web service 
address which different instructions (bindings?) for delivering 
messages to that service, and the client chooses. (Just like i have one 
real world address that i use for snail mail, fed ex, ups, and the 
grocery store delivery person. But we are often told to send me the 
message using fedex.)

I don't think this is "just syntax" and/or an efficiency trade-off. In 
the latter case its pretty clear to me that there is one web service -- 
just different ways to get to it. But there is no confusion about how 
many. In the former case, we have to consider the thorny identity 
issue. For example, how does a client which receives the different EPRs 
supposed to figure out that they are just different ways to get to same 
thing?

Making these kinds of choices mean making fundamental architectural 
choices, regardless of whether folks would like to pretend otherwise.

     cheers,
      jeff



On Nov 04, 2004, at 11:34 AM, Martin Gudgin wrote:

> 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
>
--
Jeff Mischkinsky					jeff.mischkinsky@oracle.com
Director, Web Services Standards		+1(650)506-1975
Consulting Member Technical Staff	500 Oracle Parkway, M/S 4OP9
Oracle Corporation					Redwood Shores, CA 94065

Received on Saturday, 6 November 2004 04:07:51 UTC