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.