ws-rx-implement message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx-implement] Queries on interop doc
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx-implement@lists.oasis-open.org
- Date: Wed, 8 Feb 2006 10:55:09 -0500
I'd like to suggest that we have two
variants for scenario 2.1:
1 - modify the echoString so that there
is an additional argument indicating whether or not it is the last message
in the echoString sequence - and then require this to be set to 'true'.
This will allow the RMD to know when it needs to shutdown the response
sequence.
2 - require that this new argument never
be set to 'true' and thus a terminate from the RMD back to the RMS should
never be sent - the response sequence should just timeout.
thanks,
-Doug
Matthew Lovett <MLOVETT@uk.ibm.com>
02/08/2006 06:14 AM
|
To
| ws-rx-implement@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [ws-rx-implement] Queries
on interop doc |
|
Hi all,
I think that Dan raised some interesting points here. Any of the other
implementors care to comment? My comments are inline....
Daniel Millwood/UK/IBM@IBMGB wrote on 06/02/2006 16:53:27:
>
>
>
>
> Hi all,
>
> A couple of queries on the interop doc.
>
> In scenario 2.1, it states that when the service has sent all of the
> replies and received all of the acknowledgements for those replies
it will
> send a TerminateSequence to the client. Given that the client
can send a
> varying number of requests (between 1 and 3 messages) to the service,
how
> is the service supposed to know when it can terminate the offered
sequence?
> Is it really expected to compare the number of inbound requests with
the
> number of outbound responses? This requires a relationship between
the two
> sequences that is not defined.
+1: The terminate from service to client seems to rely on the assumption
that the sequences are linked, which contradicts the main spec. This raises
questions about managing the lifetime of offered sequences, and how we
should handle them in an interoperable way.
Perhaps one option would be for the client to inform the server that the
sequence was now closed (e.g. send a sequence closed fault), and then terminate
it (send a sequence terminated fault). Of course, if the service were using
the sequence to carry some other messages to the client then the close
operation could lead to the service needing to allocate some messages back
into a new sequence... but it will work fine for most real-world cases.
>
> The clients terminateSequence message example is also missing from
this
> scenario.
+1
>
> Secondly,
>
> As the resolution of issue i090 on offered sequences has not been
resolved
> yet, I wanted to highlight the way in which offered sequences are
used in
> the proposed scenarios.
>
> Ive used the following notation to differentiate the client at the
RMS and
> the server at the RMD.
>
> RMS ------------ outbound sequence ------> RMD
> RRMD <------- offered sequence ------------ RRMS
>
> In scenario 2.1, where offer is used, the ReplyTo EPR in the CS message
> from the RMS is http://client-machine/RMreplies. The application
replies
> need to be sent to http://client-machine/replies. So in this
case, the
> offered sequence cannot be correlated against any EPR from the CS
message,
> so either a relationship is assumed between the outbound and offered
> sequences or some out-of-band exchange is required so the RRMS knows
which
> sequence to use.
>
This seems to be a symptom of offered sequences being underspecified. I
hope that we get to discuss this on the interop call, as discussion of
this specific case could lead into the issue discussion for i090 during
the main TC call.
> In scenario 2.2 where there is no offer, the CS message from the RRMS
to
> the RRMD is sent to the ReplyTo from the EchoString
> http://client-machine/replies. Application messages are sent
to the same
> address.
>
> In scenario 2.3, where the offer is rejected, the CS message from
the RRMS
> to the RRMD is sent to the ReplyTo from the application message
> http://client-machine/replies. Application messages are sent
to the same
> address.
>
> Thoughts?
>
> Thanks, Dan
>
> WS-Reliable Messaging Architect and Team Lead
> IBM WebSphere Messaging Design and Development
> MP 211
> Hursley
> Tel. Internal 248617
> Tel. External +44 1962 818617
> Email. millwood@uk.ibm.com
>
>
>
>
> Matthew
> Lovett/UK/IBM@IBM
> GB
To
>
ws-rx-implement@lists.oasis-open.or
> 06/02/2006 14:34
g
>
cc
>
>
Subject
>
[ws-rx-implement]
Updated scenarios
>
doc
>
>
>
>
>
>
>
>
>
>
>
> Hi all,
>
> I have made the updates to Scenario 2.2, and added Scenario 2.3. The
new
> doc is attached - please let me know if I should be uploading it somewhere.
>
>
>
>
> Thanks
>
> Matt
> [attachment "InteropScenarios.doc" deleted by Daniel Millwood/UK/IBM]
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]