php Transaktionsserver

Der Transaktionserver ist ein Modul des Multi Purpose php Framework und kommt damit u.A. auch bei dieser Website beim Registrierungs-Prozess und dem Bearbeiten Ihrer Kontaktdaten zum Einsatz. Er kann aber auch statt an das Website-Framework an eine beliebige andere Web- oder Desktop-Applikation gekoppelt werden. Der von Dipl.-Informatiker Martin Hupf in C# entwickelte .net-Client zur Verwaltung des Produkt-Sortiments des Shop-Plugin manipuliert z.B. über den Transaktionsserver die Shop Datenbank.

Eigenschaften


Der Transaktionserver realisiert u.A. ein CRUD-Interface, d.h. Create-, Read-, Update- und Delete-Datenbank-Operationen können in weiten Grenzen beliebig formuliert werden. Als Datenbank kommt MySQL, als DB-Zugriffsbibliothek ADODB zum Einsatz.
Datenbank-Abfragen und -Operationen können ähnlich komfortabel definiert und abgeschickt werden wie z.B. beim ORM-Framework Doctrine. Ebenso wie dieses immunisiert der Transaktionsserver die Applikation gegen SQL Injection.

Anders als bei ORM-Frameworks wurde aber darauf verzichtet, innerhalb einer Datenbank-Operation die Verknüpfung von Datenbank-Tabellen definieren zu können. Auf der Haben-Seite steht ein äußerst schlanker (ca. 2k Zeilen) und schneller Transaktionsserver.
Es ist die persöhnliche Meinung des Daten-Rücker, daß Tabellen-Verknüpfungen besser in sog. Datenbank-Views oder -Snapshots aufgehoben sind. Im sind jedenfalls kaum Problemstellungen untergekommen, die sich so nicht lösen ließen. Ansonsten werden komplexere oder umfangreichere Abfragen bzw. Transaktionen nach diesem Design-Paradigma in spezifischen Modulen des Transaktionservers realisiert.

Typen von Operationen

Folgende Typen von Operationen stehen bereit:

  • Datenbank-Operationen,
  • Dateien erzeugen (z.B. pdf oder xls),
  • Payment Operationen (z.Z. PayPal oder Kreditkarten mit Concardis) und
  • Emails versenden.

Operationen haben Typ-übergreifend u.A. die Eigenschaften

  • "ist rücknehmbar" (Datenbank-Operationen und das Erzeugen von Dateien sind normalerweise rücknehmbar, der Versand von Emails und Payment-Operationen nicht) und
  • "ist kritisch" (Normalerweise immer ja, Operationen können aber auch als unkritisch gekennzeichnet werden, sodaß die Transaktion im Falle eines Fehlschlags der Operation fortgeführt wird).

Der Datei-Generator verfügt über eine generische Schnittstelle, die es in weiten Grenzen erlaubt, beliebige interne oder externe Generatoren einzubinden.

Transaktionen

Operationen werden in Transaktions-Blöcken an den Transaktionsserver geschickt, Ein Transaktionsblock könnte z.B. sein:

  • Einen Bestellungs-Kopfdatensatz und die zugehörigen Detaildatensätze in die Datenbank einfügen,
  • Eine Rechnungs-pdf-Datei erzeugen
  • einen Bezahlvorgang bei einem externen Payment-Dienstleister auslösen,
  • eine Bestell-Bestätigungs-Email mit der Rechnungs-pdf-Datei als Anhang an den Kunden und
  • eine Nachricht über die Bestellung an den Shop-Betreiber schicken.

Das "Last-Insert-Id"-Problem ist im Transaktionsserver gelöst, d.h. die Bestellungs-Id kann im o.g. Beispiel in Bestellungs-Detail-Datensätze, die Rechnungs-pdf-Datei und die Bestell-Email einfließen, obwohl deren Wert beim Formulieren des Transaktionsblocks noch nicht bekannt ist.

Inwieweit der php-Transaktionsserver dem Vergleich mit Produkten wie z.B. JBoss standhalten kann, wäre noch eine Rechercheaufgabe für den Daten-Rücker. In einer Transaktion heißt hier konkret, daß z.B. folgende Dinge vom Transaktionsserver gewährleistet werden können:

  • Multiple Datenbank-Operationen über mehrere Tabellen werden ganz oder garnicht ausgeführt.
  • Abbruch der Transaktion und Rollback der rücknehmbaren Operationen (s.o.), wenn eine kritische Operation (s.o.) scheitert, z.B.
    • eine Datenbank-Operation schlägt fehl,
    • z.B. die Rechnungs-pdf-Datei konnte nicht erzeugt werden,
    • eine Payment-Operation ist gescheitert oder
    • ein für eine erfolgreiche Transaktion unverzichtbarer Emailversand ist gescheitert.

Transaktionen über mehrere Datenbanken sind in Arbeit. Die Verteilung von Operationen auf Datenbanken und ggfs. Rollback in allen Datenbanken soll dabei vom Transaktionsserver (nicht von der Applikation) übernommen werden.

Transportschicht

Protokolle der Transportschicht:

  • Passthrough, d.h. ein Kurzschluss in der Transportschicht.
    Empfehlenswert, wenn Transaktionsserver und Webclient im gleichen Verzeichnis liegen.
  • SOAP
  • REST ist in Planung

Request- sowie Response-Daten-Formate

  • php-Array
  • json
  • XML