2 Replies Latest reply on Jun 13, 2012 12:20 PM by splatch

    Switchyard metadata in Camel mediations

    splatch
    splatch Jun 13, 2012 10:16 AM

      Hey,

      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
          dward
          dward Jun 13, 2012 11:52 AM (in response to splatch)

          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.

            • Actions
          • 2. Re: Switchyard metadata in Camel mediations
            splatch
            splatch Jun 13, 2012 12:20 PM (in response to dward)

            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.

              • Actions