Jul 17th, 2012, 01:11 PM
Thirty five applications sharing common database methods
I have inherited a system that has 35 individual applications to it. As the users flat out rejected the idea of combining all these small apps into one big one, i am forced to come up with a new architecture that fits well.
The applications connect to a total of 8 Postgres databases and 4 AS/400 libraries. What i would like to do is move all of the entity and service classes to a central API jar/war/ear/whatever and strip out all database connectivity from the individual applications. im picturing my API project to be some kind of spring service with service classes that can be injected into my application classes to give them access to the database.
basically, inside my applications, i want to go from this:
get open DB session
query the database
commit the transaction
release db session back to queue
to a model like this
get instance of service class from central api
run method that returns my requested database records
let garbage collection clean up service class
EJB3's had the right idea, the problem with them (well one of many) was that the messaging between the service deployment and the application deployment was very slow (http-rpc if i remember right). back in the day, spring remoting had the same problem. im hoping spring has come up with a new way in the past 5 years of doing this with speed being of utmost importance.
Tags for this Thread