RE: [ws-caf] Mt Everest and WS-CF

["Jan Alexander" <alex@systinet.com>]

> -----Original Message-----
> From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
> Sent: Friday, May 28, 2004 4:08 PM
> To: Jan Alexander
> Cc: 'Mark Little'; 'Furniss, Peter'; 'Green, Alastair J.'; 'ws-caf'
> Subject: Re: [ws-caf] Mt Everest and WS-CF
> 
> 
> 
> Jan Alexander wrote:
> 
> >WS-Addressing does not place context into the address. What 
> it does, it 
> >uses set of SOAP headers to identify execution context for the 
> >particular "Endpoint" by introducing EndpointReference 
> abstraction. The 
> >EndpointReference itself additionally contains logical 
> address of the 
> >endpoint and a set of policies, which are relevant to the 
> use of that EndpointReference.
> > 
> >It is important to distinguish between a service address and 
> a service 
> >instance identifier. The first is similar to for instance IP 
> addresses 
> >and port number, the second to CORBA IOR. I don't see 
> anything against 
> >"SOA principles" in the EndpointReference concept as it is 
> not just a 
> >service address.
> >
> I guess it depends if you see equivalence between SOA and 
> distributed objects; I can say unequivocally that I do not. 
> In the web services model, we talk about services and their 
> capabilities, not object pointers. But that's probably a 
> topic for another TC...
> 

I wasn't drawing an equivalence between Web Services and distributed objects,
I was just trying to point out, that the EndpointReference is something more
than a transport address of the service. Similarly as IOR is more than only IP
address and TCP port number. I've probably chosen a bad analogy. Of course it
depends on what kind of extra data are you bundling with the transport
address. 

I agree that for example WS-RF is going in the direction very similar to the
object keys in CORBA IOR and that it might or might not be in-line with "SOA
principles", depending on how do you perceive this buzzword :-).

> 
> > I agree that it would be useful to use WS-Context for mapping 
> >EndpointReferenceProperties into SOAP headers as they identify the 
> >execution context of the endpoint.
> > 
> >Jan
> >
> >
> >  _____
> >
> >From: Mark Little [mailto:mark.little@arjuna.com]
> >Sent: Friday, May 28, 2004 11:25 AM
> >To: Greg Pavlik; Furniss, Peter
> >Cc: Green, Alastair J.; ws-caf
> >Subject: Re: [ws-caf] Mt Everest and WS-CF
> >
> >
> >+1.
> > 
> >I'd also like to suggest that context embedded in an address isn't 
> >really the right way to go. Despite the fact that we (Jim, Savas, 
> >myself and others) have suggested that ReferenceProperties 
> *could* use 
> >WS-Context, that doesn't necessarily mean that it's the best way of 
> >tackling the problem. Suggesting that context within an 
> address is the right model is ignoring SOA principles.
> > 
> >Mark.
> >
> >----- Original Message -----
> >From: Greg  <mailto:greg.pavlik@oracle.com> Pavlik
> >To: Furniss, Peter <mailto:Peter.Furniss@choreology.com>
> >Cc: Green, Alastair J. 
> <mailto:Alastair.Green@choreology.com>  ; Mark 
> ><mailto:mark.little@arjuna.com> Little ; ws-caf 
> ><mailto:ws-caf@lists.oasis-open.org>
> >Sent: Thursday, May 27, 2004 3:56 PM
> >Subject: Re: [ws-caf] Mt Everest and WS-CF
> >
> >
> >
> >Furniss, Peter wrote:
> >
> >
> >Greg,
> >
> >
> >
> ><snip the earlier part of the alastair .. thread>
> >
> >
> >
> >  
> >
> >A further comment on the IBM/MS product specs: there are in
> >
> >fact three
> >
> >contextualization mechanisms: one in WS-Coordination, one in
> >
> >WS-ReliableMessaging, and one in WS-Addressing. Putting aside
> >
> >WS-Addressing for a moment since it introduces a new model to the web
> >
> >services environment that I don't want to argue about here, let me
> >
> >observe that there is no fundamental distinction between the
> >
> >lifecycle
> >
> >control interface in WS-Coordination and WS-ReliableMessaging. Why
> >
> >shouldn't these be based on a common model? Wouldn't that in fact be
> >
> >simpler and less error prone? From there, it seems a small step to
> >
> >imagine the reliability and coordination/transaction contexts
> >
> >having a
> >
> >common root. I submit that this is in fact a flaw, not a strength, of
> >
> >the specification set; they they are unnecessarily complex due to the
> >
> >failure to deal with common constructs, idioms and patterns as, well,
> >
> >things-in-common.
> >
> >
> >
> >    
> >
> >
> >
> >Well the WS-Coordination and WS-RM both have equivalent of "begin".
> >
> >WS-RM doesn't always use it,
> >
> >and when it is used, it is asked of the eventual receiver. The
> >
> >termination sequences are different, since WS-RM is just 
> stopping, and
> >
> >WS-Coordination will have delegated to a transaction protocol. 
> >
> >
> >
> >As contextualization, it is true that a message carrying the relevant
> >
> >headers is "in the context" of those headers, and subject to their
> >
> >implications. But the same is true of more or less any 
> header - that's
> >
> >what they're for. WS-Addressing is particularly interesting 
> because it
> >
> >is essentially "opaque context" - the reference properties 
> don't need 
> >to
> >
> >contain any kind of identifier in the ws-context sense at 
> all (it might
> >
> >tell the receiver which database to look in, but since only the 
> >receiver
> >
> >knows what they meant, that's fine - it's just a piece of syntactic
> >
> >partitioning of the address)
> >
> >Is it fine? What if it happens to conflict with another header since 
> >there are no restrictions? I'd like to suggest that 
> WS-Addressing would 
> >benefit from a container and that this is generally a problem for 
> >contextualization based solely on headers.
> >
> >
> >
> >. The other two would have an identifier but
> >
> >that's the only thing they share, I think.
> >
> >
> >
> >Peter
> >
> >  
> >
> >
> >  
> >
> 
>