You can provide optimization using Entity Beans, Session Beans or DAO (Data
Access Objects). For example, your 'access objects' can probably be actually
DAOs.
Probably in simple applications you do not need a J2EE server. The J2EE
already provides several services that would take a lot of development
effort to write and a lot more of effort to maintain.
Sun recommends several components for different kind of applications:
1. Basic JSP and servlets
2. JSP Pages with modular components (servlets, JavaBeans or custom tags)
3. JSP Pages with modular components and EJBs (same as before plus EJBs)
As you go from 1 to 3 there is an increment in Complexity but also in
Robustness.
Normally going from 2 to 3 imply using a controller, normally a servlet and
EJBs. This also provides more flexibility and separation of
responsibilities. Can you imagine a web designer working with complex
servlets to change the user interface? You can for example just update the
presentation, in this case JSPs, without modifying the controller or the
business rules. Also, if you don't like MVC, you can still use the JSP Model
1.
Finally, I do not want to tell you that this is the way to work. This is
what Sun is proposing and after all, they are the creators of all this
technologies,
Benjamin
-----Original Message-----
From: Nic Ferrier [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 14, 2001 2:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Differences between serlets/jsp and ejb
>>> "Nevarez, Benjamin" <[EMAIL PROTECTED]> 14-May-01
10:11:38 PM >>>
>Of course, EJBs allows you to optimize the database
>transactions. You can use Entity EJBs or Session EJBs
>and leave the J2EE server/container manage the
>transactions for you or you, as developer, manage the
>transactions yourself.
How do you provide an optimization like the one in my example. AFAIK
you can't. An entity bean represents a single entity - it cannot be
used to provide different access systems. This is because the concept
of a primary key, used to provide access to the bean's data is central
to the persistence mapping.
>When you are creating objects to manage this, you
>are using 'EJBs' the hard way, without using the
>advantages of your J2EE server like scalability,
>resource pooling, etc.
I don't get those things automatically you're right.
But I can design for them. My accounts app is designed to work across
many servlet containers distributing load (it relies on session load
balancing for that). Since the objects get most of their data out of
SQL there isn't much to be distributed.
Resource pooling isn't so much of an issue if you design your app
correctly either. In my accounts app for example the objects that
represent transactions are very lightweight and don't need to be
reused to achieve high levels of performance.
I do re-use resources to an extent. A single Invoice object can
represent many different actual invoices. This is just the same as
EJB.
Note that the object load is actually less than if I used an EJB
server.
>What about if you application grow from 50 users to
>2000 users?
I've designed many apps at that level of performance without resort
to EJB. There is no special reason why EJB has to be used to achieve
high performance.
What EJB gives you is an extreemly complex environment. It can do a
lot of things for you. But that complexity comes at a performance
cost. The normal way of dealing with that is to throw money at the
server hardware. That's fine but sometimes that isn't an option.
Also, I just don't believe in spending money on hardware when I can
use my brain to achieve savings.
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
