1 Reply Latest reply on Nov 18, 2010 5:24 AM by Andreas Haumer

    Seam and remote access to EJBs

    Martin Höller Newbie

      Hi all!


      We have a JEE application that implements most of it's business logic in EJBs (stateful as well as stateles beans). Currently all our EJBs implement the local and the remote interface at the same time. Here is an example of a DAO:


      @javax.ejb.Local
      public interface PersonDAOLocal {
        // ...
      }
      
      @javax.ejb.Remote
      public interface PersonDAORemote {
        // ...
      }
      
      @Stateful
      @Name("personDAO")
      @TransactionAttribute(TransactionAttributeType.REQUIRED)
      @Interceptors({SeamInterceptor.class})
      public class PersonDAOBean extends AbstractDAO<Person, Long>
        implements PersonDAOLocal, PersonDAORemote
      {
        // ...
      }
      



      We have two user-interfaces to the application: a web UI and a java native client. In the webapp we are using Seam. At them moment we don't use Seam-managed persistence context (SMPC), but we would like to (as it's recommended in so many places).


      The problem we currently have with SMPC is that if we activate it, our SFSBs and SLSBs which then get the PC injected by Seam, can't be used by remote clients any more. In the webapp everything is working fine, but every call to a SFSB from a remote client gets a new PC, as there is no seam conversation that could hold the PC across multiple RMI calls.


      This situation seems totally logical (after some deeper analysis), but isn't there some way to take advantage of SMPC even in remote clients? The only relevant topic I could find is this one: http://seamframework.org/Community/RemoteEJBInvocationsAndSeamsSessionContext
      Unfortunately it is highly hypothetical and would include patching Seam :(


      The solutions that came to our mind so far are the following:



      • Don't use SMPC.

      • Inject a SMPC as well as a PC managed by the container and add some logic in the EJBs to use the suitable PC depending on the type of the call (local vs. remote).

      • Split local and remote implementations of the EJBs. Use SMPC for local implementation and CMPC for remote implementation.

      • Add some kind of Seam-conversations for remote clients (as mentioned in the link from above).



      Isn't that a common problem to JEE applications with Seam?

      How do others solve the problem of remote clients and Seam applications?


      Many thanks in advance,

      - martin

        • 1. Re: Seam and remote access to EJBs
          Andreas Haumer Newbie

          As I'm working with Martin in our team I would like to add some more info.


          It might not be clear from the original post, but we use a multi layered JEE architecture as follows:




          • On the top there is the UI/visualization layer which is implemented both as Web UI (local client) as well as Java native (remote client).

          • Below is the business logic implemented as SFSB

          • Further below is the data access layer which encapsulates all data access functionality (queries etc.) in data access objects (DAO) which are also implemented as session beans.





          Business logic never uses the entity manager directly but delegates all queries to DAO's.
          It's the responsibility of the DAO's to use the Entity Manager for database access.


          Local and remote clients use business logic session beans as well as DAO session beans regularily. Both clients as well as the business logic beans
          use DAO beans e.g. to retrieve lists of entities filtered and/or sorted by some criteria, query for distinct entities and add or delete entities.


          The question is: how do the DAO beans get the entity manager (persistence context) so that both local and remote clients work well?


          We currently use container managed persistence with an extended persistence context injected into our SFSB and automatically
          propagated to all associated session beans. This works with both local clients (which use Seam) as well as remote clients.
          But it prevents us from using more advanced features of Seam which are only available if we'd use SMPC. So we are looking for
          a way to use SMPC which is cleanly usable with both local and remote clients (or at least with local clients but without
          negative side effects to the remote clients)


          To put it another way: what is the recommended architecture/design regarding persistence context when using seam in a multi-UI multi-layer application with both local and remote clients?