At the end of the day, services are small, specific applications and need just as much attention paid to design. If SOA supports composite applications and composite processes made up of services, then the overall design of services will determine the overall success of things made out of those services...it's just that simple. Tried and true design techniques are applicable for service design as well. Please use them.

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).

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.

Posted by Dave Linthicum on June 9, 2006 01:29 PM