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.

A typical response to these challenges is to over engineer the infrastructure. In some cases, for example network connection speeds; this is an acceptable practice since it is cheap and effective - it does not cost much more for a 100GB network than 10GB. However, taking an over-engineering approach with components such as a BPM engine is expensive and overkill. A more effective approach than simple over engineering is to have flexible resources such as clusters, blade servers, logical partitions, grids (future) and load balancing techniques. Using flexible resources, which can be allocated from a pool among different applications, still implies some idle resources but multiple applications bare the cost.

It is however desirable to achieve a predictable capacity plan. A capacity plan should time infrastructure spends with capacity needs. This not only ensures SLAs are met, but also creates an accurate budget for upgrades. To establish a capacity plan one must establish the baseline performance characteristics of the infrastructure then plan for future growth. This is certainly more difficult to do for SOA than for network elements, but possible.

1

• Next

Home
Webinars
Blogs
Subscriptions
White Paper
Analyst Corner

Goals

Enabling Business Agility and Reuse
Improving Business Processes
Leveraging Information and Intelligence
Governing the Infrastructure
Leveraging the Connected Web
Securing Enterprise Applications
Supporting Industry Solutions

About Us
Editorial Calendar
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe