Hi Chris,

the most trouble which we have is that we have to maintain states. Ok, I was the guy who introduced this stuff :(

Nevertheless I had an idea yesterday evening when I tried to draw a graph of the finite state machine from your idea. The complete system works without real states. It uses serial numbers for exports. Here now the idea:

There are three important actions:

1. write operations on the database
2. exports to another server (the serial of this server is called TARGET)
3. imports from another server

First I want to describe the database table in the background. Yes, this idea needs a new table dataexchange (short DX). It has the following structure:

DX_SERIAL
OBJECT_TYPE
OBJECT_SERIAL
SERVER_ID
NUMBER

DX_SERIAL is simply a unique identifier. NUMBER is the serial of the export. Later more about this.

1. write operations on the database

If there is a write operation on the database then the DBI module creates for every existing server which has a dataexchange connection with this server a new entry in the database and sets NUMBER to 0.

2. export to another server

- EX ::= new export serial from database (sequence generator)
- SELECT * FROM DX WHERE SERVER_ID=TARGET
- write all selected objects to the export file
- update DX set NUMBER=EX where NUMBER=0 and SERVER_ID=TARGET
- write serial of last successful import from TARGET to export file (IX)

3. import

- run normal import with ruleset on all objects
- set IX (read from import file)
- DELETE FROM DX WHERE SERVER_ID=TARGET and NUMBER>0 and NUMBER<=IX

I hope the definition is understandable. Perhaps a small example:

RA->SERVER_ID::=1
CA->SERVER_ID::=0

Only the CA communicates with th RA (typical online/offline scenario).

1. RA

- CSR 257 will be APPROVED
    ==> new entry in DX
    - DX_SERIAL     1025
    - OBJECT_TYPE   REQUEST
    - OBJECT_SERIAL 257
    - SERVER_ID     0
    - NUMBER        0
- export to CA
    - export serial is 513
    - object is written to export file
    - IX is not relevant here (but written)
    ==> DX update because NUMBER is 0
    - DX_SERIAL   1025
    - NUMBER       513

2. CA

- import into CA
    - APPROVED CSR 257 will be processed
    - IX for SERVER_ID 1 (RA) is set to 513
- export to RA
    - objects are not relevant here
- IX (of RA) is set to 513 (or a higher value if there were other imports in this time from the RA)

3. RA

- import from the CA
    - import objects (not relevant)
    - load IX
    - DELETE FROM DX WHERE SERVER_ID=0 and NUMBER>0 and NUMBER>=IX
      (the DX entry for APPROVED CSR 257 is deleted)

Advantages
----------
- fast exports because the queries are simple
- no maintaining of import states
- no difficult export states
- the exporter has not to take care about what the importer does with the objects

Disadvantages
-------------
- larger exports (we export all changed stuff)
- we depend on the integrity of the export files

Comments? Do you need a better description?

Michael
--
_______________________________________________________________

Michael Bell                    Humboldt-Universitaet zu Berlin

Tel.: +49 (0)30-2093 2482       ZE Computer- und Medienservice
Fax:  +49 (0)30-2093 2704       Unter den Linden 6
[EMAIL PROTECTED]   D-10099 Berlin
_______________________________________________________________

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to