There are two modules A and B using the same DB. A imports B as a JAR. I read that messaging patterns can replace the tightly coupled solution of using a shared DB but I am not sure which message pattern I can use.A high level solution that indicates how we can stop using the shared DB, would be great.Adding more details as requested:Imagine A like a huge app (let's say Flickr) and B a plugin for A that periodically runs as a daemon and among other things calculates several user ranks (e.g. user with the most comments, most highly rated pictures, etc.). In order to do that it uses A's DB and does most calculations using stored procedures which again live in A's DB. The rest of the code is decoupled but I was wondering how I could loose the database dependency, so that any changes in the database schema or implementation won't break B.
Simple messaging pattern to replace shared DB?
design patterns;enterprise architecture;message queue;integration
Lets to do an exercice of creativityA's API Rest  as webservice:In order to feed B and unbind B from A's data model , we need an interface that will act like a contract. This contract is going to be our webservice data model.B as standalone app:Lets wrap B into a standalone app that could be executed anywhere. Desktop or web doesn't matter. Lets say desktop in order to launch it via O.S daemon.Now B is a client of A that ask for its Info with a pacted data model that may or may not be as A data model is.Point is that webservice's data model can be different from the original one. Drawbacks:B need its own data model. AbsolutlyA's webservice data model may change over time. But we invented  API rest versions for this casesAccess to A's webservice should be securized somehow (little more extra work :-) )If you expect many request from B to A, a system of cache is going to be must (more work, don't hate me)However we need to know your platform configuration and its boundaries. But this would be a possible aproach. Hope it helps.