Re: [sca-bindings] [Issue 2] Version 2: How to implement SCA callbacksusing SOAP -- a proposal

[Mike Edwards <mike_edwards@uk.ibm.com>]

Anish,

Some comments inline marked <mje>
 </mje>

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	David Booz <booz@us.ibm.com>
Cc:	sca-bindings@lists.oasis-open.org
Date:	11/09/2008 08:08
Subject:	Re: [sca-bindings] [Issue 2] Version 2: How to implement SCA callbacks using SOAP -- a proposal

---

David Booz wrote:
> I couldn't make the F2F due to a vacation, so I'm sorry if I'm treading
> over old territory. I have two questions.
> 
> 1) Anish said:
> <snip>
> it now says "... callback EPR obtained from *a* request message
..."
> 
> Wouldn't it be better to use the word 'any' since that is really what
> you seem to mean? It would look like this:
> When the service wants to invoke the callback interface, it utilizes
the 
> Callback EPR obtained from the any request message, as specified in
step 
> 1, that invoked the forward interface.
> 

I am beginning to think that perhaps the original 'the' was the right 
thing to say. The message-id and callback EPR gets picked up from a/any
request. The message-id from that request is what you are correlating to
in relates-to and therefore it is *the* request message that you are 
calling back on. Furthermore, you can't mix and match the callback EPR
and the message-id: they both must come from the same request message.
<mje> Using "the"
without explanation would almost certainly be confusing. Adding in
some of the stuff from
your reply above would help.

The concern that I have
is that, in the case of a non-conversational service, how does
the provider even know
that two requests are from the "same" client.  This would
mean
in my opinion, that the
provider can only ever treat each request individually in that
case.  The business
data may give an indication of common provenance, but then
we are moving outside
the scope of the SCA specs.

For conversational services,
it is reasonable for the provider to presume that the
invocations all arise
from the same client.  In this case any response generated from
the provider could be
in reaction to any of the forward requests.  However, it is easier
and more consistent to
say that the provider must react to an individual request and 
make it clear that the
response is to a specfic request.

</mje>
> 
> 2) If a WS client gets a fault back because it failed to satisfy step1,
> what is there in the WSDL that the client developer can look at to
see 
> what he/she should have done?
> 

Excellent question. I had not thought of it when I wrote the email.
My thinking on this is:
The way we have structured callbacks in SCA, there is nothing in the 
individual interfaces (forward or the callback interfaces) that say that
they are involved in sca bidirectional interface. IOW, the individual 
interfaces could be used independent of callbacks as POI (plain-old 
interfaces).
So, as of now there is nothing required in the WSDL that would tell a 
user what went wrong in case of a fault. But if you look at the SCDL 
then you would know.

If we want to create something that can be included in WSDL to indicate
that a particular interface is a forward interface for sca bidirectional
interface, then we would have to ask the question is sca bidirectional
interface syntax optional? Would we have to have similar annotation for
Java?
<mje>
We do have an annotation
for Java interfaces:  @Callback
- this marks the forward
interface as having a callback interface, which is identified
by the annotation

We could provide a WSDL
equivalent of this annotation, with the annotation pointing
at some appropriate PortType
for the Callback interface.

</mje>

> 
> thanks
> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> Inactive hide details for Anish Karmarkar 
> <Anish.Karmarkar@oracle.com>Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 
> 
>                    
    *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
>                    
    08/21/2008 11:00 PM
> 
>                  
> 
> To
>                  
> OASIS Bindings <sca-bindings@lists.oasis-open.org>
> 
> cc
>                  
> 
> Subject
>                  
> [sca-bindings] [Issue 2] Version 2: How to implement SCA callbacks
using 
> SOAP -- a proposal
> 
>                  
> 
> 
> I took an action at the f2f to update the proposal that I had sent
out 
> [1] based on the feedback received during the f2f and the mailing
list.
> Based on the feedback, I have made two changes: a) changed the case
of 
> 'must' and b) instead of saying "... callback EPR obtained from
*the* 
> request message ...", it now says "... callback EPR obtained
from *a* 
> request message ..."
> 
> V2 does not the incorporate the comments/feedback for which there
wasn't 
> an agreement.
> 
> -Anish
> --
> 
> [1] _http://lists.oasis-open.org/archives/sca-bindings/200807/msg00027.html_
> *
> Proposal v2:*
> 1) Every request message that invokes the forward interface MAY contain
> the wsa:From SOAP header block. The wsa:From header block, if present,
> specifies the Callback EPR. If wsa:From header block is not present,
> then the wsa:ReplyTo, if present, specifies the Callback EPR. If neither
> wsa:From nor wsa:ReplyTo are present in the request message of the
> forward interface, the service MUST generate a SOAP Fault.
> 
> 2) Every request message that invokes the forward interface MUST contain
> the wsa:MessageID SOAP header block. If a request message that invokes
> the forward interface does not contain the wsa:MessageID then the
> service must MUST generate a SOAP Fault.
> 
> 3) When the service wants to invoke the callback interface, it utilizes
> the Callback EPR obtained from the a request message, as specified
in 
> step 1, that invoked the forward interface. Once the Callback EPR
is 
> selected, the service MUST follow the rules defined in WS-Addressing
1.0 
> section 3.3 to invoke operations on the callback interface. In addition,
> when the service invokes the callback interface, it MUST include a
> wsa:RelatesTo SOAP header block. The wsa:RelatesTo SOAP header block
> MUST have the relationship type value of 
> _"http://docs.oasis-open.org/opencsa/sca-bindings/callback"_
and the 
> related message id is the wsa:MessageID of the message from which
the 
> Callback EPR was obtained.
> *
> Scenarios:*
> S: service with a bidirectional interface
> R: reference connected to service S
> 
> The wire binding (in both directions) uses SOAP.
> 
> The forward interface consists of only one one-way operation: YouRIt()
> The callback interface consists of only one one-way operation: NoYouRIt()
> 
> R invokes YouRIt(). Let's call this invocation R1 and it sets the
> callback address to RC1. S then calls NoYouRIt() twice: S1 and S2
> R invokes YouRIt() again. Let's call this invocation R2 and it sets
the 
> callback address to RC1. S then calls NoYouRIt() once: S3
> R invokes YouRIt(). Let's call this invocation R3 and it sets the
> callback address to RC2. S then calls NoYouRIt() twice: S4 and S5.
> *
> Wire messages:*
> R1:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:From>
> <wsa:Address>_http://example.com/callback_</wsa:Address>
> <wsa:ReferenceProperties>
> <myNS:SomeID>1</myNS:SomeID>
> </wsa:ReferenceProperties>
> </wsa:From>
> <wsa:MessageID>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6</wsa:messageID>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> S1, S2:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:To>_http://example.com/callback_</wsa:To>
> <myNS:SomeID>1</myNS:SomeID>
> <wsa:RelatesTo 
> RelationshipType=_"http://docs.oasis-open.org/opencsa/sca-bindings/callback"_>
> urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
> </wsa:RelatesTo>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> R2:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:From>
> <wsa:Address>_http://example.com/callback_</wsa:Address>
> <wsa:ReferenceProperties>
> <myNS:SomeID>1</myNS:SomeID>
> </wsa:ReferenceProperties>
> </wsa:From>
> <wsa:MessageID>urn:uuid:f81d4fae-8dec-11d0-a765-00a0c91e6bf6</wsa:messageID>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> S3:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:To>_http://example.com/callback_</wsa:To>
> <myNS:SomeID>1</myNS:SomeID>
> <wsa:RelatesTo 
> RelationshipType=_"http://docs.oasis-open.org/opencsa/sca-bindings/callback"_>
> urn:uuid:f81d4fae-8dec-11d0-a765-00a0c91e6bf6
> </wsa:RelatesTo>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> R3:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:From>
> <wsa:Address>_http://example.com/callback-other_</wsa:Address>
> <wsa:ReferenceProperties>
> <myNS:SomeID>2</myNS:SomeID>
> </wsa:ReferenceProperties>
> </wsa:From>
> <wsa:MessageID>urn:uuid:f81d4fae-9dec-11d0-a765-00a0c91e6bf6</wsa:messageID>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> S4, S5:
> 
> <soap:Envelope ...>
> <soap:Header>
> <wsa:To>_http://example.com/callback-other_</wsa:To>
> <myNS:SomeID>2</myNS:SomeID>
> <wsa:RelatesTo 
> RelationshipType=_"http://docs.oasis-open.org/opencsa/sca-bindings/callback"_>
> urn:uuid:f81d4fae-9dec-11d0-a765-00a0c91e6bf6
> </wsa:RelatesTo>
> ...
> </soap:Header>
> <soap:Body>
> ...
> </soap:Body>
> </soap:Envelope>
> 
> 
> ---------------------------------------------------------------------
To 
> unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU