2

I use 3 standard Spring MVC war, which share a common core (Services, DAO, and Models). The main problem is when I plan to deploy all the 3 wars on a same server. I have the Core Application Context instantiated 3 times.

I know it's possible to share a common context using an EAR, but for scalability purposes I have to keep all 3 wars, as 3 distinct units, which could deploy in a different count each.

My question is about an architectural choice:

Is it a good idea to split the Service layer used by my Controllers in a facade + commands (pattern) which can be distributed to the core (backend) via an AMQP? So that I could share requests across multiple cores.

1 Answer 1

1

Yes; it is a good idea to put your core layer on a different node and to make it communicate with the upper 3 distinct layers via AMQP. This brings horizontal scalability - not only can you put the upper layers and the core layer onto different nodes but you can replicate the core onto 2 or more nodes. Also you can have your message broker distributed onto many nodes (for example RabbitMQ supports clustering). AMQP is probably a better choice over JMS since it is more flexible by allowing you to easily integrate modules written in different language; also Spring has a good support for AMQP via Spring AMQP.

The alternative, as you have mentioned it, would have been to put all in a ear and deploy it to a Java EE server which can be distributed onto many nodes. But since you already have Spring, this requires more effort.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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