5 Replies Latest reply on Jul 19, 2011 7:46 AM by tfennelly

    InvocationContract fault type

    objectiser

      Hi

       

      Just wondering if the org.switchyard.metadata.InvocationContract is going to be extended to allow multiple fault types?

       

      Regards

      Gary

        • 1. Re: InvocationContract fault type
          kcbabo

          Hey Gary,

           

          We originally made a simplifying assumption that there would only be one fault type, with the expectation that a use case would surface where multiple fault definitions would be required.  I don't see any reason why we couldn't support this other than requiring a bit more context data on exchanges targeting a service operation with multiple faults - basically we need to identify the fault type that's being sent so that any required transformers can kick in.  Only way I can see that working is that when multiple fault types are available, the fault must be sent with a context property specifically identifying the fault type in use.  For Java-based interfaces, we may be able to relax this a bit to use the Java class used as the fault content to make the determination.

           

          Tom - what do you think?

           

          cheers,

          keith

          • 2. Re: InvocationContract fault type
            objectiser

            Hi Keith

             

            The same issue applies to multiple request parameters? How would this be represented?

             

            Ideally switchyard should only need to deal with single message types, but the problem is in the case of wsdl, a request may have a multipart message, and a Java method may have multiple parameters. This would also impact the transformation, as each multipart parameter may need to invoke a different transformer.

             

            In my initial experiments I have simply been passing around effectively the WSDL message containing the multiple parts, but from an interop perspective we need to understand what should be the convention, to enable (for example) a BPEL process to invoke a Java bean with multiple parameters.

             

            Regards

            Gary

            • 3. Re: InvocationContract fault type
              kcbabo

              The same issue applies to multiple request parameters? How would this be represented?

               

              With a wrapper object or by including the additional parameters as attachments.  The former is preferred.

               

              Ideally switchyard should only need to deal with single message types, but the problem is in the case of wsdl, a request may have a multipart message, and a Java method may have multiple parameters. This would also impact the transformation, as each multipart parameter may need to invoke a different transformer.

               

              The approach we are taking now is consistent with the WS-I basic profile constraints for doc-literal bindings.  Multiple message parts in that scenario are a no-no.

               

              In my initial experiments I have simply been passing around effectively the WSDL message containing the multiple parts, but from an interop perspective we need to understand what should be the convention, to enable (for example) a BPEL process to invoke a Java bean with multiple parameters.

               

              Personally, I have a bias toward using document-oriented interactions in SOA.  I'm sure there will be edge cases where a user is forced to integrate an RPC-lit service into their application, but at this point we have focused on the use case we feel is most important.  I'm certainly up for discussing ways to accommodate this though.

              • 4. Re: InvocationContract fault type
                kcbabo

                BTW, I should mention that I view rpc-lit as something that's incorporated at the edge of the ESB (e.g. interacting with previously defined services) and not an approach that would be used when defining services in SwitchYard.  As such, I don't think our core exchange and metadata models would have to change to accommodate this requirement.  It would be more of a convention that we follow for mapping multi-part messages onto the existing API. 

                • 5. Re: InvocationContract fault type
                  tfennelly

                  I remember looking at trying to support multiple faults and it wasn't so straightforward.  My head is fried atm and I can't remember the details exactly, but we can certainly look at it again.  I'm sure it will be possible.