1 2 3 Previous Next 34 Replies Latest reply: Sep 28, 2011 2:20 AM by Magesh Bojan Go to original post RSS
  • 15. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    Awesome , we are in sync!

  • 16. Re: Runtime Environment / Configuration
    Rob Cernich Master

    Hey guys,

     

    Magesh Bojan wrote:

    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.

     

    I thought some of the reasons for passing the objects to the deployment were to:

    • Allow the components to be managed (e.g. loaded) in a container specific fashion (e.g. other than ServiceLoader).
    • Allow alternate components to be substituted for various component types (e.g. for Savara testing).

     

    From a tooling perspective, I think it would be beneficial (though not necessary) if there were a bit more information conveyed about the "kind" of activators contributed by the component; for example, the Camel component provides activators for implementations and bindings.  This also forces a single Activator implementation to support all "kinds" in a single implementation (just an observation).

     

    Rob

  • 17. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    Rob,

    I thought some of the reasons for passing the objects to the deployment were to:

    • Allow the components to be managed (e.g. loaded) in a container specific fashion (e.g. other than ServiceLoader).
    • Allow alternate components to be substituted for various component types (e.g. for Savara testing).

    Yes that is the intention. A list of Components will be passed into Deployment.doInit() - it will not scan for Components internally. The ServiceLoader logic will move up in certain environments (e.g. unit test, Savara testing, stand-alone deployment, container-specific).  How the Components are created either through ServiceLoader or some other logic will be specific to the envrionment.

     

    From a tooling perspective, I think it would be beneficial (though not necessary) if there were a bit more information conveyed about the "kind" of activators contributed by the component; for example, the Camel component provides activators for implementations and bindings.  This also forces a single Activator implementation to support all "kinds" in a single implementation (just an observation).

    I am not sure I understand kinds here. Are you talking about reference bindings and service bindings? Could you explain why that would be beneficial? Each Component is asociated with one and only type of Activator that is that Component's implementation specific. If there are two implementation needed for the Activator then they should be wrapped in two diffierent Component implemenations. Something like

    org.switchyard.component.camel.spring.ComponentImpl
    org.switchyard.component.camel.withoutspring.ComponentImpl
    
  • 18. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    Here is a concrete implementation based on the ideas shared in this thread.

     

    The Environment properties and AS6 configuration:

    https://github.com/mageshbk/core/tree/configapi

     

    A sample properties retrieval and usage:

    https://github.com/mageshbk/components/tree/configapi

     

    A sample AS7 configuration:

    https://github.com/mageshbk/release/tree/configapi

     

    I have everything working with AS7 and the tests. AS6 is still to be perfected.

     

    The properties can be set like this in AS7:

    <module identifier="org.switchyard.component.soap">
        <properties>
            <serverHost>
                192.168.0.3
            </serverHost>
            <serverPort>
                18001
            </serverPort>
        </properties>
    </module>
    

     

    The properties for AS6 would be:

    <bean name="SwitchYardDeployer" class="org.switchyard.deployment.SwitchYardDeployer">
        <property name="domainManager"><inject bean="SwitchYardServiceDomainManager"/></property>
        <property name="modules">
            <map class="java.util.Hashtable" keyClass="java.lang.String" valueClass="org.switchyard.config.Configuration">
                <entry><key>org.switchyard.component.bean</key><value></value></entry>
                <entry><key>org.switchyard.component.soap</key><value><inject bean="SOAPConfiguration"/></value></entry>
                <entry><key>org.switchyard.component.camel</key><value></value></entry>
                <entry><key>org.switchyard.component.bpm</key><value></value></entry>
                <entry><key>org.switchyard.component.rules</key><value></value></entry>
            </map>
        </property>
    </bean>
    
    <bean name="ConfigPuller" class="org.switchyard.config.ConfigPuller"/>
    
    <bean name="SOAPConfiguration" class="org.switchyard.config.Configuration">
        <constructor factoryMethod="pull">
            <factory bean="ConfigPuller"/>
            <parameter>
                <properties>
                    <serverHost>localhost</serverHost>
                    <serverPort>18001</serverPort>
                </properties>
            </parameter>
        </constructor>
    </bean>
    

     

    Feedback?

  • 19. Re: Runtime Environment / Configuration
    Rob Cernich Master

    Hey Magesh,

     

    Magesh Bojan wrote:


    I am not sure I understand kinds here. Are you talking about reference bindings and service bindings? Could you explain why that would be beneficial? Each Component is asociated with one and only type of Activator that is that Component's implementation specific. If there are two implementation needed for the Activator then they should be wrapped in two diffierent Component implemenation.

     

    That is my point: Each component is associated with one and only one type of activator.  The Camel component's activator, for example, is used for:

    • Providing a binding (gateway) for a service or reference (binding.camel in a CompositeServiceModel or CompositeReferenceModel).
    • Providing an implementation for a service (implementation.camel in a ComponentServiceModel or ComponentReferenceModel).

    Whereas the HornetQ component's activator, by contrast is only used for providing a binding (gateway) for a service or reference.

     

    It would be nice if there were a way to determine the capabilities provided by a component.  For example, the Camel component provides support for both implementing services (implementation.camel) and accessing services (gateway support, binding.camel); the HornetQ component provides support for accessing services; the Clojure component provides support for implementing services (implementation.clojure).  (I suppose I could rephrase "implementing services" to "instantiating services" as the component really provides support for instantiating a service written in a specific dialect.)

     

    Hope that helps to clarify what I meant by "kinds."

     

    Best,

    Rob

  • 20. Re: Runtime Environment / Configuration
    Rob Cernich Master

    Hey all,

     

    As configuration items are added for runtime components, I'd like to request that a separate JIRA be created against tooling to make sure the new items are supported by the tooling (e.g. console).

     

    Thanks in advance,

    Rob

  • 21. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    The links above should be updated now with working AS6 implementation.

    <bean name="ConfigPuller" class="org.switchyard.config.ConfigurationPuller"/>
    
    <bean name="SOAPConfiguration" class="org.switchyard.config.Configuration">
        <constructor factoryMethod="pull">
            <factory bean="ConfigPuller"/>
            <parameter class="java.io.Reader">
                <inject bean="soap"/>
            </parameter>
        </constructor>
    </bean>
    
    <bean name="soap" class="java.io.FileReader">
        <constructor><parameter class="java.io.File">${jboss.server.home.dir}/deployers/switchyard.deployer/META-INF/soapconfig.xml</parameter></constructor>
    </bean>
    

    soapconfig.xml

    <properties>
        <serverHost>localhost</serverHost>
        <serverPort>18001</serverPort>
    </properties>
    

     

    Salient feature include that components are no longer scanned automatically from the deploy folder. They have to be explicitly configured via beans.xml and should be copied to deployers folder.

     

    David, could you please look at the config module changes?

     

    Tom, I was planning to move the *beans.xml file to the release build. Have you progressed on modularizing the assemblies? Do you want to do this as part of that?

  • 22. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    Rob,

     

    What if the information is provided like this?

    public interface Component {
       ...
        boolean isGateway();
        boolean isImplemention();
    }
    

     

    As configuration items are added for runtime components, I'd like to request that a separate JIRA be created against tooling to make sure the new items are supported by the tooling (e.g. console).

    Doesn't the admin API use the BindingModel? If you look at the SOAPBindingModel, that is where the Envrionment configuration is used. Wouldn't it be easier to have the implementation specific BindingModel's to be serailized by the admin console?

  • 23. Re: Runtime Environment / Configuration
    Rob Cernich Master

    Hey Magesh,

     

     

    What if the information is provided like this?

    public interface Component {
       ...
        boolean isGateway();
        boolean isImplemention();
    }
     

    That looks fine to me.  The use of an enum might be more flexible, but since there are only two types and if that's unlikely to change, I think this is fine.

     

     

    Doesn't the admin API use the BindingModel? If you look at the SOAPBindingModel, that is where the Envrionment configuration is used. Wouldn't it be easier to have the implementation specific BindingModel's to be serailized by the admin console?

    Currently, it does not.  The console uses DMR to access the server, which means these are converted to ModelNode objects, rendered as JSON then converted to business objects using AutoBean.  This process could be simplified by using the same interfaces in both the admin and console implementations.  That said, the UI is customized for the data being displayed, i.e. I'm not using code generated forms.  (Code generated forms are more ameniable to changes in the API, but also tend to be less user friendly, e.g. JMX console, or require the developer to muck up code with a bunch of annotations, purely for use by a UI consumer.)

     

    That said, I've been meaning to restart the conversation regarding the admin API.  For the most part, a lot of the current API is populated directly from the config models, which got me thinking, "Why don't we just use the model API?"  This will become a bigger issue once the admin API is specialized for various components (e.g. SOAPBindingModel).

     

    Best,

    Rob

  • 24. Re: Runtime Environment / Configuration
    Keith Babo Master

    Magesh Bojan wrote:

    Here is a concrete implementation based on the ideas shared in this thread.

    Feedback?

     

    Hey Magesh,

     

    First off, thanks for picking this up after I left it half done. :-)  I think this is coming together nicely.  I have a few pieces of feedback on the code in your configapi branch.

     

    o Do we need to add a distinct environment field to BaseModel?  What I was thinking here is that we would simply pass a Configuration directly to the component's init method.  I think where you are going with this is a generalized environment config which is separate from a specific configuration (i.e. a global config), but I'm not sure we need that.  Components just need what's in their configuration from init() and applications will be configured with properties defined in the composite and/or domain.  We have the idea of a root-level domain for any properties that need to be propagated to all applications.

     

    o I would prefer it if we didn't expose the Component reference in Activator.  Do we need this?

     

    o How do you see getConfiguration() on Component being used?  Is this for querying the configuration of a component?

     

    o Deployment should take a list of Activators instead of Components.

     

    o Now that the ServiceLoader stuff is out of deployment, we should stick it in a stand-alone class that can be invoked from all the test and runtime classes that require it now in order to pass a list of activators to the deployment.

     

    cheers,

    keith

  • 25. Re: Runtime Environment / Configuration
    Keith Babo Master

    Agreed and this really goes for anything.  If you implement a feature and it has a tooling impact (either changes tooling or would benefit from tooling), please file a JIRA against tooling which provides a brief summary.  Rob and I can take it from there in terms of breaking down where the tooling shows up (console, forge, eclipse, etc.) and when.

     

    Rob Cernich wrote:

     

    As configuration items are added for runtime components, I'd like to request that a separate JIRA be created against tooling to make sure the new items are supported by the tooling (e.g. console).

     

    Thanks in advance,

    Rob

  • 26. Re: Runtime Environment / Configuration
    Keith Babo Master

    Raising above the API details for a moment, I'm trying to determine what question the user might ask that would require this type of information.  I'm thinking there are two relevant questions that a user may ask:

     

    • Which implementation and binding types are supported by a given SwitchYard runtime?
    • For a given component, which implementation and binding types does it support?

     

    Do we all agree on that?  Personally, I think the first question will be much more common than the second. 

     

     

    What if the information is provided like this?

    public interface Component {
       ...
        boolean isGateway();
        boolean isImplemention();
    }
     

    That looks fine to me.  The use of an enum might be more flexible, but since there are only two types and if that's unlikely to change, I think this is fine.

     

  • 27. Re: Runtime Environment / Configuration
    Magesh Bojan Master

    o Deployment should take a list of Activators instead of Components.

    Here is a problem of passing a list of Activators. The Activator for that particular deployment is created by passing the ServiceDomain associated with the deployment. Although it is same for all deployments as of now, it could be different per deployment right? So the list of activators can be created or rather configured only from the Component at deploy time for that deployment.

  • 28. Re: Runtime Environment / Configuration
    Keith Babo Master

    We need to call Component.getActivator() for every deployment.  We should do that in the runtime code that detects a deployment (e.g. DeploymentProcessor) and pass the list of activators to the deployment.  So this shouldn't require the list of components to be passed to a deployment.