I will predicate this with the comment I have virtually zero experience with Service Oriented Architecture.

But the question of re-use is an interesting one. What comes to mind is the dynamic linked library. Why write code over again, if there is a snippet in a library that will do the trick for you? All you need to know are what the snippets are.

This works fine, until you loose track of what code needs which libraries, and which version of the library works with that code.

I can just picture the .dll .... expanded to entire applications that an enterprise works on. Instead of libraries, you have clusters of applications that must work together. Make sure you have the correct version of each one, or that company A doesn't change something company C depends on.

For an example of the criticality of this interdependence, consider how much time third party vendors had to modify their drivers to be Vista compatible, and how many decided that some product would be conveniently end of lifed with XP, deeming it not economically feasible to update drives for older equipment. That was with one main supplier of software doing a major re-write. What if you have five or ten all trying to improve their products with interdependencies between them that any one of which might break.

One way comes to mind to prevent that problem. Well defined *STANDARDS BASED* interfaces between different services, much as EDI provides a standard form of data interchange. What it would mean is the various service providers would need to sit down together and decide it was the interest of every one to agree to and adhere to standards for interoperability.

I don't think reuse should be a goal in it self. That would mean that if reuse is not foreseen, the service shouldn't be published. That would, in the end, go against the separation of responsibilities (the consumer will eventually need to find a way to fulfill the requirement).

It is fine for a service to have a very specific (niche) use case that won't be reused by many consumers.

However, a service should be designed in a way that once another potential consumer comes forward, the service doesn't need to be changed. In a sense, you could call that 'design for reuse' (you might also call it 'reuse-proof'). But making reuse a goal in it self, measured by the number of consuming applications, that would just be foolish.