Don't bet on it. Beans (or to be more general: "non EJB Java classes")
still have many uses within and EJB environment. It would be inefficent to
use EJB's for every little class used in your application. A suggested
architecture would be to use EJB's where you would want to take advantage of
their built in abilities (transaction management, container managed
persistance, distributed architecture, instance pooling, etc.). EJB, like
MTS, grew from ORB's and TP Monitors. That is the purpose they serve.
Non-EJB java components have a purpose also. They can be used as value
objects, dependent objects, data access objects, or any objects where you do
not see a need for EJB. In other words, they have their advantages too (as
anyone who's worked w/ EJB will tell you). If you would like to check out
some code, get a hold of the pet store demo. Sun and other app servers use
this as an example of the EJB framework. The Designing Enterprise
Applications w/ J2EE blue prints are worth a look too.
-jacob
-----Original Message-----
From: Apollo Mcowiti [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 05, 2000 6:13 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB and JavaBeans
Thanks.
seems then SUn will replace beans with EJB , given the advantages of EJBs??
-----Original Message-----
From: Alex Strasheim [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 05, 2000 4:54 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB and JavaBeans
> Apart from EJB being a "biz" bean what functional differences exist
between
> the two?
(I'm not a guru, so I could be wrong...)
Normal beans are just plain old software components. They let you
take code out of your JSP page so your web designers won't get
confused, and they can communicate with other JSP pages that live in
the same JVM on your application server.
EJBs are specialized components that can count on having a variety of
services available from an EJB container. Those services make the
components well suited for distributed enterprise computing. The EJB
containers make it possible for EJBs to communicate with processes on
other machines in a secure and orderly way. If you wanted to do the
same sorts of things on an MS system, you'd probably use MTS. And if
you wanted to make a scalable JSP system, you might need to use EJBs
so that pages running in different JVMs can communicate with one
another.
I looked at an EJB book at the store, but the first thing it said was
that it was a hard subject to tackle, so I decided to spend more time
with JSP and plain old beans before I dove in to EJBs. They do seem
to be easier to figure out than MTS, though, although I say that as a
person who hasn't learned either technology.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
