[wsif] Input-only Jms operations expect a response

[Mark Whitlock <ma...@uk.ibm.com>]

Hi,
Currently for input-only operations, the Soap/Jms, Axis/Jms and NativeJms
providers all set a JMSReplyTo; and SoapJms and AxisJms expect a response,
whereas the NativeJms provider does not. I'd appreciate people's comments
on how this should work.

For other protocols (java, ejb) WSIF always gets a response back, but with
Soap/Jms, Axis/Jms and NativeJms WSIF has the opportunity to expect no
response whatsoever. If WSIF does not expect a response, then I think it
should not set the JMSReplyTo.

For an operation that has no output parts, I think the client should be
able to invoke it "fire-and-forget" or "fire-and-acknowlege" depending on
whether the client is interested in knowing whether the operation
succeeded. If the operation is defined in the WSDL as having no output
message and the application calls executeInputOnlyOperation, then I think
this should be fire-and-forget. Whereas if the operation is defined as
having an empty output message and the application calls
executeRequestResponseOperation, then I think this should be
fire-and-acknowlege.

The WSIFClientProxy calls executeInputOnlyOperation if there is no output
message, else it calls executeRequestResponseOperation. Applications that
do not use WSIF dynamic proxies could call executeInputOnlyOperation when
there is an output message defined with parts in it, or else call
executeRequestResponseOperation when there is no output message defined. I
suggest both of these (slightly strange) cases should be valid, the first
meaning "fire-and-forget and I don't care about the output parts" and the
second meaning "fire-and-acknowlege". This would allow the client
application to override the WSDL's intention, but would affect other
providers as well.

The outcome of this discussion may change the way WSIF expects a JMS
listener to behave.
What do you think?
Mark

Mark Whitlock
IBM Hursley,  Web Services, x248340

Re: [wsif] Input-only Jms operations expect a response

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

"Mark Whitlock" <ma...@uk.ibm.com> writes:
>
> For an operation that has no output parts, I think the client should be
> able to invoke it "fire-and-forget" or "fire-and-acknowlege" depending on
> whether the client is interested in knowing whether the operation
> succeeded. If the operation is defined in the WSDL as having no output
> message and the application calls executeInputOnlyOperation, then I think
> this should be fire-and-forget. Whereas if the operation is defined as
> having an empty output message and the application calls
> executeRequestResponseOperation, then I think this should be
> fire-and-acknowlege.

+1

> The WSIFClientProxy calls executeInputOnlyOperation if there is no output
> message, else it calls executeRequestResponseOperation. Applications that
> do not use WSIF dynamic proxies could call executeInputOnlyOperation when
> there is an output message defined with parts in it, or else call
> executeRequestResponseOperation when there is no output message defined. I
> suggest both of these (slightly strange) cases should be valid, the first
> meaning "fire-and-forget and I don't care about the output parts" and the
> second meaning "fire-and-acknowlege". This would allow the client
> application to override the WSDL's intention, but would affect other
> providers as well.

I don't think that's a good idea. If the service says its an
input-only op, the client has no business trying to use WSIF
with a an InputOutput call. The second case may just not even
work as the other side (which you don't have control over in
general) may not ever acknowledge.

Sanjiva.