[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [asap] wsrm issues
ASAP has a request id, but that is not quite the same thing as a message id, since it is designed to be a locator of the service instance that is created, not the message. All other methods all calls to that service instance, but the method invocations themselves do not have message ids. Then, at the conclusion of the service instance, the completed message again does not have a message id, nor the built in idea that it should be sent again. ASAP message are mainly in the body of the message, not the header.
While it might be able to used to guarantee that something was 'delivered', ASAP was not really intended for this purpose, and in many cases will be too heavyweight for something as primitive as delivering a message. My reading of WS-RM is that it is an excellent fit with ASAP to make sure that messages are not dropped or duplicated. It seem to me more appropriate to use reliable messaging to make sure that your request to start an instance is guaranteed. Also, I would want to use reliable messaging to make sure that the completion notification is reliably delivered.
For example, for RM, you want to send a sequence of messages with serial numbers, acknowledgeing each message. If you use ASAP, then you have the start message that is acknowledged, and then a completed message which is acknowledged back the other way. Unless I don't understand what you mean, this seems like a lot of overhead. Furthermore, ASAP does not define any retry concept, or ignore duplicate concepts. Maybe I don't understand something here, but I don't see the fit.
-Keith
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]