Title: RE: [asap] wsrm issues
Am I to understand correctly that you would like to use ASAP to implement reliable messaging? This seems to me to be the wrong thing to use it for. It is possible, of course, but probably not the best fit. Maybe I don't understand something here, so please lets discuss it.
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
-----Original Message-----
From: John Fuller [mailto:]
Sent: Thursday, October 02, 2003 2:36 PM
To:
Subject: [asap] wsrm issues
Enclosed are excerpts from WS Reliability: the most recent schema,
a suggestion I made concerning using ASAP to implement a polling reply
pattern
and a proposal from others in the group for a reliability namespace
status request.
My argument is basically that ASAP was designed to deal with the Aspect
of determining the status of a service instance and could be used in
place of
adding special reliability headers for this purpose.
Again, they expect 1000s of messages a second
and want to piggyback acknowledgements. I worry the term "service
instance"
(while also used this way in the Grid Service community) may have
scared people away imagining how it would be implemented.
It seems to me ASAP's treatment of Keys and Context Data are opaque
enough
to handle it semantically.
What are opinions here about the application of ASAP for this purpose?
I don't want to misapply or stray from the intent of ASAP...
***
WS-Reliability has gone through some changes since the precommittee
document,
a recent schema writeup is shown below
