"Mark Whitlock" <[EMAIL PROTECTED]> 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.
