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".
