4 Replies Latest reply: Mar 30, 2011 8:34 AM by Keith Babo RSS

SwitchYard runtime config

Keith Babo Master

This has come up several times in the last week, so I figured I would start a thread for us to hash it out.  We all recognize that there will be runtime-level configuration outside of the SwitchYard application configuration, but we've danced around it up to this point.  I think we're getting to the point where we need to bang out an implementation and lose some of the hard-coded config we have stashed around.  IINM, we can use the existing configuration implementation to support a separate config file, so I'm assuming that the plumbing is already present.  All we need to do is settle on the initial set of config values and the basic structure.

 

I'll kick this off with a few items:

 

1) The list of component activators is currently hard-coded in the deployer implementation.

2) The bus provider(s) configuration (e.g. local, HornetQ, etc.)

3) Registry configuration details.  Not an issue today because we have not distributed the registry, but I'm guessing that this will come up when we go to use JGroups or Infinispan.

4) List of out-of-the-box transfomers available.

 

I know there are more, so please pile on with others.

  • 1. Re: SwitchYard runtime config
    Tom Fennelly Master

    So are we talking about a process whereby these runtime configs are loaded based on a classpath scan for one or more runtime config files?  For example, out-of-the-box transformers are placed in META-INF/switchyard/transforms.xml and would only contain TransformsModel data?

  • 2. SwitchYard runtime config
    Keith Babo Master

    That's a good point about META-INF/transforms.xml.  For the benefit of folks that did not see our #switchyard IRC conversation yesterday, here are the use cases we talked about for transformer configuration:

     

    1) we have a stock set of transformers that we define and these are wrapped up in a definition file inside a jar

    2) the user might want to supply instance/domain-wide transforms and those can be put in the runtime config

    3) lastly, there may be application-specific transforms and those go in switchyard.xml

     

    The runtime configuration I was referring to when I originally created this thread was #2 above.  It's a configuration that controls the configuration of a service domain and anything it creates (registry, bus, activators, etc.).  Looks like we will need to add config support for #1 as well.

     

    This brings up another question w/r/t schema modularity.  We need to decide whether all of these configs go inside one big switchyard schema or if they are stuck in independent schemas.  The latter approach would likely lead to n + 1 schemas, since you would want a base schema which holds common types.  Personally, I'm leaning toward one switchyard schema, but I can certainly be convinced otherwise.

  • 3. Re: SwitchYard runtime config
    Tom Fennelly Master

    Keith Babo wrote:

     

    This brings up another question w/r/t schema modularity.  We need to decide whether all of these configs go inside one big switchyard schema or if they are stuck in independent schemas.  The latter approach would likely lead to n + 1 schemas, since you would want a base schema which holds common types.  Personally, I'm leaning toward one switchyard schema, but I can certainly be convinced otherwise.

     

    One uber config namespace for everything?  Not sure how nicely that would play with the configuration code, since it relies on the namespacing to split out the configs.  One uber config namespace would mean all the config stuff we currently have split out for core, transform, soap, bean etc would all be piled in together.  In time, I'd say that could become a big blob.  It would work... just saying that I wouldn't really like it... I think having the separate concerns split out cleanly into their own namespaces is nice.

  • 4. SwitchYard runtime config
    Keith Babo Master

    We definitely can't have one uber namepsace for everything, because it destroys our modularity and extensibility support.  To be perfectly honest, I can't remember what point I was trying to make with the single schema thing. ;-)  I think I might have meant that the runtime configuration that I referred to in the first post can all go in the same schema.  One risk with the modular configuration is that you end up with a schema for each element in the name of modularity.  Certainly there are cases where this is appropriate (e.g. component schemas), but we should try to group schema definitions when they are related (e.g. runtime configuration).