[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: PR Issue 7: Title: RM Destination lacks a mechanism for cleanlyterminating inbound sequences.
|
PR Issue 7 From: Gilbert Pilz
[mailto:Gilbert.Pilz@bea.com] Note:
I'm filling this to complete an action item from the WS-I RSP. I view this
largely as an interop issue -
gp ------------
Title: RM
Destination lacks a mechanism for cleanly terminating inbound sequences.
Description:
Stipulate
the following scenario: a client and server communicate using asynchronous,
two-way, reliable messaging. During the initial sequence creation the client
offers a sequence to the server and this offer is accepted. Some number of
requests and responses are exchanged using the requested and offered sequences.
At some later time the user of the client application causes that application
to exit. It is obvious that the client-side RMS should clean up the
outgoing, client-to-server sequence by sending a wsrm:TerminateSequence message
(possibly preceded by a wsrm:CloseSequence message) to the server-side RMS.
What is not clear is what steps the client-side RMD should take to clean up the
incoming, server-to-client sequence. There are three basic courses of action: 1.)
The client-side RMD could do nothing to clean up the incoming sequence. From a
distributed systems viewpoint this seems less than optimal as it leaves the
server-side RMS with a "dangling sequence". If the server-side RMS
ever tried to use this dangling sequence it would engage the entire RMS
machinery for messages that would never get through (send, retry, request acks,
retry, request acks, etc.). 2.)
The client could wait for a length of time sufficient for it to consider the
inbound sequence to be "inactive", then exit. There are a couple of
problems with this. Firstly the user that caused the client to exit may grow
impatient and attempt to terminate the client by other means. Secondly, outside
of the optional expiration time, there is no mutually agreed upon inactivity
period for a sequence. 3.)
The client-side RMD could send a message to the server-side RMS to indicate
that the inbound, server-to-client sequence is being cleaned up. Since the
direction of the wsrm:TerminateSequence message is specified by
WS-ReliableMessaging 1.1 as being from the RMS to the RMD only, this leaves
either the wsrm:SequenceTerminated or wsrm:SequenceClosed faults as the only
viable messages for the client-side RMD to use. This brings up all the problems
attendant with using faults/exceptions to indicate "normal"
application behavior. The server-side RMS may construe the appearance of a
fault as an indication of some lower-level problem, etc. Note
that, although this issue is discussed in the context of a client application
attempting to exit, it is applicable in any situation where the process/VM that
"contains" an RMD must exit in a relatively short period of time for
whatever reason. Raised
against/Related drafts: http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf
Proposal:
Amend
the wording of section 3.6 (Sequence Termination) to indicate that a
wsrm:TerminateSequence/wsrm:TerminateSequenceResponse exchange may be initiated
by the RMD. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]