RE: [asap] wsrm issues

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

No, thanks for the explanation.  I thought you meant to use ASAP as a replacement for WSRM.  What you propose sounds reasonable.

-Keith

-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Friday, October 03, 2003 10:52 AM
To: Keith Swenson
Cc: asap@lists.oasis-open.org
Subject: Re: [asap] wsrm issues

Thanks for the feedback.

I agree that WS-Reliability should provide the Reliability Aspect and that the existing elements in the schema

be used for that purpose. I had no intention of suggesting existing WSRM elements be removed, only

that ASAP could be used with them to implement service instance status functionality when necessary.

Since the ReplyPattern supports Polling, WSRM needs to indicate how that pattern can be supported

(the driving example is a case where a firewall forces a one-way request scenario)

My thought was that rather than introduce the new StatusRequest and StatusResponse

headers as Sunil suggests to implement the Polling Reply Pattern,

that ASAP could be used with WSRM for that purpose.

(Synchronous and two-way reply/requests could continue to work without additional ASAP headers)

It looks like I may have misapplied the ASAP's schema, hence my request for help

mocking up messages using ASAP with WSRM to implement WSRM's Status request/response.

If using ASAP and WSRM together for that purpose is too heavyweight,

and Sunil's headers are preferrable, that's exactly the feedback I need

and I will stop pursuing the issue there.

On Friday, October 3, 2003, at 10:55 AM, Keith Swenson wrote:

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