Java Reference
In-Depth Information
your related services. Do not allow the idea of saving a few development steps to seduce you
into defeating the whole point of SOA.
Always allow only one service implementation per deployment. If your service is implemen-
ted as a servlet, put that single servlet in your WAR, along with any supporting classes. If you
have another web service that seems related, create a separate project, and put the second im-
plementation in it. If it, too, requires some of the same supporting classes as your first service
did, then you have a shared dependency that must be treated as a first-class citizen. JAR those
classes up, put them in a versioned repository somewhere (such as Archiva if you're using
Maven), and declare the dependency in both service implementation projects. The extra time
you take here is absolutely negligible in comparison with the flexibility you gain down the
road. There's no point in doing SOA to create business agility, just to tie everything together
on a fundamental and practical level. This will strangle your future efforts.
