I am working on designing an architecture using Jsp/Servlets and EJB's using Weblogic. What is the typical architecture that is followed? I mean, do we use Weblogic for both jsp/servlet and EJB or do we put JSP/Servlet into another webserver like Iplanet calling EJB in Weblogic?
What the pros/cons of these options?
Any insights would be helpful,
I suggest you use weblogic to handle jsp/servlet objects as well as your ejbs, but write them as if you will separate them. This will allow you to separate them if the need arise for load or security reasons. Weblogic servlet container has good speed, however, I wouldn't use it as an webserver. Serve up html and graphical content from a better webserver like apache or nes or others.
The advantage of running the two together is less network traffic is required because the servlets and ejbs are in the same context. Additionally, you don't have to use ssl between two applications servers.
That was insightful.
Ok, of course we want to seperate JSP/servlets from the (EJ)Beans as much as possible. It's not even that much a problem. But the problem (at least that's what I think) really comes in when preparing for multiple interfaces. For instance right now we have a web application using JSP's and simple very thin (normal Java, so not EJ) beans containing session information. The logic is all done via stateless sessionbeans (EJB). It pretty much works right now, but in a way (I haven't really thought about this yet) it seems to me that this pattern isn't ready to serve (for instance) desktop applications or other apps using different protocols.
So how to do a layered design with respect to both JSP/servlet-EJB seperation and to an independent protocol mechanism. Anybody ideas about this? I think this seems to be also a discussion about whether or not to use EJB's for maintaining state in a web application (instead of normal JavaBeans).
Any input would be handy :))
I've got a suggestion . . . regardless of application type (web or desktop) store state information on the client application in a HttpSession. HttpSession is really just an interface that is implemented by servlet containers. You could create an implementation for desktop applications. The result is that no matter what type of application you are using . . . the state information can be stored and reference by an HttpSession object. With this in place you can develop all ejb's that may be used across different types of clients as if you were comming in from a servlet/jsp. Think about using controller and facade patters to more decouple business logic from client connection and access.