Comments inlined below <pp> </pp>
Regards,
Piotr Przybylski
Connector Tools and Architecture
"Sanjiva
Weerawarana" To: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
bm.com> Subject: Re: [wsif] Input-only Jms
operations expect a response
10/01/2002 12:26
PM
Please respond to
axis-dev
"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.
<pp>
I agree, for input only operation the client should invoke
executeInputOnlyOperation and the provider should not add any reply
to information.
The other question is whether it is correct to send
reply to info, as it is done in jms provider, for the requestReply
operation,
when jms binding does not contain ReplyTo property or any other
specification of where the reply should be sent. This seems to
introduce behaviour not defined in the wsdl that may potentially confuse
the other side.
</pp>
