5

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.

coding_idiot
  • 215
  • 2
  • 10
  • 2
    Decoupling the admin will make it easier to maintain, but decoupling something is never as easy as it first looks. – Reactgular Sep 30 '13 at 11:50
  • When doing so, you can deploy the "Admin"-war in your intranet, so it will not be accessible via your public webapplication-war. If this is an advantage or disadvantage is up to you. – Uooo Sep 30 '13 at 12:12
  • Do they use the same classes? How do you update them? Do bad things happen if the versions do not match? Do you use application session? –  Sep 30 '13 at 12:34
  • I've updated the question. Please see. – coding_idiot Sep 30 '13 at 13:49
  • @coding_idiot you mention making changes/updates/settings in the database? Are you using an ORM like hibernate or other data access layer? Typically these will have classes to map java objects to the database or queries to the database. Where is this stored? Do you create a `user` object in both admin and regular side for, say, resetting a user's password? Is this user object created twice? once in each war? or in an external jar that they both share? –  Sep 30 '13 at 13:54
  • Also keep in mind that if the WARs need to comunicate to each other they will have to do so by webservices/EJB alike and that means serialization/deserealization which adds overhead. – Alfredo Osorio Sep 30 '13 at 17:42
  • as of now, there's almost no communication between the admin part and the other part. – coding_idiot Sep 30 '13 at 21:32

1 Answers1

3

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.

  • thanks for this perfect answer. It was really an eye-opener. My main reason was some performance gain that might happen, but it seems there won't be any and it'll get buggy. – coding_idiot Sep 30 '13 at 14:50
  • @coding_idiot the point where it becomes useful (and then you go to that external jar) is when you have multiple different web applications (/forums is one web app, /wiki is another, /game is another) and then you will find that splitting the admin functions out to another application *may* make sense - the key thing to remember in this though is to keep common functionality in a common spot. –  Sep 30 '13 at 15:08