How to Define Services

January 20 2009

3 comments
motif

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


We'd love to hear your opinion on this post


3 Responses to “How to Define Services”

  1. There are another form of service named “Decision service”. Which will help to separate business logic from task services.

  2. Hi Shamim,
    Can you give me a concrete example of this type of service? If I was to make an assumption this sounds like it manages routing logic. If so, I would class this a function of the service container. In Mule you would configure routing services on the service configuration that would make decisions on which services to communicate to, when to wait for a response, how to correlate a set of messages, etc.

  3. Mike Rosen has an article called “SOA Service Usage Types” at bptrends.com on that. Quote from his article:

    “Services that execute business rules to provide business decisions. An example of a decision service would be the underwriting of an insurance policy. Decision services generally provide yes/no answers to complex questions, or they support frequently changing externalized rules, such as tax regulations. Decision services
    are usually composed into other services and are small to medium in size. ”

    Especially the frequently changing rules make sense to me. That’s definitely something you want to encapsulate well.