IMO the best thing about Scenario 1 is that you can use Java inheritance so
you can write generic servlets that implement a framework of basic services
such
as authentication, session management, error reporting and logging, JDBC
pooling,
generic SQL querys, etc. So your business-logic-implementing subclass
can be very small indeed. Of course HTML presentation is handled using JSP.
For instance:
Object
|
+-- GenericServlet
|
+-- HttpServlet
|
+-- BasicServlet // provides JDBC pooling, session management,
logging, error reporting
|
+-- AuthenticatedServlet // provides authentication
| |
| +-- YourAppLogicServlet // your app logic goes here
+-- AnotherAppServlet // app with anonymous services
Regards
Javier Borrajo
www.tid.es
>I guess it depends on your requirements but very quickly two scenarios that
>I can think of.
>Scenario 1
>For large applications I would base it on MVC architecture, ie EJB(Model),
>JSP(View) and Servlet(Controller)
>
>1) html form passes user request to servlets
>2) servlet passes parameters to JSP
>3) JSP gets data from EJB
>4) JSP generates HTML and sends it back to user.
>
>This is a scalable solution albeit a bit more complicated to design and
>implement.
>Scenario 2
>For small applications typically a RAD prototyping effort I would eliminate
>the controller, ie servlet and use the following approach
>
>1) Form passes request to JSP
>2) JSP gets data from EJB
>3) JSP generates HTML and sends it back to user.
>
>This makes it easier to develop quick prototypes but is not a scalable
>solution. e.g if there are too many similar requests
>with authentication required in each then it gets very messy doing this in
>the JSP. Servlets are better designed do handle them.
>
>Vivek
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
