This is a pattern I’ve seen in many hosting situations, and ended up debating a little while back. It’s the one-DNS-name-for-a-machine-and-lots-of-services-on-it pattern. 😉 Among the services is typically a SubVersion repository, Maven repository, Maven proxy, Hudson, Wiki and and maybe some other stuff you use when developing. When migrating to new hardware the discussion about timing and responsibilities pops up. The usual plan: A big bang migration with a change in the DNS to point to the new machine.
This brought to mind some important things to remember when designing services. The funny thing is that this doesn’t just apply to SOA in the sense of integration across a network. These are important things to remember even if you are designing straight up internal object calls.
Connect to the interface or role, not the implementation. In the above scenario, meaning: Use a DNS name for each service, and not the DNS name for the machine. This also applies in Java where you use the interface of the service, not the implementation of it. Think in roles roles. 🙂
Use business meaning names for services and methods on them. Don’t call it LDAPLookUpService, it is a UserAuthenticationService and should have a method called authenticateUser(username, password) not getUser(username, password). getUser will be (mis)used for lots of different stuff that has nothing to do with authentication. With the DNS case this can be a bit trickier since your SubVersion client will of course be tied to a SubVersion repository. It could be handled by calling it http://sourcecontrol/svn/, but that would of course tie several sourcecontrol systems to be on the same machine. Better than the original case though.:) And if you absolutely must, you could do some proxy magic with Apache.
In the above case if each service did have it’s own DNS you could migrate each service separately, only changing the DNS for the specific service that is beeing moved. This would give you a more controlled step-wise migration, and different downtimes for different services. Having the SubVersion repo down doesn’t necessarily match the same timeslot when you can have the Wiki down.
So should this stuff really be handled by something like UDDI? Maybe. Does SubVersion support UDDI? Don’t think so. 🙂