Kontenschnittstelle

konto.idl

#include"buch_base.idl"

module buch
{
   enum Konto_typ { aktiv,passiv,aufwand,ertrag };
   interface Konto
   {
      Kontonr get_knr();
      string get_beschreibung() 
          raises(databaseerr);
      Betrag get_saldo()
          raises(databaseerr);
      Konto_typ get_ktyp()
          raises(databaseerr);
   };
};

Weitere Überlegungen

• An sich macht es Sinn, auf dieser CORBA-Ebene die logische Vererbungshierarchie zu bilden:

                  Konto
                    |
            ---------------
            |             |
     Billanzkonto     Erfolgskonto
      |      |          |      |
  Aktiv    Passiv    Aufwand  Ertrag
  

  Die Kontos werden dann noch weiter unterteilt:

  Aktive Konten

  • Anlagenverwaltung
  • Material/Lagerverwaltung
  • Debitoren
  • Kasse/Bank

  Passive Konten

  • Teilhaber
  • Darlehen
  • Kreditoren

  aufwendungen

  ertraege

• Wie aus [Scheer95] hervorgeht, werden wohl diese Kontos in eigenständigen Teilbuchhaltungen verwaltet.
• Impementierungstechnisch wird das heißen, daß die Teilbuchhaltungen über mehrere Server verteilt sind, wozu sich CORBA sehr gut eignet.
• Die Teilbuchhaltungen werden dann wohl über den Cos-Transaktionsdienst verbunden sein.
  Dazu wird die Kontenschnittstelle wohl mit den Operationen debit(...) und kredit(...) erweitert, die einen Buchungshalbsatz eintragen.

Bemerkungen zur Postgresimplementierung

Die Kontenobjekte werden durch einen POA mit folgender Politik realisiert:

Retention_policy: NON_RETAIN

(vgl. Core POA 11.3.7.5) Die Servants, also die C++-Objekte, die die CORBA-Objekte Implementieren, werden nach dem Aufruf nicht aktiv gehalten. Dies verhindert die Inkonsistenzen durch Caching, allerdings zu dem Preis, das bei jedem Aufruf die Daten neu aus der Datenbank geholt werden müssen.

Request_processing_policy: USE_DEFAULT_SERVANT

Die Kontennamen gehen in die IOR ein, die Daten werden nach den Kontennamen sowieso aus der Datenbank geholt, so haben wir nur einen Servant, der alle Konten implementiert. (vgl Core POA: 11.3.7.6)

id_uniqueness_policy: MULTIPLE_ID

Unser Servant bahandelt meherere IDs, nämlich alle. (vgl. Core POA: 11.3.7.3)

id_assignment_policy: USER_ID

Die Objekt-Identitäten sollen die Kontonummeren sein, also müssen wir sie selber festlegen. (vgl. Core POA: 11.3.7.4)

lifespan_policy: PERSISTENT

Die Referenzen auf die Konten sollen mehrere Serverinkarnationen überdauern. (vgl. Core POA 11.3.7.2)