Capacity planning for SOA infrastructure is complex for several reasons. Given the loosely coupled nature of SOA, services can have unexpected load demands and services may be consumed in unexpected ways - for example, file systems have been implemented on top of Google's GMail presenting much different capacity demands than email. Also, the SOA infrastructure consists of many components, such as Message Oriented Middleware (MOM), Business Process Management (BPM) engines, brokers for mediation and orchestration, integration services (such as security, monitoring, exception handling) and the network infrastructure. Within the network infrastructure there are many components that impact performance and capacity including connection speeds, routers, switches, traffic load balancers, and encryption (SSL) and transformation (XLST) accelerators.
Another complication arises from constructing a composite application from services with varying performance and availability characteristics. Including a service with no Service Level Agreement (SLA) within a composite application having a rigid SLA can result in a failure to comply with the SLA. Also, architecting for recovery via retries simply adds to the demand for the service. One must consider the SLA of every service within the composite since the weakest link impacts overall performance and availability. This implies that an SLA is needed for every service. It is also necessary to document the service use for each business process - a dependency matrix works well cross referencing processes and services.
