© The Linthicum Group, LLC Page 1 11/14/2006

Service Design
David S. Linthicum
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

© The Linthicum Group, LLC Page 2 11/14/2006
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.

© The Linthicum Group, LLC Page 3 11/14/2006
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.
What’s strange about this new, hot, and somewhat over-hyped space is the lack of design
tools. While there are many deployment, management, and development tools, sold by
the larger players like IBM, Microsoft, BEA, there are few tools on the market that
specifically address Web services design. IBM Rational Software Development Platform
comes the closest, providing a complete suite of tools for service and architecture design,
and other products provide some service design capability, such as BEA’s WebLogic
Workshop.