  | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
  | | | Will EJB help Scalablity, Availiblity and Preformance with/instead of JDO? | Will EJB help Scalablity, Availiblity and Preformance with/instead of JDO? 2003-12-08 - By Graham Cruickshanks
Back Hi,
I'm looking for some experienced Peer J2EE architect advice.
I've about 35 fined grained JDO objects, These map to the row level in each row of my database. There is about 6 different object graphs that represent larger entities.
>From looking through best practices with EJB entity beans, It recommends that Entity Bean should be Coarse Grained Objects and to use the 'Composite View' design pattern. The Composite View pattern uses database access object I.e. JDO.
My application preformance and scalablity are untested at the moment but I know it needs to support between 1000 and 3000 clients concurrently polling to see if they have any notification about once every 20 seconds via a webservice. Also Interactions of about 1 a minute will be sent to the server for processing. These interactions are processed asyncronessly.
Currently the architect is: (High Abtraction)
Interactions Interface:
httplistener -> Axis -> message queue (JMS)-> processor selection (java obj) -> process (java obj) -> entitymodel (jdo) -> database
Notification Interface:
httplistener -> Axis -> message queue (JMS)
So here is my question.
If I convert my app by extended its architect to include EJB objects like so
Httplistener -> Axis -> message queue -> business deligate (Plus service locator) -> processor selection (stateless-sessionbean) -> process (stateless-sessionbean) -> session fa�ade (stateless-sessionbean) -> entitymodel (Coarse Grained Entity EJB with composite pattern JDO) -> database
Q1: From experience, how will this affect non-functional requirements:
Scalablity, Availiabity, Preformance and Security?
Q2: I'll a little confused on how by adding so many more object instances, I will increase scalablity and preformance from the J2EE containers object life cycle handlers (passivation,activation). I.e. When using the 'Composite View' pattern it seems like I'm just adding an EJB for EJB sake. Can someone clarify or confirm that there is (no?) benefits in practice.
Kind Regards
Graham Cruickshanks
===================================================================Companion Site: http://www.corej2eepatterns.com J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
 |