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
