Hi,
>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.
Ouch. That would be a very large class. But, it is an interesting idea.
However, I can't redo the entire site..that isn't my objective. I would love
to..but there is more than just me on the team and there is no way our boss
will allow this. My goal is to rewrite the way our server-side front-end
works. Right now we are using subclassed servlets from a DefaultServlet and
the specific pages/forms call specific servlets to handle them. I am
replacing all these servlets with action classes. Most of the code in our
servlets is UI related and we use read and write methods to read in and
write out the forms using html objects. By switching to JSP, that will
eliminate most of the code, but we still need an easy way to go to EJB down
the road. Well, easy is a bit overkill..ofcourse it will be some work. What
I am trying to do is minimize the movement to ejb.
>>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.
My bad..I did meant stateless session bean. What I don't get is..whats so
time consuming using stateless or stateful? If I have to pass a JavaBean
that reamins in the HttpSession to the EJB and back, then is the speed
problem in the storage of the stateful bean? Seems to me no matter what I do
I will have to send this object from the web server side to the ejb side
anyways..so that the ejb can do the logic. What exactly is the bottleneck
here...and why wouldn't I want to use stateful session beans so that my
action class merely creates the EJB and calls on it? I know I want the ejb
side to be independent of web related tasks, so that CORBA clients can
access it to. It also makes sense that the EJB doesn't store anything
because normally a client desktop program would store the info, so the web
server Http side should as well. I think I may have just answered my
question! ;)
>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).
This seems more likely. It follows along the lines of an application that
would use centralized logic. It would still store the info, but simply pass
that info back and forth to the logic. Is this workable..in that I can pass
a JavaBean with data in it to the EJB, have the EJB modify it in some way,
and get the object back.
===========================================================================
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
