I've been running into a lot of "early SOAs" that I'm looking at on behalf of my clients . These SOAs just don't provide the performance my clients had expected.

Why? Well, I guess you can blame a lot of things for poor performance; however I've found the core architecture and design issues are the most relevant variable. So, I figured we would focus a bit on service design for performance...what works...what does not.

There is indeed a right way and a wrong way to design a service. Also, there are things out of 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, including: legacy abstraction, simple composites, complex composites, and new autonomous services.

Furthermore, we can put them into behavioral sub categories, including: transactional, data services, light weight and heavy weight services. Notice there is no mention of fine grained and course grained, I'll blog about that next week.

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 me, 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, how 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. Almost always these are services built on top of 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.

Light weight services, as the name implies, means that you're doing things with a light volume (typically less 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). Heavy weight 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.

Okay, get service patterns? Over the weekend I'll dig into design.

Posted by Dave Linthicum on February 9, 2007 03:58 AM