RE: [asap] wsrm issues

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:]
Sent: Friday, October 03, 2003 10:52 
  AM
To: Keith Swenson
Cc: 
  
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