I am working on a very large scale web project with several other developers. We have gathered many of the project requirements, generated several design documents, have a database schema in place, and have developed several prototypes.
- Posted by: Matthew Kull
- Posted on: August 01 2004 17:51 EDT
This is our first enterprise java web project, so it is very much a learning experiences for all of us. Our lack of experience has made it hard for us to determine how to go about certain things.
One of the main problems we currently are having is what direction to go implementation-wise.
We started out developing our own framework. However we quickly found out we were re-inventing the wheel and struts had solved much of the problems we were facing.
Data object persistence was something else we planned on writing our own framework for, but again found many of our issues resolved through the use of EJB's, and recently we have been reading up on Spring / Hibernate.
One of or core concerns is the scalablity, flexibility, and maintainability of our code. We will be constantly tweaking things, and plugging in new features.
We plan to start out small, but one of our core requirements is over the next couple of years to mantain the ability to scale to something the size of say yahoo, amazon, or sourceforge.
The site will consist entirely of dynamically generated content. The site will require 24x7 uptime, be very transaction heavy, require clustering, etc.
I guess what i am looking for is a recomendation on data object persistence, and maybe a recomendation on other technologies to look at. Though what we really need is some more experienced developers looking over our shoulders.
I know it is hard to make a recomendation based on the flaky description and requirements given here, so if any developers have the time for a more lengthy and detailed conversation please contact me here or at [email protected]
- Large Web Project - What technologies to use by Stephane Vaucher on August 02 2004 02:37 EDT
- Large Web Project - What technologies to use by Robbie Stewart on August 04 2004 18:11 EDT
- Large Web Project - What technologies to use by Robbie Stewart on August 06 2004 06:41 EDT
- Large Web Project - What technologies to use by Alex Reznikov on August 20 2004 00:16 EDT
If this is your first at an enterprise application, keep it simple. Figure out what is the minimum you need, implement it as simply as possible and make sure everything is testable and mesurable. When first applying new technologies, chances are that you'll make bad decisions or use them incorrectly, so make sure nothing is too big, that it can't be fixed.
My last large enterprise app dates back a while. It was done with EJBs and performance was horrible. I currently use Hibernate and performance is decent and dao classes are more easily testable (no need of a container). I haven't had to tweek it much, so I don't know how well it can scale large-scale projects.
Fear not, though, experts should be lurking about...
I must say that you seem very optimistic with your sales targets. Bon Chance!
We delivered a major online system (30,000+ users) in 4 months (development + testing) which has been running 3 months now with zero maintenance and no downtime. We used the Spring Framework top to bottom after coming from a handcoding EJB background. I would never willingly go near EJB again having gone through EJB hell in the past two years. Our management think we are now the bees knees and we have shaken off our reputation for not delivering (using RMI/EJBs). With Spring, your productivity will soar. There's no need to deal with EJBs, although we do wrap our manager/service objects in SLSB Spring wrappers. We only program to interfaces and only using POJOs. Spring WebMVC is similar to Struts but simpler in that you do deal directly with domain objects, though I feel that the (extendable) Spring MVC classes could offer more. I can't comment on Hibernate, as we for the moment wish to handcode our SQL; again if you use Spring you can substitute Spring DAO layer with whatever you wish at a later date.
Don't develop your own framework. We lost three months doing this ourselves prior to going with Spring.
Our other biggest boon was TDD, we know our code is bomb-proof and using arrays of HttpUnit tests using 1000s of mock users with JProbe proves we can survive high hit rates. We are using JBoss 3.2.2
Robbie I will definetly be looking into Spring after reading your post. I am impressed you were able to deliver that system in four months, how many developers were working on the project?
I do not know much about spring, but I have only heard good things. Would it be feasible (or make sense) to use a combination of spring / struts? What would be the advantages to this?
I agree with you on TDD, we will be using JProbe heavily.
Thanks for the replies!
Matthew, some figures; we had 1 full-time consultant for four months, three dedicated programmers (one ex-EJB, one JSP, one ex-Swing/RMI) plus contribution from four others. We are a typical Windows dev/unix deploy site using JBoss 3.X, Ant, JUnit, HttpUnit, CruiseControl, CVS, JEdit. We only paid for JProbe - this is a lifesaver and you need to use this early on. Our UML docs are limited to detailed class/use case diagrams, I feel complete RUP etc would have hamstrung us for a small dev group like ours. We really only went for Spring WebMVC because we felt it was easier to stick with one system, not because it was superior to Struts. Spring WebMVC has a neat typed object mapping from web page to domain object. Struts is probably more mature, extending Spring's web 'wizard' can get a bit ugly and I expect it to improve. Configurable IOC is a boon, this is where productivity rises, no more callbacks, EJB exceptions, value objects, jndi lookups, facades or in-container testing. EJB3 seems to be going this way, but we can't wait for it. Best of luck.
If I were you I'd hire one or several experienced J2EE contractors to contribute to the development, and certainly a J2EE architect to help out with the design. I've seen a couple of projects where none of the team had previous experience with the technology yet everyone was keen to try it out - and the outcome wasn't very encouraging. It's even more applicable if the project you are about to start is large.
Best of luck,