Best Architecture choice for my web application

[johnhunsley]

Hello,

I have a medium sized web application which currently runs in tomcat. I'm looking at clustering to give me fail over and load balance. I could just go ahead and cluster it as is but as more functionalty comes along the application is starting to look a bit big and clumsey.

I want to break the application up into various sub projects / packages , tidy up the struts web tier and implement a proper DAO layer down at the bottom. I want each one of my sub projects to be nice a loosley coupled through a container so that one does not depend on the other.

I want a simple container which will let me plug in Hibernate and take care of my persistence, keep the web tier seperate and hold all my other business layer sub packages together without any dependancy to the container or each other, (well, as much as is possbile). I don't particularly want to get bogged down with EJB, just nice simple POJOs in my business layer. The whole thing must be very easy to scale horizontally, so when I get more and more load I can just stick another server on with no fuss.

Okay, I'll get to the questions now! Should I -

1) Use JBoss as my app server implement Hibernate as a service, web service as a war, everything else jarred up and all dumped in an EAR?

2) Stick with tomcat and use Spring or maybe nanocontainer, again implementing Hibernate through the container?

3) Not bother with a container and just refactor my current code, splitting it up into sub projects each as a jar and war the whole thing up to be dropped into tomcat as currently is the case?


After reading up and having a play with JBoss, Spring, pecocontainer I favour number 2. Even JBoss seems a bit to heavy weight, I don't really see the point unless I'm using EJB. Can I use Spring simply with tomcat? If so, whats the deal? Does Spring just go into the war as any other jar? Will it deal with clustering the application when I cluster tomcat?

Maybe I'm asking too general a question here, but any input would be greatly appreciated.

Thanks.

John.

[dejanp]

Yes, you can use Spring with Tomcat, it's a library like any other. Tomcat clustering is a low-level concern and does not influence your application, with or without Spring.

[karldmoore]

I have a medium sized web application which currently runs in tomcat. I'm looking at clustering to give me fail over and load balance. I could just go ahead and cluster it as is but as more functionalty comes along the application is starting to look a bit big and clumsey.

If you already know and use tomcat, I'd be tempted to stick with it. If it currently works for you and supports where you are wanting to go it seems like a good choice.

I want to break the application up into various sub projects / packages , tidy up the struts web tier and implement a proper DAO layer down at the bottom. I want each one of my sub projects to be nice a loosley coupled through a container so that one does not depend on the other.

Refactoring the code and consolidating what you've got, is a good thing regardless of what approach you take. If your program to interfaces and use Spring for DI you should be able to achieve a nice separation.

I want a simple container which will let me plug in Hibernate and take care of my persistence, keep the web tier seperate and hold all my other business layer sub packages together without any dependancy to the container or each other, (well, as much as is possbile). I don't particularly want to get bogged down with EJB, just nice simple POJOs in my business layer. The whole thing must be very easy to scale horizontally, so when I get more and more load I can just stick another server on with no fuss.

Spring has support for EJB if you ever want to go there and the Hibernate support is very easy to use. Theres a whole host of support for various web tiers.

The whole thing of horizontal scalability though is a little more than just throwing hardware at it. Spring, Hibernate, EJB, Tomcat, JBoss aren't going to make your application scale. There is lots of work there to ensure its capable of doing it in the first place; testing, measuring, tuning, fixing. Regardless of how its deployed you need to sort out these issues.

I may be naive in this, but I'd like to think that the whole Tomcat/Jetty/JBoss thing is less important in the overview of the whole thing. If you can make it scale, it should realistically scale on the different platforms. Granted there might be some platform specific tweaks and settings required, and the whole test, tune, fix. I'm not suggesting write it for Tomcat and ship on JBoss but you get the idea.

What kind of numbers are you trying to support?

[johnhunsley]

What kind of numbers are you trying to support?

Many thanks for your feedback. I'm looking at up to 500 - 1000 concurrent users for this architecture. I have gone quite a way down the path of clustering Tomcat so I think I'll take your advice and stick with that. If Spring will do what I want on the application level, that is nice clean loose coupling between multiple small packages, and so long as I can scale up relatively simply with another Tomcat instance then I'm good to go.

If i were to cluster now then I would have to implement Serializable for all my business objects, Does Spring deal with that for me or do I just develop as if Spring wasn't there. i.e. just build each small package to stand alone, ready for a cluster, then let Spring bind them together?

I guess I need to start clustering from scratch to know these things.

Anyone else clustered an app' in Tomcat and Spring?

Many thanks again.

John.

[karldmoore]

If i were to cluster now then I would have to implement Serializable for all my business objects, Does Spring deal with that for me or do I just develop as if Spring wasn't there. i.e. just build each small package to stand alone, ready for a cluster, then let Spring bind them together?

The last project I worked on had less than 5 classes with Spring imports (XML is code argument ignored). I tend to develop without thinking about Spring (I mean that in a good way), just write my code and add the configuration. Obviously if I really need to extend something its there, but thats usually the exception rather than the rule.

I guess I need to start clustering from scratch to know these things.

Anyone else clustered an app' in Tomcat and Spring?

There are some really good articles on the net regarding clustering tomcat (I found them very useful). The whole experience wasn't that painful.

[johnhunsley]

tend to develop without thinking about Spring (I mean that in a good way), just write my code and add the configuration.

does the same apply with regard to persistence? Should I just go ahead and create a nice simple DAO layer, as I would with a medium sized app', then let Spring deal with it when I come to glue it alll together? For example, I would like to start by building a persistence manager for each sub project, creating my DAOs all programmed to interfaces. Obviously programming to interfaces is good but do I need to bother with the managers or will Spring deal with that?

Thanks,

John.

[dejanp]

Many thanks for your feedback. I'm looking at up to 500 - 1000 concurrent users for this architecture. I have gone quite a way down the path of clustering Tomcat so I think I'll take your advice and stick with that. If Spring will do what I want on the application level, that is nice clean loose coupling between multiple small packages, and so long as I can scale up relatively simply with another Tomcat instance then I'm good to go.

If i were to cluster now then I would have to implement Serializable for all my business objects, Does Spring deal with that for me or do I just develop as if Spring wasn't there. i.e. just build each small package to stand alone, ready for a cluster, then let Spring bind them together?

I guess I need to start clustering from scratch to know these things.

Anyone else clustered an app' in Tomcat and Spring?

Many thanks again.

John.

You don't need to make all business objects serializable, you only need to make objects you are going to store in sessions serializable (if any). Tomcat clustering doesn't mean application replication, it's basically just session replication across the clustered instances and nothing more.

[karldmoore]

does the same apply with regard to persistence? Should I just go ahead and create a nice simple DAO layer, as I would with a medium sized app', then let Spring deal with it when I come to glue it alll together? For example, I would like to start by building a persistence manager for each sub project, creating my DAOs all programmed to interfaces. Obviously programming to interfaces is good but do I need to bother with the managers or will Spring deal with that?

It really depends how you are writing your Dao layer. If you are using Jdbc, Stored Proceedures, Hibernate, Spring contains lots of helpers for this. You are obviously going to use Spring imports for this, but I think its worth the cost. Spring also has great support for transactions, either declarative or programmatic.

I'd check out the reference manual.
http://www.springframework.org/docs/...ansaction.html
http://www.springframework.org/docs/reference/dao.html

As for the rest of the architecture, I'd just keep it simple. The last couple of projects I've seen had Application/Service Layer, Domain Model, Dao. That was it. Solved the business problems in the code and left the glue down to Spring. Spring provided the transaction support.

If you look at the examples that ship with Spring there are some nice examples. Appfuse might also be a worth looking at.

[karldmoore]

You don't need to make all business objects serializable, you only need to make objects you are going to store in sessions serializable (if any). Tomcat clustering doesn't mean application replication, it's basically just session replication across the clustered instances and nothing more.

I didn't even pick up on that. What was the reasoning behind having to make everything serializable.

[johnhunsley]

Hi, yes I mean't everything on the session.

OK, thanks so much for your advice, it's been very helpful.

John.