No Service is An Island

No one has ever claimed that processing of XML was speedy. Indeed, my reaction to the results of the first test I ever conducted on SOA Security Gateways back in 2003 was to test them again. And again. It turns out that this was actually okay, as a subsequent review of the application servers these devices were protecting weren't capable of keeping up anyway.

But that was back in 2003, right? Things have gotten better, haven't they?

Well, yes and no. Another round of testing in 2005 showed that while the devices offloading XML processing from servers had certainly increased their capacity, the performance increase was still abysmall to those of us used to the type of performance produced by other gateway-esque products.

One of the latest debates in the SOA arena centers around the granularity of services and the subsequent impact on the performance of the SOA as a holistic entity. Indeed, extremely fine-grained serices do negatively impact performance based even when the impact is computed based solely on the consumption of resources required by each intermediary required to parse the XML message. That's ignoring the impact of TCP connection management that grows along with the number of services that comprise any given application.

David Linthicum always has something interesting to say about SOA, XML, and Web Services, and this subject is no exception.

Indeed, Web Services are slow. There, I said it. They are very synchronous in nature, and do cause concern for those building a SOA around Web services (Keep in mind that Web services are only one type of technology you may use to build your SOA). However, tossing new standards and technology at the problem won't get you there. Instead, you need to think at a more fundamental level...the design of the service.

Truth-be-told is most developers have gotten accustomed to having commodity resources available in their deployment environments, meaning memory, CPU, bandwidth, I/O, etc., and many don't think "service efficiencies" when designing (if they do design), programming, and deploying a Web service. In fact I'm reviewing services now that with just some rethinking in terms of how they leverage resources, including when, how often, and why...they are increasing service performance by 200 percent in many cases. Also, the whole "too course grained" or "too fine grained" thing becomes issues as well.

If one remembers that SOA is an architectural design and deployment pattern and not a product or set of products, David's statement becomes very clear and right on the mark. An application is no longer a contained entity; it's comprised of multiple services in multiple tiers of the application infrastructure and the path to optimizing the performance of the application becomes a challenge not for developers, but for architects. It's the old "common path" optimization methodology that has been used for decades to optimize code.

There are many factors that influence the performance of a service that are external to the code. Indeed, there are some factors that cannot be affected simply by writing better code.

The Five W's can help you identify those factors, which in turn can help you design a more efficient infrastructure on which services can be securely delivered in as performant an environment as possible.

1. Who or What will be accessing the service?

Is this service ultimately used by partners, customers, or internal applications? Are any of those end-users part of a mission critical business process that is sensitive to network conditions such as latency, jitter, or availabilty?

2. When will they be accessing it?

Profiling the request pattern of an application is a necessary step in determining what types of controls may be necessary to ensure compliance with SLAs, maintain availability and apply any required time-based QoS mechanisms.

3. How often will it be accessed?

This question can assist in determining whether scalability will be an issue. Perhaps an additional instance of the service will be necessary if this service will be under a steady stream of requests.

4. Where will it be accessed from?

Is this a publicly consumable service? A partner consumable resource? Will transport layer security be required (which will negatively impact performance of said service)? What kind of connectivity between the producer and consumer can be expected?

This list of questions is certainly not all-encompassing, but it does provide a starting point from which you can begin to determine all the factors that affect the performance of your services. No service is an island, and its overall performance can be negatively - or positively - impacted by external conditions; conditions which should be considered sooner rather than later.

Imbibing: Coffee