Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seein Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up-and-running, however in many cases scalability is simply not a consideration within the SOA, nor was load testing, or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology in many instances. My daily routine is to answer an e-mail from somebody, somewhere, asking me why their SOA does not scale. Unfortunately, the answer is something they don’t want to hear. It’s really the fact that they took the wrong approach, used the wrong technology, and the fix is going to be painful. However, you can avoid these issues by just doing some additional planning and testing up front before you commit to a solution. The core issue is that many SOA technology vendors have not focused on scalability within their solutions. Instead, feature/function enhancements are the rule of the day. It’s more important to add orchestration features and more adapters to your solution than to figure out how to pump more information, and manage more services. Thus, these single threaded solutions, on top of the issues around Web services in general, make for solution that are more about integration than true business transaction loads. Dependence on the traditional architectures is the core problem of scaling SOA solutions. The most popular SOA technologies require that all information and services under management do so within a single server domain (in most cases). This processing is a mixture of service abstraction, service management, schema and content transformation, rules processing, message splitting and combining, as well as message routing (ESBs). This is despite the fact that Web services, at their essence, are more about distributed service invocation model that is not as well followed. Why the scaling crisis around SOA is not well known at this point, considering the fact that the larger SOA projects have just started moving, there are a few vendors that I’ve been watching that do indeed provide the distributed architecture needed to better bring distributed reliability to SOA. Rogue Wave’s HydraSCA, for instance, provides a service grid based on “Software Pipelines.” Software Pipelines is an architecture and methodology that enables the development and deployment of a scaleable SOA-based application(s). Rogue Wave is promoting Software Pipelines as a cross vendor approach to service distribution, and key players are in their as well. Software Pipelines, the approach and the instance of technology (Hydra), increases scalability by providing concurrent computing of business services within, and across servers, while preserving business rules. For those of use who’ve been in the business for a while, this is really common sense scalability, meaning that the processing is distributed across more than one processing entity, and thus the throughput increases using this parallel processing model. As long as this distribution is managed well…it’s very effective. There are other SOA solutions moving this direction as well, and as SOA becomes more accepted, the ability to make your SOA scale is clearly going to be on the critical path. Software Development