When I was negotiating with the Swedish tax department (skatteverket.se) about them using SiteVision, one of the first and most fundamental questions I got was: "we will be around centuries after you are gone, so how will we be able to migrate out of your product once your compay is not there anymore?". It was an eye-opener to me, and also got me thinking about one of the fundamental points of Service Oriented Architecture. I had often heard the suggestion that "your data will outlive the application", and it is a correct one. It should also be the case that consumers of a service should not care how the data it is managing is being stored, since all acces to it is through a service interface.
With this in mind, it makes sense that one of the fundamental requirements for a service is that, considering the time aspect, it should have an import function, for handling the data of the service that was its predecessor. It should also have an export function, so that once it is replaced with another one there is a predefined escape route from it.
In SiteVision, the escape-route is the export format, which is a zip-file with an entire website, where the internal Java domain model is simply XStream-ed to XML, and all the binary files are added as files to the zip. That zip can then be migrated to any format that the tool replacing it, hopefully in a couple of decades or so, is using. If we always have this in mind when creating and managing services and its data, then it should be radically simpler to create SOA's that will evolve over time.
Currently it seems like the default answer to the assumption that "the data will outlive your application" is to use a relational database. I think that is wrong. I think that as long as a service has been designed with these requirements in mind, so that data can always be imported and exported using formats that are reasonably long-lived (such as XML), then each individual service can be implemented using whatever makes sense today, be it relational databases, network databases (like Neo4j), persistent hashtables (like Hadoop or JDBM), Lucene, GigaSpaces, or whatever.
This will give the developer of the service the freedom to experiment, and to use the tool that best solves the given problem. Without this insight one would almost always have to apply the most cautious route and use relational databases for everything, which would be wrong in many cases.
It also provides a natural way to do backups, since that is simply a copy of whatever export/import format the service uses. It makes sense to standardize this to whatever works well right now, such as XML formats, but as previously noted, this is not primarily for handling corrupt databases and restores, but rather to ensure that data really does live longer than the application that produced it.
I doubt, however, that many people see it that way currently. And that is wrong. They should. It will simplify the lives of everyone, inclding the ones writing the service. If this is realized, it will mean that there is less fear of change, and that owners of SOA's can be sure that whatever technology is "correct" in the future, there will be a way into it, and subseqently, a way out of it once it is not the best way to solve things. We don't do things the same we did five years ago, and certainly not the same wasy as we did ten or fifteen years ago, and there's no reason to assume this will not be true in the future as well.
Therefore I suggest that one of the most critical things to keep in mind when building SOA's, or any system at all which is expeced to exist for a long time, is this import/export idea. Expect change, and do so by making it easy not only to migrate into a solution, but also to migrate out of a solution.
