The Pattern we describe in this post will be useful to organizations that operate with a central master datacenter together with distributed applications in geographically diverse locations. We can take as examples the retail sector where an organization runs a chain of many stores, hospitality sector with many hotels and restaurants, or the healthcare sector with many hospitals and pharmacies.
Synchronizing data between the distributed agent repositories and the central master repository is a common requirement for businesses of this nature. Often the two-way synchronization must occur on at least a daily basis to keep all the systems up-to-date. Transaction data has to come from the agent data stores to the master store; master data and reconciled data has to go back to the agent data stores from the master data store.
A common approach to implement the above scenario is to run a periodic process within each agent data store, which connects with a process running in the central data store and creates a channel to transfer between data stores. This approach requires a large-scale system change, requiring systematic changes to both the central system and each agent store system. It may require coordination between agent stores to avoid overwhelming the central store. Each store may even have to purchase new hardware and the associated costs can quickly scale upward depending on the number of connected stores. IT staff may be needed to look after each and every store to keep the system running smoothly. Costs and expertise requirements mount quickly with this architecture.
How can we reduce the deployment and management complexity and keep costs reasonable? WSO2 has identified a solution pattern that pulls and pushes data from the main datacenter, without installing additional components and initiating periodic processes in the agent data stores.
This pattern consists of a central process that schedules and connects to each agent data stores using a data connectivity technology (e.g. JDBC, ADO) and directly synchronizes the data (e.g. RDBMS) running in the store. The WSO2 middleware platform, specifically the WSO2 ESB and the WSO2 Data Services Server, provides OOTB functionality to implement the above pattern. These products are deployed a the central datacenter location.
WSO2 ESB scheduled tasks are configured to kick off the synchronization task, based on the frequency of the synchronization needed. These timer tasks invoke data services deployed in the WSO2 Data Services Server, which provide a CRUD (Create/Read/Update/Delete) service interface directly against the agent data repository. The WSO2 Data Services Server is capable of executing the SQL queries or calling a stored procedure of the agent data store as required to implement the required CRUD operations. WSO2 ESB will update the sub-system data store with data coming through the data services and will push the data back through to the master store through the same data services by reading from sub-systems. Built-in mediation features of the WSO2 ESB such as transformation and routing can be used to convert messages between different data models as well as route to relevant sub-systems, kick off additional events or processes, and so forth.
This pattern is suitable for both NRT (Near Real Time) and batch synchronization requirements, whichever is best suited for the organization that runs these type of distributed deployments.
Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/