Access Keys:
Skip to content (Access Key - 0)

Proposed IBP Architecture


  • A separate instance of the middleware will run on the Cyber-Infrastructure IBP and each of the local IBP installations. The local IBP middleware will communicate with the central cyber-infrastructure middleware. This is to minimize impact during schema changes as the central middleware can perform backward compatibility with older locally-deployed middlewares.
  • The IBP may connect directly to the configuration database. On retrieving breeding-related data we can course the queries via the middleware. But on getting some configuration details/metadata we can skip using the middleware (it could become huge and add large overhead during development).
  • Local database with private data are backed-up in the cyberinfrastructure on their own separate database instance.
    • Question: What is our strategy for managing the private data backups on the cyber infrastructure? Do we just offer these to scientists and just let them give us copies of their local db to place in the backup? There is a line between these backups and the middleware and these might cause concern because it might appear to some that the private data are being publicly accessible on the cyber infrastructure.
    • Answer: That's why the backups are on separate instances in the cloud, we can manage the access to their instance backups. We can provide applications so that they can "incrementally" sync modifications on the databases. If the sync processes are interrupted and some data are corrupted we can easily copy-deploy a clean instance either from their local or the central.
Adaptavist Theme Builder (3.3.3-conf210) Powered by Atlassian Confluence 2.10.3, the Enterprise Wiki.
Free theme builder license