SOA, Java EE and data organization

Question

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.

Answer 1

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)

Answer 2

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:

• Spring Boot
• Dropwizard
• Vert.x
• Play - as standalone etc.

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.

Answer 3

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.