Jerry,
> I still don't have clear in this questions:
>
> When it is better to use EJB than servlets or JSP?
> What are EJB from view of servlets?
Well, I thought about posting a reply the first time you asked,
then I thought better of it because I'm not very familiar with JSP and
EJB. But, maybe the problem is a communication problem, not a
knowledge problem :-). People usually find it easier to shoot holes
in incorrect information than to articulate correct information in a
void. Here's my take on it. Those more familiar with the
technologies can tear it to pieces.
According to what I've read so far, JSP/Servlets/EJB are a
complementary set of technologies. While you can make any of them do
some of the work of the others, that doesn't mean you have to, and
each approach is optimized (in terms of developer work) for a specific
area of problems.
- JSP is optimized for presentation.
- Servlets are optimized for a fairly narrow range of web
applications (analogous to single-user applications, that operate
in a fairly straightforward context).
- EJB is optimized for enterprise web applications (applications
meant to be used in "workhorse" situations involving lots of
persistent data, scalability, load distribution, mission-critical
performance, ease of management, transactional integrity and
security).
Sometimes you'd use one, sometimes the other, sometimes a
combination. You might use JSP alone for simple HTML pages, much the
way you'd use SSI or some simple markup tag languages (PHP, ASP, etc).
You can put some logic in the JSP, but you'd use a servlet for
situations where you want sophisticated logic, like a form processor.
That same servlet might use a JSP to display the output, by sticking
the processed data into a javabean and passing the javabean to the JSP
via a requestDispatcher to generate the output HTML.
Meanwhile, the servlet may need to do things with that data
besides generating a reply page, things beyond the immediate context.
Besides taking the form data and making sure it adds up, etc, it may
need to run it through some business rules and make sure it makes
logical sense. It may need to forward it to a system for processing.
It may need to add it to a database of requests for tracking. It may
need to do things I can't even imagine, but which would be hard to
shoehorn into the context of a servlet.
There are a number of ways you could implement these. You could
stick the data into a database and have other servlets or java
applications that then pull it out and apply business rules, another
that polls the database and forwards new requests for processing, etc.
You could just code a bunch of specialized servers to handle these
tasks and have the servlet open RMI connections to the (I've done
that, it's not much fun). But really, this is where EJBs come in.
EJB is a way of drawing lines around part of an enterprise
application and making it a component. Besides the enterprise
advantages of being able to automate distributing the component,
running it across multiple servers, etc, it also makes it easy for the
people who write the EJB environment (the application server) to
provide various services the EJB might need in a standardized format,
things like providing connections to other systems, sending email,
scheduling tasks, etc. Which means *you* don't have to write
them. This is considered a Good Thing :-).
Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________________________________________________
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
