Re: AW: [ws-rx-implement] WS-RM/RX question...

[Doug Davis <dug@us.ibm.com>]

Stefan,
 see comment inline
in this pen.
-Doug

"Rossmanith, Stefan" <stefan.rossmanith@sap.com>

03/01/2006 10:24 AM

To	Doug Davis/Raleigh/IBM@IBMUS, "Paul Fremantle" <paul@wso2.com>
cc	<ws-rx-implement@lists.oasis-open.org>
Subject	AW: [ws-rx-implement] WS-RM/RX question...

Hi Doug, hi Paul,
thank you for your fast responses!!
Okay, this sounds good for current
version of WS-RX.
 
Of course the old WS-RM spec is
not subject of this SC, but you were involved creating it ;-) and therefore
I am interested in your
answer if you relate my question
to WS-RM 2005/02.
 
WS-RM 2005/02 spec is the basis
of current interoperable RM implementations until WS-RX is ready for beeing
the basis for "product" implementation.
Is my interpretation of WS-RM
2005/02 concerning my mentioned topic correct? 
 
Concerning WS-RX: Your answer
So good behaviour would be for the
RMD to close the sequence not terminate it.
 
is hopefully written more
precise in the spec. If the RMD can decide by itself to
terminate or close the sequence,
then the problem I mentioned is not really solved...
To my opinion the closing instead of terminating should be a MUST for RMD?!
<dug> under normal
conditions I agree - a Close would be better than a Terminate, but I
don't think we can force
it.  There will be times when an RMD must terminate the sequence
and not allow any more processing
happen related to that sequence.  I would imagine
those would only be under
the most serious conditions though - normally, i would hope
that people would use Close
instead.
</dug>
 
But in current WS-RX spec I found:

3.2.: To ensure that the Sequence ends with a known final state both the RM
Source and RM Destination may choose to 'close' the Sequence before terminating it.

4.2.:
This fault is sent by either the RM Source or the RM Destination to indicate that it has either encountered
an unrecoverable condition, or has detected a violation of the protocol and as a consequence, has chosen
to terminate the sequence. The endpoint that generates this fault should make every reasonable effort to
notify the corresponding endpoint of this decision.

What are the arguments to make only such a soft statement in 3.2.
Why do we really need 4.2. and cannot always use close instead of terminate.
Do you have examples when a closing is not possible but only a termination?

<dug> perhaps some serious system error prevent us from maintain state any more? </dug>

From the very first time I start thinking about WS-RM spec I worried about the statement in 4.2. but maybe
this was because I always thought that a terminated sequence must somehow be continued using a
new subsequent sequenceID (think about offering the real application a stable serialization context using
a sequence of underlying WS-RM sequences which are related. But there is no relation between WS-RM
sequences and so this issue cannot be solved on WS-RM level. So in case of a termination or closing, the
in-order processing is interrupted and can only be handled using a protocol on a higher level or by application
(e.g. a rollback work).

Do you think it would be a good proposal to define subsequent WS-RM sequences on WS-RM level
so that one can continue a sequence (by using a subsequent sequence) after termination or closing (else only
a kind of rollback is possible, isn't it?)? Or is this proposal out of scope of
WS-RM in your opinion? (Background: how to offer the real application a stable serialization context hiding
sequence terminations and sequence closing by just creating a subsequent WS-RM sequence for a given
closed/terminated WS-RM sequence?)
<dug> up to now I think people have decided that things like the linking of sequences or the
continuing of sequences is something that would be done at a level above RM itself.
If you want you should continue this discussion on the main TC mailing list since this isn't really
about interop anymore but more about the spec itself - and if you believe that the spec needs
to be changed in some way I think it makes sense to see how others in the TC feel or even
open a new issue to address them.  The worst that can happen is the issue is closed w/no action
:-)  </dug>

With kind regards,
Stefan

---

Von: Doug Davis [mailto:dug@us.ibm.com]
Gesendet: Mittwoch, 1. März 2006 14:15
An: Paul Fremantle
Cc: Rossmanith, Stefan; ws-rx-implement@lists.oasis-open.org
Betreff: Re: [ws-rx-implement] WS-RM/RX question...


Also, MaxMessageNumber has been removed from the spec.
-Doug

Paul Fremantle <paul@wso2.com>

03/01/2006 06:52 AM

To	"Rossmanith, Stefan" <stefan.rossmanith@sap.com>
cc	Doug Davis/Raleigh/IBM@IBMUS, ws-rx-implement@lists.oasis-open.org
Subject	Re: [ws-rx-implement] WS-RM/RX question...

Stefan

This is the usage for the CloseSequence, which still allows the RMS to
find out the final state of the sequence. So good behaviour would be for
the RMD to close the sequence not terminate it.

Paul

Rossmanith, Stefan wrote:
> Hi Doug,
> I have another question concerning WS-RM/RX.
> Scenario: The provider decides to terminate a sequence because of
> timeout (or other error situations).
>
> Is my understanding correct that the RMS in this case does not know
> which already sent messages were received successfully by RMD, because
> maybe some acks were lost and the RMS cannot request acks after RMD
has
> terminated the sequence?
>
> If this is true, WS-RM only could be used for real applications if
we
> have in addition a higher level protocol (e.g. a kind of transaction
> protocol or a mechanism on application level) which can handle this
> situation, i.e can proceed after this error situation in an appropriate
> way.
>
> I only want to know if my understanding fits to WS-RM intention ;-)
>
> One note to WS-RM 2005/02: In the AckRequest element the spec tells
to
> use MessageNumber element but the schema tells to use
> MaxMessageNumberUsed Element...
> (I looked at the documents at
> http://msdn.microsoft.com/webservices/webservices/understanding/specs/de
> fault.aspx?pull=/library/en-us/dnglobspec/html/wsrmspecindex.asp )
>
> With kind regards,
> Stefan
>
>
> PS: unfortunately I cannot participate tomorrow and next week at WS-RX
> SC/TC, because of other dates.
>
>
>
>   

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com