SOA: Responsibilities of Service Providers (Part 3)

This blog post is one in a series.  An overview and general outline of this series is linked here.

Responsibility 2:  Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.

Background

Sometimes we encounter situations where an existing service does not meet the performance or availability requirements for a new project.  Resolving the matter often involves a technical constraint of some variety.  Here are a couple examples:

• The service makes very heavy use of database stored procedures.  The approach to scalability long term is complicated.
• The service interface supports very large request/response payload sizes.  The worst case is probably where an "unbounded" size is allowed (e.g. by the XML Schema Definition or XSD).  Under low volumes the service may work fine.  However, the service becomes unstable as volume and number of concurrent requests increases (e.g. due to exhausting the JVM memory allocation).

Issues such as these and/or organizational concerns can prevent changes from being made in a timely manner to meet requirements.  This can impact the re-usability of a service.

Considerations

This requirement, or principle, is front and center so it is clear to service providers the architecture must scale to meet current and future requirements.  Even a re-architecture should not be out of the question for any unforeseen situations.  The service provider must have "ownership" of a solution to meet the purpose and general objectives of a SOA.

Typical patterns and decision points:

1. Implement stateless request/response services that scale by adding additional computers or virtual machines behind a load balancer to handle additional volume.
2. Use of an "intelligent" load balancer to direct requests away from failed instances during a period of outage (as opposed to static DNS RR).
3. Clear separation between data persistence and application tiers to enable each to scale independently.
4. Business logic is best suited in the application tier where scalability is much easier to achieve. If there is a belief it belongs within a stored procedure to meet performance requirements, evaluate this belief very carefully. (Maybe I'll cover this topic in a later blog post.)
5. Where applicable, an in-memory caching strategy can and should be employed behind the service interface to meet aggressive requirements.
6. The application team must make critical decisions around the appropriate level of granularity for the service. For instance very fine-grain RPC style invocations are typically not appropriate when the technology is SOAP or REST over http. A more coarse-grain approach is best with these technologies.
7. Where applicable enable a client to submit multiple "units of work" in a single request. This will cut down on the number of round trips across the network.

In a later installment, we will touch on a related topic--Service Level Agreements and measuring planned vs. actual metrics.

The 7 Responsibilities of a Service Provider in an Enterprise SOA (Part 1 of 8)

I thought I'd pen a few entries related to Service Oriented Architecture (SOA) over the coming weeks.

In the area of service orientation, one key area that sometimes isn't framed effectively involves clear responsibilities for development teams that build and support services.  I'll attempt to provide an outline here of items I'll expand on in follow-up posts...

Why are clear responsibilities important?

The typical goals and value proposition of an SOA have been elaborated time and again, so I'll at least postpone a recap.  But among them are reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.

In large I.T. shops, significant coordination across multiple organizations is often needed to deliver enterprise solutions.  Typically this is the case when applications are highly integrated and delivering a business solution cuts across multiple application domains.

Transitioning from a highly integrated legacy environment to a SOA will require I.T. to be on the same page when building services.  It is important to share a common set of goals and imperatives to achieve the promises of SOA across the enterprise.  Ineffectiveness in this regard will place achieving the full benefits of an enterprise SOA program at risk.

Key responsibilities for those that provide a service for enterprise consumption (click on each link for details):

1. The functional needs of the enterprise as a whole must be considered to maximize reuse and minimize duplication.
2. Meet performance and availability requirements. As requirements and usage patterns change over time, be prepared to adapt.
3. Publish and commit to a defined level of service (SLA). Publish planned vs. actual performance, and availability metrics.
4. Implement common interface format and semantics applicable to the type of service.
5. Implement business rules and edits to ensure the validity/integrity of the operation and any data that is mastered.
6. Implement formalized change management. And implement interface versioning to limit the number of clients impacted by changes (decoupling).
7. Provide business eventing, where applicable (e.g. asynchronously via JMS).

To a certain degree the responsibilities outlined here transcend SOA.  I plan to detail each of these items and their importance in later installments.  Thanks for reading.  I welcome and look forward to feedback about your experiences.