Re: [asap] Re: rough draft using ws-addressing

[John Fuller <jfuller@wernervas.com>]

On Dec 10, 2004, at 1:49 PM, John Fuller wrote:

> On Dec 10, 2004, at 11:15 AM, Keith Swenson wrote:
>
> > Thanks John for incorporating the WS-Addressing things. 
> >
> > One of the design goals of ASAP was that an observer has a single address.  The idea is that a by storing a single address, you have everything you need.  "observers" can register to receive events, but this is for a single address for each observer, not a separate address for errors.   WS-Addressing outlines ways to send three addresses, but does not define very well what they are. 
> >
> >  wsa:ReplyTo - this is the address of the observer.  It MUST be included in any message that requires a response (and I think all of our messages require responses).  I think we should simply state that an ASAP compliant implementation MUST include a Reply-To in the header.
>
> Observers and requestors are different things.  We could say we should always say who to respond to, but so far we've said one need
> not necessarily identify the observers for subsequent exchanges.
>
> 1) Not all message sources/response sinks are observers
> We have defined requests and corresponding responses for different roles.
> The instance role, for example, makes "requests" to indicate state change and completion.
> 2) In the case of a create instance request, we'd want to reply-to the observer because that's the role that initiates the request,
> however the Observer key we pass in the message body is optional.
>
> > wsa:From - This is not well defined.  I would like to state that implementations of ASAP MUST ignore this header, and MUST NOT include it in any message.  In the response header, it is the "ReplyTo" that is required.  Note the subtle distinction: there is is no guarantee that you can send a message to the "From" address, which is why it is more or less useless.
>
> When an instance reports a state change, then, the way we know which instance is in the ReplyTo instead of the From?
> Admittedly that's where we'd send the response, I guess, but it seems like From would make it semantically more clear.
>
> > wsa:FaultTo - Similarly, I would like to discourage this optional field.  We specify that errors are included in a response, and they must go back to the source (replyto) address.  The point is that the ASAP pattern has well defined resources, and there is no other well defined resource to which errors might be sent.  ASAP implementation do NOT need to remember this address.  The single ReplyTo address is all that needs to be recorded.  It is possible that for any given particular exchange, FaultTo could be used for that given exchange if there is a message, but there is no real need for this, and it adds complications to the implementations.  I would rather state that an ASAP compliant implementation MUST NOT use this header when sending, so that implementation never need to have the added logic to handle it.
> >
> > as for the other header fields: 
> >
> > wsa:To - there is discussion over whether this will be required or not.  For ASAP, I feel this should be REQUIRED so that all implementations can count on it being there, incase the transport does not provide complete addressing.  An example is SMTP which has restrictive rules about addressing, but the address in the To field might be longer and include "query parameters" needed to identify the instance.
> >
> > wsa:Action - this is a fixed value for each of our defined operations.  I don't care too much whether this is required or not.  I think it is completely redundant, because the fist tag within the body is exactly the same thing.  In fact, this value will be the exactly the same as combining the namespace url and the first tag within the body.  We should argue that this is unnecessary and redundant.  But if WS Addressing ends up deciding to make this required, then we should conform.
> We did just fine without it, I agree.   If the semantics were defined through predefined URIs that included the roles,
> it could open up some implementation options to know what type of object you might be making way up front in the headers
> and could avoid the ambiguity implementation issue I ran into dispatching off method for GetProperties.
> (Ex: are you talking to the factory or the instance when you've got the same method name and same network endpoint?
> I ended up inspecting the URI and overwriting the representation of the method
> )

To clarify the point, some of our early request-response SOAP/HTTP bindings in the 0.9 wsdl 
had soapAction's like that read 

> <wsd:operation name="GetProperties">
> <soap:operation
>
> soapAction="http://www.oasis-open.org/asap/0.9/asap/factory/GetProperties"/>
> <wsd:input message="asdl:getPropertiesRequest">
> <soap:body parts="body" use="literal"/>
> <soap:header message="asdl:getPropertiesRequest" part="head" use="literal"/>
> </wsd:input>
> <wsd:output message="asdl:getPropertiesResponse">
> <soap:body parts="body" use="literal"/>
> <soap:header message="asdl:getPropertiesResponse" part="head" use="literal"/>
> </wsd:output>
> </wsd:operation>
:
:
Now of course the header part would be different, but the soapAction distinguished instance from factory from observer.

> > comments? 
>
> Also, I went with the 08/2004 submission because WSRF and WSDM went with that one,
> though admittedly 12/08/2004 three specs came out that may look more like what we end up with eventually.
>
> > Keith D Swenson, < kswenson at us . fujitsu . com > 
> > Fujitsu Software Corporation 
> > 1250 E. Arques Avenue, Sunnyvale, CA 94085 
> > (408) 746-6276 mobile: (408) 859-1005 
> >
> >
> >
> >
> > > -----Original Message----- 
> > > From: John Fuller [mailto:jfuller@wernervas.com] 
> > > Sent: Thursday, December 09, 2004 1:46 PM 
> > > To: ASAP 
> > > Subject: [asap] Re: rough draft using ws-addressing 
> > > 
> > > 
> > > 
> > >