4 Replies Latest reply on Mar 25, 2014 9:37 PM by chz29

    multiple bean instances as services

    chz29

      I have an existing java class in different remote host JVMs connected to JMS queues and then talking to equipment through vendor APIs. Since I need to maintain instance's of a class (they have state), how do I use SY to implement this same separation? I understand promoting a component service multiple times, but wouldn't that be calling the same instance of the component implementation?

      It doesn't seem to like the following concept (different service names, but same interface and implementation). My guess is that CDI hates this (ambiguous reference).

      ...

      <sca:component name="LegacyCodeComponent1">

            <bean:implementation.bean class="org.acme.LegacyCodeImpl"/>

            <sca:service name="LegacyService1">

              <sca:interface.java interface="org.acme.LegacyCode"/>

            </sca:service>

      </sca:component>

      <sca:component name="LegacyCodeComponent2">

            <bean:implementation.bean class="org.acme.LegacyCodeImpl"/>

            <sca:service name="LegacyService2">

              <sca:interface.java interface="org.acme.LegacyCode"/>

            </sca:service>

      </sca:component>

      ... promote and bind to JMS queue/custom camel endpoint, etc

        • 1. Re: multiple bean instances as services
          kcbabo

          There is one instance of each bean implementation per application.  Promoting a bean component multiple times will not result in multiple instances.


          Based on the switchyard.xml snippet you provided, I assume that the processing logic is identical between instances and you just want to have localized state, right?  If there's something in the messages that can be used to identify the source system, then you can use that in combination with a local map (keyed by instance id) in the implementation or use an external store like a database to hold the state.  If the message doesn't provide that detail, you can use context details like the service name and/or binding name to differentiate between source systems.


          Hope that helps.  If I misunderstood your requirement, let me know.

          • 2. Re: multiple bean instances as services
            chz29

            Thanks for the clarification. My final input rate of relatively small messages should be about 60-90/sec total from 18 custom camel endpoints, should I be concerned with performance and throw a route/seda queue combo in front?. Also, I see in BeanComponentActivator source that you are pulling just the local part off the QName for the ServiceProxyHandler. Any plans in future releases to pull the namespaceURI and allow multiple handlers/bean pools for non-CDI/local bean kind of instances?

            • 3. Re: multiple bean instances as services
              kcbabo

              Sorry for the late response.  For some reason, I didn't get a forum notification for your response.

               

              My final input rate of relatively small messages should be about 60-90/sec total from 18 custom camel endpoints, should I be concerned with performance and throw a route/seda queue combo in front?.

               

              It really depends on the execution time of the bean method and the scope of the synchronization in your code.  If you are only synchronizing a small part of the logic which updates the shared state, and that operation is quick, then there may be no need to have multiple instances.  I would definitely test with the bean alone first and see what kind of performance you get.  If you find that you can't get to the numbers you want, then adding a route with a seda endpoint to get asynchronous dispatch is worth looking at, although there are some trade-offs there (transaction scope being one).

               

              Also, I see in BeanComponentActivator source that you are pulling just the local part off the QName for the ServiceProxyHandler. Any plans in future releases to pull the namespaceURI and allow multiple handlers/bean pools for non-CDI/local bean kind of instances?

               

              Within the scope of an application, all services provided by CDI beans will have the same namespace.  That's why we only use the local name.  Bean pooling has been discussed as a possible enhancement in the past - if it's a feature you would like to see, please file an enhancement request with background on what you would like to see.

               

              regards,

              keith

              1 of 1 people found this helpful
              • 4. Re: multiple bean instances as services
                chz29

                I'll give it a go on the single instance and crank up the volume. If it doesn't work out I'll file that enhancement request.Thanks, Keith!