Within the world of SOA, services are the building blocks, and at the lowest level of the stack. SOA is an architectural style supporting loosely coupled services that enable the construction of many systems that are technology-agnostic. Services become the base of an SOA, and while some are abstract existing “legacy services,” others are new and built for specific purposes. Moving up the stack we then find composite services, or services made up of other services and all services abstract up into the business process or orchestration layer, which provides the agile nature of an SOA. So, back to designing services.
While there are no hard and fast guidelines on what makes up a well-defined and developed service, we do know a few things: Services are not complete applications or systems. They are a small part of an application. Nor are they subsystems; they are small parts of subsystems as well.  Indeed, services are more analogous to traditional application functions in terms of design, and how they are leveraged to form solutions, fine or course grained. Knowing that, we have a better basis of understanding when approaching the service design problem.
Each service has a specific purpose, and they are not complex or naturally dependent upon other services. Thus, they are easily abstracted into composite applications, in essence, leveraging these services as if they are functions local to the composite.
Services should exist with a high degree of autonomy. They should execute without dependencies, if at all possible. This allows you to leverage the service by itself, and design the service with this in mind, no matter how course or fine grained the service is.
Service Design Principles
So, how do you design a service? First, it’s important to follow a few basic principles. While following these principles does not insure success, it will clearly send you down the right path.
First and foremost, services should be designed for reuse. Services become a part of any number of other applications, and thus must be designed to provide behavior and information, but not be application specific. This is a difficult paradigm for many developers since custom one-off software is what they’ve been doing for most of their careers. Thus, the patterns must be applicable to more than a single problem domain or application, meaning you must have use for your reusable service. Else, the exercise is in vain.
In addition, services have to be designed for heterogeneity. Web services should be built so that there are no calls to native interfaces or platforms. This is due to the fact that a Web service, say, one built on Linux, may be leveraged by applications on Windows, Macs, and even mainframes. Those that leverage your service should do so without regard for how it was created, and should be completely platform independent.
Among other benefits, abstraction allows access to services from multiple, simultaneous consumers; hiding technology details from the service developer. The use of abstraction is required to get around the many protocols, data access layers, and even security mechanisms that may be in place, thus hiding these very different technologies behind a layer that can emulate a single layer of abstraction.
Also, when we build or design services we need to account for aggregation. Many services will become parts of other services, thus composite services leveraged by an application, and you must consider that in their design. For instance, a customer validation service may be part of a customer processing service, which is part of the inventory control systems. Aggregations are clusters of services bound together to create a solution.
Services are not applications and should have limited scope, as we discussed above  In other words they do simple things such as check inventory or calculate reorder points. If your needs are more complex, you simply write more services and not overload a single service with too much functionality. Services with too much functionality are considered heavy, and are difficult to reuse since you may deploy a service where you’re only leveraging 10 percent or less of its functions.
Finally, services need to be designed as standards-based. While in the world of Web services this seems like a no-brainer, many developers and architects ignore compliance with standards and thus limit interoperability.
Steps to Service Design
So, now that we understand the common design patterns we must follow, the question is: How does one design a service? Also, what tools are available? There are certain steps architects and developers can follow. Here are some suggestions, assuming new service design.
1. You need to define the purpose of the service. What will the service do, and who is the intended user; human, application, and other services?
2. You need to determine the information to be bound to the service, including both metadata and schemas. This means you need to understand how information is leveraged by the service, and what functions require what data.
3. You need to determine the functions (methods) encapsulated inside the service; in other words, the behaviors you would like to expose. It’s also at this step where we define each function, including how the function breaks down using a traditional functional decomposition chart.
4. You need to define any interfaces into the service; both machine and human.  This means we need to determine how the service will interact with the calling applications, and through what mechanisms.
5. You need to define how the service is to be tested, using the suggestions above. This is a very important but often neglected step where you define how those leveraging the service will test the service within the context of their usage pattern. You need to define test information, service invocation, and validity of results.
