Performance is often an afterthought when building new systems, and I'm finding that services are no exception. Truth be told, most services out there just function. They are not optimized to scale, and SOAs are running into walls as those services hit the upper limit. If we don't learn to solve this problem, many SOAs simply won't get off the ground.

There is indeed a right way and a wrong way to design a service. Also, there are things beyond your control that you must consider during your design. As with anything else, you need to do your homework, allow enough time for design, and do some experimenting and proof-of-concept testing to determine the best path.

First, Know Your Service Patterns
A few patterns are beginning to emerge. We can categorize them into larger buckets such as legacy abstraction, simple composites, complex composites, and new autonomous services.

Furthermore, we can put them into behavioral subcategories such as transactional, data services, and lightweight and heavyweight services. Notice there is no mention of fine grained and course grained; we'll get to that next month.

Legacy abstraction services are services built on top of existing services, including elderly technology such as Cobol and CISC on the mainframes, or perhaps services liberated from mini computers, or even enterprise class Unix systems. You can toss ERP and CRM applications into this mix as well.

The notion is that you somehow are able to externalize these internal processes as services and leverage them as modern Web services, no matter how ugly and arcane the interfaces are.

Simple composites are one or two services that are bound together in a new service. Complex composites are many layers of services that are bound together, perhaps a composite that's made up of other composites. New autonomous services are services that are created for a single purpose such as a Web service, and are typically not based on other services (non-composite).

Transactional services can be a simple or complex composite, or even new autonomous, but they support transactional characteristics including ACID. For those of you who have not seen ACID as many times as I have, Atomicity refers to the "all or nothing" quality of transactions. The transaction either completes, or it does not. Consistency refers to the fact that the system is always in a consistent state, regardless of whether or not it completes the transaction. Isolation refers to the transaction's ability to work independently of other transactions that may be running in the same environment. Durability means that the transaction, once committed and complete, can survive system failures. With new standards such as WS Transaction, the way in which you build a transactional service should be more consistent. For now, developers are taking their own unique approaches, typically leveraging TP monitors or application servers.

Data services, as you might expect, are services that are built to produce and consume data. These could be Web service abstractions on top of call level interfaces, or simple services exposed out of an ERP system that produces data. These are very simplistic services, with schemas, access controls, and the encapsulated data. These services are almost always built on top of a relational database, but other database types are leveraged as well. Moreover, through a data services abstraction layer, you can emulate database types to meet the needs of your SOA.

Lightweight services, as the name implies, means that you're doing things with a light volume (typically fewer than 10 invocations or messages-per-second), and the size of the message that the service is passing is small (typically less than 50 KB). Heavyweight services, in contrast, do heavy volumes (greater than 10 invocations or messages-per-second, but more typically 100-300 invocations and message-per-second), and can transmit and consume huge messages.

Second, Experiment and Test
Many of those who focus on the discipline of performance within complex distributed systems such as SOA will first steer you toward modeling. Unfortunately, we don't know enough about how services behave to model how they will perform, so it's a good idea to test the services that will make up your SOA before you build your performance model; otherwise, you're just guessing.

So, how do you test services you've not yet built? It's called a "proof-of-concept," meaning you stand up very raw and simplistic versions of the services (either existing abstractions or new services) for the purpose of proving that they work and to illustrate their operational characteristics. This is typically done in parallel with existing design work, and the proof-of-concept is largely a throw away after you gather your data, but nonetheless it's important to your understanding of the final product before you complete the design and development.

Testing services, even proof-of-concept services, means that you simulate operational characteristics during the test, or, how you intend to leverage the service. You do this by building or buying test harnesses that can load the service as needed for testing. You should utilize low use, medium use, and high use scenarios to determine how the service behaves under an increasing load, and make sure you have some sort of monitoring mechanism to gather the data for analysis.

What you'll find, in most cases, is that the service will reach a saturation point where performance drops off significantly as the load increases. The saturation point is largely dependent on the patterns of the service. For instance, transactional service should be able to support a much higher load than lightweight services.

Next month we'll expand our discussion to the next steps, including: creation of a performance model, and design, monitoring, and optimizing performance of services after they exist in your SOA.