We are building a central application that controls the usual core services. This central application serves as an anchor point to a large group of other applications that are the actual services offered to users.
We expect the hub and spoke services to sustain rather large load of concurrent users.
The application was originally built using POJO/Spring with the central app and service apps all living under the same JVM.
We are planning on clustering for scalability. Because the load might be uneven on the different service apps we don't want to have a monlithic app. So we are starting to move towards service apps as MBeans that talk to the hub via JMS. This will take some reimplementation but our main worry is wether making it a distributed app will help scalability or wether we should just go for a massive resource pile in the style of Azul Systems and run a single VM and avoid the distributed issue altogether.
So the main architectural question is:
What are the best practices for architecting large scalable, highly available applications? Any links, annecdotes or recommendations will be very much appreciated. Who can we consult that will be platform agnostic?
Decoupling your application into distributed services will help you maintain better control on SLA of individual services and size of data in memory and the time server spends on serializing session information in a cluster. I am not sure how neatly all the services are sandboxed, if they are not, then errors in one application can affect other applications directly or indirectly where a rouge application can reduce the machine resources to other applications. Also, from security point of view, you would be better of decoupling them.
In future as your application size increases, if you go ahead with monolithic model, the above factors will compound the performance degradation.
Then there are classic software management issues like flexibility and speed in offering different combininations of the decoupled services to respond to market changes, maintainence issues and change management issues. Future changes will require significant investments in gap analysis to understand the impact of new changes on the monolithic application.
Thanks for your reply. You are actually echoing many of the reasons we had for suggesting this alternative in the first place.
We have concerns about wether JMS is a suitable substitute for what is basically method calling in a coupled app.
We are also wondering if we need to go the route of message driven beans or wether we can maintain our own pojos instead and just pass around objects with the JMS queue. We also need to decide on what message queue best suits us.
We are also considering Tangosol Coherence for caching, anyone has experience with it?
There are other contention points such as what do we do with our AOP-based functionality, it won't work across the network, as far as we know.
Drop me a line at rmisek at tangosol dot com, this sounds very similar to many of the applications our customers have used Coherence for.
Rob MisekTangosol, Inc.Coherence
: It just works.