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.

  • Integrated (this is the positive term) or monolithic (negative term for the same thing) systems have many advantages and disadvantages. There is no general reason why a collection of web services should or shouldn't use the same data base, or different data bases with the same schema, or the same business layer code or custom-tailored small code bases. Which to choose depends on the reasons you're splitting up your code base in the first place - which you haven't given us. – Kilian Foth Nov 4 '13 at 10:22
  • Thanks for your comment. I've now added the reasons for splitting the monolith up into smaller services. The most important reason for splitting up the code is independence; developers should be able to work on features, without having to even know about code from completely unrelated functionality. – jolasveinn Nov 4 '13 at 10:44

If you want that this services be really independent different schemas or different databases is a better approach in my opinion. In the future you can move this services to different applications services or split the dtabase into different servers.

But i'm not sure if a partition at the service level (REST or SOAP i suppose) its convenient for ease/independent development. You can make the partition at library level (different .jar for each team), each team can work in one of this .jar that expose some clases (an interface) for others. You have the same independence of development without the complexity of deployment you have with different services.

With the services partition, if a change don't change the service contract with others services or applications you can deploy/test only this service, but if the service change this contract you need to change/deploy/test all the clients of this services, this sounds easy but can easily turn into a nightmare or dependencies.

In my opinion a partition at the service level its ok when is done for deployment needs, you divide you system into small independent deployable pieces because this way you can have dedicated server to some pieces (a subsystem with heavy load for example) or perhaps replicate the same piece in a lot of servers, usually this is necessary for scalability reasons. But for development reasons in my opinion a partition at the library level its easier (i you are looking for ease of development)


You are restructuring your application architecture from a monolith to a more modular approach:

At the company I work for, we're currently splitting up our monolith solution into a number of small services (SOA).

But why still rely on an application server?

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.

There are other options today available:

Each Service would manage its own DB-connection.

For the scenario given:

I would opt for the case with one service - one datasource - one schema. This gives you flexibility: if you restructure your architecture in the future, you could easily move complete schemas to different servers (including the respctive services). Say you are developing in an e-commerce-scenario, possible parts were:

  • login-infrastructure
  • customer-data (e.g. address)
  • order-data
  • data for storage information (location of storage)
  • product catalog ...

These are all different concerns in the sense of SoC, which could be splitted up.

Depending on how large you grow, it might be necessary to implement an separated login-infrastructure.

On the other hand:

Since I do not know your business, nor your current architecture, there is YAGNI and Premature Optimization. It might be possible, that you refactor your current model to a use case, which will never happen (e.g. not every e-commerce-shop is the next Amazon).

Analyzing your (monolithic) architecture, a possible restructuring should emerge by itself. You know best, which subsystems are used how.

Here a nice read.


I'm no SOA expert but I think you are looking for a more lightweight solution. In any case, see http://soaprinciples.com

If you are splitting up just one application I suggest studying the OSGI platform.

In the 'classic' SOA a Canonical Data Model is used http://soapatterns.org/design_patterns/canonical_schema, or at least it is a widely used pattern.

I don't get your DB object prefixing issue. In the Canonical Data Model you use xsd schemas for your data types and you can put them in different xml namespaces.

  • Thanks for your input Karl. When I talk about databases and schemas, I'm referring to an Oracle database and Oracle schemas. Services are in essence EARs. OSGI was considered at the start of the work, but was deemed unsuitable for our work. The services expose REST APIs. The implementation of the APIs uses Oracle for data storage, but the question revolves around how the data should be organized. I can't find any relevant information on the sites you pointed to unfortunately, but they will definitely help with other issues I'm working on :) – jolasveinn Nov 4 '13 at 23:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.