1

I am trying to create a java web application using Spring mvc. The purpose of this application is to serve different groups of users from different business units in the enterprise. So, for instance, if you think of it as a shopping experience kind of application, where the application is functionally about

  • picking what you want
  • adding what you pick to the cart
  • checking out from cart

then, I need to list plumbing items for plumbing department, electrical items for electrical department and and so on.

So, I decided to have two different schemas with identical table structure. So schema 'PLUMB' will store plumbing dept users who can use the application, and items related to plumbing in USERS and ITEMS table of the PLUMB schema. Similarly, electrical department has its own schema. That's for multitenancy on database side.

For the application/deployment side, the code of the webapp remains the same except for the one property that tells that application which schema it needs to query (this would be obviously different on each instance). So, I am thinking about deploying

Are there any known anti patterns to this kind of architecture? I see one down side is that I will now have multiple environments to manage - like dev.mycompany.com/plumbingapp and test.mycompany.com/plumbingapp. Other than that, I think this allows for cleaner separation than having one single app that authenticates the user and then asks him to pick from which department he wants to go to and depending on department he picks, I would populate the webpage.

Have you used this kind of structure before? Are there any known down sides to this kind of design/architecture? If I deploy multiple instances, is it a multi-tenant application anymore?

Jay
  • 2,394
  • 11
  • 54
  • 98
  • why is it that some questions get no views? .. like this one for instance. another one that I asked just got 50 views in no time and it was tagged under java as well. – Jay Aug 24 '15 at 15:32

2 Answers2

1

depend on user and his rights, after his login, you will create /plum or /electrical modelAndView. In your DB you may create tables plum_table and elec_table, except for user table and user_roles. The other way is to create virtual machines and proxy to different machine depend on /plum or /electrical

Milos
  • 66
  • 3
  • 8
  • well, technically, each app has its own users. So, I just have to setup users for each app through admin screen OR have one central webapp that manages users. Either way, each app will have its own users table to authenticate against and verify for roles. – Jay Aug 24 '15 at 16:33
  • is there any particular drawback to my approach, other than ending up with multiple environments and war file work directory copies on application server and also the memory requirement increasing with same libraries loading again for each instance. – Jay Aug 24 '15 at 16:33
  • If you keep all user in one table and create one war file for both app it will be easy for you to programm. Also you may to create two war file, but you can not use the same packates. class for one must be com.plum and othe com.electrical. and you must wrote twice the same functions for user. On that way you can create two user table plum_user and elec_user – Milos Aug 24 '15 at 17:04
  • this is not true. Both applications have the same view, so I don't need a different package in code. What is only changing is the data on the screen. – Jay Aug 24 '15 at 17:57
  • If you plan to have two war file, you must have two class, but if you have one war file, you need one view, and it is easy for you. – Milos Aug 24 '15 at 18:07
  • You are wrong. Each webapp gets its own classloader. – Jay Aug 24 '15 at 18:38
  • Ok, you right. If you have http://mycompany.com/plumbingapp/login and second http://mycompany.com/electricalapp/login. On that case you have one controler for any war. – Milos Aug 25 '15 at 16:19
0

The approach listed in the question suits well for two or a few tenants. But not easy to scale.

There is no need for a separate deployment bundle. The tenant identification and separation can be at only DB schema level, roles and any business rules. And the rest of the System components can be common. There is no binding reason to create a separate app for each tenant.

These posts can help help:

Databse architecture (single db vs client specific db) for Building Enterprise Web (RIA) application on cloud

Architecture for SaaS based online portal

Community
  • 1
  • 1
techuser soma
  • 4,766
  • 5
  • 23
  • 43