Re: [asap] review of WS-Addressing

[John Fuller <jfuller@wernervas.com>]

The revision here was to the November draft.  Attached is the December 
draft that
was uploaded to our site.  One difference is there is a lot more 
discussion in the
December draft about ListInstances and filtering ideas, and there are 
more references
because of this.  I believe that the schema and wsdl in the December draft
validate.

Once WSA is finalized we'll need to change the schema, examples and 
references
to refer to the new namespace instead of the 200408 document.


Keith Swenson wrote:

> At long last, the WS-Addressing specification is availble for final 
> review.  It has been broken into three pieces: Core, SOAP, and WSDL.  
> The core piece is the critical one.  It is clear and succinct. It 
> defines two things: an EPR (end point reference) and a some header 
> elements to be used to address the message.
>  
> First of all, in February all references to "URL" or "URI" were 
> replaced with a new acronym "IRI".  The IRI is clearly very similar to 
> a URL/URI but it has some international extensions, and possible some 
> vague points clarified.  Seems we will need to make the same change in 
> the ASAP spec.
>  
> The EPR is a way to refer to a web service instance.  It is a 
> structure to be passed around from one web service to a second web 
> service in order to deliver the address of the first or possible a 
> third web service.  The EPR definintion shows the effect of political 
> fight between parties that have a vested interest in particular 
> implementation, and as such it shows a certain amount of "overkill" 
> for our situation.  But the extra parts are optional, so for the most 
> part can be ignored.  Here are the parts of an EPR:
>  
> <Address> - this carries the IRI (essentially the URI or URL) of the 
> service endpoint.  This is the only part that ASAP needs.
>  
> <ReferenceParameters> - this is needed by some legacy protocols where 
> the address does not in itself address the actual web service.  The 
> example is given where where a service needs a "shopping cart id" and 
> a "customer id" in order to address the web service.  The position of 
> ASAP & WfXML has always been that these can be encoded into the 
> address using URL parameters. 

(It could also be passed in a WS-Context.)

> This is allowed under WS-Addressing ... there is no limitation on the 
> address.  So, as far as I can conclude, the reference parameters as 
> essentially a legacy appendage to allow WS-Addressing to remain 
> compatible with older implementation.  Since ASAP is a new protocol, 
> and all implementations are new, and because reference parameters are 
> optional dependent upon the protocol, we should take the position that 
> reference paramters MUST NOT be used in ASAP exchanges.  There is no 
> need for them, and to clarify implementation decisions they should be 
> prohibited from ASAP implementations. 
>  
> <Metadata> - this optional tag is not needed by the ASAP protocol, but 
> there is a potential use in service instance migration when we get 
> around to it.
>  
> Then there are the tags for implementing the actual addressing. 
>  
> <To> this required tag carries the address part of the EPR. (and not 
> the entire EPR which would be more logical).  It serves the same 
> purpose as the former ASAP ReceiverKey tag. 
>  
> <ReplyTo> carries an EPR.  This is optional, but it is required if 
> there is to be a response.  Since every ASAP exchange involves a 
> response, this is effectively required.  It carries the address that 
> the response will go back to.  This is meaningless in the case of HTTP 
> where the response is sent back over the same connection that the 
> request was sent on.  There is, in fact, a special defined 'anonymous' 
> value that can be used in this case if you wish.  This serves the same 
> purpose as the former ASAP SenderKey tag.
>  
> <FaultTo> is an optional field to carry an EPR that error should 
> be sent to.  This sound more like someone's pet feature than a good 
> programming principle.  It is not clear that sending fault messages to 
> a different place is a good idea.  Nevertheless someone wanted this 
> flexibility.  ASAP requires that every request gets a response, and 
> that response is either the successful completion of the operation, or 
> a fault message.  Therefor, implementations of the ASAP protocol MUST 
> NOT specify a different fault address from the ReplyTo address, which 
> means that FaultTo should not be used.
>  
> <Action> - this is a required tag for protocols where the the first 
> tag in the body does not necessarily distinguish the operation.  The 
> value here is a unique identifier of the operation.  For ASAP 
> protocol, each operation has a unique tag in the body that 
> distinguishes it.  In this case the value of the action 
> parameter should be the URL that is the namespace URL combined with 
> the name of the body tag, but the spec says that the WSDL can override 
> this convention and specify any unique IRI.   For ASAP this is 
> redundant, but the WS-Addressing requires it.
>  
> <MessageId> - this is a unique id for the message.  It is required 
> whenever there is a response message, and since ASAP always involves a 
> response message, the message ID is required.  This replaces the 
> former ASAP RequestId tag.
>  
> <RelatesTo> - if this message is a reply message, this tag carries the 
> message id of the original message.   This replaces the ASAP former 
> RequestId tag, when it is in a response message.  This tag has an 
> optional parameter to tell what kind of relationship, but the only 
> relationship needed by ASAP is that of a response, and for this case 
> the attribute can be omitted.
>  
> <From> - the meaning of this optional EPR is not defined.  You can't 
> send a message to it, and it is not a secure field for authentication 
> purposes.  ASAP protocol does not need a from field.  It is STRONGLY 
> RECOMMENDED that implementations of ASAP omit this tag, and ignore the 
> tag if received.
>  
> (reference parameters) - any reference parameters from the EPR are 
> then placed in the header of the message.  As mentioned earlier, 
> reference parameters MUST NOT be used.
>  
> Backward compatibility.  Since we have a couple of implementations out 
> there, for maximum interoperability, one should implement the 
> following optional upgrade procedures.  The former ASAP tags are 
> considered "deprecated", and are to be replaced by another "new" tag.  
> When sending message, both the deprecated and the replacement tag 
> should be included.  The header is allowed to contain any amount of 
> additional tags, so this should not cause any problems.  Upon receipt 
> of a message, if the new tag is present, it takes precidence, and the 
> corresponding deprecated tag must be ignored.  If the new tag is 
> missing, but the corresponding deprecated tag is present, then the 
> value should be received from the deprecated tag.
>  
> _New Tag_            _Deprecated Tag_
> <To>                <ReceiverKey>   Both carry IRI addresses
> <ReplyTo>        <SenderKey>    Deprecated carries just address, while 
> new tag carries EPR.
> <MessageId>    <RequestId>  (in request messages)
> <RelatesTo>     <RequestId>  (in a response message)
>  
> The second specification is the "Binding to SOAP" which brings in some 
> additional requirements when addressing SOAP messages.  Some further 
> research is needed because it is not clear to me what the impact of 
> this spec is.
>  
> A read through the 2a version of the ASAP spec, I see these action items:
>
>     * Change URL/URI to IRI.  Research whether this should be done
>       across the board, or whether it applies only to certain situations.
>     * Discuss the proactive positions described above.  If people
>       agree, the change descriptions to discourage use of FaultTo and
>       From.  Make a definition of how the Action tag should be filled in.
>     * Response message uses From as the address of the originally
>       requested server.  Does it make more sense to use ReplyTo?
>     * What about the old ResponseRequired tag?  Do we want to continue
>       with this, or drop it?
>     * Add a small section on backward compatibility.
>
> I have made an initial pass as modifying the document, a PDF showing 
> changes is attached.  (I am not 100% sure I started with John's latest 
> version, so need to chack that.)  This should just about do it.  I 
> don't see any reason why we can't get an updated new version into 
> Committee Draft status, why we can not move forward with getting this 
> through the OASIS process to an actual standard.
>  
> -Keith
>
> Keith D Swenson,_ __kswenson@us.fujitsu.com_
> Fujitsu Software Corporation
> 1250 E. Arques Avenue, Sunnyvale, CA 94085
> (408) 746-6276 mobile: (408) 859-1005
>
>

wd-asap-spec-02b-2.doc