Java Reference
In-Depth Information
Packaging Related Services
Problem
You want to create a set of web services that are related conceptually and package them ap-
propriately.
Solution
Require a separate source project and deployable artifact for each individual service imple-
mentation. Never allow more than one service implementation per WAR or EAR, even though
it may initially seem more convenient.
Discussion
We're used to creating web applications that require us to put dozens of servlets in a single
WAR. We're used to creating EAR and EJB-JAR archives that allow us to put multiple EJBs
in a single deployable artifact. Do not allow this habit to permeate into your source projects
when creating services. If you know that for a given solution you need to create a set of ser-
vices, resist the urge to put more than one servlet or EJB that implements a service endpoint
into a single deployable artifact.
For example, you might be charged with creating some data services for internal use in your
organization. One will retrieve customer information, and another will retrieve store informa-
tion. These services may appear related for a variety of reasons: because they are not intended
for external use, because you're going to encapsulate them behind the same domain's ESB,
because they are read-only, because they wrap legacy code on the same iSeries mid-range box,
or because they both must use the same third-party adapter to communicate with a backend.
However, to package these two services together is a category mistake. If two services are so
designed that it appears incontrovertible that they be deployed together, they are poorly de-
signed. A service should have a single purpose (high cohesion). If it is composable within a
larger service, that's terrific. But that's yet another deployable artifact because it, too, is just a
service.
The obvious drawback to lumping multiple services together is that you cannot truly version
them separately, and you cannot fix bugs in one without recompiling and redeploying the lot
of them. Because, like regular servlets, they have separate URLs (and separate WSDLs), it
may seem that you can package them together to save development time. This may seem es-
pecially important when you have to include some third-party API, such as a JAR that allows
