SOA Tips - Address Scalability Bottlenecks with Distributed Caching

By Iqbal Khan

After the explosion of Web applications to accommodate high-traffic usage, the next big wave has become service-oriented architecture (SOA). SOA is destined to become a standard way for developing extremely scalable applications, and cloud computing platforms like Windows Azure represent a giant leap in moving SOA toward achieving this goal.

SOA allows users to distribute applications to multiple locations, multiple departments within an organization, and multiple businesses across the Internet. Plus, it permits reuse of existing code within an organization and, more importantly, collaboration among different business units.

A SOA application is usually deployed in a server farm in a load-balanced environment. The goal is to allow the application to handle as much load as you throw at it. The question thus becomes: What are some of the considerations you should have in mind for improving both performance and scalability of your SOA application?

Although SOA, by design, is intended to provide scalability, there are many issues you must address before you can truly achieve scalability. Some of these issues involve how you code your SOA application, but the most important bottlenecks often relate to how you store and access your data. I’ll explore those issues and provide some solutions in this article.

Find Scalability Bottlenecks

A true SOA application should scale easily as far as the application architecture is concerned. A SOA application has two components: service components and client applications. The client application may be a Web application, another service or any other application that relies on the SOA service components to do its job.

One of the key ideas behind SOA is to break up the application into small chunks so these components can be run on multiple servers as separate services.

Ideally, these services should be stateless as much as possible. Stateless means they don’t retain any data with them across multiple calls, allowing you to run the services on multiple computers. There’s no dependence on where the data was the last time, so there’s no data being kept on any particular server across multiple service calls.