A few service patterns are beginning to emerge. We can categorize them into larger buckets, including:

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 (Atomicity Consistency Isolation Durability). 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 databases, 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.