Re: [sca-bindings] How to implement SCA callbacks using SOAP -- proposalfor focusing discussion

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

Anish,

This is a good proposal and generated
a good debate at the F2F meeting last Friday.

In this email, I'd like to capture some
thoughts relating to the proposal:

1) First, there is the high level concept
of what is going on when there is a Bidirectional interface and a client
(reference) calls a service.

As Simon Nash discussed, the thinking
is that there is an EPR generated by the client, which represents the address
for the service to
call back.  Alongside the EPR is
an ID, which in principle can be different for each forward call that the
client makes to the service (whether
it is created for each forward call
and whether it has a different value for each successive forward call is
a decision that the client side code makes).

2) The first point in your proposal
is that the callback EPR is transmitted from the client to the service
provider in a SOAP header block.

In my opinion, it would be cleaner if
the EPR were ALWAYS transmitted in the wsa:From header.

If there is a need for optimisation
(to reduce the size of the forward message), then I suggest that it is
the wsa:ReplyTo header which could be absent,
with the wsa:From field providing the
value for any Request/Response meply message.

I believe that this arrangement is likely
to be less error prone.  It will be clear to the SCA runtime code
on each end of the wire what is expected, meanwhile
any non-SCA client code either gets
it right (ie fills in wsa:From) or it will get a straightforward error
- eg if the client code acts as if there is no callback and
only supplies a wsa:ReplyTo.

2) I have big doubts that wsa:MessageID
is a suitable place for the ID associated with the callback.

The problem here is that according to
the WSA specification, for the Message ID header: "When present, it
is the responsibility of the
sender to ensure that each message is
uniquely identified".

I read this to say that:
a) it is valid for a message not to
have a message ID
b) if there is a message ID, it must
be unique

[NB there is a section in the WSA specification
that indicates "In either of the above cases, if the related message
lacks a [message id] property, the processor
MUST fault." when sending a reply
message - which implies that there MUST be a  message ID field present
on the forward messages...]

- the uniqueness requirement is a problem
in that the ID envisaged for the client could in principle be the same
for a sequence of forward calls,
although it might be different for each
forward call.

I suppose that a unique message ID could
be minted for each forward message, which would then be translated by the
infrastructure code on the client to
a "client call ID" which may
or may not change from one forward message to the next, but this imposes
a burden on the client infrastructure code.

I note that in your examples below,
there is a reference parameter passed in the forward calls:  <myNS:SomeID/>
- this appears to have the form of the
"client call ID"

- was this intentional ?
- what did you intend this to be used
for?


I note that the use of a reference parameter
of this type is fine, except that it is supposed to be treated as an opaque
entity from the service provider
perspective and so cannot be used by
the service provider to test for anything.


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

Anish Karmarkar <Anish.Karmarkar@oracle.com>

18/07/2008 21:16

To	OASIS Bindings <sca-bindings@lists.oasis-open.org>
cc
Subject	[sca-bindings] How to implement SCA callbacks using SOAP -- proposal for focusing discussion

Here is a proposal for implementing SCA callbacks using
SOAP. This isn't totally new as there have been some discussion on this
before. It consists of proposal, scenarios and how the proposal would work
for the scenarios and how the messages would look on the wire.

Proposal:
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 generate a SOAP Fault.

3) When the service wants to invoke the callback interface, it utilizes
the Callback EPR obtained from the 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

---

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