In previous blogs, I have discussed contract-first service design and the benefits to constructing services as information-rich, smart endpoints. In his most recent book, SOA: Principles of Service Design, Thomas Erl formalizes and extends these ideas by defining 3 categories of services based on the type of logic they encapsulate, the extent of potential reuse, and the degree of focus on a singular domain. The service categories are:
Entity Services – modeled around business entities like customer, purchase order, insurance policy, and invoice. Such a service typically includes the CRUD-like operations to Create, Read, Update, and Delete instances of the business entity. As I’ve mentioned in the past, entity services are ideal candidates for contract-first service design, with entities modeled in XML Schema, and that schema becoming the basis of the interface to create, read, update, or delete a business entity.
Task Services – services that generally model a business process in the enterprise. This type of service very often combines business logic and calls to other services, and because of its focus on a particular business domain, often has a low degree of reusability. Orchestration and choreography environments, along with environments that facilitate flow logic (XAware, for example) are common ways in which to create task services, although many are still writing code to stitch together services with business logic to expose “task” services. Task services also typically involve operations on more than one entity. When processing a purchase order, for example, a process may require validating a customer (using the “customer” entity service), generation of a unique purchase order number (using a order number generator service – a utility service), and adding the order to the provisioning system (using the purchase order entity service). A requirement to access multiple entities is an indicator that your service is a task service. Task services are often referred to by other names, among them: business process services, process services, task-centric business services, or orchestration services (when using orchestration tools).
Utility Services – services that are technology-oriented rather than business focused. Utility services typically provide common and reusable functions that cut across functional domains, such as event logging, notification, and unique number generation. Utility services are often referred to as “technology services” or “infrastructure services”.
The service category definitions are just the beginning in Erl’s book. The heart of the book discusses a palette of principles that guide a designer through the complex activity of creating services with appropriate characteristics for a particular use case and environment within an SOA. This is a book that I highly recommend, and I plan on referencing Erl’s ideas frequently in future blogs.
