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

 

> -----Original Message-----
> From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com] 
> Sent: 06 November 2004 02:19
> To: Martin Gudgin
> Cc: Bergersen, Rebecca; Vinoski, Stephen; 
> public-ws-addressing@w3.org; Newcomer, Eric
> Subject: 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. 

I'd argue that we should try to make the minimum number of such decisions necessary.

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

I disagree. I believe in constrained agreement; Send messages here. Make sure the messages look like this. If you do this, I'll send you messages that look like that.

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

No, that's not Gudge's argument. Gudge's argument is that having 4 different addresses is *ONE* way to skin that cat. I believe that people will want to design systems in different ways, and that our spec should accommodate that.

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

I think the spec is clear that if [address] and [ref props] of two EPRs are the same, then the behaviour of those two endpoints is the same. It doesn't say anything about 'identity'. I don't think the identity issue is something that WS-Addressing necessarily needs to solve. And I'm not yet convinced there is one right answer. Again, I think our spec should allow people to build systems with different notions of identity.

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

I agree that some architectural choices need to be made. But I don't think this WG gets to make them. I think the designer/architect/programmer of the web service gets to make them. We should be enabling people to build systems using all sorts of different architectures, not constraining people to a fixed set of choices.

Gudge

> 
>      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 10:32:14 UTC