5 Replies Latest reply: Jul 19, 2011 7:46 AM by Tom Fennelly RSS

InvocationContract fault type

Gary Brown Master

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
    Keith Babo Master

    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
    Gary Brown Master

    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
    Keith Babo Master

    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
    Keith Babo Master

    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
    Tom Fennelly Master

    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.