The WSIF native JMS binding currently has no way for JMS response message
to be treated as a fault and returned to the caller in the wsif fault
message.
Dieter has proposed the following solution which I'd like to get peoples
comments on:
This could be a possible solution for this problem: instead of hard-coding
a specific fault indicator into the native JMS binding, we introduce a new
optional WSDL extension for the native JMS binding. If a WSDL fault is
specified, then the new JMS fault indicator must be specified as well.
<wsdl:operation>
<wsdl:input>...</wsdl:input>
<wsdl:output>...</wsdl:output>
<wsdl:fault name="fault1" message="...">
<jms:faultIndicator type="property"> <!-- this indirection allows
later introduction of faults indicated by message body elements -->
<jms:faultProperty name="myAppl:faultName" type="xsd:string"
value="fault1"/> <!-- property name/type/value must match -->
</jms:faultIndicator>
<!-- the following is just an example: the message may contain
anything -->
<jms:property name="myAppl:exceptionName" part="myException"/> <!--
map message properties: same semantics as for output -->
<jms:fault parts="myExceptionExplanation"/> <!-- map message body:
same semantics as for input and output -->
</wsdl:fault>
<wsdl:fault name="fault2" message="...">
<jms:faultIndicator type="property">
<jms:faultProperty name="myAppl:faultName" type="xsd:string"
value="fault2"/>
</jms:faultIndicator>
<!-- ... -->
</wsdl:fault>
<!-- ... -->
</wsdl:operation>
Kind Regards
DK
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.