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.
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.