There is a lot of information stored in many of different places: databases, repositories, SCM systems, registries, file systems, services, etc. The purpose of the federation engine is to allow applications to use the JCR API to access that information as if it were all stored in a single JCR repository, but to really leave the information where it is.

Why not just move the information into a JCR repository? Most likely there are existing applications that rely upon that information being where it is. If we were to move it, then all those applications would break. Or they'd have to be changed to use JCR. If the information is being used, the most practical thing is to leave it where it is.

Then why not just copy the information into a JCR repository? Actually, there are times when it's perfectly reasonable to make a copy of the data. Perhaps the system managing the existing information cannot handle the additional load of more clients. Or, perhaps the information doesn't change, or it does change and we want snapshots that don't change. But more likely, the data does change. So if applications are to use the most current information and we make copies of the data, we have to keep the copies synchronized with the master. That's generally a lot of work.

The JBoss DNA federation engine lets us leave the information where it is, yet lets client applications use the JCR API to access all the information without caring where the information really exists. If the underlying information changes, client applications using JCR observation will be notified of the changes. If a JBoss DNA federated repository is configured to allow updates, client applications can change the information in the repository and JBoss DNA will propagate those changes down to the original source.