0

Currently we are building web services applications with Spring, Hibernate, MySQL and tomcat. We are not using real application server- SoA architecture. Regarding the persistence layer - today we are using Hibernate with MySQL but after one year we may end up with MongoDB and Morphia.

The idea here is to create architecture of the system regardless concrete database engine or persistence layer and get maximum benefits.

Let me explain - https://s3.amazonaws.com/creately-published/gtp2dsmt1. We have two cases here:

Scenario one: We have one database that is replicated (in the beginning no) and different applications. Each application represents on war that has it's one controllers, application context, servlet xml. Domain and persistence layer is imported as maven lib - there is one version for it that is included in each application.

Pros:

  • Small applications that are easy to maintain
  • Distributed solution - each application can be moved to it's own tomcat instance or different machine for example

Cons:

  • Possible problems when using hibernate session and sync of it between different applications. I don't know that is possible at all with that implementation.

Scenario two - one application that has internal logic to split and organize different services - News and User.

Pros:

  • One persistence layer - full featured of hibernate
  • More j2ee look with options to extend to next level- integrate EJB and move to application server

Cons:

  • One huge war application more efforts to maintain
  • Not distribute as in the first scenario

I like more the first scenario but I'm worried about Hibernate behavior in that case and all benefits that I can get from it.

I'll be very thankful for your opinion on that case.

Cheers

home
  • 12,468
  • 5
  • 46
  • 54
gsone
  • 1,188
  • 8
  • 25

2 Answers2

1
  • Possible problems when using hibernate session and sync of it between different applications. I don't know that is possible at all with that implementation.

There are a couple of solutions that solve this exact problem:

Terracotta

Take a look at Hibernate Distributed Cache Tutorial

Also there is a bit older slide share Scaling Hibernate with Terracotta that delivers the point in pictures

Infinispan

Take a look at Using Infinispan as JPA-Hibernate Second Level Cache Provider

Going with the first solution (distributed) may be the right way to go.

It all depends on what the business problem is

Of course distributed is cool and fault tolerant and, and,.. but RAM and disks are getting cheaper and cheaper, so "scaling up" (and having a couple hot hot replicas) is actually NOT all that bad => these are props to the the "second" approach you described.

But let's say you go with the approach #1. If you do that, you would benefit from switching to NoSQL in the future, since you now have replica sets / sharding, etc.. and actually several nodes to support the concept.

But.. is 100% consistency something that a must have? ( e.g. does the product has to do with money ). How big are you planning to become => are you ready to maintain hundreds of servers? Do you have complex aggregate queries that need to run faster than xteen hours?

These are the questions that, in addition to your understanding of the business, should help you land on #1 or #2.

Community
  • 1
  • 1
tolitius
  • 22,149
  • 6
  • 70
  • 81
  • Thank you very much for your answer! I red the theme you posted - for now our system doesn't involve online money. I need to rethink things based on your answer- currently I'm making database model and specify REST services. I'll write here chose solution. Currently we will have more reads than writes for sure one data that should be accessed fast from different locations. – gsone Oct 17 '11 at 10:19
0

So, this is very late answer for this but finally I'm ready to answer. I'll put some details here about further developing of the REST service application.

Finally I landed on solution #1 from tolitius's great answer with option to migrate to solution #2 on later stage.

This is the application architecture - I'll add graphics later.

Persistence layer - this holds domain model, all database operations. Generated from database model with Spring Roo, generated repository and service layer for easy migration later.

Business layer - here is located all the business logic necessary for the oprations. This layer depends on Persistence layer.

Presentation layer validation, controllers calling Business layer.

All of this is run on Tomcat without Application server extras. On later phase this can be moved to Application server and implement Service locator pattern fully.

Infrastructure - geo located servers with geo load balancer, MySQL replication ring between all of them and one backup server and one backup server in case of fail.

My idea was to make more modern system architecture but from my experience with Java technology this is a "normal risk" situation.

With more experience - more beautiful solutions :) Looking forward for this!

Community
  • 1
  • 1
gsone
  • 1,188
  • 8
  • 25