Question

I built a web-applicationg using struts2. Then I built a small admin interface in the same war.

With time the webapp grew and so the admin-interface. Now, I'm thinking to separate the admin interface from the rest of the app in a separate war

Is it a good idea ? Is there any performance benefit that I can get due to separation of the admin war and the rest of the webapp.

The admin part is mostly about making changes/updations/settings in the database, so it's not affecting the UI of the rest of the app directly. Separating it also ensures that I can make updations to both parts without affecting the other.

[UPDATE]

I cannot put admin part on local machine. It's a web-app.

Do they use the same classes? Nope, the entire package is different for admin actions and view is also separate.

How do you update them? upload war

Do you use application session? yes of course, although different sessions are used for admin & normal-user.

Was it helpful?

Solution

Separating out different parts of a web application from each other as separate wars means that one can stop and restart individual applications at the application server and possibly simplifies the access control on each application. The separate applications means that, in theory one can deploy changes to the admin (take it off line, redeploy it) while the main application is still running (note that theory is emphasized - more on this later).

Thats really about it for benefits. One might see some very slight performance increase on the admin pages because of a reduced number of sessions there. It is unlikely one would see any improved performance on the main application.

Now the implications that make this much more challenging and take away some of the possible gains.

Consider if you have a user object. This has methods on it like changePassword that can be done by the admin or the user.

Consider these two options:

  • you're using hibernate or some other orm to annotate the user table to the user object
  • you've got a data access layer running native queries against the database

You again have two options for these:

  • two copies of the user object / data layer - one in each war
  • one external jar that both wars load

Whenever you make a schema change (anything that necessitates updating the user or the data layer) you will either have at least twice as much work (reload both applications and make sure they stay in sync), or you will have to reload the shared jar and restart both applications (and if the app server is being fussy, restart it).

At the end of the day, you are going to find that you have copied the entire set of data objects (and data layer). The admin may have a few more, but likely everything that is in the main app will be in the admin.

There is a real damager of bugs if the two duplicate the data/model. Furthermore, you'll find yourself duplicating views (the admin view of a user update page vs the main app view of a user update page).

Ultimately, you'll likely find that there are only minor differences in the authorization between the two applications - you want to share the same authentication, the same data, and likely the same views. They are just different controllers for admin and normal user.

From this, its likely best to just keep it all as one application. Don't Repeat Yourself. Don't duplicate the views and don't duplicate the models.

Licensed under: CC-BY-SA with attribution
scroll top