In my project the web tier(JSPs and Servlet) and app tier(Stateless EJB) are running on the same JVM. In near future I don't see any possiblity to separate these tiers on remote machines. My transaction processing is taken care by XSQL. Do I still need to use any EJB layer in between. Instead of calling Stateless EJB I can directly call a simple Java class and hence remove the RMI overhead. If the need arise in future to use separate tier on separate machines altogather I can just plug in a SLSB and that class.
Please suggest. -ShriKant A mailing list for Enterprise JavaBeans development wrote: > Hi > > Just my $0.02/cdn, but here's the thinking we used to make the our > technology choice. > > First off, there are performance issues with each option. I am going to > assume that the coding involved is done optimally and isn't a factor in the > performance. We'll just assume that it's the underlying technologies that > determine the response time. > > 1 - SLSB using a DAO / JDO. > - Pretty good performance for an 'enterprise' application. > - Easier learning curve for developers not up to speed on J2EE as > you only > need to manage a Session Bean. All the dataside stuff usually handled by > Entity Beans (EB's) is done thorugh SQL which most developers already know. > - Tends to adds development time as you have to write all the SQL. > - You can put more responsibility on the Database to handle > queries/reports > through stored procedures to get related information. (I know I'll get > flamed for that last comment so I want to add a disclaimer that EJB 2.0 has > functionality to incorporate EB's having references to other EB's.. I just > haven't used it yet.) > - Limited declarative Security. > - Declarative transactions. > > 2- SLSB accessing EJB's though CMP or BMP. > - Performance lowers if using BMP when compared to (1), get's worse > if you > use CMP. > - You're ready to be fully distributed if you need it. > - Less 'work' if you use CMP as the tedious work is handled for you > in > deployment descriptors, and/or, by the app server itself. (No SQL to > write.. > woo hooo!!). > - If using BMP you still have to write the SQL as in (1). > - Requires all developers to be up to speed on EJB spec. If you > have the > time and resources this may be a non issue. > - You can reduce headaches by using declarative Security. You may > not be > able to implement ALL your security needs here but it usuallt takes a bit > big out of the task for you. > - Your transactions could be handle declaraitively. > > 3- Doing it all yourself. > - You're pretty much re-creating most of the functionality of the > Application Server. > - Have fun managing your transactions. > - Have more fun managin your security. > - If you need object distributiom you have to "roll your own" using > RMI etc > etc. > > My opinion. > Option (1) or (2) are starting to become the defacto standard picks in the > industry. You just have to weighall the pros and cons. > > Option (3): Yo'ure competing against Bea, IBM, Silverstream and all the > other big guns in the app server market. Why re-invent the wheel when there > are a lot out there for you to use. > > If you really need the benefits of an 'enterprise' application like > security, transactions and distributed computing.. number (2) would be the > one for you. If you really don't need the whole kit and kaboodle I would go > with option (1). > > On our current project we had to get rid of Entity Beans and use a DAO > object because of performance but, I blame that on the fact that we are > using EJB 1.1 and not the new 2.0. > > Maybe other members here have opinions on the 2.0 performance. > > Hope this helps. > > > > > 1. Using statless session bean which in turn talks to Data Access > > Objects (DAO) to do the transaction processing. > > > > 2. Using stateless session which works as Session Facade and which in > > turn talks to Entity Beans to do the transaction processing. > > > > 3. This option I haven't seen anywhere, but doing the transaction > > processing using JDBC APIs only. > > > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
