Java Reference
In-Depth Information
Modeling Services
Problem
You have determined a service candidate and want to begin modeling the service.
Solution
Employ established architectural modeling techniques such as generalization, decomposition,
and aggregation.
Discussion
Once you have determined a reasonable candidate service, model the service using a set of
techniques, refactoring its definition until you know what kind of service it is, you feel com-
fortable with its definition and level of granularity, and you're sure it's still a service.
To aid in this effort, employ these information modeling techniques:
Generalization
Generalization
Analyze your service to determine what it representsconceptually, in general terms. In
object-oriented (OO) programming, this is called finding IS-A relationships. You want to
find the appropriate level of generalization for your service. You may determine that a
Customer is a Person and an Employee is a Person too. This could be a useful degree of
generalization within your enterprise. But the fact that a Person is a Homosapiensmay be
the wrong degree of generality for your dot com. Perhaps the more common problem is
that you do not get general enough in your design, failing to realize what aspects of dif-
ferent components truly align and differentiate them. Designing services at too specific a
level can shrink their possibility for reuse, and make for very complicated interfaces and
orchestrations, defeating the very purpose of your SOA efforts.
It doesn't matter what kind of service you're working with. The Person example shown
earlier regards an entity, but it's the same for a process service.
Decomposition
Analyze your service to determine what other elements it composes. Such analysis can re-
veal functional or entity services that may be worthy of standing alone in their own right.
In some cases, your process will be composed of other independent processes. Note that
the finer grained your service is, the better chance of composability and reuse it has. The
