Defining what constitutes a service when building service-orientated applications seems to be a common problem for developers and architects who are new to building services. The main issue seems to be the scope, i.e. what is the granularity of the service. This is actually quite difficult since the granularity of a service can vary depending on the application. The trick with any fuzzy problem is to break it into smaller pieces. There is a very simple service taxonomy defined in Thomas Erls SOA in Principals of Service Design book which I believe makes the approach to defining services much easier.
Essentially you can group services into 3 categories –
Utility Services – These are usually fine-grained services that perform a single function. They are the most reusable.
Entity Services – These are services that model something concrete in your application (When I was at University, Entity Relationship diagrams were all the rage, we’re talking about the same sorts of entities here). These are business centric services that may model one or more entities in the organization such as Customer or Ledger. These types of service are highly reusable within the context of the organization.
Task Services – These types of service typically model a specific function or process. They tend to compose or orchestrate other services. These are less reusable since their function is very specific.
Thinking of services in terms of task, entity and utility will make it easy to extract service definitions from your problem domain but it will also help to define the granularity of the service, i.e. you wouldn’t define utility or task functionality in an entity service. This makes the job of defining services much easier and ultimately your services will be of a higher quality and easier to consume by your users.
