Announcement Announcement Module
Collapse
No announcement yet.
EjbServiceExporter? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • EjbServiceExporter?

    I'm wondering why Spring Remoting does not include a EjbServiceExporter in line with the exporters for Hessian, Burlap, HTTP etc? I'm wondering whether or not it is a good idea to implement one? I imagine a stateless session bean that can act as a proxy for a given spring bean. I could imagine this would be useful at least in pre EJB3 environments.

    This reason why I want to put an EJB stateless SB facade in front of my Spring beans is that I want them to be remotely accessible and able to participate in global transactions. AFAIK this is not achievable with Spring Remoting.

    I know Spring comes with some EJB support classes but it still requires me to implement one EJB per Spring Bean I want to export which is what I want to avoid.

    Does anyone else see the desire for a EjbServiceExporter? If not why not?

  • #2
    I can see the use case however it would be quite impossible to create such a bean. You would dynamically have to create a Remote and/or Locale interface, deployment descriptor and app server specific deployment descriptor.

    Next to that that stuff all needs to be available prior to starting your application, because those things need to be available to/for the container to properly deploy the ejbs.

    Comment


    • #3
      Let me elaborate.

      Consider one stateless session bean which exposes a business interface that looks something like this:

      Code:
      public interface EjbService {
      public Object executeMethodOnSpringBean(String service, Class serviceInterface, Method method, Object[] params);
      }

      The session bean has access to a Spring context which contains the services. The method looks up the Spring bean with the supplied name. It finds the given method and invoke it with the supplied parameters.

      So thinking about it is not so much a EjbServiceExporter I am after, but more a EjbServiceProxyFactoryBean which can be used by clients.

      For example:

      Code:
      <bean id="myService" class="org.springframework.remoting.ejb.EjbServiceProxyFactoryBean">
      		<property name="ejb" ref="ejbService" />
      		<property name="service" value="myService" />
      		<property name="serviceInterface" value="com.mycom.MyService" />
      </bean>
      
      <jee:remote-slsb id="ejbService" jndi-name="ejb/EjbService"
            business-interface="org.springframework.remoting.ejb.EjbService"/>
      One drawback to this approach is that the transaction policy (Requires, RequiresNew etc.) would be the same for all invocations regardless of what Spring bean we hit in the end. However, I believe Supports would be appropriate as I would let the Spring bean layer control the transactions scope. It would support global transactions because if a remote client has started a transaction the EjbService bean will hook itself to that transaction before calling the Spring beans.

      Comment


      • #4
        As you seem to have control over EJB-Deployment and as you also seem to not really want to use EJBs: Why do you bother with them in the first place? If you use another remoting technology (i.e. one that Spring readily supports) you would have a clearer technical design and your deployment would be much easier. You could perhaps even drop the application server and use a web server instead (if you do not need other features than EJB, that is).

        Regards,
        Andreas

        Comment


        • #5
          I want my business layer to be based on POJO's and I want to expose them remotely and enable them to participate in global transactions. The lattter can AFAIK not be achieved with Spring.

          If I were on a JEE 5 platform the answer seems easy. Just annotate my POJO's with EJB3 annotations.

          But I'm not on that platform. The straightforward solution would be to develop a SB for each service. However, this imply in a lot of boilerplate code. My idea was to make one SB which can be used a proxy for all my services.

          Still think it is a bad idea?

          Comment


          • #6
            I understand your intention. I just try to find a possibly simpler solution

            As of transactions: You can use JTA transactions from within Spring. The only thing Spring does not support is propagation of a transactional context (i.e. client controlled transactions) which are questionable anyway.

            I hope this might help,
            Andreas

            Comment


            • #7
              Propagation of a transactional context is exactly what I want. I want a service in one EAR file to be able to participate in a transaction with services located in other EAR files. Do you agree that this cannot be achieved with Spring alone?

              I too want a simple solution that gives me the support for propagation of transactional context. Can you see a more simpler solution that can achieve this than the one I have proposed?

              The overall architecture I'm going for is the classic 3 layer model:

              Web layer: Use spring to bind web controllers to business services (we currently use Struts).
              Business layer: POJO's. Using Spring in combination with JTA to control transaction scopes.
              Persistence layer: DAO's with implementations in JPA (Hibernate) and Spring's JDBC support classes.

              We use Spring as clue between the layers.

              J2EE container is Websphere 6.1.

              If we were on a EJB3 platform I would do the following:

              Web layer: Use spring to bind web controllers to EJB3 SLSB business services (we currently use Struts).
              Business layer: business services as POJO's. EJB3 annotated.
              Persistence layer: DAO's with implementations in JPA (Hibernate) and Spring's JDBC support classes. JPA DAO's would be implemented as EJB3 SLSB's so they can be injected into business services.

              The advantage with the EJB3 architecture is our case that global transactions are supported out of the box. In the non-EJB3 architecture I have to put an EJB layer between web and business layers.

              Feel free to comment on my design thoughts.

              Comment


              • #8
                Originally posted by mulle View Post
                Propagation of a transactional context is exactly what I want. I want a service in one EAR file to be able to participate in a transaction with services located in other EAR files. Do you agree that this cannot be achieved with Spring alone?
                As far as I know that is true. Unfortunately I cannot suggest another solution except redesigning the application so that global transactions are not necessary anymore.

                I guess, using the approach you sketched might work and would reduce the boilerplate code. However I would check whether the propagation of the transactional context actually works and whether Spring's JtaTransactionManager can pick up the propagated transaction.
                I just fear that the clarity of service interfaces and the traceability of problems could be reduced.

                Regards,
                Andreas

                Comment


                • #9
                  For websphere I think there is a good case that it works if you use the transactionmanager designed for websphere. Also you wouldn't need a EJB layer, if you tap into the jta transaction manager and the applications are on the same server there shouldn't be a problem.

                  Comment


                  • #10
                    It's pretty much imposible to create some kind of generic EJBExporter, the best you can do is create some kind of template engine that creates files needed for your app server based on the business interface.

                    Comment

                    Working...
                    X