[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [ws-rx-implement] WS-RM/RX question...
Doug What about changing the wording from MAY use close to RECOMMEND use close? I agree it can't be a MUST. Paul Doug Davis wrote: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]