- This topic has 3 replies, 2 voices, and was last updated 20 years, 2 months ago by Riyad Kalla.
-
AuthorPosts
-
Jason PriceMemberHi
I’m in the process of learning struts and j2ee for a project I am involved in at work and I just wondered if anyone could share there thoughts on whether the design I am suggesting would be the best approach to the problem?Basically we have a dbase system that I need to convert into a web app. I am proposing to use PocketPCs with Bluetooth barcode scanners and 802.11b LAN access. This would enable the people in the warehouse to be much more efficient.
The structure of the web app we be as follows:
Struts to define the user interface for the PocketPCs via PIE. The actual business objects would be using the DAO pattern and stored as EJBs.
With dispatch (for example) I would have an invoice object that will have all necessary invoice info (including stock, etc) which is returned by a call to the InvoiceDAO ejb. The actual database access would be through jboss 4.0.0 to SqlServer 7.0 (jTDs driver). I didn’t go the hibernate route as I didn’t want to have to learn 3 technologies in 1 project!I am thinking that I could develop a separate WAR for each department (i.e. dispatch, returns, production, etc) that way if we need to redeploy we would only affect that war and not everything else (which would be the case if we one war with everything).
Am I right in this approach or are there better ways of achieving the same?
Incidentally the App Server will be jboss 4.0.0 running on Linux (probably slackware or possible fedora core 2).
Riyad KallaMemberFunky over all sounds like a very cool project to be working on. A few things I need you to correct me on though:
1) “Struts to define the user interface”, I don’t quite understand that… Struts is really a controller framework where JSF is almost entirely a View (user interface) framework.
2) InvoiceDAO EJB… as I understand the DAO abstraction pattern, DAO’s are used to abstract your persistence layer from all calling parties, weather it be servlets, EJBs, or utility classes. Then behind the DAO layer you implement however you want (JDBC, Hibernate, iBatis, etc.) so that later when you decide hand coding JDBC is for the birds you can switch to Hibernate and not have to change any EJB code. So it looks something like:Web APp > EJB > DAO > (Persistence mechanism) > RDBMS
3) When you decide to learn Hibernate, buy the Hibernate in Action eBOok or hardback, its EXCELLENT. I think in 2 solid days of reading and getting through chapters 1, 2, 3 and 4 you will be drooling about Hibernate. The book is written excellently IMO, really covering everything in a very natural flow with good details.
4) Separate WARs, sounds like a good idea. Modularity is always nice when you need it.
Your over app design sounds great though, can’t really think of any other way I’d approach it… maybe I wouldn’t do the EJBs, but I don’t know what your user load will be like.
Jason PriceMember1) I meant only that I am using the struts taglibs in the actual jsp pages instead of jsf ( I looked at jsf but there is so much more info about struts that I thought I’d be confusing the issue – also there are only 2 other developers here and we all know java & html).
2) That’s is what I am trying to do I have business objects (Invoice, in above example) that is created by the data factory (InvoiceDAO), the factory is called via the ejb (InvoiceEJB), this EJB provides access to all invoice methods, events, data, etc. The thinking behind this is that if I implement the DAOs as POJOs the I (as I understand it) will have to embed them in each of separate war files. If I have to change one of them after deployment the each war will need to be recompiled and redeployed; by implementing local interface EJBs (for the moment) I only have to redeploy the ear file.
3) I will definitely be checking that book out thanks. The other reason for not implementing Hibernate is until we have got rid entirely of the dbase system I cannot add/change any fields without breaking it (it doesn’t support things like varchars,binary,indentity,null,etc.) so I have to implemented with as few database changes as possible. I couldn’t see how to get around the fact that hibernate needs its own PKs (or if I defined a custom one how I would implement it for our schemas we have to exclusively lock the whole table and do a select max(is)+1 to get the new PK when inserting records. So for simplicity sake I use the existing procs and views we already have.
The user base is about 100-150 people internally but eventually this will also form the basis for redeveloping the new website which currently has about 1000 concurrent connections for most of the working day/week.
Thanks for your comments, I wanted to check I was understand the technologies involved correctly.
Riyad KallaMemberHonestly it sounds like you have a very firm grip on all the technologies involved, thank you for the clarifications as well.
-
AuthorPosts