1 2 3 Previous Next 34 Replies Latest reply on Sep 28, 2011 2:20 AM by mageshbk

    Runtime Environment / Configuration

    dward

      The Component configuration discussion as well as Jira issues SWITCHYARD-384 and SWITCHYARD-434 got me thinkin'...

       

      We have a similar requirement that there is a notion of a runtime environment, whether it be a server runtime or a test case runtime, and that environment needs access to configuration information.

       

      What information is needed?

       

      In the case of 384, this would contain configuration for components that spans individual deployments.  For example, a default context path or server port for the soap component.

       

      In the case of 434, this would contain information that spans test cases.  For example, to resolve port conflicts when running the jbpm test cases which require starting up a jbpm/mina task server and client, when that user might already be running things on those ports. Or heck, even in a shared build environment where those ports are not available.

       

      In both cases, this could also provide a better way for specifying which activator implementations to use, rather than the current ServiceLoader approach.

       

      How should the information be structured?

       

      We already have a data structure for configuration: org.switchyard.config.Configuration.  Currently, we use this deployment-level component configuration, but it is by no means dependent or tied to that usecase. It is a generic, flexible, heirarchal configuration structure which I see no reason to not reuse.

       

      The more debatable question is whether or not we use org.switchyard.config.model.Model(s) to wrap the Configuration(s), as we normally do for deployment-level component configurations.  The benefits of using models is two-fold:

      1. Models can be validated with schemas, Configurations cannot.
      2. Domain-specific methods can be added to Models to increase ease-of-use.  For example, model.getPort() vs. Integer.parseInt(config.getAttribute("port"))Note: I'm considering adding helper methods to Configuration to make this easier, so it might become a moot-point. For example: config.getInt("port").

       

      Even if we only have a model at the root of the runtime environment, maybe called SwitchYardEnvironment, that might afford us to add validation in the future without having to change a hundred method signature calls - even if we don't define a schema for the environment this early on, if ever.  I think this would be a Good Idea.

       

      How should the information be created?

       

      This would be dependent on the runtime itself.  I believe we'd have different SwitchYardEnvironmentBuilder implementations, one for AS6, one for AS76, one for OSGi, one for JUnit tests, and any other environment we might someday run within.

       

      My point is that our code:

      1. Should not have to know how to handle different kinds of structures representing configuration data. We already have that, and we should use it.
      2. Should not have to know how that configuration data was built.

       

      How should the information be provided?

       

      This, again, would be dependent on the runtime itself.

       

      For example,

      • Maybe our test cases can will have a new method on SwitchYardTestKit called getEnvironment()
      • Maybe our test cases can have a SwitchYardEnvironment auto-injected via annotation.
      • Maybe in an AS6 or AS7 runtime, one can access SwitchYardEnvironment via JNDI or the AS7 modules functionality.
      • Mabye in an OSGi runtime, the SwitchYardEnvironment is provided by the ConfigAdmin functionality.

       

      I'm sure other implementations can be thought of, but I'm not stuck on how this is done.

       

      Thoughts?

        • 1. Re: Runtime Environment / Configuration
          dward

          I should add that in order to make the Configuration API viable for this, the notion of "immutable attributes" should be introduced. This would be easy to do, though.

          • 2. Re: Runtime Environment / Configuration
            mageshbk

            Last week I went ahead and created a dead simple implementation for the Boot-time configuration or the so called runtime configurations that you talk about here.

             

            The Environment properties and AS6 configuration:

            https://github.com/mageshbk/core/tree/SWITCHYARD-384

             

            A sample properties retrieval and usage:

            https://github.com/mageshbk/components/tree/SWITCHYARD-384

             

            A sample AS7 configuration:

            https://github.com/mageshbk/release/tree/SWITCHYARD-384

             

            Notice the properties can be set like this in AS7 and only at boot-time (SwitchYardExtension.java, SwitchYardSubsystemAdd.java):

            <subsystem xmlns="urn:jboss:domain:switchyard:1.0">
                <modules>
                    <module identifier="org.switchyard.component.bean"/>
                    <module identifier="org.switchyard.component.soap">
                        <properties>
                            <property name="serverPort" value="18001"/>
                            <property name="serverHost" value="localhost"/>
                            <property name="contextPath" value="swydws"/>
                        </properties>
                    </module>
                    <module identifier="org.switchyard.component.camel"/>
                </modules>
                <properties>
                    <property name="core.something" value="somevalue"/>
                    <property name="runtime.something" value="somevalue"/>
                </properties>
            </subsystem>
            

             

            That is also true with AS6:

            <bean name="SwitchYardDeployer" class="org.switchyard.deployment.SwitchYardDeployer">
                    <property name="domainManager"><inject bean="SwitchYardServiceDomainManager"/></property>
                    <property name="properties">
                        <map class="java.util.Hashtable" keyClass="java.lang.String" valueClass="java.lang.String">
                            <entry><key>org.switchyard.component.soap.serverHost</key><value>localhost</value></entry>
                            <entry><key>org.switchyard.component.soap.serverPort</key><value>18001</value></entry>
                            <entry><key>org.switchyard.component.soap.contextPath</key><value>swydws</value></entry>
                            <entry><key>core.something</key><value>somevalue</value></entry>
                            <entry><key>runtime.something</key><value>somevalue</value></entry>
                        </map>
                    </property>
            </bean>
            

             

            This will create SwitchYard Environment variables like:

            org.switchyard.component.soap.serverPort=18001
            org.switchyard.component.soap.serverHost=localhost
            org.switchyard.component.soap.contextPath=swydws
            core.something=somevalue
            runtime.something=somevalue
            

             

            As for the test environment properties are concerned, most can be picked up from these deployment properties I guess. SwitchYardTestKit.getEnvironment() can hold test environment properties that are more specific.

             

            I beleive we do not need a very structured Configuration implementation for these cases and eliminates the need for any validations and maintenance of schemas.

            • 3. Re: Runtime Environment / Configuration
              dward

              I looked over the code in your branches, and I think you've done a great job with regard to the integration bits of AS6 and AS7, and I think we should use most of what you have there.

               

              I do have a few comments, though:

               

              1. I don't believe the Environment data should be static.  I've seen more problems arise from static data than I care to remember.  Even though I know static things aren't truly singleton per jvm because they are actually scoped by classloader, I don't think that's something we should assume/bet on for SwitchYard.  I would rather us figure out a way to provide a runtime Environment instance to code that needs it in some way. This is especially important for certain modular environments, mock testing, and things that depend on injection.
              2. I think that by default, Environment data should be immutable.  No matter if we go with the Properties way you have, or the Configuration way I suggested, I believe this should be added.
              3. My arguments for using Configuration instead of Properties are:
                • Consistency: We already have a single way of providing name/value data in SwitchYard.  Namely, Configuration attributes.  I don't think we should add a second.
                • Functionality: There's only so much you can do with Properties. There's already good stuff in Configuration that you would be duplicating, like getting a list of attribute names, testing for the existence of attributes, copying the Configuration, writing out the Configuration in a way that's easy for debugging... And once we add the helper methods I described above, it will benefit not just the environmental requirements, but also the component deployment-level code.
                • Structure: I think that we would be limiting ourselves in thinking that we will always only need a flat Environment, and never a heirarchal one.  Heck, we can start by using a flat Environment and still use Configuration to achieve what we need at first, but at least that affords us flexibility in the future.
              4. I believe we should still wrap said Configuration in an Environment model becaues it allows us to add functionality which is specific to environmental concerns without muddying up Configuration for other code.  Just because something is a Model does not mean we need it for validation or have a schema for it.  For now, we could simply override isModelValid() by always returning true, but in the future if we want to add a schema for validation, we wouldn't have limited ourselves in the beginning.

               

              Thanks.

              • 4. Re: Runtime Environment / Configuration
                rcernich

                David Ward wrote:

                 

                I looked over the code in your branches, and I think you've done a great job with regard to the integration bits of AS6 and AS7, and I think we should use most of what you have there.

                 

                Absolutely agree.

                 

                 

                I don't believe the Environment data should be static.  I've seen more problems arise from static data than I care to remember.  Even though I know static things aren't truly singleton per jvm because they are actually scoped by classloader, I don't think that's something we should assume/bet on for SwitchYard.  I would rather us figure out a way to provide a runtime Environment instance to code that needs it in some way. This is especially important for certain modular environments, mock testing, and things that depend on injection.

                I agree completely.  I think this pertains to more than just configuration though.  There should be a standard means for retrieving information about the SwitchYard runtime (configuration, admin, etc.).  In addition, it should be possible to bootstrap the provider in a platform specific manner.

                 

                I think that by default, Environment data should be immutable. 

                This probably makes sense for most cases, but I'm guessing there will be cases where some properties could be changed (e.g. log levels, trace filters, etc.).

                 

                Rob

                • 5. Re: Runtime Environment / Configuration
                  kcbabo

                   

                  This probably makes sense for most cases, but I'm guessing there will be cases where some properties could be changed (e.g. log levels, trace filters, etc.).

                   

                  Rob  - assuming this configuration is stored in standalone.xml, it should be editable via the AS7 CLI (and by extension our admin console), right?

                  • 6. Re: Runtime Environment / Configuration
                    rcernich

                    Rob  - assuming this configuration is stored in standalone.xml, it should be editable via the AS7 CLI (and by extension our admin console), right?

                    Yep.  I'm assuming all properties would be stored in standalone.xml for AS7, as in Magesh's example.

                     

                    From the perspective of the console, I'd assume all properties could be changed, but that changing certain properties would require a restart of the SwitchYard subsystem and possibly other subsystems as well.  That said, we probably need to consider what impacts certain changes would have in a broader context (i.e. governance), but that's probably a topic for another thread.

                    • 7. Re: Runtime Environment / Configuration
                      dward

                      Hmmm... this got me thinking - although I might be OVER-thinking:

                      1. Should env cfg data be read-only for user applications, but read-write for admin applications?
                      2. If an admin changes something, is there a listener/notification mechanism to apps/components that care?
                      • 8. Re: Runtime Environment / Configuration
                        rcernich

                        I think I'm starting to over think this.

                         

                        I think we've acknowledged that there isn't a one-size-fits-all approach to managing configuration data.  That said, I think we should simply create usage scenarios for specific sets of configuration data.  Since this discussion was born out of defaults for SOAP bindings, let's use those as a starting point:

                        • Can those properties be modified while SwitchYard is running?
                        • What happens when the properties are changed?  For existing deployments?  For new deployments?
                        • Should the change be propagated to other consumers (e.g. for impact analysis)?
                        • Is there another piece of configuration that defines the behavior when a property changes?
                        • ???
                        • 9. Re: Runtime Environment / Configuration
                          kcbabo

                          Configuration should be editable.  Changes to runtime configuration requires a restart.

                          • 10. Re: Runtime Environment / Configuration
                            kcbabo

                            Take a look at the following deployment changes to get an idea of what I'm thinking from an API level:

                            https://github.com/kcbabo/core/commit/d9cf3c08c5c0e61edaae4e97913ee8f7d969132b

                             

                            Main changes are:

                            • Added a Component interface.  One of these is created by the SwitchYard bootstrap logic (not the deployer) on system startup.  There is exactly one instance of a Component per SwitchYard runtime.  Note to Rob : this will allow us to query installed components without having a deployment in the system.
                            • The init() method on Component takes a Configuration instance.  This is how the component gets configured.
                            • Activator is created from a Component instance.  The applicable ServiceDomain for the activator is passed in the call to Component.getActivator().  The implementation of component can decide if/how the ServiceDomain is required for processing related to services/references in the deployment itself.  There is one instance of Activator per deployment.
                            • A list of Activators is passed into Deployment.doInit() - it no longer scans for Activators internally.  The ServiceLoader logic that was there before will move up in certain environments (e.g. unit test, stand-alone deployment).  ServiceLoader does not need to be used in AS7 as we have a list of component modules already defined in the SwitchYard subsystem.

                             

                            I have not followed these changes out into other modules, but I don't think there will be a huge problem there.  I believe this change is compatible with Magesh's approach w/r/t AS integration and David's approach to use our config module.  Seems like it should hang together OK to me.  Thoughts?

                            • 11. Re: Runtime Environment / Configuration
                              dward

                              I guess I'm still thinking we pass in some kind of (Component?)EnvironmentModel into Component's init method, rather than just a raw Configuration.  This would give us the flexibility to add logic to the model if we ever need to, without messing with Configuration. And for now, we can either override isModelValid() with always returning true, or we add a simple xsd that allows for any content.  And if people simply always just go for env.getModelConfiguration().getAttribute(...) for everything in a flat manner, that's fine by me. Just my 2 cents.

                              • 12. Re: Runtime Environment / Configuration
                                kcbabo

                                My thinking with just passing in Configuration is that it's not 100% clear what form this configuration will take in all environments.  The underlying representation could be XML, properties file / NTV, JSON, YAML, etc.  Certainly XML seems like it's a leading candidate, but I would like to get a larger set of uses for Configuration before we move into defining a model layer and anything related to schema.

                                • 13. Re: Runtime Environment / Configuration
                                  mageshbk

                                  One of these is created by the SwitchYard bootstrap logic (not the deployer) on system startup.  There is exactly one instance of a Component per SwitchYard runtime.


                                  Activator is created from a Component instance.  The applicable ServiceDomain for the activator is passed in the call to Component.getActivator().  The implementation of component can decide if/how the ServiceDomain is required for processing related to services/references in the deployment itself.  There is one instance of Activator per deployment.

                                  You mention only one instance per runtime. Shouldn't it be per component? Looking at the Component interface suggests this.

                                  public interface Component {
                                      Activator getActivator(ServiceDomain domain);
                                      String getName();
                                      void init(Configuration config);
                                      void destroy();
                                  }
                                  

                                   

                                  If this Component instance is per component, then are you suggesting that we go down the route of Activator and BindingModels that we have for the components something like org.switchyard.component.bean.ComponentImpl, org.switchyard.component.soap.ComponentImpl etc. and BeanConfiguration, SOAPConfiguration etc.?

                                   

                                • A list of Activators is passed into Deployment.doInit() - it no longer scans for Activators internally.  The ServiceLoader logic that was there before will move up in certain environments (e.g. unit test, stand-alone deployment).  ServiceLoader does not need to be used in AS7 as we have a list of component modules already defined in the SwitchYard subsystem.
                                •  

                                  If the above argument is true about the Component interface then we can set the list of Components rather than Activators. The ServiceLoader logic can be then used for Component rather than Activator in certain environments and for AS7, create it from the list of module names.

                                  • 14. Re: Runtime Environment / Configuration
                                    kcbabo

                                    You mention only one instance per runtime. Shouldn't it be per component? Looking at the Component interface suggests this.

                                     

                                    Yep, one component instance for each component per runtime.  Main thing here is that we're not creating one for each deployment and that we can query the list of available components at a system level.

                                     

                                    If this Component instance is per component, then are you suggesting that we go down the route of Activator and BindingModels that we have for the components something like org.switchyard.component.bean.ComponentImpl, org.switchyard.component.soap.ComponentImpl etc. and BeanConfiguration, SOAPConfiguration etc.?

                                     

                                    It's similar to Acivator in the sense that each component will provide an implementation of Component.  We certainly could create a specific configuration object for each component, but I don't think this is required.   At first, I just expected the deployment code to read the specific config (e.g. AS7 module config) and load that into the generic Configuration object.

                                     

                                    If the above argument is true about the Component interface then we can set the list of Components rather than Activators. The ServiceLoader logic can be then used for Component rather than Activator in certain environments and for AS7, create it from the list of module names.

                                     

                                    Exactly!

                                    1 2 3 Previous Next