Question

I am building a web application where I want to distribute the code in various tiers like UI, Business logic and database. Here are my desired features which explain my usage scenario:

• Real time high performant request-response type application
• Application to be divided in various layers like UI, business logic and database- each layer working on a cluster of computers
• The layers should support load balancing and failover features preferably transparent to other interacting layers.
• Interoperability with various languages in future will be an additional desirable feature
• These layers will be residing internally to my organization itself, i.e. I don’t intend to interact with outside organization services at present.

I tried out RMI but drawbacks were Java lock-in and no support for load balancing and fail over features. I have considered JMS but realize that even though the features like load balancing, failover of MOM are very tempting, it doesn’t seem suitable for real time request-response type application to me(Correct me if you think I am wrong).

Please suggest me good popular, suitable framework(s) that best suit in this use case scenario.

Update:
Exploring SOA, I come across the two prominent options SOAP and REST. As I mention, I have to make a choice interms a communication methodology to use internally between the modules/layers in my application. Is there an obvious/popular choice to make between them when looking for quick request-response and high scalability, load balancing, failover scenario? I don’t intend to convert this post into REST vs. SOAP discussion, but if quick lite comparison can help in this case. I am also open for any third alternative if it’s there in SOA which I am missing. Some examples from real world deployment scenarios will also help.

Answer 1

Let’s dig into your architectural requirements:

1. Real-time high-performant request-response type application

• if you are probably trying to achieve almost zero application latency, then you must cache almost everything near the web layer, like memcached, and postpone or make updates asynchronously.
• consider also using REST, it demands less overhead than SOAP, and you can use JSON as a document format which is also more compact than XML, lowering network throughput requirements.

2. Application to be divided in various tiers like UI, business logic and database- each layer working on a cluster of computers:

• The more tiers you use, the more latency your application probably have, database is the least scaleable item from almost every architecture, then you must try to avoid hitting it for every request, you will definitely need a powerful cache.

3. The tiers should support load balancing and failover features preferably transparent to other interacting tiers:

• in order to increase scalability and failover you must seek service statelessness because session state synchronization between servers is very expensive and a load balancer with sticky sessions, will be a problem when a single server crashes.
• HTTP load balancers can be very transparent.

4. Interoperability with various languages in future will be an additional desirable feature

• SOAP have more fancy features that are not well supported in all languages, if you use REST you will be probably more safe here. REST interfaces are usually more simpler to design and less dependent on specific technology than SOAP’s WSDL.

5. These layers will be residing internally in my organization itself, i.e. I don’t intend to interact with outside organization services at present.

• If you think you will have interaction with other services outside your service repository, you have to know that if you don’t use standards, you will probably need a kind of gateway tier that would do message translation.