It's All in the Staging
Similarly, in the direct remote synchronization architecture, each offline application had to query a currency conversion service after receiving each change. In this architecture, after the staging database has noted that inventory has changed, it can make these service requests and store the result. This method eliminates the 1,980 redundant requests needed in the direct remote synchronization architecture and effectively "pre-mashes" the data that will be synched to the offline applications.
Just as the staging database can support change tracking, it can also support the data partitioning and filtering. Unlike the generic data services that are not designed for synchronizing applications, the staging database can be designed to handle this task. The staging database may still need to do the same steps to partition the data as in the direct remote synchronization architecture, except the staging database can do it in a single step on the server side.
Although the application still must be installed on all devices, the staging database totally decouples the application from the back-end data stores. In an extreme case, entire systems can be renamed or protocols changed without the installed offline application ever being updated. As long as the staging database is modified to access the new data, the offline application will remain oblivious.
In the previous architecture the application had interfaces to SOAP, XML-RPC, and JMS. In this architecture, the offline application has to only support the single protocol that the staging database decides to expose. This approach helps reduce both the application's size and the number of support issues against the application.
The architectures discussed here are very general architectures for supporting offline applications that access data across many heterogeneous systems. The benefits of stronger security, increased robustness, reduced traffic, and simplified application maintenance tip the hand in favor of the staging database solution. The staging database solution allows for the greatest amount of flexibility because the bulk of the synchronization effort is done on the server side. However, as mentioned previously, these architectures represent the two extremes. Your particular setup may be best solved by a hybrid approach that combines elements of both architectures.
The approach discussed here really only scratches the surface of the challenge of synchronization to heterogeneous data sources. Most of the complex synchronization problems you encounter will be unique to your application and your infrastructure.
In many ways synchronization is a lot like security. Security is at its best when it's a core feature of each component. VPN servers act as buffers to provide security to components that lack it as a core feature. Similarly, synchronization works best when it's designed as a core feature in each synchronizable data store. The staging database, working as a synchronization server, can provide synchronization for data stores that cannot provide it themselves.