I am designing a simple order system which will allow a user to view current orders and to add or delete orders from their account. I would like to run this past the experienced users of this forum and get feedback on whether or not I am thinking straight, or if I should take a different approach. This is my first time designing a Struts application, and using EJBs, so I am a bit unsure of whether or not I'm going about this in the right way.
My plan is to have Struts Actions call stateless session beans to perform actions such as authenticating users, getting user preferences, getting current orders, and adding/modifying/deleting orders from the system. As an example of my thinking below is a use case and my current ideas on how to tackle it.
The use case is a user logging in to the system, and upon successful authentication having a new page display the user profile information (name, organization, etc.) and a list of pending orders.
I plan to have a Struts Action class (LoginAction) mapped to the action of the JSP login form. The LoginAction will lookup a session bean which will have a business method to authenticate the user against a LDAP server or database of users. If the authentication succeeds then the LoginAction will call another business method of the session bean to find the user's profile and preferences information as an entity bean (via findByPrimaryKey()), and get a collection of entity beans which will represent the orders. So now there will be one entity bean with the user profile information and a collection of entity beans which represent the user's orders.
This is the point where I am very unsure of things, assuming the above is the correct approach in the first place.
How do I maintain control of these beans -- do I add the component interface references to the user's session as attributes ? Or do I want to get the beans' handles and store these in the session ? The session bean will get the profile entity bean and the collection of order entity beans and pass them out as return values to the LoginAction class, but will they still be present on the server for use once the LoginAction completes and passes control on to the next JSP page ? Since they're entity beans they're not tied to any one user's session (right ?), so how will a JSP or another Action class know how to access these unless they are tied to the user's session as attributes ?
How do I access these beans on the JSP page that I redirect to once the orders and profile are found -- is it as simple as just using <jsp:useBean> ?
Another consideration is how do I deal with the collection of entity beans on the JSP page ? What I mean is that I want to go through the collection of entity beans which make up the orders and print the order items on the page in a table, something like "for each order bean in the collection of order beans print order id, order item, order amount, order price, etc.". It doesn't appear that there are any facilities for doing this sort of processing of collections of beans, in that you only have jsp:useBean at your disposal, and this is for single beans, not collections of beans.
Any feedback will be greatly appreciated, thanks in advance for sharing your knowledge and expertise.
If you have access to JAAS and know how to configure it for your app server, use it to perform your logins instead of Struts. Its one less thing to maintain.
Though EJBs are good, they make your architecture more complex, you have to balance the complexity of your architecture with the time you have to spend. Its usually better to get to market first and refactor things as you go along.
With the exception of using JAAS (which is more complicated than writing your own authentication system when you are starting) just create a simple web app with direct JDBC calls and no struts.
Once you have that working (its not going to be efficient and maintainable) you can try plugging in struts if you are going to expect a lot of changes going on in the user interface side, otherwise work on refactoring your data calls to EJBs.
When doing EJBs so SLSBs first to extract your data calls so you remove all JDBC calls from your web tier. Do the least painful things first which is to locate all your JDBC calls and push them down to the EJB tier. Note, put a lot more refactoring weight on the UI side because those get really tedious if you have to meddle with client requirements. Also when using EJBs use a cached home object (XDoclet will create this for you if you let it).
Once you have removed the JDBC calls from your web tier you now have another branch to deal with: convert direct JDBC class to Entity EJBs (or some other persistence framework) or move your business logic down to SLSB layer. To decide on this use the amount of data and users as your decision maker: if you have a lot of users and a lot of data or its getting to be that way, prioritize getting your Entity Beans created to take advantage of caching. If not move more of your existing "business" code down to the SLSB layer so you will reduce your web tier to just presentation stuff.
If you have to do the web tier refactoring you have two paths from here: extract common elements into tiles or use struts action mappings. If you have to do a lot of changes to the look and feel of your application, do the tiles conversion first, but before you do it just do simple jsp:includes then convert to tiles includes then convert to proper use of tiles.
Now if you have a client that changes their requirements for screen flow more often than styles, you should start moving to struts action mappings. Refactoring these would be easy if you are just dealing with presentation layer but if you are not so lucky, its just a bit more elbow grease. To get you started you have to map out the current site flow. You should end up with something like a state diagram. If you are just starting this refactoring I suggest you locate a simple flow (click data entry -> fill form -> submit -> go back to menu) and convert your pages to stuts pages. As you are doing this changes move your JSPs to the WEB-INF folder so you won't accidentally call these pages via JSP directly and make sure you have a 404 checker when you do these moves.
Just a caveat. These are more step by step suggestions, in real life you would probably skip a few steps just because you are more experienced and can quickly jump to the next refactoring.
To help you get started you may want to look at the maven:genapp there are a few generators to help you get started. I am not sure about the "complex" one though. But when I created the templates I was using most of the refactoring procedure I outlined above.