1. One design to minimize code changes on the web tier (servlet/jsp) caused
by changes in component models (eg. moving from regular java beans with
business logic to EJB or Corba)is to have the web tier use a facade.
The facade could be an interface which defines all business methods needed
by the client (which in this case is the servlet).
You could then implement the interface using ejb, corba, etc. This hides
details like getting the jndi context, or looking up the EJBHome away from
the web tier. To use a business component the servlet only needs to
instantiate the correct implementation of the facade. If the component
model changes, no changes are needed on the web tier except for getting the
facade reference to point to the correct implementation.
2. I'm not sure what you mean by single-instance session beans...Stateless
session beans are preferred over stateful session beans since stateless
beans are not dedicated to one client (each client get's one stateful
bean...imagine 1000's of customers....) and don't require activation or
passivation they tend to be more scalable and offer better performance.
3. In terms of maintaing the client's state, you could use a stateful
session bean, keeping it's reference in the HttpSession object, or, you
could keep you domain objects (eg. order, product, etc ---implemented as
regular java beans) in the HttpSession and pass them into your stateless
session bean(s).
Albert
-----Original Message-----
From: Kevin Duffey [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 24, 2000 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Thin beans in model 2 - revisited
Hi,
<snip>
<snip again>
I posted a question on this a week or two ago and don't recall seeing a
response. My email was down for 3 days so maybe some came across..so I
apologize if this is a repeat.
I went to a seminar on JSP/JavaBean/EJB use not too long ago, and from my
understanding, on the EJB side of things you have entity beans and session
beans. Ideally you want to use single-instance session beans and store the
session information in the HttpSession (if this is correct or not, please
elaborate). So, based on all the discussiones of Model 2 and action classes
we have been having, I figured the best thing to do was create and populate
a JavaBean in the action class from the request object, then pass that
object to the EJB session that performs the logic. It would then modify the
contents of the bean via its get/set methods, and then return the bean back
to the action class. The action class would then forward it on to a JSP page
for viewing. Ofcourse..the details are left out, but my question then as it
is now is, how would you pass a JavaBean object created (or retrieved from
the HttpSession) to the EJB, and then get it back again without creating yet
another bean? I apologize for I don't know the EJB spec very well, and it
would probably clear this up, but I don't have the time to read up on it
right now, yet I find myself trying to write a proposal for converting our
site to Model2/Action/JavaBean/JSP with the design including the ability to
easily incorporate EJB down the road.
On that note, I figured my action classes would be nothing more than
"adaptors" if thats the right term. They get passed the request, get or
create a bean and using a "static" helper method populate the bean with the
request parameters via introspection (like how a JSP engine does with a
JSP/Javabean and the property="*" setting). Next, the action class would
call one of our local "logic" classes (we call them session classes because
on multi-page forms, we do store them in the HttpSession) to perform the
logic using the bean fields set by the request object, and filling in more
(from results) or modifying existing ones. Later on, we could move those
"session" classes to the EJB side and just pass the JavaBean over to it and
get it back modified. Last thing that occurs is the JSP page is forwarded
to, to display the JavaBean fields dynamically.
So, is what I am trying to do and propose to my boss a flaw in design? Or is
this the right way to go? I realize there are many opinions and choices, but
ideally I want to figure out how to redo our front-end server-side stuff
from multiple servlets and JSP/JavaBeans (with logic in the JSP page to call
javabean methods) to one where ALL forms are submitted to one instance
controller and farmed out to instance action classes (as Craig and Daniel
have described..using a hashtable or whatever to store the single instance
of each class) through the lookup of an action name.
I would appreciate any ideas back on this before I submit my proposal on
Friday. ;) Sure would make it look better if I knew exactly what I am
proposing.
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
===========================================================================
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
