SOA Service Design - Part 1

In recent years SOA has come out of the „trough of disillusionment”. Many companies and IT service providers now use it in earnest to strengthen reuse, agility and quality and to decrease cost. But one of the central questions for each SOA project still remains: which are the concrete services which are needed? Should some functionality be split up in two services or rather be implemented in a single one?  Whether these services will be implemented as web services, java classes or stored procedures does not really matter and can be put aside for a moment. In the following I will describe a method how to identify the relevant services and how to find the right level of detail, in short a method for service design.

According to my experience a top-down approach leads to sensible results. Foremost the services are governed by the business process which shall be implemented (or are implemented, respectively). This means, in order to find the services, we have to consider the relevant processes and how they can be subdivided in activities. Since services provide logic (functionality) and data (information), exactly these two aspects have to be considered when analyzing the processes. Thus, we also get to criteria, which help us to find the right level of detail: activities, which don’t need special data or logic, also don’t need special services. Therefore, they can be excluded from the process description. On the other hand, most processes have decision points, which govern the control flow, and which need data or logic in order to make the decision. This means, that services are needed, in order to support the control flow in the process, and thus sometimes special activities must be added to support these services.

Let us look at a simple example. The diagram shows a simple top-level process, which only has two activities: “login” and “menu”. The dotted lines which lead from the activities to the services indicate which services are called from which activity. E.g. the “login” activity needs a login service which then directly or indirectly accesses an LDAP in order to execute the login. From a process perspective the login could be subdivided even into more activities like “enter ID” and “enter password”. But since no further services would be derived from that, we stop at the current level of detail. The “menu” activity calls two services: one provides the menu entries and the other provides the current language. We don’t consider the sequence of the service calls inside one activity, because this doesn’t have any consequence for the service identification. But why are the services for the menu entries and the language separated in the first place? In this case it could indeed be handled together in one service. In our example we assume, that the language is needed in other processes as well. Therefore, we introduce a separate service, in order to further reuse.

To sum it up: when using this method the key question is: which data and which logic is needed for the current activity? Sometimes this question can be answered from a business perspective alone. But often background knowledge in system design and application architecture is necessary. Thus, service design based on business analysis alone is fraught with risk and it can lead to incomplete results.