So, now that we know how to diagnose the performance of an SOA, as well as model for it to determine how it will behave in a changing environment, how do we design a service and SOA with optimized performance? Here are a few tips.

The more processing you can place at the origin of the service, the better your SOA will perform. In many SOAs, the architects abstract the services to a single server, and performance can be somewhat problematic in larger implementations.

Many services are built on top of more traditional legacy APIs, and as such the translations between legacy APIs to expose them as services may cause performance problems. The ability to leverage existing legacy systems as services is a powerful notion. However, you must be careful in selecting the proper enabling technology to do this. Service invocations that take a second or more to produce behavior, or information bound to behavior, will cause big problems when you align them with hundreds of other services that are doing the same thing.

The use of too many fine-grained services may cause performance problems. Indeed, you should not be afraid to leverage fine-grained services within your SOA. However, you need to understand the performance issues associated with doing so, and take the network bandwidth and how other applications leverage the services into careful consideration.

Make sure to consider performance when selecting your orchestration layer. Many BPEL engines are notoriously poor performers, and can become the bottleneck for the SOA.

Understand the basic rule that, while the value of an SOA is the ability to leverage many remote services, the more services you leverage, the more problematic your SOA will become.

Posted by Dave Linthicum on August 24, 2006 02:11 PM