OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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

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

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

 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.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]