Vertical deployment pros and cons in Jboss/MySQL - mysql

Question

I'm working on a project which has a single WAR file for each application, it is like an app store.
So 10 apps have 10 different WAR files deployed. Usually there's a DAO, BL as separate jars inside the WAR file which exposes web services.
However there are few cases where we refer to a library usually the DAO/BL from another WAR file.
I'm not sure if this is the right approach. We seem to face difficulties when deploying to figure out what versions of deployed JARs are used etc. Another approach would be to not talk to another app's JAR(DAO) but talk to the deployed web service from the client if need be.
The DAO's have a mysql-ds.xml for a database in MySQL.
We could have one single data source for all the features but not sure if it helps.
As you can figure out from my previous paragraph, I'm a bit confused and also concerned if we have 100 different apps then maintaining all 100 of them with their dependencies would be really hard. Also how can connection pooling be effectively used from jboss? Would it be good to have single database for all apps or multiple databases - this is in terms of maintenance?? Our stack is
Jboss
Apache CXF
Dozer
DAO (Hibernate)
Entity (POJO)
Hibernate
Mysql
And maven as the build tool. I know my questions are a bit general please let me know if you need some more info.

Answer 1

Complex infrastructures like this are always difficult to manage.
There's three main approaches you can take, and each has pros and cons:
Web services to encapsulate all business layer/data access into an API. This minimizes the proliferation of versions of jars in various apps, but forces you to be more rigorous about API changes.
Creation of libraries that can be shared amongst multiple projects. I'm not clear on what you mean by referring to a library from another WAR file, perhaps this is what you mean in that you're including the relevant jars in your newly deployed WAR. This does lead to version compatibility concerns you mention, but can make modifying existing APIs more flexible, in that you don't have to immediately modify all existing apps.
Encapsulate all data logic in the database. In my experience, this is the most problematic, as it separates the dev from knowledge of how the business logic is working, and can be the most fragile - one stored procedure change can be harder to detect when it starts breaking other apps than the other approaches.
In my experience, it comes down to having more established processes and agreements among the team about how changes will be made. You really have to look at your business layer/data access layer as APIs and be very conservative about making changes. If you aren't already using a continuous build system, I'd highly recommend it, as it can help you catch changes that break existing applications early on and allow you to keep things in sync.

Answer 2

It's perfectly fine to have all your applications use the same database.
However, you run the risk that different apps use the database in different ways.
For this reason I would recommend that you put as much logic as possible in MySQL.
I cannot tell you how to do this, because I don't know what your apps do or need, but I can give you some general ideas and pointers.
General ideas and pointers
You can use stored procedures/functions to do stuff
If your apps use a stored procedure to make stuff happen in the single database, all apps will work in the same manner.
Use stored functions to do calculations on fields. (e.g. E.g. use a stored procedure to book a transaction)
Price_per_sales_line = price * quantity * 1+tax% * 1-discount%
If you put this logic in a MySQL function, than you don't need to worry about debugging this in app A or B, because all apps will work the same way.
And my personal favorite
Use triggers to make sure stuff happen properly.
E.g. if you have a transaction where you need to add new item for sale, you an put this in a stored proc, but you can also do something like:
Pseudo code
CREATE table blackhole_new_sales_item (
name varchar(45) not null
price decimal(10,2) not null
category_id integer not null )
ENGINE = Blackhole;
DELIMITER $$
CREATE TRIGGER ai_bh_new_sales_item_each FOR EACH ROW
BEGIN
/*all stuff inside a trigger happens in a single transaction*/
DECLARE new_item_id INTEGER;
INSERT IGNORE INTO items (name) VALUES (NEW.name);
SELECT id INTO new_item_id FROM items WHERE name = NEW.name;
INSERT IGNORE INTO item_categories (item_id, cat_id) VALUES (new_item_id, NEW.category_id)
INSERT INTO price (item_id, price, valid_from, valid_until) VALUES
(new_item_id, NEW.price, NOW(), '2038-12-31');
END $$
DELIMITER ;
In your apps you can just do a single:
INSERT INTO blackhole_new_sales_item VALUES ('test','0.99',2)
And the trigger will take care of everything and if you change the structure of your database, you need only change the inside of the trigger and all your apps will work without change.
If you add extra fields to the blackhole table, you need to only change the single call in each app.
You can even create an extra blackhole table and create a separate trigger for that, and fill your old-blackhole-table-trigger with fall-back code to support the older apps.
So this approach gives you a single point to put all your DB logic into so all apps will behave in the same way, whilst still being flexible enough to support upgrades.
Hope this helps.