At the company I work for, we're currently splitting up our monolith solution into a number of small services (SOA).
The purpose of this is to make the developers working on each chunk of code (service) more independent, and on the whole to make the code base more manageable. When a change in code is introduced, only one part (i.e. a whole service) needs to be deployed, instead of having to deploy everything. This also helps with testing, there's less of a need to test everything when something is deployed.
Many of the services are small, so we'd like to deploy a number of these services on the same application server, JBoss 7.1 in this case.
As per the SOA philosophy, the independence of each service and the teams working on them is very important. What would be the best way to organize the data?
- Use one schema per service
- Would you use one datasource per schema in the application server?
- Or use one datasource, prefixing all DB object names with the schema name in some transparent manner?
- Use a shared schema, but evading any naming collisions by requiring each service to use a distinct prefix for all DB objects
- Other options?
Am I maybe thinking this completely wrong here? :)
Edit: Explained why the code base is being split up from a monolith to smaller services.