Discussions

EJB design: Wrap Entity by Session Bean - Bad in few deployments ?


  1. I read everywhere as a good design pattern "Wrap an entity bean by Session bean - it saves you n/w traffic (atleast as one of the benefits )".

    The above statement is true if you deploy Session/Entity beans in the same APP Server. Correct me if I am wrong !

    But in my case, I have to deploy all entity beans in one WL App Server and my stateful session beans are deployed more towards the Client Layer. So, how would it reduce my network traffic ( if my session bean calls sets() and gets() of entity bean the same way my client does ).

    Isn't the standard design pattern making an assumption about the deployment here ?

    Any ideas ?
    thanks


  2. Value Objects -> Sessions Remote --> Entity Locals.

    Alvaro
  3. Value Objects -> Sessions Remote --> Entity Locals.
    Hi Mr.Alvaro, Can you elaborate on the above?
    Thanks
    Ajay
  4. Also, this is the best idea for Tranasaction Management.

    If you are going to have entities called from Command or some other controller, how are you going to manage the Transactions.

    Always Session beans and Entity beans should be coupled together. It is not good to have SessionBean in some other server and entity beans in some other server .

    As one has mentioned we can have a cluster and putting all the EJBs there .

     We always have this Session Facade in all our EJB based projects, except in WebSphere Commerce suite. In Commerce Suite we use Command Pattern , but we have Transaction Management also which is taken care by the WebController.
  5. When ever you want to some updations to the DB, Have a value object , a simple serializable Java Object and set the values and pass it to the Session Bean Remote method. The SEssion bean will call the entity beans and does all the updations . Since the Session Bean attacks the Entity beans and if they are in the same server we can avoid a lot of network traffic.
  6. Yes, you are right, that design pattern does make assumptions on the state of your deployment.

    However, from my experience, if you have two (or more) servers you would be better off deploying your session and entity beans onto each server and then move the servers into a cluster. This way you will get the benefits of load balancing / failover whilst also cutting down on network calls between sessions and entities that would otherwise exist in remote locations. In fact, if you want to run multiple EJB servers in a cluster you will need to have the same EJB configuration on each server for the clustering to work (at least, in a WebLogic environment).

    You may also want to look at having stateless session beans and not stateful session beans. Your web tier is stateful anyway (HTTP isn't but you will undoubtedly use a HttpSession object per client). If you keep your state on the web tier you will find that you will be more scalable as the footprint for a HttpSession object will be less than that of a Stateful Session Bean and you won't have to worry about hitting pool limits etc. Also, once you make the move to having stateless code you will find that the reusability of your codebase will improve dramatically, cutting down on development time, bugs, testing, doco etc.

    Just my .02.

    Cheers,
    Darren.