Federation Concepts

i. Dataservers

• handle all files - 99% being image data

• dataservers know about each other

• files are store()d on one local dataserver

• files are retrieve()d from the local dataserver

• if a file is not available locally it is retrieve()d automatically from one of the other dataservers

• files that were not locally available are cached to speed up future access
  

Current situation

• single dataservers in use at the different Astro-Wise sites
  98,697 files at OmegaCEN
  

Soon and fairly soon

• multiple dataservers connected and in use at OmegaCEN

• dataservers connected between Astro-Wise sites

ii. CVS

• configuration files + source code are handled by CVS

• central repository

• local copies / check outs
  

• STABLE version

Current situation

• in use at all Astro-Wise sites - more than 30,000 changes to odoco, opipe and awhtml.

• automatic updates

Soon and fairly soon

• automatic installation and maintenance

• more (and more) commits. Software, manuals, etc.

iii. Database federation

• persistent objects are distributed via a messaging protocol (queue),
  

  • either through Oracle STREAMS messaging
    

  • or through Python messaging

• true for all DBObjects i.e.

  • CalFiles

  • METAdata of Raw and (Reduced)ScienceFrames and CalibrationFrames - such as image statistics

Current situation

• multi-user databases operational at the Astro-Wise sites
  

• prototype using STREAMS messaging being implemented
  

Soon and fairly soon

• federation-wide users
  

• per user / context read/write and delete permission
  

Locally, a client-server architecture of Oracle is deployed. awe clients connect to the local database via the network.

Different servers communicate with each other (OAC, USM , Terapix etc) via iii) and i).

Servers exchange the METAdata / DBObjects, but not the files. Files are handled by the dataserver.