Hi Megan,
> According to the blueprint - the JavaBeans on your Web-tier
> become "read-only," mirroring the EJB - use only to easily
> display information in your JSP page. (Craig & Daniel - please
> confirm - this is my question too.)
Seems like we got it down. :)
> I agree, this seems like a duplication - but here is the reason.
> The EJB is responsible for all application processing,
> transaction management, and session management. By isolating
> this on the EJB Tier - your application can be deployed to any
> number of clients - web/HTTP is only one. Also consider - also
> consider mobile phones, telephony, WebTV, etc. - each of these
> has a different client interface. By keeping your application
> logic completely separate - you can [more] easily add
> new/different clients. Long term maintenance becomes an option
> instead of planning to re-write your application in 2-3 years
> because technology has changed again.
I agree, accept the approach being used by most people (so it seems) is to
use STATELESS session beans. If you do this, it supposedly speeds up your
application processing in the EJB tier by a magnitude. The state is
maintained in the JavaBean/HttpSession syntax on the web server side
instead. So the EJB becomes strictly a logic tier, without state. This is
the case I am talking about. If you are using stateless beans, then why are
we duplicating the "properties" on the EJB bean. My guess is that it is
necessary to hold the data from the database, or whatever. But, if you can
pass the JavaBean on the web side TO the EJB as a parameter, can not the EJB
use the JavaBean object passed to it as well..to store what ever info it
needs. Then, when done with the logic, it passes that bean right back to the
action class that called the ejb, which hopefully is still the same object
in memory as the one passed in, so that the overhead of a NEW JavaBean
object being created is ignored. As an example, if you did something like
this:
MyBean bean = new MyBean();
bean.setXXX("xxx");
bean = getSomeBean();
and the getSomeBean method is like so:L
public MyBean getSomeBean()
{
MyBean b = new MyBean();
b.setXXX("xxx");
return b;
}
Notice you are assigning a NEW bean object to the old one. That means that
the first MyBean object created is no gc'd because the bean = getSomeBean()
changed the reference bean points to, to the returned MyBean object.
So, what I am wondering is if you do the same thing, does EJB return a "new"
object, or does the object returned from the EJB (assuming it is able to be
passed the javabean and returned it), overwrite the JavaBean you passed in,
in the exact memory location..or does a NEW object reference get created
(thus, the EJB returns a NEW object).
This is kind of confusing to write. ;)
>
> There is a good description of how to migragte from "web-centric"
> (your current model) to EJB on p.120 of the J2EE blueprint.
> It's brief - but gives you a general description of what to do
> for each step.
Thanks for the pointer. Now if I could just find out where I can get all the
blueprints. ;) I know..java.sun.com. Thanks.
===========================================================================
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
