Announcement Announcement Module
No announcement yet.
Thirty five applications sharing common database methods Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    start transaction
    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.

    any ideas?