Documents and decoupling

This isn't really a huge thing, but I'm figuring I'll write about it a bit to point out some best practices when dealing with distributed systems.A common thing that tends to pop up in these types of systems is service calls that happen between the systems. This is all well and good, but it tends to create dependencies between the systems that are hard to manage. If the specifics of the interface start to change between different versions of the call, you can get yourself into a situation where both of the systems need to get upgraded simultaneously to get things working. This can be a bear to pull off if the systems are run by different teams or even different organizations.An alternate way to look at this is instead of making complex service calls between the systems, you can make calls that both send and receive a document of some type.Documents can be a lot more flexible than a tightly specced method invocation. So, instead of a call that looks like:

Customer service.getCustomer(long customerId);

where a Customer is a strictly defined object, you can make something more like:

XMLDocument service.getCustomer(long customerId);

This way the exact definition of what's returned by the service request can change over time. So if another group decides they need something else with the customer it can be added to the resulting document withoutevery downstream system needing to care about it or getting re-deployed.Likewise, it can be a lot easier to code around data that might be missing from an older implementation of a service than it is to work around a call that outright fails.In this case I was just using XML as the document container, but there's no real reason to limit yourself to that. You can just as easily use something like JSON or YAML.Another key advantage is it's a way to further decouple yourself from even the languages that are in play. As long as you have a way of reading and writing the format in whatever language you're working with you're in a good place.