sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-bindings] How to implement SCA callbacks using SOAP -- proposalfor focusing discussion
- From: Simon Nash <NASH@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Thu, 24 Jul 2008 12:25:24 +0100
I have thought some more about whether
the per-call identity (if any) should be passed in an EPR reference parameter,
or whether the messageID should be used.
In the F2F discussion, we identified
a difficulty with using a reference parameter if this ID were used as a
conversation ID passed by the client that the service provider would need
to interpret. Since the provider could not parse reference parameters
that the client had created, the provider could not extract the conversation
ID from other reference parameters that might be present, so that it could
do a reliable comparison.
This difficulty can be solved by having
the conversation ID (if any) be generated by the provider and passed to
the client in reference parameters for the service EPR. The callback
ID (if any) would be generated by the client and passed to the provider
in reference parameters for the client callback EPR.
This works as long as both of the following
are true, which I believe is the case:
1. The provider never needs to look
at the client callback ID. It just needs to return it back to the
client when calling back to the client EPR.
2. The client never needs to look at
the provider conversation ID. It just needs to pass it back to the
provider when calling the provider EPR to initiate or continue a conversation.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
Mike Edwards/UK/IBM@IBMGB
21/07/2008 10:45
|
To
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
cc
|
|
Subject
| Re: [sca-bindings] How to implement
SCA callbacks using SOAP -- proposal for focusing discussion |
|
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
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]