SOA Service Design - Part 3

In this third part of my discussion of SOA service design I’d like to concentrate on how to group and structure the services found.  Let’s remember: the general goal we’re trying to achieve here is to break up an “application” into smaller parts which each encapsulate clearly defined business and/or technical functionality (s. picture below). These “smaller parts” are often called services and may be deployed in an enterprise service bus (ESB) for production.

 But how do we find the services in the first place? As a short recap of the method presented in parts 1 and 2, here is a step by step walkthrough:

1. Get somebody who is very familiar with the business processes and requirements of the system in question and go through all the use cases step by step. Focus on who does what, what information does he or she need to do that and what data is needed to make decisions in the process.
2. While going through the processes model them, e.g. with the modeling technique I outlined in the first two parts of this series (the legend is shown below).
3. While modeling you will find the services as they are called by the activities. Focus on what is needed to build the user interface imagined by your business expert.
4. Sometimes you will encounter situations where your former services will not fit to new processes you just model. That’s part of the game. In these cases you have to adjust your service (e.g. take them apart or join them) in order to fit all of the situations when they are called. If you cannot make them fit, this may be a sign that a new service is needed.

Thus, we end up with a bunch of process models containing services. Now what? At the end – which is the beginning of design and implementation – we need a precise definition of our services, at least precise enough that the programming team can implement them. Therefore, the names of the services won’t do for that. We have to write a short documentation for each service. It’s good practice to group the service methods we found with our process analysis by a business related criterion. That would lead us to describe the service belonging to one group in a close context in the document. This is a good ides, because services which are close business-wise also share other common traits for example pre- and post-conditions and validation functions which should be described consistently.

I recommend grouping the service with regard to the domain mode, which is the data model which contains all of the major business object types of the processes in question.

The results can be depicted graphically which could look like the following picture:

As you can see, there can be services which belong to more than one entity (like “identify” which can be group with “passenger” and with “missing baggage”). That’s absolutely normal and can lead to even more constraints for these services, which should be documented. Now remains the question of granularity. There are clues which can be gained from the grouping: If some of your services in the group contain very concrete verbs (like “create” and “delete”) than it should be a warning sing, when others are very fuzzy or even miss verbs totally. A switch in granularity (level of detail) from one group to another can occur, when e.g. one group acts “supportive” to another. This happens in the example above, when detailed passenger data (like phone number) is retrieved via a fine grained service, while the missing baggage reports are more abstract.

Now, we arrived at the end of this short series about SOA service design. Questions are more than welcome and I will be very happy to post any relevant answers here on the blog. I’d also like to here about you personal experiences with SOA modeling, so feel free to contact me.