Service dependencies
Dependencies in SOA open a whole new can of worms
Dan Creswell has an interesting take on how he sees service aggregation panning out in the future, particularly with respect to the problems around service dependencies.
There is much talk about aggregating services together with a lot of excitement around the idea of combining services supplied by other enterprises. At the base level this seems like an exciting proposition and it's possible to realize this promise now but I think there are some interesting issues just over the horizon.
...
Assuming that you've managed to wire all these services together successfully, you've now substantially widened your network of dependencies. Many of the factors in question are now out of your control, you are reliant on the service's vendor to "do the right thing". This is an order of magnitude worse than being reliant on some other team's services within a single enterprise.
Personally, this makes me think that (1) it's even more important to define public services at the correct level of granularity and (2) you need to think carefully about designing service interfaces that are seamlessly upgradeable. Certainly some food for thought.
Re: Service dependencies
This, like so many "new" problems, was addressed by the designers of Jini years ago. The trick is to think in terms of linking to capabilities and content rather than locations.
The metaphor I use to illustrate this problem is of a public library. It would be nonsensical to walk into a library and ask for the book, third from the end of the second shelf by the door. Obviously libraries are free to move, lend, and replace their books. And no two libraries arrange their books in the same places.
So library users ask or look for some of the aspects of the kind of book they are seeking: author, title, ISBN, subject etc.
Networked services are just the same. To assume that a URL is enough to robustly find a service can be dangerously naive.
