OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx-implement message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: AW: [ws-rx-implement] Interop doc scenario 1.3


Hi Doug,
does WS-RX specifiy that an ack must be sent back after the message was received (and stored) successfully or after predecessor messages were received, too? As far as I know the spec does not say anything about this.
So one implementation (A) could send an ack for a given message not before the predecessor messages were received and another implementation (B) could send the ack after the message independent of in-order criteria was successfully received.
In this case (A)  acks message #1 only and (B) #1 and #3 if we use solution 3 and if my above assumptions are correct.
 
Do we want to have the same test result concerning acks independent of (A) and (B)? Is this the aim of this automated test case?
If my assumptions are correct this could be difficult for 1, 2 and 3...
 
A reason for implementing (A) could be to use a protocol on top of WS-RM for linking of sequences. In this case e.g. an ack should not be sent back before the message was inserted into a FIFO queue in the correct order.
 
Regards,
Stefan


Von: Doug Davis [mailto:dug@us.ibm.com]
Gesendet: Dienstag, 28. Februar 2006 18:29
An: ws-rx-implement@lists.oasis-open.org
Betreff: [ws-rx-implement] Interop doc scenario 1.3


In the scenario doc for 1.3 we close down the sequence after messages 1 and 3 were acked.  There's a problem here.  Depending on how the incoming message is sent, and depending on the implementation choices, message #3 may or may not ever get acked.  Its possible that the RMD could block on processing of message #3 until message #2 arrives.  This is because, even though its a one-way a Fault could still be generated and would need to flow back on the http response flow - hence an implementation may choose to block waiting until it knows for sure that no fault needs to go back.  This then gets into the entire anon-replyTo issue - which we don't want to get into.  Therefore I see a couple of options:
1 - send a close after just #1 is acked
2 - send a close after a certain amount of time
3 - assume everyone will send an independent AckRequested message that will then allow the ack for msg #3 to flow back.

I can go with any of these.  Thoughts? others?

thanks,
-Doug


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]