2 Replies Latest reply on Jun 13, 2012 12:20 PM by Łukasz Dywicki

    Switchyard metadata in Camel mediations

    Łukasz Dywicki Novice


      During work on sql quickstart I've found that it's extremally different to get operation name for calls from switchyard consumers. To detect operation I had to rely on body type. Are you ok with putting some additional headers to message sent from Switchyard to Camel?


      For example:

      • SwitchyardOperationName: print
      • SwitchyardInputType=java:some.pkg.print.Invoice
      • SwitchyardFaultType=null
      • SwitchyardOutputType=java:some.pkg.print.Status
      • SwitchyardServiceName={urn:camel-core:test:1.0}CamelMathService


      This will let users to do simple choice statements for services with more than only one operation.

        • 1. Re: Switchyard metadata in Camel mediations
          David Ward Master

          I'm fine with adding properties, but the names of the context properties (stop thinking "headers") might need some discussion.


          Specifically, I think it's time we came up with a convention for SwitchYard property names.  Below is a list of options.  The first two are already in place (and I don't like it), and yours would add a third:


          1. Prefixed with "org.switchyard." We do this with messageId (and correlationId I believe). Maybe other things.
          2. Use QName with a switchayrd namespace, for example: "{urn:switchyard-component-bpm:process:1.0}processInstanceId".  We do this in our rules, bpm and bpel components.
          3. Prefix with "SwitchYard" (as you suggest).


          Please let's decide upon ONE form?  Even though I admit to adding option #2, I prefer option #1 since it's simpler than option #2, and would volunteer to go back and change it.  And, even though option #3 is a lot like Camel does it, I still prefer option #1 since the "package notation" gives us more options for granularity/groupings of properties.  For example, a property prefixed with org.switchyard.component.bpm is clearly a bpm-related proeprty, and then in context mappers we can easlity write our includes based off of it.

          • 2. Re: Switchyard metadata in Camel mediations
            Łukasz Dywicki Novice

            I think that #1, the package notation will be ok - org.switchyard.component.camel. I proposed a #3 form to be close to Camel, and have shorter conditions. The #2 is way to complex for simple values. I am with you to operate using #1 as camel have lots of problems with number of headers (in SwitchYard terminology context properties) and management of them.