RE: [wsrm] "However, an RMP is not requried to disinguish WSDL operation types."

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: RE: [wsrm] "However, an RMP is not requried to disinguish WSDL operation types."

Doug: inline

-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Wednesday, June 09, 2004 5:25 PM
To: wsrm@lists.oasis-open.org
Subject: [wsrm] "However, an RMP is not requried to disinguish WSDL
operation types."

I realize this text[1] must have been included in an earlier round of
changes since 1.01 but believe our recent discussions calls the statement
into question.  As we add a Respond operation, we also add a requirement
that the receiving RMP know whether the Deliver operation should be
correlated with an invocation of the Respond operation.  That is, the
receiving RMP must know whether to wait before publicizing.

<JD> I knew I had not addressed this in my previous summary and that
someone would pick on that :)
This is also what I thought initially, but it appears we do not have to make this
assumption (that the RMP knows if there will be a Respond to a Deliver or not).
The following explanation actually makes this concern purely an implementation concern, not justified in most cases. Here is why, according to our main implementor.

Two cases are to be considered, based on the current behavior of WS stacks:

(1) non-BP compliant stacks. For these, there is no essential difference
between a one-way message and a request of a req-resp op type.
In both cases, the HTTP connection is maintained open until a response
is obtained from the "Consumer" level, and the RMP always sees a response from
teh Consumer (which it can manipulate).

(2) BP-compliant stack, such as the recent Axis 2.0. In that case,
there is, transparently to the RMP, a knowledge that the message is a one-way,
and the stack manages to send back the empty HTTP response transparently
to the RMP, with the right status code. (At best, the RMP can raise an exception
in case RM headers were not well processed, which will translate into
an error HTTP code.) So the RMP does not wait for anything.

NOTE1: When the RMP is implemented as a handler, the actual mapping of the consumer response to the right HTTP response is handled outside the RMP, based on some message context. Yet the RMP has the possibility to (a) not pass a request to the COnsumer, and (b) initiate its own response over HTTP.

NOTE2: When the RMP is implemented as a distinct SOAP node, then the "Deliver-Respond" pair naturally maps to a new HTTP connection with Consumer, and the RMP always expects a consumer response to map it to its other HTTP connection.

 Only, in case of a One-Way then the COnsumer response is not called a "Respond" operation :)

</JD>

 It will either
(abstractly ;) deliver and immediately respond on the underlying protocol
(Response RM-Reply pattern), send a callback request (Callback pattern) or
queue information for a later Poll request (Poll pattern) or deliver and
wait for the corresponding consumer response, then do the rest.

These differences imply the sentence quoted in the subject is incorrect.
At most, the RMP is not required to distinguish between specific signatures
(the payload syntax) described in a WSDL instance.  I recommend we strike
this sentence.

<JD> still tthe RMP, as a functional entity , does not need that WSDL knowledge:
the knowledge wether or not a "Respond" invocation is expected after a Deliver,
can reside out of it. I think it is still an important statement.
Now, nothing in the spec explicitly requires an RMP to have this knowledge, so this could go without saying... but I think we should not suggest that the statement is not true.

</JD>

thanx,
        doug

[1] At line 1207 of EditingDraft101Idiff101H.pdf in section 5.2.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.