How to organize and manage multiple database credentials in application?

Question

Okay, so I'm designing a stand-alone web service (using RestLET as my framework). My application is divided in to 3 layers:

• Data Layer (just above the database, provides APIs for connecting to/querying database, and a database object)
• Object layer (responsible for serialization from the data layer... provides objects which the client layer can use without worrying about database)
• Client layer (This layer is the RestLET web service... basically just creates objects from the object layer and fulfills webservice request)

Now, for each object I create in the object layer, I want to use different credentials (so I can sandbox each object...). The object layer should not know the exact credentials (IE the login/pw/DB URL etc).

What would be the best way to manage this? I'm thinking that I should have a super class Database object in my data layer... and each subclass will contain the required log-in information... this way my object layer can just go Database db = new SubDatabase(); and then continue using that database.

On the client level, they would just be able to go ItemCollection items = new ItemCollection(); and have no idea/control over the database that gets connected.

I'm asking this because I am trying to make my platform extensible, so that others can easily create services off of my platform.

If anyone has any experience with these architectural problems or how to manage this sort of thing I'd appreciate any insight or advice...

Feel free to ask questions if this is confusing. Thanks!

My platform is Java, the REST framework I'm using is RestLET, my database is MySQL.

Answer 1

My suggestion is to use JTA where you can use more then one database with respective number of datasources. you can refer here for more info https://test.kuali.org/confluence/display/KULRICE/Datasource+and+JTA+Configuration

Answer 2

Hi,

I feel what you explained is sensible and you are trying not to expose the database details and credentials to the cleint level.

For this situation, you need to think of any design patterns that might help you I can think of the singleton pattern , where you create one instance and use it in the Object layer, thus avoiding showing any details about the credentails and URL to the users.

Second option, what i get in my mind is the use of the hibernate layer, that will help you to hide the details and just access the ORM objects and you can get what you are looking for.

Answer 3

I would echo @saugata's comments. Look at Spring and inject your data source implementation (or stubs for testing!) to your object layer in your Spring configuration. This should help your overall application architecture in a number of ways:

1. You'll be able to switch databases (either instances or implementations) on the fly without code recompile.
2. You'll abstract the data source completely from it's implementation - allowing you to swap a database for a web service, queue implementation, or a stub.
3. Decoupling your application in this way will make it easier to test.