RE: [wsrm] comments on Jacques Update on mep mappings

Title: RE: [wsrm] comments on Jacques Update on mep mappings

Sunil:

inline <JD>

>

> 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鴳e reader.

>>

<JD> I will not pretend the spec is simpler: adding the Respond RM abstract operation

forces us to say more on how these ops map to WSDL operations, as well as to

underlying MEPs. I believe the model is not simpler, but more precise/complete

and addresses (or is a basis for) several points in our latest list of issues.

However I understand the concern, and frankly, if we can get away - for the time being - with a

"partial" model (for example only mention Submit + Deliver RMP ops)

then I am all for it. But that means we'll have to skilfully put aside

several points in our late issues list, as out of scope for this release, or 

as non-options for now.

</JD>

>> 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.

>>

<JD> We could significantly shorten the SOAP MEP section, if

we refer to external definitions of SOAP MEPs, when available. (I have not found one

for one-way, but a SOAP 1.2 adjunct doc gives one for request-response.)</JD>

>> 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.

<JD> What part of the Respond description is confusing? I am all for

simplifying it if we can. But a minimum of semantics needs differentiate Respond

from Submit. </JD>

 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.

<JD> Why? the model allows also for sending a Respond payload on same connection as

the request.</JD>

 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.

<JD>Talking of our friends' spec: granted it is shorter but is it crisper? Corner cases 

and border cases are left unanswered: there is a small set of abstract operations:

Send and Deliver. But how do these map to WSDL operation types? No mention about it.

Is a WSDL output message

of a request-response op supposed to be submitted with "Send"? If yes, how can a 

resending mechanism handle the resending of these responses when they

bind to HTTP responses? Also, no mention on how an Ack is to be returned: 

all these distinctions we use (reply patterns) are ignored. 

Will that allow for better interoperability?

I don't think so, unless you end-up with detailed policy extensions defined somewhere else.

Short specs can be a nightmare to implement, and interop is more than 

what shows on the wire. 

</JD>

>

>> - 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.

<JD> The contribution said exactly this in the updated 5.2: One-way WSDL operation types

map to One-way RMP invocations (Submit + Deliver).

</JD>

 

>

>> 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