2 Replies Latest reply: Jun 12, 2012 6:18 PM by Brian Fitzpatrick RSS

Support for esb interface in tooling

Brian Fitzpatrick Apprentice

Just trying to gather some bits of information for interface.esb support in the tooling.

 

The schema looks like this:

{code:xml}

   <element name="interface.esb" type="swyd:EsbInterface" substitutionGroup="sca:interface"/>

   <complexType name="EsbInterface">

      <complexContent>

         <extension base="sca:Interface">

            <attribute name="inputType" type="string" use="optional"/>

            <attribute name="outputType" type="string" use="optional"/>

            <attribute name="faultType" type="string" use="optional"/>

         </extension>

      </complexContent>

   </complexType>

{code}

 

And the example we found in the Camel Service quickstart looks like this:

{code:xml}

<service name="XMLService">

     <swyd:interface.esb inputType="java:java.lang.String" xmlns:swyd="urn:switchyard-config:switchyard:1.0"/>

</service>

{code}

 

I suspect that there is a list of supported types for the optional inputType, outputType, and faultType. But they may also just be "java:java.lang.String" as well. Are we pointing into a JBoss ESB config file?

 

Thanks for any and all help on this.

  • 1. Re: Support for esb interface in tooling
    Keith Babo Master

    The type names can be anything.  Think of these names as equivalent to what you can put in the from: or to: sections of a transformer definition.  For Java types, they will be "java:[name]".  For XML types, you can expect QNames like "{urn:foo:bar}order".  Really, it can be any string literal the user wants to provide for a message name, so we can't provide much in terms of constraints in the input control.  That said, it would be excellent if we could provide a combo input where we provide a list of all available types in the application already to select from.  This would handle a case where you are using a type name in an ESB interface that's already defined in another interface type elsewhere in the app (e.g. Java, WSDL).  But we can't limit it to those types, so the user should still be able to enter a new type name that doesn't exist already.

     

    I believe Rob was going to look at providing a drop-down of types in an application for transformers based on all service interfaces in the app.  The exact same logic can be applied for this scenario.

  • 2. Re: Support for esb interface in tooling
    Brian Fitzpatrick Apprentice

    For now I'm leaving the fields open in the dialog launched from the new service/reference/etc wizards using Rob's tooling as well as in the control on the Interface property page. When we have the additional functionality to search for types, we can definitely add that.