Results 1 to 10 of 10

Thread: EjbServiceExporter?

  1. #1
    Join Date
    Nov 2007
    Posts
    6

    Default 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. #2
    Join Date
    Jun 2006
    Location
    The Netherlands
    Posts
    13,624

    Default

    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.
    Marten Deinum
    Java Consultant / Pragmatist / Open Source Enthousiast / Author


    Pro Spring MVC: With Web Flow
    Conspect

    Have you read the reference guide.
    Use the [ code ] tags, young padawan

  3. #3
    Join Date
    Nov 2007
    Posts
    6

    Thumbs up

    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.

  4. #4
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    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

  5. #5
    Join Date
    Nov 2007
    Posts
    6

    Default

    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?

  6. #6
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    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

  7. #7
    Join Date
    Nov 2007
    Posts
    6

    Default

    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.

  8. #8
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    Quote 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

  9. #9
    Join Date
    Jun 2006
    Location
    The Netherlands
    Posts
    13,624

    Default

    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.
    Marten Deinum
    Java Consultant / Pragmatist / Open Source Enthousiast / Author


    Pro Spring MVC: With Web Flow
    Conspect

    Have you read the reference guide.
    Use the [ code ] tags, young padawan

  10. #10
    Join Date
    Sep 2004
    Posts
    1,086

    Default

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •