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.

Reply via email to