Re: [wsrm] Groups - COntribution-JD-WS-Reliability-2004-06-21.pdfuploaded

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

Tom Rutt wrote:

>
>
> Sunil Kunisetty wrote:
>
>> Jacques,
>>
>> I’m very un-comfortable with the new wordings.
>>
>> A Meta Point: The spec. is getting very “verbose” and complicated. If 
>> I myself have to read couple of times to
>> understand the gist, understand the plight of the naïve reader.
>>
>> I do understand that the spec. has to talk about the model. But to me 
>> that has to be simple and crisp and not
>> overly complicated. An overly complicated model implies 
>> implementation restrictions. Also, while I understand
>> that RMP is not an independent entity and piggy backs on a SOAP 
>> processor, we should discuss about RMP
>> model in particular and not SOAP Processing model in general.
>>
>> Emphasize should be more on the protocol behavior and the headers as 
>> these have an affect on the
>> interoperability.
>>
>> To me a model description should be as simple as:
>> - Supports RM capability for request messages only
>> - Works with both request-response and one-way transports.
>> - For cases where RM-Reply has to be piggy backed on the response 
>> (such as the Response pattern case),
>> the RMP should wait until the Consumer responds.
>
>
> To do this the spec needs the Respond primitive as an abstract action 
> by the Consumer to the Responding RMP

 We need respond. However, it doesn't have to be complex and confusing 
as it is defined now.
 It could be as simple as:
     If the sending RMP has to piggyback the RM-Reply on the Response, 
then it will wait until
     the Consumer calls this abstract operation.

 Current definition:

         /An abstract operation supported by the RMP. When invoked, the
    operation transfers payload data from the Consumer to a Receiving
    RMP. An invocation of Respond must be related to a previous
    invocation of Deliver on the same RMP./


 This implies Receiving RMP sending _asynchronous results w_hen ever the 
Consumer calls response.
 This is outside our realm. Also, the whole thing about correlation is 
confusing.

 My biggest concern is this whole abstract model. It is no longer 
abstract and is implying implementation
 restrictions.

 Take our friendly spec. for a second. The abstract model there is 
plain, simple, and crisp. One can digest
 things with a simple read.

>
>> - Explain the patterns abstractly etc.
>>
>> I think we should only emphasize on the Submit and Deliver operations 
>> and avoid defining Notify and Respond.
>> The way the current Notify is defined, it implies that a RMP 
>> implementation should support some kind of
>> notification/callback mechanism to the Producer. This is what I meant 
>> earlier when I said over emphasizing on
>> the model could imply implementation restrictions.
>
>
> The implementation of the primitives is not subject to 
> standardization, there are many ways the response or fault
> can be conveyed to the producer, by the sending RMP.
>
  However, the current definition and model seem to imply that one has 
to support it.

>>
>> Some specific concerns about the Respond abstract operation:
>>
>> 1) We need to mention that Respond is not always there if the 
>> operation is an one way message or the
>> message is dispatched asynchronously (using some Queues).
>
>
> I agree that respond should only be invoked by the consumer when 
> response payload needs to be conveyed.
>
>> 2) Even for synchronous request-response, we don’t have to wait for 
>> the Response from the Consumer in
>> cases such as Callback where in Response and RM-Reply are sent on 
>> different channels and we don’t have
>> to wait for the Response to send the RM-Reply (which we send when we 
>> make available the message to the
>> Consumer).
>
>
> This version of the protocol has only an http post binding as 
> normative, which does not support sending a response payload.

 That's not always correct. It is correct if the WSDL operation is a 
one-way operation.
 If the operation istelf is a Request-Response operation, why can't the 
Receiving RMP send the
 response in the payload. That's the example I gave here.


 -Sunil