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



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








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