To follow up on what Kevin said. JavaBeans and EJB (Enterprise
JavaBeans) really have nothing to do with each other. They only share
two things: both have the word Bean in their names, and both impose a
component like model on a programming problem.
I suspect that one of the reasons that JSP uses JavaBeans is to
encourage the future development of visual page design tools that allow
drag and drop JavaBean integration into JSP. Right now there are none,
but I can imagine a tool like Dreamweaver having it in the future. The
whole process may become even more likely after the 1.1 spec is
implemented.
As far as the programming models go, one possibility for enterprise
class applications is: JSP->JavaBean->EJB->DBMS. The JavaBeans would
handle the interaction with the EJBs and encapsulate the results for the
JSP. The problem with this approach is cost. EJB servers are pretty
expensive. For a simpler application, database interaction can be
managed in servlets or JavaBeans. This kind of system can be deployed
for a much lower cost.
Carles
> Kevin Jones wrote:
>
> Don't you just hate marketing!!
>
> A 'bean' is a Java component that follows certain loosely defined
> rules - mainly that it has a default (no-args) constructor, and that
> it may have set/get methods for its properties. Any java class that
> follows these rules can be thought of as a 'bean'. So beans have
> nothing really to do with UI development, although they were
> introduced originally as an alternative to ActiveX controls to allow
> developers to have drag and drop java development environments similar
> to VB in the Microsoft world.
>
> Enterprise Java Beans are an entirely different thing - EJB is used on
> the server as a way of easing the pain of developing distributed
> applications. If you write an EJB application things like
> transactions, database connection pooling and threading are taken care
> of for you. EJBs are most likely to be used for server-side code that
> needs transacted data-base access. In Sun's Application Programming
> Model (APM) the idea is that we use HTML for the fron end,
> Servlets/JSP in the middle tier and EJBs at the server, with the
> servlets talking to the EJBs and the EJBs managing all the data.
>
> Kevin
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and
> reference [mailto:[EMAIL PROTECTED]]On Behalf Of Elena Palanca
> Sent: 28 July 1999 11:05
> To: [EMAIL PROTECTED]
> Subject: JavaBeans vs. Enterprise JavaBeans
>
> Dear all,
> I'm newbi in JavaBeans and I'm thinking that I'm using them
> in the wrong way.
> From what I know the JavaBeans is a component model for
> visual construction of reusable components for the Java
> platform.While Enterprise JavaBeans
> extends JavaBeans to middle-tier/server side business
> applications. The extensions that Enterprise JavaBeans adds
> to JavaBeans include support for transactions, state
> management, and deployment time attributes.
> In my application (intranet/extranet) I started to work with
> JavaBeans as simply containers of some type of information
> (databeans), without any visual interface so I used them as
> server-side containers. After some readings on EJB I think
> that the way I'm using JavaBeans is wrong, should be better
> in my case to use EJB?
> If yes, is there someone who could give me some fast
> information to use them, (the configuration I have to
> support to work with them, IDE, some internet sites where I
> can find information, etc.)
> Thanks
> Elena
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
