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

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

Doug: inline

-----Original Message-----

From: Doug Bunting [mailto:]

Sent: Wednesday, June 09, 2004 5:25 PM

To: 

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.