An EJB Architecture to manage failover/load-balancing

Discussions

EJB design: An EJB Architecture to manage failover/load-balancing

  1. Hi All,

    Here is a draft copy of an Architecture I putting together.
    The main requirement of the Architecture is performance combined with failover and load blanancing support.
    I would like any of you familiar with EJB architecture to look at the diagram and see how I am using EJB's to work off a local database, a database which is local to the Application Server and holds a copy of data taken from a remote database. Each user will have ther own copy of data and I am hoping the use of EJB's will give me the failover and load-balancing support I need. Any critial session data and all resultsets from the remote database will be mapped to EJB's.
    One thing I have not shown is how to transfer updates back to the remote database.
    Is what here a good start?

    You can view the draft copy of the architecture here.....
    My EJB Arch - Draft
  2. A couple questions that are not a 100% clear by reviewing the diagram.

    Why are you putting business logic into your sevlet? It seems as though you are roughly trying to implement the MVC design pattern, but in MVC business logic is handled within the EJB Container. This may just be a confusing point on the diagram.

    I am not sure what you are trying to to do with your UDB, from the picture you are making copies of the remote database, but I am not sure for what purpose, are you creating a "cache"? You may just want to use session beans for the cache purposes.

    What is the purpose of the RSManager? Why is it needed, will this be run in RT (real time)?

    Why do you have a query_bean and a proc_bean not sure what they are used for or how they affect the architecture?

    These would be the questions I would ask when reviewing this architecture.

    Also, the diagram doesn't really show anything about fail over and redundancy, I am assuming you are using an application server that provides clustering and load balancing like weblogic, or you are putting your servers on top of some kind of hardware cluster. I would draw two pictures, one showing the failover and clustering and one showing the software architecture (which is what you are showing in this diagram)

    just my two cents worth
    rich

  3. Hi Rich,

    thanks for the reply.....
    I have tried to answer some of your questions below.

    <
    As you indicated I am using the MVC pattern. There will be no logic in the Servlet, it just processes control between command/business/display. The Command object will use the Servlet to access the Business Object, Business Objects hold any business logic not inside the EJB layer, (Herer the EJB layer is Primarily used for Data).


    >>>I am not sure what you are trying to to do with your UDB,

    Yes it is a cache. I cannot use Session Beans as they die with the Session. The only way I can protect my Session and user data, which is quite large, is by storing it in an Entity Bean. These Entity Beans will be mapped to UDB.


    >>>>>What is the purpose of the RSManager?
    The RSManager passes the ResultsSets returned from the Query and Stored Procedures to UDB. This is quicker than doing a ejbCreate for each row in a ResultSet.


    >>>Why do you have a query_bean and a proc_bean not sure >>>what they are used for or how they affect the >>architecture?

    These are Stateless Session Beans that are pooled on the Application Server. They are used to run the Queries and Stored Procedures that are required to get the ResultSets needed to populate the local data cache sitting in UDB. Access to this data cache is only achieved via Entity Beans.


    >>>Also, the diagram doesn't really show anything about >>>fail over and redundancy,

    WebSphere are the App Servers running in an Edge Server managed Application Server Domain. The EJB part of the Architecture is there for failover reasons, i.e. anything in an Entity EJB will survive when an App Server is Nuked. So my EJB part is my failover. WLM is also managed by the Edge Server. Session and Entity Beans can be Spread across the Application Server Domain giving better performance, etc.


    Does this all make sense?

    Stephen
  4. For clarification purposes I would put the business objects within the EJB layer, because techinically if I understand your business objects will be session beans that perform business logic.

    You are using a resultset cache which is interesting, but that means if I am understanding that many users will be performing the same queries, and you want to see if the query has already happened and then give the result set to that user, if I am understanding your comments. I would caution you that this could become very large, how are you going to "key" the entity beans to know if the query has already been performed?

    I am still not sure why you are seperating query and stored procedure beans, from your comments basically you have a bean that queries your remote data store, creates a result set then creates an entity bean that holds that result set.
    How were you planning on handling updates to the data? Are you going to update all result sets with that data, and the remote store? I assume that you do not have any other process that can come behind the scenese and update the remote database, because if you did wouldn't that invalidate all of your "cached" data?

    Again, I would suggest drawing another supporting diagram depicting your tiered architecture approach using Edge Server and Websphere, which shows load balancing and failover.

    rich

  5. understanding that many users will be performing the >>>same queries

    >>>I would caution you that this could become very large, >>>how are you going to "key" the entity beans to know if >>>the query has already been performed?

    Each user will have their own copy of data in each Entity Bean. Entity Beans will have the Sessionid and user id as part of their key.
    Whats the limit on Entity size? Is there one? They are persisted out to a Database.
    Each user will be looking at between 100 and 10000 rows from each Entity...........

     


    >>I am still not sure why you are seperating query and stored procedure beans,
    These Stateless Session Beans are Generic Query and Procedure call EJB's, i.e. they have no Query or Proc calls statements hard coded in them, you pass them the parameters for your Query or Proc call.....We can use these SSB's in any application.

    >>>How were you planning on handling updates to the data? >>>Are you going to update all result sets with that data, >>>and the remote store?

    The updates go direct to the remote store and then update the user Entities on the 'local' UDB database.


    >>>I assume that you do not have any other process that can >>>come behind the scenese and update the remote database, >>>because if you did wouldn't that invalidate all of >>>your "cached" data?

    Yes.....It a risk thats there no matter how you handle an off line cache. Remember I looking for performance here by having each user working off a local database. It is agreed that this risk is acceptable, we would need to develop an DB cloning process to get around it and the time-frame ain't there.


    >>Again, I would suggest drawing another supporting diagram >>depicting your tiered architecture approach using Edge >>Server and Websphere, which shows load balancing and >>failover.

    You can find an example topology here

    Failover WLM Topology
  6. Err..........it's here

    You can find an example topology here

    Example Topology
  7. Hi Stephen
       Well ;ur architecture seems different than the beaten path.Can u please describe ur project and the architecture u are using to solve the issues ; that made u design this architecture.
       I will very much appreciate ; as this will be a learning experience for me and for other readers
       Thanks
    Tim