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

[Greg Pavlik <greg.pavlik@oracle.com>]

Jan, may I suggest also that you look at: 
http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/

Jan Alexander wrote:

>So if I understand this correctly, your original comment was not about
>WS-Addressing at all, since WS-Addressing does not place context related
>information within an address. The other question is, whether the concept of
>the EndpointReference (encapsulation of the address and other endpoint
>instance related information), as defined by WS-Addressing, is appropriate for
>Web Services. Is it right? 
> 
>From my experience with Web Services, having only a transport address of the
>endpoint is not always enough to be able to communicate with the service - I'm
>not talking about message formats here, you have to know them too of course .
>It is helpful to have a mechanism to embed additional properties (like
>policies) to the particular web service instance reference, that, as you said,
>shouldn't be placed inside the original Web Service endpoint address. Such a
>endpoint reference can then be placed into a WSDL describing that particular
>web service instance instead of the transport address of the endpoint.
>Unfortunately this cannot be easily accomplished using WSDL 1.1. This is not
>about WS-RF, which is going a lot of further and is defining concept of
>resource and association between the resource and the service, which executes
>in the resource context. I agree, that this is rather a questionable thing to
>do in Web Services environment in general.
> 
>Jan
>
>
>  _____  
>
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: Friday, May 28, 2004 11:53 AM
>To: Jan Alexander; 'Greg Pavlik'; 'Furniss, Peter'
>Cc: 'Green, Alastair J.'; 'ws-caf'
>Subject: Re: [ws-caf] Mt Everest and WS-CF
>
>
>Jan, I hope you didn't think I was suggesting that WS-Addressing does place
>context into the address, but rather commenting on 'WS-Addressing is
>particularly interesting because it is essentially "opaque context"' As I
>said, context shouldn't be within an address.
> 
>However, it's a different argument as to whether the use of
>ReferenceProperties to create the equivalent of an IOR
>(ReferenceProperties==Object Key) is a good thing. If you read the recent
>paper on WSJ comparing WS-Context with WS-RF I think you'll see the argument
>against in a much stronger way than I have time to write in this email.
> 
>Mark.
>
>----- Original Message ----- 
>From: Jan Alexander <mailto:alex@systinet.com>  
>To: 'Mark Little' <mailto:mark.little@arjuna.com>  ; 'Greg
><mailto:greg.pavlik@oracle.com> Pavlik' ; 'Furniss, Peter'
><mailto:Peter.Furniss@choreology.com>  
>Cc: 'Green, Alastair J.' <mailto:Alastair.Green@choreology.com>  ; 'ws-caf'
><mailto:ws-caf@lists.oasis-open.org>  
>Sent: Friday, May 28, 2004 10:42 AM
>Subject: RE: [ws-caf] Mt Everest and WS-CF
>
>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 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 Pavlik <mailto:greg.pavlik@oracle.com>  
>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
>
>  
>
>
>  
>