OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bindings] [Issue 2] Version 2: How to implement SCA callbacksusing 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.
> 
> 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?

> 
> 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
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]