Document displayer architectural question

I am thinking of working on an online homework submission system where students can upload their text documents that can viewed by somebody(Teacher/Professor) with viewing rights. This person can annotate/mark up/highlight this document and then can pass this document on for further review. After the review is done, this document is sent back to the student with proper feedback.

There are a lot of moving pieces here and I am having a tough time trying to figure out where to start. I am using this project as an exercise to design a scalable/secure/fast web-application using entirely open source tools that supports des开发者_StackOverflow社区ktop like user experience but besides the UI-framework(Vaadin) and language(Java), I am having a little bit of trouble figuring out the roadmap needed to make some progress with this.

It will be great if the SO gurus can mentor me through this or provide me with a nudge in the right direction.

Edit: Thanks for the response. This is the standard three-tiered architecture that was described in the response. I need massive scalability and since the application will be primarily document centric and I may have to retrofit search at some later date, I would like to steer away from RDBMS. Since we have a massive amount of users posting their documents at any given time(lets say *.txt) files for the time being, I would need some kind of message queue to process this massive information influx. There has to be some kind of a fast transformation layer that takes the documents in all its formats and displays it in a format suited for annotations and markup....and the list goes on. Starting with the Domain model and moving down would be ideal but I am a little bit of a skeptic.

I'm a Java guy. How I would approach this problem will be,

1. Figure out the data model. What are the Objects that the system will be using.
2. Based on that design your database. You can use ORM frameworks like Ibatis or Hibernate ( Ibatis has a code generator which generates pretty much all the DAO's to access the tables. It gives you the CRUD methods and you can add on top of it).
3. Once you are done with that, then you can start designing your service layer. Its not a good practice to expose the DAO's directly to the controllers( MVC pattern). This is where your business logic should go in.
4. The choose one of the web frameworks available. The most popular java web frameworks are Spring MVC. You can also try Google Guice.
5. Final step will be to design your front end. I think your project will include a lot of javascript. So look into JQuery or EXT JS

I hope this helps you to get started with.

Not really a "full answer" but hopefully some food for thought.

I am using this project as an exercise to design a scalable/secure/fast web-application using entirely open source tools...

That's a great thing to be doing - so my question would be why worry about the architecture? I admit this is a bit strange coming from someone who see's themselves as an advocate for architecture, but "learning architecture" and learning new technologies can both be demanding. Maybe you just want to get up-to speed with one first, then tackle the other?

Architecting, designing and building a system that is "scalable/secure/fast" isn't trivial. In a "real-world" business driven case you'd have a system context to fit in with, and non-functional requirements to hit: these might suggest a different technology stack. Different key drivers will have a huge affect on how you approach things and what decisions get made - and of course the architecure would be built around that.

Edit:

I'd start with what was more important to you; then as I start on the "other" topic I'd be constantly checking what I'd learnt / my assumptions.

Depending on the two subjects there might be some "synergies" which suggest a different approach. Part of me wants to recommend doing enough on one to get a good basic grasp and then bring the other one up to a similar level - then move on. That way you're kind of more consistent.

Another part of me says - just do what's most interesting!

Should I plumb the depths of a given technology stack before moving forward or get the blueprint right from a tool agnostic standpoint?

As a start, you'd definately want to get a broad but shallow view; maybe go into some specific areas in a little more detail if they were of particular importance to you.

Or is my blueprint going to change because of the technology constraints?

By this I'm assuming you mean that: if you discover a "given technology works in such a way" and how it works it different form what you were expecting - then will this affect the blueprint?

It could do - that's why a broad but shallow view of the relevant technology should help you avoid the worst / most obviously bad mistakes. I'm also assuming that you have enough overal experience to know what you're looking at when you start doing this - that you can recognise an area that needs more detailed study before committing to a design.

At a high level, all you're looking to do is ensure you're not restricting options further down the path.