6 Replies Latest reply on May 14, 2008 2:09 PM by Jesper Pedersen

    JBAS-2408 - EJB3 / JCA integration

    Jesper Pedersen Master

      I'm going to look into the

      http://jira.jboss.com/jira/browse/JBAS-2408

      task which is about the integration between EJB3 and JCA in regards to inbound messaging for EJB 2.1 and EJB3.

      I have been going over the existing code - especially JBossMessageEndpointFactory, MessageInflowLocalProxy and MessagingContainer.

      The previous thread on this task discusses how the separation should be done using a MessageEndpointFactory, which is done.

      So what are the design/implementation goals for this task in context of the new microcontainer ?

      I can see two areas that would benefit the implementation:

      1) The TODO in JBossMessageEndpointFactory::resolveResourceAdapter about the creation of the ObjectName for the RA - is this still valid ?

      2) The use of JMSProviderAdapter in MessagingContainer which add a JAR dependency - we can just move this class to the ejb3 namespace

      The previous thread on this issue is here: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73265

      Any input on this task would great.

        • 1. Re: JBAS-2408 - EJB3 / JCA integration
          Adrian Brock Master

          The correct fix for this is for JCA to provide an AbstractMessageEndpointFactory
          and "MessageEndpointInterceptor" (you actually need two for the two different models
          AOP or JMX, but they can share a lot of code).

          All the EJB2/3/POJO containers should do is provide callbacks for
          things like isDeliveryTransacted(Method), getTransactionTimeout(Method)
          and the dispatch interceptor (i.e. invoke the ejb container or pojo).

          This work is also tied up with the JCA metadata repository.

          "jesper.pedersen" wrote:

          I can see two areas that would benefit the implementation:

          1) The TODO in JBossMessageEndpointFactory::resolveResourceAdapter about the creation of the ObjectName for the RA - is this still valid ?


          This should be replaced with the container passing the above mentioned callback
          to the JCA metadata repository.

          2) The use of JMSProviderAdapter in MessagingContainer which add a JAR dependency - we can just move this class to the ejb3 namespace
          


          No. EJB3 is not the place for integration code. All EJB3 cares about is
          I want to activate an endpoint with
          * this callback
          * these activation config properties
          * some selection parameters to determine the rar, e.g. listener interface, rar name, etc.

          There a lot of other threads about this with more details in either the JCA forum
          and possibly the EJB3 or JMS forums?

          • 2. Re: JBAS-2408 - EJB3 / JCA integration
            Adrian Brock Master

             

            "adrian@jboss.org" wrote:

            No. EJB3 is not the place for integration code. All EJB3 cares about is
            I want to activate an endpoint with
            * this callback
            * these activation config properties
            * some selection parameters to determine the rar, e.g. listener interface, rar name, etc.


            i.e. there should be a jca spi in the jboss-integration that has something like:

            public interface EndpointActivationBus
            {
             EndpointActivation activate(Endpoint endpoint, Set<ActivationConfigProperties> properties, RarSelection selection);
            }
            public interface EndpointActivation
            {
             deactivate();
            }
            
            public interface Endpoint
            {
             boolean isDeliveryTransacted(Method);
             int getTransactionTimeout(Method);
             // etc.
            }
            
            public interface AOPEndpoint extends org.jboss.aop.Interceptor {}
            public interface JMXEndpoint extends org.jboss.invocation.Interceptor {}
            
            public interface RarSelection
            {
             String getRarName();
             Class<?> getListenerType();
             Map<String, String> getProperties(); // for some kind of fuzzy match based on rar config
            }
            


            which we then implementation in JBossAS over the JCA metadata repository.

            You can imagine alternate methods where the caller does more work upfront
            if it knows a lot a about the rar, e.g.
             EndpointActivation activate(Endpoint endpoint, ActivationSpec spec);
            

            the activation spec obviously determines the rar.

            • 3. Re: JBAS-2408 - EJB3 / JCA integration
              Adrian Brock Master

               

              "adrian@jboss.org" wrote:

              which we then implementation in JBossAS over the JCA metadata repository.


              Obviously EJB3 is reposnsible for implementing the AOPEndpoint on top of its
              MDBContainer(s).

              • 4. Re: JBAS-2408 - EJB3 / JCA integration
                Jesper Pedersen Master

                I've created the following task to track the SPI

                http://jira.jboss.com/jira/browse/JBAS-5426

                and imported the first version into jboss-integration. The classes lives under the org.jboss.jca.spi package as it seem like a good choice when looking at jboss-jca.

                I havn't added the JMXEndpoint interface yet as I could find the correct Maven artifact for this. Feel free to add the interface, Adrian :)

                The next tasks would be to add an implementation in the AS -- currently the locator looks for java:/EndpointActivationBus or org.jboss.jca.EndpointActivationBusManager.

                Additional tasks/sub-tasks can be created for this work - or for work that enhanced the current SPI.

                Feel free to share your design/implementation ideas, Adrian - or move code around as you see fit,

                • 5. Re: JBAS-2408 - EJB3 / JCA integration
                  Adrian Brock Master

                   

                  "jesper.pedersen" wrote:
                  I've created the following task to track the SPI

                  http://jira.jboss.com/jira/browse/JBAS-5426

                  and imported the first version into jboss-integration. The classes lives under the org.jboss.jca.spi package as it seem like a good choice when looking at jboss-jca.


                  I haven't looked at it. The spi needs implementing to validate it works.


                  I havn't added the JMXEndpoint interface yet as I could find the correct Maven artifact for this. Feel free to add the interface, Adrian :)


                  The JMXEndpoint should live in the appserver project. It is the backwards
                  compatibility implementation for EJB2.1
                  The invocation model is in the appserver's server project.


                  The next tasks would be to add an implementation in the AS -- currently the locator looks for java:/EndpointActivationBus or org.jboss.jca.EndpointActivationBusManager.


                  The bus should just be injected.


                  Additional tasks/sub-tasks can be created for this work - or for work that enhanced the current SPI.

                  Feel free to share your design/implementation ideas, Adrian - or move code around as you see fit,


                  The other thing that we will need is a mechanism to predetermine what the rar
                  resolves to such that the ejb can add the dependency during deployment.

                  Something like:
                  public interface EndpointActivationBus
                  {
                   EndpointActivation activate(Endpoint endpoint, Set<ActivationConfigProperties> properties, RarSelection selection);
                  
                   /**
                   * Determine the dependency name for the rar
                   * @param properties the config properties
                   * @selection the rar selection parameters
                   * @return the dependency name, e.g. JMX object name or MC name or null if it cannot be determined
                   */
                   String resolveRarContext( Set<ActivationConfigProperties> properties, RarSelection selection);
                  }


                  • 6. Re: JBAS-2408 - EJB3 / JCA integration
                    Jesper Pedersen Master

                    Just a small update on the SPI work.

                    The EndpointActivationBusLocator isn't needed as the EndpointActivationBusManager should be injection using @Inject or through a -beans.xml file. The manager itself is installed in the microcontainer using a -beans.xml together with its dependencies. The manager is a singleton.

                    One dependency is currently the JCAMetaDataRepository as the manager needs information about the resource archives that have been installed. Furthermore the client can activate the endpoint using a set of properties -- and of course the client callback object (Endpoint).

                    I'm currently investigating the interaction with the EndpointActivation from a clients point of view using the EJB3 messaging container as the example.

                    The EJB3 messaging container currently relies on two classes: JBossMessageEndpointFactory and MessageInflowLocalProxy both in the org.jboss.ejb3.mdb.inflow package.

                    Most of the functionality in JBossMessageEndpointFactory will be replaced by the EndpointActivation and the callback object.

                    The task is to replace the MessageInflowLocalProxy with something on both sides - or some sort of callback that the client provides. The AOPEndpoint interface doesn't currently fit in here, since MessageInflowLocalProxy is an java.lang.reflect.InvocationHandler. The question is also how much of the JCA API we expose to the client.

                    I havn't investigated yet how the resolveRarContext method should be implemented, but properly a scan through the metadata and lookups in the microcontainer.