transObjects® vs. WinXY oder wozu brauche ich einen Datenbankserver?

Die nachfolgend diskutierten Fälle sollten mögliche Konsequenzen aus dem Nicht-Vorhandensein von bestimmten technologischen Merkmalen, hier der aktiven Datenbankinstanz, veranschaulichen.

Der Gegenstand der Analyse (aus dem Jahre 2004 – Anmerkung anno 2009) ist jeweils eine typische Desktop-Software, basierend auf einer Access-Datenbank mit dem dazugehörigen Interpreter fürs Basic. Auf die explizite Benennung der jeweiligen Softwareprodukte verzichten wir wohlwollend 😉 – verwenden stattdessen den Kunstnamen „WinXY“, wobei Affinitäten zu den bestehenden Produkten rein zufällig und in keiner Weise beabsichtigt sind. Unsere Fälle, auf den in zahlreichen FAQ-Artikeln unserer Website Bezug genommen wird, liegen folgendermassen:

Fall 1:

Ein kleineres Speditionsunternehmen in der Schweiz wendet seit einigen Jahren die WinXY-Software für die Bereiche des Auftrags- und Logistikwesens an. Im Frühjahr 2004 beschliesst der Geschäftsführer und Inhaber einige transObjects®-Anwendungen für elektronische Verzollungsverfahren anzuschaffen. Fortan betreibt er diese an mehreren Standorten, darunter auch mobil vom Lieferfahrzeug aus und auch am Hauptstandort neben WinXY im gleichen LAN. Zunächst versetzt ihn das Ansprechverhalten von transObjects® an externen Standorten in ein nicht schlechtes Staunen, hat er sich doch bereits vor einigen Jahren Ähnliches mit WinXY glatt abgeschminkt: Es hatte sich schlicht nichts von der Stelle bewegt!

Trotz Einschränkung der Anwendung von WinXY auf die Grenzen des lokalen Netzwerkes am Hauptstandort (noch vor der transObjects®-Zeit) verschärften sich die Probleme stetig weiter. Während es für den Benutzer direkt am Server gerade noch ging, wurde das Ansprechverhalten von WinXY an den jeweiligen Workstations immer unangenehmer, bis schlicht unzumutbar. Eine Datenbankabfrage, die einem weit zurückliegenden Vorgang galt, konnte schon mal ein paar Minuten dauern und so lange könne man einen Kunden ja nicht am Telefon hinhalten, wie der betroffene sympathische Tessiner einmal zu uns sagte… 😀

Notgedrungen (oder vielleicht müsste man sagen, WinXY-gedrungen) griff unser Kunde seinerzeit zu Windows-Terminals. Dadurch entschärfte er ein wenig die Problematik des Ansprechverhaltens an den Workstations, wenn auch zum Preis diverser anderer Probleme, etwa mit den Peripheriegeräten. Völlig entnervt orderte er schliesslich eine neue High-End-Hardware und erhoffte sich dadurch seine Sorgen loswerden zu können. Unser Verweis auf das nach wie vor souveräne Ansprechverhalten von transObjects® geriet in den Hintergrund; stattdessen ruhten alle Hoffnungen nun auf der neuen Hardware mit dem neuen Betriebssystem.

Wie die Geschichte ausging, kann sich jeder technisch bewanderte Leser leicht denken: WinXY lief auch auf einer noch so guten Hardware nicht viel besser, also musste unser Tessiner zurück zu den Windows-Terminals, wobei Inkompatibilitäten des Windows 2003 zu diversen Peripheriegeräten, die unschwer vorauszusagen waren, auch prompt eingetreten sind. Sein Gemütszustand ist mit seinem „Aaach! Es ist doch alles hoffnungslos!“ (oder so ähnlich…) am besten umschrieben.

Und was war in dieser Zeit mit den transObjects®-Applikationen los? Ja, die verrichteten ihre Dienste stets ohne Anstalten, so dass man sie in dem ganzen Wirrwarr schlicht vergessen hatte. Ob auf der alten oder neuen Hardware, von externen Standorten aus oder via GPRS-Verbindung vom Fahrzeug aus, ob über den Datenbankserver am Hauptstandort oder über das kurzzeitig dazwischen geschaltete Datacenter: auf transObjects® war immer Verlass!

Fall 2:

Ein mittelständischer Logistiker und Dienstleister wendet transObjects®-Applikationen mit durchaus hoher Intensität an und zwar an den drei grössten Passagierflughäfen in der Schweiz und vereinzelt auch im Ausland. Für die Finanzbuchhaltung schafft er sich u.a. aus historisch gewachsenen Gründen die WinXY-Software an. Den potentiellen Performanceproblemen der Desktopsoftware WinXY hofft er durch ein optimales Handling beikommen zu können: Getrennte Datenbankfiles für die jeweiligen Mandanten und eng gesteckte Abrechnungszeiträume, möglichst ein exklusiver Zugriff nur eines „single“-Clients auf die jeweiligen Datenbankfiles etc.

Diese Massnahmen ermöglichten zwar der zuständigen Abteilung des Unternehmens die klassischen FiBu-Aufgaben einigermassen zuverlässig erledigen zu können. Allerdings musste auf weitergehende Funktionen, wie etwa die betriebswirtschaftliche Auswertung, wie sie transObjects® processPRO in den Probeläufen im Nu erledigte, gänzlich verzichtet werden, denn eine Auswertung über grössere Zeiträume hinweg hätte ja geheissen, die zuvor aufgesplitterten Datenbankfiles nacheinander „abklappern“ zu müssen. So gesehen war es nicht unbedingt überraschend, dass ein Versuch dies doch noch zu tun in einem totalen Fiasko endete: Clients, die solche Auswertung starteten, gaben anschliessend leider nicht zu erkennen, ob sie sich bereits aufgehängt hatten oder noch am rechnen waren… Auf die Frage, was denn nun zu tun sei, antwortete jemand scherzhaft, „Reset-Taste betätigen“… 😉

Leider war die Konsequenz einer solch unsanften Massnahme zumeist eine Inkonsistenz von den Datenbankfiles. Solche Datenbankfehler waren weitaus ärgerlicher, als die dadurch begrenzte Anwendbarkeit von WinXY. Der Alltag in der FiBu-Abteilung sah doch so aus, dass man vor jeder grösseren Operation, etwa einem Buchungslauf, die Datenbankfiles sichern musste, um sie dann im Falles eines Fehlers in den Ausgangszustand zurück versetzen zu können. „S’ischt mühsam“ war häufig zu hören.

Damit aber noch nicht genug. Die Datenbankfehler waren leider an der Tagesordnung und nicht immer war man bereit, den halben Arbeitstag durch den File-Restore „ungeschehen“ zu machen. In anderen Fällen waren wiederum die Datenbankinkonsistenzen so schwer, dass die beschädigten Files nur durch äusserst aufwendige Reparaturen (erforderlich war das Einschicken der Files an den Softwarehersteller!) wieder instand gesetzt werden konnten. Gewiss war die Umgebung, in der WinXY betrieben wurde, nicht ganz optimal: LAN-Störungen waren des Öfteren zu verzeichnen und die Verfügbarkeit des Files-Servers war auch fernab von „100 pro“. Aber das alles war fürs transObjects® genau gleich und dort ist eine Datenbankinkonsistenz im Laufe des 10-jährigen Betriebes kein einziges Mal vorgekommen…

Wie kann ich mein System XY ans TransObjects® koppeln? Hat’s da Schnittstellen?

Dieser Artikel ist outdated. Schnittstellen und Services zum Datenaustausch mit Fremdsystemen bietet die logistische Integrationsplattform loggPRO.net.

Zu den wohl am häufigsten zu beobachtenden – oder mittels processPRO feststellbaren (!) – Unstetigkeiten (nennen wir es mal so) im alltäglichen betrieblichen Ablauf aus der Sicht der IT gehören Doppelerfassungen von Daten. Der volkswirtschaftliche Schaden, der dabei entsteht, ist so immens, dass man inzwischen die Güte eines Systems völlig zu Recht u.a. an dessen Fähigkeit zu einer möglichst aktiven Kooperation mit anderen Systemen misst.

Der nachfolgende Artikel belegt, dass TransObjects® ein sehr offenes System ist, dass diverse Möglichkeiten in dieser Hinsicht bietet und die Interaktion mit anderen Systemen aktiv eingeht.

Vor ein paar Jahren hat einer unserer Kunden bei einem der führenden und börsennotierten Anbieter von ERP-Lösungen wegen einer Schnittstelle angefragt. Die Antwort lautete „selbstverständlich“, die Schnittstelle werde verfügbar gemacht, unter lizenzrechtlichen Auflagen (insb. Geheimhaltung) und gegen eine Lizenzgebühr in Höhe von 50’000,- € !

Ein Größenwahn? Das sicherlich auch, zumal das betreffende Unternehmen unaufhaltsam wächst, was dem Management, das derartige Verträge eingeht nicht gerade das beste Zeugnis ausstellt. Aber eine nicht minder wichtige Ursache hierfür liegt klar auf der Hand: das betreffende System ist schlicht nicht up-to-date! Es ist veraltet, daher nur unter schier unermesslichem Aufwand mutierbar und ausserdem unter sicherheitsrelevanten Gesichtspunkten nicht richtig konzipiert, weshalb die Geheimhaltung eine so wichtige Auflage darstellt.

Wir können den Leser beruhigen. Nachfolgend findet er eine (kostenlose ) Beschreibung der TransObjects®-Schnittstellen, ferner von Szenarien, in denen eine Interaktion mit anderen Systemen zustande kommen kann und dies zu bewerkstelligen ist.

Zu den wohl häufigsten Szenarien, in denen sich die Ausgangsfrage stellt, gehört in etwa das Folgende: Ein Unternehmen verfügt über ein betriebsinternes System für Auftragsbearbeitung, das über Jahre hinweg, gewissermassen organisch, gewachsen ist, so dass man sich hiervon nur ungern trennen möchte. Mangels Alternativen legt man sich aber TransObjects®-Software für Warenabfertigung zu, etwa atlasPRO, edecPRO oder was auch immer. Nach erfolgreicher Inbetriebnahme stellt man rasch fest, dass viele Daten, obwohl diese schon einmal im Auftragswesen erfasst worden sind, zwecks Warenabfertigung erneut erfasst werden müssen.

Ein anderes Szenario: Ein Unternehmen, mit dem ein TransObjects®-Anwender kooperiert, möchte diesem Auftragsdaten auf elektronischen Wege zukommen lassen und den fertig bearbeiteten Auftrag wieder zurückbekommen, um ihn z.B. finanzbuchhalterisch weiterverarbeiten zu können.

Beide Fälle sind ähnlich gelagert. Es geht im Wesentlichen um zweierlei Fragen: Wie kann ich eine TransObjects®-Datenbank mit Daten versorgen bzw. wie kann ich aus der TtansObjects®-Datenbank Daten herauslesen. Beides sollte natürlich ohne Informationsverlust stattfinden und möglichst automatisiert ablaufen.

Um Letzterem zu genügen, bedarf es zu allererst einer gemeinsamen Sprache, die allseits verstanden werden kann, also geht es um ein Datenformat. Da der sog. „Object Dump“ doch recht proprietär war, schwenkte die K&S Anfang der 2000’er auf das XML ein, was das Format für multidimensionale (also auch objektorientierte) Datensätze schlechthin war und inzwischen einen beachtlichen Bekanntheitsgrad errungen hat. So gibt es inzwischen unzählige Softwareprodukte, die – ein bestimmtes Schema vorausgesetzt – Daten in XML-Form aufbereiten bzw. diese aus einem XML-File herauslesen können. Das senkt schon mal vorab den anstehenden Programmieraufwand in einem nicht unbeträchtlichen Masse.

Verständigt man sich also bei den Formaten auf einen inzwischen weit verbreiteten Standard á la XML, so kann man mit dem Aufbau eines Interaktiven Systems zur Koppelung des eigenen TransObjects®-Systems an externe Systeme (oder umgekehrt) beginnen. Als mögliche Datenaustauschwege gibt es wie bei den Formaten auch schon eine Vielzahl von unterstützten Protokollen, deren bloße Auflistung den Rahmen des vorliegenden Artikels völlig sprengen würde. Aber auch hier gibt es eines dem der Vorzug zu geben ist und das gerade im Zusammenhang mit dem XML immer wieder genannt wird (www.xml.org, vgl. auch SOAP), nämlich das HTTP(S), darunter insbesondere die sog. Webservices.

Es gibt eine ganze Reihe von Vorteilen, die die Webservices mit sich bringen. In einem Satz: Sie sind verhältnismässig einfach in eigene Umgebung zu integrieren, weisen aber gleichzeitig ein akzeptables Sicherheitsniveau auf und sind bidirektorial einsetzbar, d.h. auch um bestimmte Daten aus der TransObjects®-Datenbank herauszulesen.

Was muss also letzten Endes jemand tun, der z.B. Auftragsdaten einem Beauftragten User zur Weiterverarbeitung (etwa Verzollung) in dessen TransObjects®-Datenbank schicken möchte? Ganz einfach: diese in XML-Form lt. Schema aufbereiten und aufs „DFÜ“ legen, wobei dieses „DFÜ“ vorzugsweise ein Webservice sein sollte und nur in zweiter Linie evtl. etwas anderes, wie z.B. SMTP(S), FTP(S), FTAM, X.400, WEBDAV oder was auch immer.

Wozu 64-Bit? Welchen Nutzen hat es im Allgemeinen und fürs transObjects®?

Die Frage „Wozu überhaupt 64-Bit“ lässt sich am besten aus der geschichtlichen Retrospektive heraus erklären. Die alte 8-Bit-Welt ist nicht mehr sehr vielen von uns geläufig, dafür aber die 16-Bit-Welt aus den Zeiten von Windows 3.1 usw. Das Problem des 16-Bit-Adressraumes ist sehr schnell ausgemacht: Gerade mal 65 KByte Speicher standen z.B. einer DOS-Anwendung zur Verfügung! Mehr war – wenn überhaupt – nur auf Umwegen zu haben; wir erinnern uns an so was wie XMS, EMS etc.

Der Einzug von 32-Bit’ern würde uns schier unbegrenzte Adressräume eröffnen – dachten wir uns vor ca. 15 Jahren, als wir unseren 286’ern beim Abzählen von teuer angeschafften ein paar MB’s RAM zuschauten. Dass in nicht allzu ferner Zukunft eine gute Vertausendfachung dieser Kapazität stattfinden wird, war zum einen nicht unbedingt zu erwarten und zum anderen haben wir uns nicht so sehr Gedanken darüber gemacht, wie das 32-Bit-Windows den Adressraum von Schwindel erregenden 4 GB aufteilt (vgl. z.B. /3GB-Switch).

Bleiben wir noch einen Moment bei der Geschichte des Wachstums von Adressräumen. Eine der Fragen, die manchmal an dieser Stelle gestellt wird, ist die, ob man mit den 64 Bits nicht schon wieder zu kurz springt. Hier kann man wenigstens einmal ruhigen Gewissens eine Antwort geben, die man ganz sicher nicht schon ein paar Jahren wieder einsammeln kann: Die Millionen TB (Terabyte), die vom 64-Bit-Adressraum erfasst werden, werden nicht mehr zu unseren Lebenszeiten gesprengt. Denn immerhin bedeutet es die Kapazität der Erde, würde man pro nur ein paar Tonnen Erdmasse je ein Bit speichern!.

Die schier unbegrenzten Adressräume sind schön und gut, aber die Frage lautet abermals, wozu das ganze?Brauche ich denn wirklich so viel Speicher? Was bringt mir das als TransObjects®-Anwender ganz konkret?

Nun, hier ist die Antwort sicherlich nicht monokausal. Zunächst hat sich schon mal jeder, der die CPU-Belastung eines Servers angeschaut hat, gefragt, ob er ihm denn mit höherer Taktung resp. mit weiteren Prozessoren wirklich auf die Sprünge helfen kann, wo doch die bereits vorhandenen CPU’s offensichtlich z.B. über 90% der Rechenzeit damit zubringen, auf andere langsamere Komponenten zu warten. Eine solch langsame Komponente ist schnell ausgemacht: Disk-I/O. Würde man hier weitaus mehr von häufig benötigten Daten im RAM halten können – z.B. Active Directory, Postfächer, Datenbanken, Suchindizes – sähe die Sache ganz bestimmt anders aus. Gleiche Asymmetrie ist aber auch zwischen RAM und der CPU, dem CPU-Cache und den CPU-Registern feststellbar; letztere wiederum sind leistungsfähiger, wenn sie länger sind – etc. Das alles greift ineinander und ergibt per Saldo einen Vorteil für „64″.

Anders ausgedrückt heißt das, mit der 64-Bit-Technik können vor allem die Unternehmensserver weitaus effektiver beschleunigt bzw. von der Kapazität her erweitert werden, als mit noch so vielen und noch so „hochtourigen“ Prozessoren. Stark ausgelasteten TransObjects®-Servern kann dadurch weitaus mehr geholfen werden, als etwa mit den sündhaft teuren „Mehrzylindern“ (Mehrprozessor-Rechnern, auch „Multiprocessing“-Maschinen genannt), jedoch mit nur 32-Bit-Technik.

Hingegen erschließt sich einem die Sinnhaftigkeit einer 64-Bit-Workstation für einen TransObjects®-Anwender nicht sofort, schließlich haben wir hier keine Serveraufgaben zu bewältigen und die TransObjects®-Clients konsumieren noch lange keine GBytes an Speicher.

Nun, es trifft zwar zu, dass eine auf einem 64-Bit’er isoliert ausgeführte TransObjects®-Anwendung keine weltbewegenden Performancevorteile gegenüber einer hinlänglich dimensionierten 32-Bit-Umgebung aufweist, denn diese Vorteile rühren – wie bereits ausgeführt – lediglich von dem, was mit dem Prädikat „enhanced memory“ in Intel’s „EM64T“ bezeichnet wird und das ist bei einer schwach ausgelasteten Workstation weiß Gott nicht dramatisch. Kommt jedoch der Anwender auf die Idee, eine der modernen Streaming-Software parallel zu TransObjects® mit auszuführen, sieht es natürlich ganz anders aus. Und solch hungrige Applikationen sind bereits im Anrollen – dafür hat diejenige Branche, in der auch wir tätig sind, J entsprechend gesorgt.

Trotz dieser sich klar abzeichnenden Entwicklung lautet das häufigste Verkaufsargument in denjenigen Teilen der Softwarebranche, die das Neue nicht beherrschen, gegenüber der Zeit vor 15 Jahren nahezu unverändert: „64-Bit? (früher 32-Bit?) Das brauchen Sie nicht. Unsere Logistik- und/oder Verzollungsanwendung läuft bestens auf den jetzigen Systemen…“ usw. Ja, wortwörtlich genommen stimmt es sogar: So etwas brauchen Sie als TransObjects®-Anwender wirklich nicht.

Viele haben noch die Turbulenzen des Übergangs von 16- auf 32-Bit in den frühen 90’ern gut in Erinnerung. Nun steht unweigerlich etwas Ähnliches ins Haus und zwar mit den offensichtlich unaufhaltsam aufkommenden „64-Bit“-ern. Diese Entwicklung betrifft die Hardware, die Betriebssysteme und schlussendlich auch die Anwendungs-Software.

Obwohl die K&S Informatik und deren TransObjects® weite Teile der neuen 64-Bit-Welt längst erschlossen haben, z.B. durch die Inbetriebnahme von 64-Bit Itanium-Servern im TransObjects® Message Clearing Center, häufen sich die Fragen zu diesem Thema erst jetzt so richtig, wo viele Anwender eine Migration auf die neuen Plattformen ganz konkret für sich erwägen und sich z.B. mit der Frage Itanium oder EM64 konfrontiert sehen. Diese aber auch andere Fragen zu diesem Thema, was die neue Welt mit sich bringt, was zu beachten ist und was das für uns als TransObjects®-Anwender bedeutet, versuchen wir vorliegend zu klären

Was ist der Sinn und Zweck eines verteilten Datenbanksystems?

Auf zahlreichen FAQ’s und auch an anderen Stelen unserer Website wird die extrem ausgeprägte Client/Server-Topologie von transObjects® als eines dessen wichtigsten technischen Merkmale neben der durchgehenden Objektausrichtung charakterisiert. So werden beispielsweise in unseren FAQ-Artikeln „transObjects® vs. WinXY…“ bzw. „…Citrix- WinTerm-Software…“ gravierende Konsequenzen des Wegbleibens einer Client/Server-Topologie (bzw. gar der aktiven Datenbankinstanz überhaupt) diskutiert und mit Beispielen aus praktischer Erfahrung untermauert. Die Zielsetzung dieses Artikels kann daher nicht darin bestehen, die Sinnhaftigkeit der Client/Server-Topologie vor dem Hintergrund beispielsweise einer Terminal-Topologie zu beleuchten. Vielmehr beschäftigen wir uns nachfolgend mit einer Art Enhancement oder Verallgemeinerung der Client/Server-Topologie und zwar mit den sog. verteilten Datenbanksystemen.

Bei der Beschreibung der Systemvoraussetzungen fürs transObjects® fällt bereits der Begriff des verteilten Datenbanksystems (DDS, distributed database system) und zwar im Zusammenhang mit der aktiven Datenbankinstanz, als eine alternative Systemvoraussetzung hierzu. Und das ist es auch in der Tat, d.h. eine einzelne Datenbankinstanz (also ein Datenbankserver) ist ein Spezialfall eines verteilten Datenbanksystems, gewissermassen ein verkrüppeltes DDS. Die Frage, die in diesem Zusammenhang sofort gestellt wird – sozusagen die FAQ schlechthin – lautet, ob denn die ganze Philosophie des DDS in der Nutzung mehrerer Datenbankinstanzen bestehe? Ist beispielsweise der Datenaustausch mit den Datenbanken des transObjects®-Datacenters und parallel dazu das Arbeiten mit dem unternehmenseigenen Datenbankserver (beispielsweise bei der Anwendung von Corporate-Editions der elektronischen Verzollungsanwendungen) bereits als Anwendung eines verteilten Datenbanksystems zu bezeichnen?

Dazu ein klares „Ja“. Denn eine abwechselnde Nutzung mehrerer Datenbankserver durch einen Client, der Daten aus geographisch weit verstreuten Datenbanken benötigt und diesen unterschiedliche Daten zukommen lässt, fällt in der Tat in die Kategorie der Nutzung eines verteilten Datenbanksystems. Das tut jedoch dem High-End-Anspruch eines DDS keinen Abbruch – denken wir doch an das DDS, das bereits mit nur einem einzelnen Datenbankserver losgeht. Aber um auf die obige Frage zurückzukommen, ja, das Wesen eines DDS besteht im Prinzip in einer Vereinigung von mehreren Datenbankinstanzen, wobei erst deren Zusammenwirken untereinander ein modernes DDS ausmacht..

An dieser Stelle sei vorweg genommen, dass ein DDS per se nichts mit dem Clustering zu tun hat – auch nicht mit einem Hauptknotencluster unter Windows 2003 Enterprise- oder Datacenter-Edition. Denn das Wesen des Clusterings – zumindest unter den gängigen Betriebssystemen – besteht ja darin, einzelne Clusternodes abwechselnd für bestimmte Datenbankinstanzen und Datenpools zu aktivieren. Das Failover-Prinzip des Clusterings bedeutet die potentielle Bereitschaft eines Clusternodes zur Aufrechterhaltung einer Datenbankinstanz mit einem zugeordneten Datenpool, wenn andere Nodes diese Bereitschaft – aus welchen gründen auch immer – nicht aufrechterhalten können.

Um ein klassisches DDS zu charakterisieren, entwerfen wir ein Szenario, in dem die Client/ Server-Topologie mit nur einer Datenbankinstanz an ihre Grenzen stossen könnte, wobei gleich vorweggenommen sei, dass dies kein Fall ist, wo andere Topologien die bessere Wahl wären; ganz im Gegenteil. Mit einer Terminal-Topologie (zu denen gewissermassen auch eine Browser-Anwendung zählt) könnten wir nachfolgend gleich einpacken.

Seien A und E Standorte eines Unternehmens entsprechend in Afrika und in Europa. Das Unternehmen wendet diverse Special-Builds von transObjects®-Applikationen für den operativen Bereich sowie processPRO für den administrativen Bereich an, wo es um vielfältige Auswertungen dieser Daten geht. Natürlich bietet sich eine via Internet erreichbare zentrale Datenbankinstanz hierfür bestens an, z.B. am Standort E, so dass am Standort A mit den Clients über eine WAN-technische Anbindung (Internet) auf diese Instanz zugegriffen werden kann. Dies ist grundsätzlich kein sehr grosses Problem, wo doch transObjects® für eine Minimierung des Client/Server-Datenflusses bekannt ist. Dann können wir ruhigen Gewissens voraussetzen, dass die Bandbreite der WAN-Anbindung an die zentrale Datenbankinstanz signifikant geringer ist, als die LAN-technische Anbindung am Standort E.

Wo ist also das Problem bzw. der Sinn und Zweck eines DDS? Nun, die geringere Bandbreite der WAN-Anbindung an die Datenbankinstanz kann nicht mehr umgangen werden, wenn der Datenfluss notwendigerweise sehr hoch ist. Das könnte beispielsweise dann der Fall sein, wenn am Standort A Daten an sehr vielen und stark frequentierten Clients nach E geschickt werden – oder denken wir an das Beispiel des philippinischen Energieversorgers Real-World Benchmark: Caché vs. Oracle…, wo anderweitig erfasste Daten mit einem hohen Stream in den zentralen Server (in unserem Beispiel wäre es der Standort E) „gepumpt“ werden müssen. Hier reicht langsame Leitung schlicht nicht mehr aus, egal, wie schnell die Internetverbindungen künftig werden sollten.

Was also tun? Auch am Standort E werden vielen Daten im operativen Bereich erfasst und ebenso wir am Standort A transObjects® processPRO angewendet, um Auswertungen, Controlling-Aufgaben etc. wahrzunehmen. Somit ist es damit nicht getan, den Datenbankserver von E nach A zu verlegen. Was man aber machen kann, ist auch am Standort A eine Datenbankinstanz zu etablieren. Das Bandbreitenproblem ist damit zwar behoben, nicht jedoch das der Datenintegrität, das so sauber durch eine zentrale Datenbankinstanz gelöst werden konnte. Hier hilft nur eines, nämlich ein gezielt implementierter Datenabgleich von den beiden Datenbankinstanzen untereinender und zwar über die bestehende WAN-technische Verbindung.

Was erreichen wir dadurch? Nun kann an beiden Standorten mit der hohen Bandbreite einer LAN-technischen Verbindung gearbeitet werden, es können datenintensive Streams gespeichert und umfangreiche Abfragen problemlos durchgeführt werden – dem verteilten Datenbanksystem aus den beiden Instanzen an beiden Standorten sei Dank.

Natürlich stösst ein solches DDS durchaus an seine Grenzen. Haben wir beispielsweise nicht nur 2 sondern 20 Standorte, so wäre der Aufwand des Datenabgleichs und der Bandbreitenverbrauch hierfür enorm. Oder denken wir an das zuvor zitierte Beispiel des Energieversorgers, der nachts erst einmal gute zwei Stunden lang Daten in den (lokalen) Oracle-Datenbankserver eingelesen hat. Solche Datenmengen über eine Internetleitung abzugleichen, würde viel zu lange dauern. Und wäre ein solcher Abgleich endlich einmal durch, wären die Daten womöglich längst obsolet. Deshalb sprechen wir vom gezielten Abgleich*. In unserem Beispiel wären nur bestimmte Daten oder auch Zwischenresultate der Queries etc. abzugleichen.

________________________________________

* Um ein verteiltes Datenbanksystem mit Hilfe der transObjects®-Technologie aufzubauen, werden Enterprise bzw. Special-Build-Editions der transObjects®-Clients benötigt, ferner sind Caché-Server für alle DDS-Standorte erforderlich. Einen gezielten Datenabgleich übernehmen entweder die jeweiligen Caché-Server selbst oder proprietäre transObjects®-Services.

ItaniumDDS

DDS-Schema mit zwei Standorten – im Beispiel: Hewlett Packard 64-Bit (Itanium) Integrity – Reihe, mit Superdome-Servern in den RX2600’er Workstations.

Warum denn TransObjects® und nicht etwas anderes?

Diese Frage stellen sich viele IT-Verantwortliche bzw. Entscheidungsträger, die bei anstehenden Neuanschaffungen im Bereich IT die Qual der Wahl haben. Der nachfolgende Leitfaden möge Ihnen die Entscheidung ein wenig erleichtern; jedenfalls ist TransObjects® insbesondere dann die richtige Wahl, wenn Sie an dem abzulösenden oder dem potentiell anzuschaffenden System einiges aus dem Folgenden zu konstatieren bzw. Anlass zu einigen der folgenden Fragestellungen haben.


*) Sie fragen sich (und den Anbieter Ihrer Branchenlösung auch), warum denn Ihre Branchensoftware immer noch im Textmodus mittels archaisch anmutender Terminal-Emulatoren(!) betrieben werden sollte – und das in der Ära von Multimedia und 3D-Grafiken, die Ihr System längst unterstützt!? Es kann sich hierbei um ein älteres System basierend auf DOS, UNIX, XENIX, MUMPS, AS400 – um nur diese zu nennen – handeln;

*) Ihre Branchenlösung hat den typischen Windows®-Look, dieser wird aber nur auf indirektem Wege erzielt, nämlich mittels ominöser Interpreter, die zumeist in sog. Desktop-Datenbanken als Entwicklungsumgebungen vorhanden sind. Zu recht befürchten Sie Einbussen bei der Performance, Stabilität und sehen die Kontinuität dieser Lösung nicht als gesichert an;

*) Ihre Branchenlösung beruht sogar auf nativen Windows®-Clients (d.h. ohne die o.e. Interpreter), beherbergt aber immer noch Anachronismen aus einer Zeit, der sie ursprünglich entstammt. Sie befürchten zu recht Konzessionen zugunsten des alten DOS, Mumps, R2 oder welchen alten Systems auch immer und vermissen die Zukunftssicherheit einer strikt objektorientierten Entwicklung, insbesondere der objektorientierten Hierarchie;

*) Ihre Branchenlösung ist objektorientiert implementiert und bedient sich sogar aktiver Datenbankinstanzen. Prima! Allerdings sind diese Datenbankserver leider allesamt SQL-orientiert, d.h. tabellarisch. Sie fragen sich (und den Hersteller ebenfalls), wie denn das zusammenpassen würde. Sie misstrauen dem Paradigmenwechsel an der „Client/Server“-Schnittstelle und befürchten, dass dadurch die eigentlichen Vorteile der oo-Technologie zunichte gemacht werden könnten;

*) Sie planen den Aufbau eines internationalen oder gar interkontinentalen Verbundes, mit logisch gesehen einem aber sehr wohl verteilten Datenpool – befürchten aber Engpässe auf der Datenautobahn. Sie möchten ferner Ihre Daten teilweise im Web publizieren, etwa ein Auskunftssystem über den Bearbeitungsstand von bestimmten Aufträgen im Internet anbieten (Tracking & Tracing bei den Forwarders);

Sie befürchten, nicht alle Kompromisse den anderen überlassen zu können, sondern dass Ihnen sehr wohl einige davon „erhalten“ bleiben könnten.

Kann ich transObjects? mit einem anderen Datenbankserver als Caché betreiben?

Dieser Artikel ist outdated. Siehe die aktuellere Version u.a. „Kann ich transObjects® unter Linux bzw. unter Oracle, MSSQL etc. betreiben?

Diese Frage wird uns meistens von Anwendern ziemlich teurer Datenbanken gestellt, die nur schwer einzusehen vermögen, dass sie u.U. horrende Lizenzgebühren für etwas investiert haben, dass in der oo-Welt völlig unzulänglich ist


Die klare Antwort lautet „Nein“ !

TransObjects® setzt eine objektorientierte (und aktive) Datenbankinstanz voraus. Somit scheiden zunächst einmal alle Datenbankserver, die das Kürzel „SQL“ im Namen tragen, ebenso aus, wie z.B. Oracle, das ebenfalls eine SQL-Datenbank ist. Aber auch objektorientierte Datenbankserver, sofern es diese überhaupt gibt, etwa:

werden spätestens seit der dritten Generation von TransObjects® nicht mehr unterstützt. Der Grund ist im proprietären Charakter der jeweiligen internen Datenmodelle, Klassenarchitekten, Programmiersprachen etc. zu suchen.

Siehe auch:

Fallstudie: Systemverfügbarkeit und Ausfallsicherheit

Die nachfolgende Fallstudie zur Systemverfügbarkeit und Ausfallsicherheit betrifft ein mittelständisches Dienstleistungs- und Logistikunternehmen in der Schweiz. Die dortigen IT-Verantwortlichen überlegten zum Zeitpunkt der Studie einen Windows-Cluster anzuschaffen, da die Kosten der Nicht-Verfügbarkeit von zentralen Serverdiensten relativ hoch waren, während auf der anderen Seite die Verfügbarkeit des transObjects®-Servers dank der Failover-Vorrichtung deutlich spürbar in ganz anderen Bereichen angesiedelt war.

Die K&S Informatik GmbH wurde beauftragt, eine Kosten/Nutzen-Rechnung im Hinblick auf die eventuell anzuschaffende Cluster-Vorrichtung zu erstellen und diese vor den Hintergrund der empirischen Erfahrungen mit der transObjects® Failover-Vorrichtung zu stellen. Dies war nur mit einem stochastischen Ansatz zu machen, den wir nachfolgend präsentieren.

1. Stochastische ➡ Natur der Systemverfügbarkeit

______________
➡ Stochastik [griech.], Bezeichnung für mathematische Verfahren zur Untersuchung zufallsabhängiger Ereignisse, sei es aufgrund von der Natur des zu untersuchenden Systems, sei es aufgrund von statistischen Erkenntnissen (z. B. von Stichproben).

.
Im Zusammenhang mit der Verfügbarkeit eines Systems bzw. dessen zentraler Komponente (im Folgenden „Backbone“) wird meistens mit einer dimensionslosen Zahl operiert. Doch was bedeutet beispielsweise eine Systemverfügbarkeit von 0.99 (99%)?

Betrachten wir zunächst ein Backbone an einem Serverstandort und lassen dies im Wesentlichen aus genau einem Server bestehen. Vereinfachen wir ferner unsere Überlegungen, indem wir einen planmäßigen Ausfall des Backbones (etwa aufgrund von Wartungsarbeiten) völlig außer Betracht lassen. Unter einem „Totalausfall“ verstehen wir ein Versagen des Backbones, was die Inanspruchnahme von Serverdiensten in einem bestimmten Zeitintervall gänzlich unumgänglich macht. Im Folgenden betrachten wir nur die Totalausfälle. Dies bedeutet keine wesentliche Einschränkung der Allgemeinheit, da wir jeden Teilausfall auf einen Totalausfall mit entsprechend geminderten Folgen zurückführen können.

Falls uns Erfahrungswerte eines hinreichend langen Betriebszeitintervalls vorliegen, sind wir schnell geneigt, eine hieraus abgeleitete Aussage über die Verfügbarkeit eines Systems bzw. dessen Backbones zu formulieren. Man braucht nur noch die Ausfallzeiten der empirisch festgehaltenen (Total-) Ausfälle aufzuaddieren und diese ins Verhältnis zu der gesamten Laufzeit zu setzen. Für mathematische Puristen, die wir vorliegend ebenfalls zufrieden stellen wollen, hieße es:

Diese Zahl ist genau genommen die Nicht-Verfügbarkeit. Die Verfügbarkeit selbst wäre dann das 1-η.

Dabei können die Ursachen für jedes Ausfallereignis ω von sehr unterschiedlicher Natur sein – vom „klassischen“ Hardwareversagen über ein Software- bzw. Konfigurationsfehler oder gar ein organisatorisches Problem, bis hin zu einem destruktiven Eingriff und höherer Gewalt. Und genau an diese sozusagen naturgemäße Komplexität der Wechselwirkung rund um die Verfügbarkeit eines hoch technisierten Systems verdeutlicht deren eigentliche stochastische Natur; dazu später mehr.

Wir sehen an dieser Stelle überaus deutlich, dass diese Wechselwirkung all der Systemparameter von der empirisch ermittelten Verfügbarkeit allenfalls nur sehr indirekt erfasst wird. Sie besagt nichts über die tatsächlich lauernden Gefahren, sei es aufgrund des informationstechnischen Grundkonstruktes, sei es aufgrund von organisatorischen Belangen rund um das betr. System und sie trifft eine reine a posteriori Aussage. Folglich benötigen wir ein anderes Werkzeug, um die eigentliche Frage der vorliegenden Studie zu beantworten, nämlich die, wie sich ein Servercluster auf die Verfügbarkeit unseres Systems auswirken würde.

2. Stochastisches Zeit-Diskontinuum

Betrachten wir ein Ereignis ω, das zum Totalausfall unseres Backbones führt. Sei dieses Ereignis beispielsweise ein Ausfall eines RAM-Chips im Server. Setzen wir voraus, dass ein solcher Ausfall zum Anhalten des Servers führt, obwohl nicht unwahrscheinlich ist, dass das interne Hardwaremanagement einen solchen Ausfall erkennen und mittels „Isolierung“ umgehen könnte.

Wir wissen, dass Silizium-Komponenten heutzutage mit mehreren Megahertz takten und mit jedem „Takt“, was ja einen Schaltvorgang im Inneren des Chips bedeutet, immer wieder aufs Neue Gefahr laufen, Schaden zu nehmen. Wir spüren irgendwie, dass diese aufeinander folgenden Schaltvorgänge die eigentlich kritischen Momente für unseren RAM-Chip sind. Daher sehen wir die Zeiträume zwischen den einzelnen Takten als irrelevant an, da sie keine Gefahr für eine Silizium-Komponente darstellen. Wir untersuchen demnach die Lebensdauer des RAM-Chips nicht in einem klassischen Zeitkontinuum, sondern vielmehr in einem (zeitlichen) Diskontinuum.

Sei ε die Wahrscheinlichkeit für einen Ausfall des RAM-Chips bei einem beliebigen Schaltvorgang (Takt). Diese Wahrscheinlichkeit – normalerweise eine verschwindend geringe Zahl – ist wohl im Wesentlichen von der Materialbeschaffenheit und der Betriebsumgebung abhängig. Wir lassen eine zeitliche Veränderung dieser Parameter (etwa infolge von Alterungsprozessen) außer Betracht. Ähnlich wie im russischen Roulett bedeutet jeder Takt ein neues „Abdrücken“, mit der Gefahr ε, dass ein scharfer Schuss losgeht. Die Wahrscheinlichkeit, dass dies in den ersten n Versuchen erfolgt, ist eine exklusive Alternative von einzelnen Ereignissen, was für unsere mathematischen Puristen folgendermaßen aussieht:

Es entspricht durchaus der Lebenserfahrung, dass es im Laufe der Zeit immer wahrscheinlicher wird, den Ausfall unseres Chips zu erleben. Mit anderen Worten, irgendwann einmal geht ein scharfer Schuss los, wenn man das russische Roulett oft genug bemüht: die obige Wahrscheinlichkeit geht gegen 1 bei wachsendem n.

Sicherlich können wir in unserem zeitlichen Diskontinuum von der Taktung abstrahieren und unsere obigen Überlegungen auf die Betriebszeit einer Komponente verallgemeinern. Seien:

die Ausfallwahrscheinlichkeit aufgrund vom Ereignis ω im Zeitraum T (1 Jahr);
die durchschnittliche Dauer des Ausfalls aufgrund vom Ereignis ω;

Wären uns diese Größen für alle Ausfallereignisse bekannt, so würden wir sofort den stochastischen Erwartungswert der jährlichen Ausfallzeit bilden und diesen ins Verhältnis zu der jährlichen Betriebsdauer setzen können. Damit hätten wir die stochastische Nicht-Verfügbarkeit unseres Systems:

Natürlich ist es ein absolut aussichtsloses Unterfangen, all die verfügbarkeitsrelevanten Ereignisse zu erfassen und entsprechend obiger Formel zu quantifizieren. Aber immerhin leiten wir daraus eine längst verinnerlichte Weisheit, nämlich die, dass wir die Verfügbarkeit unseres Backbones dadurch erhöhen können, indem wir einfach die jeweiligen Summanden möglichst verkleinern – oder anders ausgedrückt, indem wir die jeweiligen Ereignisse unwahrscheinlicher machen und/oder deren Folgen (Ausfallzeiten) minimieren. Das führt zu einer Reihe von bekannten Maßnahmen, die bis ins Organisatorische hinein reichen würden, weshalb auf deren Auflistung hier verzichtet werden soll. Aus unserer Formel folgern wir, dass wir damit ohnehin ein eher mäßiges Resultat erzielen würden. Im kommenden Kapitel versuchen wir einen Ansatz, der uns signifikant weiterbringt.

3. Verfügbarkeit eines Backbones

Die Aussichtslosigkeit der exakten Erfassung aller Ausfallereignisse zwingt uns dazu, eine Systemverfügbarkeit aufgrund von Erfahrungswerten mit ähnlichen Systemen bzw. aufgrund von Normungen, anzunehmen. Dies ist keineswegs der Rückfall in die empirische Verfügbarkeit aus dem Kapitel 1. Im Gegenteil. Der statistische Ansatz ist ein probates und anerkanntes Mittel der Stochastik.

Betrachten wir einen realen Fall des eingangs erwähnten mittelständischen Unternehmens aus Zürich. Für systemkritische Dienste (etwa MS Exchange, MS IIS etc.) wurde zunächst eine neue Hardware ohne Cluster angeschafft und in Betrieb genommen. Im Zeitraum unmittelbar danach konnte zunächst ein überaus erfreulicher 3000-stündiger Betrieb des Servers ohne einen außerplanmäßigen Unterbruch verzeichnet werden. Auch der daraufhin erfolgte ca. 30-minütige Ausfall aufgrund des Deadlocks tangierte nur ganz wenig die insgesamt sehr hohe empirische Verfügbarkeit.

Allerdings, bei näherem Hinsehen war da noch zwischendurch ein durch höhere Gewalt verursachter Ausfall der Internetverbindung, was zu einem gewissen Prozentsatz als Ausfallzeit zu zählen war, und die eine oder andere Kleinigkeit auch noch – und sei dies nur eine vorübergehende Software-Fehlfunktion. Ferner ist nicht zu vergessen, dass im Laufe der Zeit mit fortschreitenden Alterungsprozessen zu rechnen ist und dass einige Ereignisse, obwohl diese im vorliegenden Falle nicht eingetreten waren, immer noch mit einer gewissen Wahrscheinlichkeit über allen wie das sprichwörtliche Damoklesschwert schwebten. Daher war man im vorliegenden Falle, bei einer groben Orientierung an den Industrienormen bzw. sonstigen Erfahrungswerten, mit einer Nicht-Verfügbarkeit von:

recht gut bedient. Das klang zunächst einmal nicht so schlecht, bedeutete aber einen stochastischen Erwartungswert von immerhin knapp einem ganzen Kalendertag Ausfallzeit pro Jahr:

Ein totaler und nicht planmäßiger Ausfall eines systemkritischen Backbones ist sicherlich stets mit mehr oder minder gravierenden Kosten verbunden. Diese Kosten wurden vorliegend mit 500,- CHF pro Stunde angesetzt, was zu einem stochastischen Erwartungswert der jährlichen Verluste bedingt durch Ausfälle des betreffenden Servers von knapp 11’000 CHF pro Jahr geführt hätte.

Vor dem Hintergrund obiger Zahlen wurde die K&S GmbH beauftragt, die entsprechenden Erwartungswerte erstens für den transObjects®-Server zu ermitteln, der ja zum Zeitpunkt der Studie bereits unter Shadow-Failover lief (hierzu später mehr) und zweitens zu errechnen, inwieweit eine Failover-Vorrichtung die stochastische Verfügbarkeit des betreffenden Servers verändern würde.

4. Grundzüge des Clusterprinzips

Die Grundidee des Failover, d.h. der Steigerung von Serververfügbarkeit mittels einer wie auch immer gearteten Serverredundanz, ist denkbar einfach. Will man beispielsweise eine simple Serverfreigabe ?ber den Ausfall des Servers hinaus verf?gbar machen, so sorgt man wohl dafür, dass diese Freigabe notfalls von einem anderen Server „serviert“ werden kann, wenn denn der Hauptserver hierzu vorübergehend nicht in der Lage sein sollte.

Technisch gesehen würde man dies wohl so zu bewerkstelligen suchen, indem man eine Art „Shared Drive“ gleichzeitig mit zwei oder mehr Servern (sog. Cluster-Nodes) verbinden würde. Dabei würde man beide Nodes ans gleiche LAN bringen, jedoch nur einen der beiden zu dem „primären“ erklären, der seine Serveraufgaben (z.B. simple Freigaben) wahrzunehmen hätte. Sollte dieser aus irgendwelchen Gründen ausfallen, so würde man den zweiten der beiden vorübergehend zu dem primären erklären und ihn aufgrund seiner Verbindung zu dem Shared-Drive, wo sich die betreffenden Freigaben befinden, aktivieren.

Es stellt sich nur noch die Frage, inwieweit sich so etwas irgendwie automatisch machen ließe, d.h. ob es nicht irgendwie möglich wäre, dieses „Failover“ einem speziellen Dienst zu überlassen, der den Ausfall des primären Nodes selber erkennt, den sekundären Node entsprechend aktiviert und den Clients den Zugriff unter unveränderten Eckdaten gewährt. Bei Microsoft ist dieser Dienst der sog. Clusterdienst. Die Clustertopologie sieht, anhand des vorliegend relevanten Exchange-Clusters, folgendermaßen aus:

Cluster1Cluster2

5. Serververfügbarkeit unter einem Servercluster

Bevor wir uns an das Thema Verfügbarkeit eines Clusters heranwagen, machen wir den folgenden Ansatz:

Es ist klar, dass die hier angesetzten Zahlen existieren (Zwischenwertsatz) und dass es sogar unendlich viele Zahlenpaare gibt, die der obigen Gleichung genügen. Doch wie sind denn pT und t zu interpretieren?

Rufen wir noch einmal kurz das russische Roulett aus dem Kapitel 3 in Erinnerung. Dort ging es um einen einzelnen RAM-Chip. Doch k?nnen wir nicht eine ähnliche Natur dem gesamten Backbone unterstellen? Beide Zahlen sind dann eine Art Durchschnittsgrößen, die zum gleichen Resultat führen. Das einzige Ausfallereignis lautet dann „Ausfall des Backbones“ bzw. des Clusternodes.

Setzen wir eine Gleichwertigkeit der beiden Clusternodes voraus, so ist die Ausfallwahrscheinlichkeit des Clusters aus der mathematischen Konjunktion der Ereignisse „Ausfall des Nodes 1“ und „Ausfall des Nodes 2 bevor Node 1 wiederhergestellt werden konnte“:

Das hat für die Nicht-Verfügbarkeit eine fast sensationelle Konsequenz:

Es spielt demnach eine untergeordnete Rolle, wie wir unsere Durchschnittswerte ansetzen, denn in jedem Falle ziehen wir sehr kleine Zahlen ins Quadrat, was eine dramatische Schrumpfung der Nicht-Verfügbarkeit nach sich ziehen würde. Versuchen wir es bloß mit unserer zuvor genannten Zahl, so ergäbe sich daraus anstatt 0.25% gerade mal 0.000625% und anstatt knapp 11’000,- CHF gerade mal knapp 30,- CHF!

Sicherlich haben wir hier ein idealisiertes Bild des Failover-Clusters gezeichnet. Denn zum einen sind nicht alle Dienste Cluster-fähig und zum anderen sind beide Nodes nicht desimilar redundant (bedeutet soviel, wie nach unterschiedlichen technischen Prinzipien ausgelegt). Dennoch konnte eine Ersparnis von mehreren Tausend Stutz pro Jahr konnte guten Gewissens angenommen werden. Und was noch viel wichtiger war: ein ähnlicher Kosteneffekt konnte dem hochverfügbaren transObjects®-Server bescheinigt werden und das bereits ohne einen kostspieligen Servercluster!

Was sind Petri-Netze von welcher Bedeutung sind sie fürs transObjects®?

Dieser Artikel ist outdated.

Kapitel 1:

Die stark proprietäre und daher generell nur in der Special-Build-Edition erhältliche transObjects®-Anwendung processPRO widmet sich der Analyse, Auswertung, Kontrolle und Optimierung innerbetrieblicher Vorgänge im Kontext der Dislokation und Umwandlung von Ressourcen und das über den klassischen Kern des Enterprise Resource Planing hinaus. Eine solche Verallgemeinerung einer ERP-Lösung gehört zu den schwierigsten Aufgabenbereichen, die von der Anwendungssoftware überhaupt zu bewältigen sind. Die Anlehnung an ein probates systemanalytisches Mittel in der Gestalt von Petri-Netzen war seinerzeit eine der wichtigsten Weichenstellungen für das heutige transObjects® processPRO. Der nachfolgende Artikel soll die grundlegenden Konzepte rund um Petri-Netze vor dem Hintergrund deren wissenschaftlicher Erforschung vorstellen und gleichzeitig ansatzweise eine Überleitung zu den im transObjects® processPRO angewandten Gebilden geben.

Stellen wir uns vor, wir beobachten in einer Montagehalle für Verbrennungsmotoren den folgenden Sachverhalt: An einer der dort zahlreich vorhandenen Montagestellen werden Zylinderblöcke aus je zwei gleichen Hälften zusammen geschraubt, wofür jeweils 6 Schrauben benötigt werden. Stünden wir vor der Aufgabe, diesen Vorgang im Kontext der involvierten Ressourcen – d.h. des Verbrauchs der beiden Zylinderblockhälften und der Schrauben sowie des Ausstoßes des zusammen geschraubten Zylinderblocks – grafisch darzustellen, so würden wir wohl in etwa so etwas zeichnen, wie die nachfolgende Abb. 1 a) zeigt.

Bildhaft gesprochen, fließen die Ressourcen aus den Input-Stellen – etwa aus Vorratsbehältern – in die Montage hinein und werden auf der Outputseite als Bestandteil einer anderen Ressource, hier des Zylinderblocks, ausgestoßen. Klar, diese Ressource könnte wiederum eine Input-Ressource für einen weiteren Prozess sein, etwa da, wo man diese mit Kolben, Kurbelwellen etc. bestückt.

Würden wir darüber hinaus der Tatsache Rechnung tragen wollen, dass unsere Montage nur mit Hilfe eines speziellen Schraubenschlüssels erfolgen kann, der alle Schrauben gleichzeitig hineindreht, würden wir unsere Zeichnung wohl um eine weitere Ressource ergänzen, deren Vorhandensein zwar für die Montage selbst unerlässlich ist, also zwingend gebraucht, jedoch infolge dieser nicht verbraucht wird. Unsere Abb. 1 a) bekäme somit eine Modifikation, wie auf der obigen Abb. 1 b) zu sehen ist. Auch hier fließt die betreffende Ressource in die Montage hinein, wird aber anschließend nicht auf der

Outputseite mit ausgestossen, sondern vielmehr an die ursprüngliche Input-Stelle in völlig unveränderter Form zurückgeschickt. Diese Ressource ist wieder uneingeschränkt für den betreffenden Prozess bzw. auch für andere, die sie evtl. benötigen könnten, verfügbar – lässt man etwa Verschleissprozesse etc. ausser Betracht.

Wenn wir das alles so gemacht haben, würden wir nicht schlecht staunen, wenn man uns erzählte, wir hätten nichts Geringeres entworfen, als ein sog. Petri-Netz für den hier betrachteten Vorgang! In der Tat, Petri-Netze sind ein Mittel bei einer – nennen wir es – ressourcenabhängigen Prozessanalyse, das nicht nur sehr anschaulich, sondern auch absolut nahe liegend ist; der Urheber und Namensgeber Carl Adam Petri möge uns diesen Einwurf nachsehen.

Betrachten wir nachfolgend noch einige Petri-Netze aus [RAS], so könnten wir versuchen, diese graphentechnisch zu erfassen, denn Graphen sind diese Gebilde allemal, offensichtlich mit gerichteten und beschrifteten Kanten sowie zweierlei Knoten. Während die einen für so etwas wie die Orte für bestimmte Ressourcen (Schrauben, Zylinderblockhälften etc.) stehen, tun es die anderen für die Prozesse selbst, die eine Verarbeitung dieser Ressourcen (deren Gebrauch, Verbrauch, Ausstoß etc.) darstellen. So nennt man auch die ersten der beiden (die runden Knoten) einfach „Stellen“, während die dunkelgrünen Balken mit dem Originalbegriff aus dem Englischen bedacht sind: wir nennen sie „Transitionen“.

Der graphentechnischen Erfassung entzogen sich bislang die schwarzen Punkte, die in den Stellen placiert sind (Abb. 2). Die Belegung der Stellen mit den sog. Token ist jedoch für die Struktur des Petri-Netzes irrelevant. Allenfalls wird dadurch der Zustand des Petri-Netzes zu einem x-beliebigen Zeitpunkt dargestellt, genauer gesagt, die Quantitäten einzelner Ressourcen zu diesem Zeitpunkt. Wie sich diese infolge der Montage ändert, schildern die beiden „vorher/nachher“-Zustände aus Abb. 2 a/b) – dazu später mehr.

An dieser Stelle – weil es sich so aufdrängt – wollen wir einen scheinbaren Widerspruch auflösen, in dem der Name processPRO zu dem FAQ-Artikel http://www.ks-informatik.de/faq.php?id=13 steht, aber wie gesagt nur scheinbar. Bei der Erklärung des Wesens von objektorientierter Sicht der Dinge wird nämlich vom Ansetzen an den Prozessen selbst abgeraten und zwar zugunsten von den weitaus weniger volatilen Rahmenbedingungen, unter denen diese ablaufen. Auf der anderen Seite hat aber processPRO eben diese Prozesse zum Gegenstand. Was gilt also nun?

Schöner könnte die praktische Anlehnung an die objektorientierte Sicht der Dinge nicht demonstriert werden, als eben anhand von Petri-Netzen. Die Analyse der Abläufe im processPRO ist in der Tat an Graphen angelehnt, in denen ja die Stellen für Objektklassen, die Token für die Objekte selbst und Transitionen für Klassenmethoden stehen! Diese Analyse ist also strikt objektorientiert und gilt eben den wenig volatilen Klassenstrukturen, d.h. den Rahmenbedingungen, unter denen die Prozesse ablaufen.

Aber nun zurück zu unseren schwarzen Token. Der Begriff des Zustandes eines Petri-Netzes zu einem x-beliebigen Zeitpunkt hat sich uns bereits vorher aufgedrängt. In der Tat wird eine momentane Verteilung der Token (also der Ressourcen in einem zu analysierenden System) mit dem Zustand des gegebenen Petri-Netzes identifiziert und auch so bezeichnet. Wie die Abb. 2 darlegt, kann sich dieser Zustand ändern, indem ein Prozess stattfindet, der die Ressourcen in einer vordefinierten Form umwandelt – hier werden Schrauben und Zylinderblockhälften verbraucht und ein vorgefertigter Zylinderblock hervorgebracht. Diesen Prozess bezeichnen wir in der PN-Terminologie als die „Zustandsüberführung“, die infolge vom „Feuern einer Transition“ stattfindet.

Nach dem ersten Touch mit den Petri-Netzen ist man vielleicht ein wenig geneigt, eine Parallelität zu elektrischen Schaltkreisen zu sehen, was jedoch gänzlich unangebracht ist. Denn während im elektrischen Schaltkreis ein Schaltvorgang, z.B. das Schliessen eines Relais, zwingend erfolgen muss, sobald eine bestimmte Spannung anliegt, haben wir im Falle von Petri-Netzen diesen Determinismus nicht. Vielmehr fragen wir danach, was in einem Petri-Netz alles passieren kann. Insofern galt die Aufmerksamkeit der Wissenschaftler seit jeher den sog. Erreichbarkeitsmengen und auch das transObjects® processPRO stellt auf diese Fragestellungen ab, wie wir nachfolgend sehen werden.

Für die Bedürfnisse des vorliegenden Artikels reicht das intuitive Verständnis von Petri-Netzen, gestützt auf die oben angeführten Beispiele, gerade mal aus. Dennoch seien nicht nur mathematische Puristen auf den FAQ-Artikel http://www.ks-informatik.de/faq.php?id=32 verwiesen, der die von Petri-Netzen aufgeworfenen Fragestellungen vor dem Hintergrund deren wissenschaftlicher Erforschung etwas formeller fasst und so das Verständnis der Funktionsweise von transObjects® processPRO vertieft. Für die nun überfällige graphentheoretische bzw. algebraische Formalisierung der Petri-Netze möge der interessierte Leser die reichlich zitierte Fachliteratur zu Rate ziehen. Vorliegend, wohl wissend um die abschreckende Wirkung einer mathematischen Formel J, wollen wir es mit folgender Beschreibung versuchen: Wir identifizieren Petri-Netze als einen Graphen bestehend aus Stellen und Transitionen sowie einer Kantenabbildung von Stellen zu Transitionen und umgekehrt, mit jeweils ganzzahliger Beschriftung (auch Kantenvielfachheit genannt). Kanten mit der Vielfachheit gleich Null werden als nicht existent angesehen.

Apropos „was alles passieren kann“. Natürlich gilt unser Interesse denjenigen Zuständen, die irgendwie problematisch sind. Es kann sich z.B. um einen Deadlock handeln, d.h. einen mangels Ressourcen verursachten Systemstillstand, oder um einen Blowup, d.h. um eine unkontrollierte Zunahme von Ressourcen innerhalb eines Systems – um vorerst nur diese beiden zu nennen. Welchen volkswirtschaftlichen Wert es beispielsweise hätte beantworten zu können, ob es in einem AKW zu einer unkontrollierten Zunahme an Neutronen kommen kann oder nicht, braucht man wohl nicht zu erläutern. Auf der anderen Seite wissen wir, dass solche Systeme viel zu komplex sind, als dass wir in absehbarer Zukunft adäquate Petri-Netze hierfür zu erwarten hätten.

Die processPRO-Analysen gelten jedoch weitaus weniger komplexen Systemen und auch nur einigen relevanten Klassen, Ressourcen und Methoden. Dennoch leisten diese Analysen eine wertvolle Hilfestellung bei der Optimierung von betriebswirtschaftlich relevanten Prozessen, sie sind unerlässlich für ein modernes und erfolgreiches Management. Denn es wäre schlicht unverantwortlich, mögliche Deadlocks, Blowups, Nebenläufigkeiten etc. nicht abzustellen. Und um das tun zu können, muss man zuerst wissen, dass es diese potentiell im System gibt und wo sie lauern, bevor man es zu einem ziemlich hohen Preis empirisch in Erfahrung bringt.

Warum dann transObjects® processPRO und nicht etwas anderes, was z.B. unter der Überschrift „Workflow-Analyse“ etc. Ähnliches verspricht? Die K&S GmbH steckte das gesamte profunde Wissen deren Entwickler in das processPRO. Gleichzeitig ist das Objektorientierte an transObjects® wie geschaffen für diese Aufgabe. Die Kombination aus Sachkompetenz und passender Technologie spricht also deutlich fürs transObjects® processPRO.

Abb. 1 a) Abb 1 b)

Kapitel 2

Im Kapitel 1 des FAQ-Artikels über Petri-Netze und deren Anwendung in der transObjects®-Technologie haben wir ansatzweise die Komplexität der Problematik, wie sie durch diese Gebilde aufgeworfen wird (und der sich die transObjects®-Applikation processPRO stellt), kennen gelernt. Vorliegend wollen wir unsere Überlegungen vertiefen, indem wir Petri-Netze etwas formeller fassen und die Problematik, die sie aufwerfen – insbesondere diejenige rund um die Erreichbarkeitsmengen – genauer ergründen; Letzteres nicht zuletzt vor dem Hintergrund der Geschichte deren wissenschaftlicher Erforschung.

Eine der recht häufig gestellten Fragen zu unseren Artikeln über processPRO und Petri-Netze(eigentlich sollten unsere Artikel Fragen klären anstatt welche aufwerfen J) lautet, wozu sich über die per se unendlichen Erreichbarkeitsmengen Gedanken machen, wenn doch alles in der realen Welt beschränkt ist? Nun, so einfach ist es nicht. Zum einen können z.B. Datenbankkapazitäten, betrachtet in einem konkreten systemanalytischen Kontext, sehr wohl praktisch unbeschränkt sein. Zum anderen erhoffen wir uns von den theoretischen Erkenntnissen ein besseres Gespür z.B. für die Komplexität bestimmter Aufgaben, wie Sie in Gebilden à la Petri-Netz naturgemäss steckt.

Im ersten Teil unserer Überlegungen haben wir eine graphentechnische Erfassung von Petri-Netzen unter Meidung jeglicher mathematischer Formeln 😉 vorgelegt. Wörtlich heisst es in Teil 1: „Wir identifizieren Petri-Netze als Graphen, bestehend aus Stellen und Transitionen sowie einer Kantenabbildung von Stellen zu Transitionen und umgekehrt, mit jeweils ganzzahliger Beschriftung (auch „Kantenvielfachheit“ genannt). Kanten mit der Vielfachheit gleich Null werden als nicht existent angesehen“.
Etwas formeller gesprochen – aber immer noch unter Meidung jeglicher mathematischer Formeln J – bilden gewöhnliche Petri-Netze (d.h. ohne sog. inhibitor-Kanten) ein Tupel (S,T,k) bestehend aus den beiden Knotenmengen sowie der Kantenabbildung k, wobei es sich bei S und T stets um endliche und zueinander disjunkte Mengen handelt und die Kantenabbildung wie gesagt die Quantität (also Vielfachheit) der gerichteten Kanten (inklusive Null) zwischen jeweils heterogenen Knoten angibt.

Aber Graphen hin oder her – aus guten Gründen wollen wir vorliegend eine andere Fassade von Petri-Netzen beleuchten. Betrachten wir hierzu die nachfolgend aufgeführten Abbildungen, die eine sukzessive Zustandsüberführung in einem Petri-Netz infolge vom Feuern bestimmter Transitionen darlegen. Identifizieren wir die Stellen mit Achsen eines n-dimensionalen Raumes und deren Belegung mit der Quantifizierung derselben, also dem Koordinaten, so stellen wir fest, das die augenblicklichen Zustände eines Petri-Netzes den Punkten in einem ndimensionalen ganzzahligen Raum (Gitter) entsprechen und das Feuern einer Transition einem Übergang (Translation) von einem Gitterpunkt zu einem anderen entspricht!

Der so modifizierte Begriff der Transition, der diese nicht nur als einen Graphenknoten beschreibt, sondern darüber hinaus die Kanten, in die sie involviert ist, mit einschliesst, gestattet nun das Feuern einer Transition als eine Translation in dem n-dimensionalen Gitter aufzufassen, demnach als eine simple Vektoraddition x+t, wobei t nun einen Translationsvektor darstellt und T all solche Vektoren in einem gegebenen Petri-Netz enthält.

So gesehen verwundert es nicht allzu sehr, dass man in der Fachliteratur über Petri-Netze mit Begriffen wie Vectorsets, Multisets, (VAS)/(VRS)’s (vector addition/replacement system) etc. häufig konfrontiert wird. Denn in der Tat sind solche Gebilde die rein algebraische Form von Petri-Netzen, wie sie sowohl in den theoretischen Überlegungen wie auch in der IT selbst weitaus mehr Anwendung findet, als die noch so anschauliche aber wenig praktikable Urform der „place / transition“ – Graphen. (Für den Äquivalenzbeweis sowie die Unterscheidung zwischen (VAS)’s und (VRS)’s möge der Leser einmal mehr [RAS] konsultieren).
Nun aber erinnern wir uns wieder an die wohl wichtigste Frage, die Petri-Netze aufwerfen, und die sich auch uns zuvor aufgedrängt hat, nämlich die, was alles (in einem zu analysierenden System) passieren kann. Wörtlich genommen ist es doch nichts anderes als die Frage nach allen Zuständen, die ein Petri-Netz von einem vordefinierten Anfangszustand ausgehend annehmen kann. Anders ausgedrückt ist es die Menge aller Punkte x, die durch eine regelkonforme Kombination von Transitionsverktoren erreicht werden kann; so nennen wir diese Mengen auch „Erreichbarkeitsmengen“.

Das alles scheint auf den ersten Blick wie auf dem Silbertablett geliefert (und mit mathematischen Formeln untermauert „scheint“ es noch mehr J). Ein Vektorsystem, wo die Addition als einzige Operation auftritt? Hat das nicht etwas mit [MPR], der Presburger Arithmetik, zu tun? Demnach müsste doch jede Erreichbarkeitsmenge durch die Menge aller Linearkombinationen von den Translationsvektoren zu beschreiben sein (und wäre somit stets linear!). Zwar hätten wir noch zu berücksichtigen, dass nicht jede Translation zulässig ist – insbesondere nicht in den halbnegativen Raum, da es keine negativen Quantitäten an den Stellen geben kann (die Transitionen bei Ressourcenmangel nicht feuern dürfen) – aber das war es schon, so scheint es.

Aber leider… weit gefehlt! Welche Konsequenzen es hat, Translationen und demzufolge auch die Erreichbarkeitsmengen unter den Vorbehalt der Zulässigkeit (Schaltbarkeit von Transitionen) zu stellen, wurde relativ früh deutlich und zwar durch Rabin’s Beweis von der algorithmischen Nicht-Berechenbarkeit von Erreichbarkeitsmengen gewöhnlicher Petri-Netze!

Diese Erkenntnis ist für jemanden, der bislang nur über unsere Sparte Bekanntschaft mit Petri-Netzen gemacht hat, erstaunlich – sind doch die Erreichbarkeitsmengen bei den bislang vorgestellten Beispielen zumeist endlich und auch sonst können sie fast immer intuitiv bestimmt werden. Und dennoch gibt es keinen Algorithmus, keine allgemeingültige Struktur von Erreichbarkeitsmengen, die deren einheitliche Charakterisierung ermöglichen würde. Das sog. Erreichbarkeitsmengenproblem bei den gewöhnlichen Petri-Netzen ist unentscheidbar, d.h. diese sind nicht algorithmisch berechenbar (Grundzüge der Berechenbarkeitstheorie möge der Leser der Fachliteratur entnehmen).

Wer sich bis dahin der Tragweite der zuvor erwähnten „kleinen Einschränkung“ der ungehemmten Presburger Arithmetik nicht bewusst war, ist es jetzt wohl endgültig. Denn die unscheinbare Vorbehaltstellung des Feuerns von Transitionen – nennen wir es eine Inhibition – hievt in der Tat die Komplexität des im Falle der ungehemmten Vektorsystems trivialen Erreichbarkeitsmengenproblems jenseits des algorithmisch Machbaren!

Und wie gering wirklich diese Inhibition ist, wird einem spätestens nach dem Studium von [HPA] und [RAS] deutlich. Denn in der Tat mag auf den ersten Blick eine Inhibition, die auf eine kontrollierende Stelle zurückgeht, nicht unbeträchtlich erscheinen. Eine Stelle, die eine Input- und Outputstelle zugleich für eine Transition ist, bedeutet doch, dass es mit dem Verbot der halbnegativen Räume (d.h. mit mindestens einer negativen Koordinate) nicht getan ist.

Dennoch zeigten Hopcroft und Pansiot in [HPA], dass kontrollierende Stellen (vgl. Abb. 1b),2a),2b)) stets durch 3 zusätzliche nicht-kontrollierende Stellen simuliert werden können, so dass die Erreichbarkeitsmengen im Sinne der Projektion auf die ursprünglichen Stellen unverändert bleiben (zahlreiche Beispiele für diese Simulation findet der Leser in [RAS], eine Ausdehnung auf Petri-Netze mit sog. inhibitor-Kanten enthält das Lemma 3.3 mit nachfolgenden Korollaren).

Die Konsequenz aus diesem Lemma ist für uns eben die, dass die Inhibition in gewöhnlichen Petri-Netzen wirklich auf das Verbot der halbnegativen Räume beschränkt werden kann, was die nicht-Entscheidbarkeit des Erreichbarkeitsmengenproblems nicht weniger erstaunlich macht. Hingegen spielt die obige Transformation im TransObjects® keine entscheidende Rolle. Vielmehr arbeitet processPRO direkt mit kontrollierenden Stellen, also den Vector Replacement Systems (VRS)’s, wie noch zu gegebener Zeit zu sehen sein wird.

Obwohl die Nicht-Berechenbarkeit der Erreichbarkeitsmengen relativ früh feststand und das Gleichheits- bzw. Inklusionsproblem der Erreichbarkeitsmengen hieraus folgernd ebenfalls als unentscheidbar ausgewiesen werden konnten [HGB], vermuteten viele Forscher fortan, dass ein anderes damit sehr verwandtes Problem entscheidbar sein könnte. Es handelt sich um das sog. Erreichbarkeitsproblem, also die Fragestellung, ob ein bestimmter Zustand x von einem festen Anfangszustand aus erreichbar ist (natürlich mittels zulässiger Translationen bzw. Schaltfolgen). Die Grundidee war dabei die, dem Erreichbarkeitsproblem ohne eine implizite Bestimmung der Erreichbarkeitsmenge beizukommen. Es sei vorweggenommen, dass diese unscheinbare Einschränkung bzw. Präzisierung des Erreichbarkeitsmengenproblems uns in der Tat über die Grenze des algorithmisch Machbaren hilft!

Die Entscheidbarkeit des Erreichbarkeitsproblems bedeutet für uns, dass wir zwar die Frage nach dem, was alles passieren kann, nicht direkt beantworten können, aber wenigstens die, ob ein bestimmter Zustand – der in vielerlei Hinsicht problematisch sein kann – vorkommen kann. Das ist zwar schon etwas, kann aber in der Praxis eine unbefriedigende Antwort liefern. Die Frage, der man sich auch in der Vergangenheit widmete, lautete daher, unter welchen Umständen lässt sich eine umfassendere Antwort auf diese Fragen doch geben. Das Augenmerk der Forscher richtete sich nun darauf, ob denn die Inhibition in gewöhnlichen Petri-Netzen zwingend die so elegante Linearität der inhibitionsfreien Vektor-Additionssysteme zerstören muss.

Offensichtlich ist Letzteres nicht immer der Fall. Ein Petri-Netz, das ausschliesslich aus nichtnegativen Transitionen besteht, hat zwangsläufig lineare Erreichbarkeitsmengen und in den bislang zitierten Fällen (Abb. 1, 2) sind diese Mengen sogar endlich und dadurch zwangsläufig zumindest semilinear, also aus endlich vielen linearen Mengen bestehend. Offensichtlich ist das Erreichbarkeitsproblem in solchen Fällen berechenbar, wenn es die Erreichbarkeitsmengen selbst schon sind. So war auch die Semilinearität von Erreichbarkeitsmengen zunächst der Dreh- und Angelpunkt in der Petri-Netz-Forschung. Van Leuwen wandte sich beispielsweise in [JVL] der Vermutung zu, dass ein hinlänglich kleines Petri-Netz (gemeint ist stets die geometrische Dimension des VAS/VRS, d.h. die Anzahl der Stellen) semilineare Erreichbarkeitsmengen haben dürfte. In der Tat konnte er beweisen, dass ein dreidimensionales Petri-Netz stets semilineare Erreichbarkeitsmengen hat, völlig unabhängig von der Anzahl und Art der Transitionen. Im Folgenden haben Hopcroft und Pansiot gezeigt, dass dies sogar auf fünfdimensionale (VAS)’s zutrifft. Eine andere Teillösung lieferte Cardoza in [EWC] für sog. selbstduale Petri-Netze, d.h. mit einer Art Symmetrie. Auch hier konnte gezeigt werden, dass diese Klasse von Petri-Netzen stets semilineare Erreichbarkeitsmengen hat, mit allen Konsequenzen für das Erreichbarkeitsproblem und das Erreichbarkeitsmengenproblem.

Aber bei aller Zufriedenheit mit diesen Teilresultaten, einen Vermutstropfen gab’s dann schon noch. Nehmen wir das Petri-Netz aus [RAS], so stellen wir fest, dass die Semilinearität bereits in relativ kompakten Petri-Netzen nicht unbedingt vorliegen muss, was unsere Teillösungen des Erreichbarkeitsproblems weniger wertvoll erscheinen lässt. Was ist also nun mit dem (allgemeinen) Erreichbarkeitsproblem?

In der Tat erwies sich der Ansatz, dem Erreichbarkeitsproblem ohne eine implizite Errechnung von Erreichbarkeitsmengen beizukommen als goldrichtig. Den als ersten geltenden Beweis für die Entscheidbarkeit des Erreichbarkeitsproblems lieferte Mayr in [EWM] und zwar auf dem klassischen Wege über einen konkreten Algorithmus. Nicht viel später lieferte Kosaraju in [SRK] einen anderen Beweis, wobei viele in seiner Arbeit inzwischen einige „mistakes“ festgestellt haben wollen.

Wie knapp entscheidbar d.h. wie hart das Erreichbarkeitsproblem wirklich ist, zeigt uns nicht zuletzt die Arbeit von Lipton [RLN]. Der exponentielle Speicherplatzbedarf bedeutet, dass ein Algorithmus zur Lösung des Erreichbarkeitsproblems auch dann exponentielle Laufzeiten hätte, wenn wir hierfür Maschinen mit noch so vielen parallel arbeitenden Prozessoren einsetzen würden. Interessanterweise sollte sich erst viele Jahre später herausstellen, dass es ein noch härteres und dennoch entscheidbares Problem durchaus gibt und zwar ist es – um es vorwegzunehmen – das Erreichbarkeitsproblem von Petri-Netzen mit genau einer sog. inhibitor-Kante.

Kapitel 3

Im Kapitel 2 unserer Überlegungen über Petri-Netze und deren Rolle in der transObjects®-Technologie haben wir die Komplexität der Probleme rund um die Erreichbarkeitsmengen durch Nachzeichnen der Geschichte von deren wissenschaftlicher Erforschung beleuchtet. Wir haben den langwierigen Weg der Wissenschaft hin zur Lösung des Erreichbarkeitsproblems kennen gelernt und zwar stets vor dem Hintergrund des als (algorithmisch) unentscheidbar ausgewiesenen Erreichbarkeitsmengenproblems. Im Falle von Petri-Netzen mit den sog. Inhibitor-Kanten, bei denen sich die Geschichte teils wiederholen sollte, haben wir vorliegend Ähnliches vor.

Zu den in der Fachwelt bekanntesten qualitativen Erweiterungen des Grundmodells von Vektor-Additions-Systemen (und somit von gewöhnlichen Petri-Netzen) gehören so genannte Inhibitor-Kanten –nachfolgend „i-Kanten“ genannt; grafisch durch den Unterbruch –| |– dargestellt.

Die qualitative Verschärfung der Inhibition durch die i-Kanten beruht darauf, dass diese – ausschliesslich von einer Stelle zu einer Transition führend – eine Transition nur dann zum Feuern befähigen, wenn die betreffenden (Inhibitor-) Stellen leer sind. Somit wird das Grundprinzip der gewöhnlichen Petri-Netze – nennen wir es positive Inhibition – total auf den Kopf gestellt. Denn während normalerweise das Feuern von Transitionen nur bei Vorhandensein von hinlänglich vielen Ressourcen stattfinden kann, ist dies genau umgekehrt, wenn i-Kanten mit im Spiel sind.

Auf den ersten Blick scheint diese wie auch jede andere Verschärfung der Inhibition – und die daraus zwangsläufig resultierende Verkomplizierung von Strukturen der Erreichbarkeitsmengen – weiter weg von der praxisnahen Anwendung im transObjects® processPRO zu führen. Jedoch bei genauerem Hinschauen stellen wir rasch fest, dass exakt das Gegenteil zutrifft. transObjects® processPRO arbeitet nämlich mit Petri-Netzen, bei denen die Inhibition sogar noch weiter verallgemeinert ist, indem sie von Fall zu Fall für alle Transitionen einzeln redefiniert werden kann („derrived classes“ lassen grüssen!). Deshalb ist ein genaueres Studium von Petri-Netzen mit i-Kanten im Hinblick auf das letztendlich zu beleuchtende Funktionsprinzip von transObjects® processPRO ausserordentlich hilfreich.

Ähnlich wie bei der Erforschung von gewöhnlichen Petri-Netzen, hat auch hier die Fachwelt relativ früh die Grenzen des algorithmisch Machbaren aufgezeigt bekommen. Aus Minsky’s Arbeit [MLM] aber auch aus diversen Abhandlungen von Rabin war nämlich bereits Anfang der 70’er Jahre zu folgern, dass das allgemeine Erreichbarkeitsproblem von Petri-Netzen mit zwei nur zwei i-Kanten unentscheidbar ist. Allerdings konnte diese Erkenntnis nicht auf Petri-Netze mit genau einer i-Kante ausgedehnt werden; das Erreichbarkeitsproblem für diese Gebilde blieb seinerzeit, zu Minsky’s Zeiten, unbeantwortet und das sollte für gut 30 Jahre so bleiben. Angesichts der nachgewiesenen Unentscheidbarkeit des allgemeinen Erreichbarkeitsproblems von Petri-Netzen mit zwei i-Kanten und der bekannten exorbitanten Härte dieses Problems im Falle von gewöhnlichen Petri-Netzen – also ohne i-Kanten – konnte die Nicht-Entscheidbarkeit des Erreichbarkeitsproblems bei exakt einer i-Kante durchaus vermutet werden. Allerdings gab es gleichermassen auch genau anders lautende Mutmassungen. So untersuchte beispielsweise Rainer A. Stawarz 1991 in [RAS] den Einfluss von i-Kanten auf die Struktur von Petri-Netz-Erreichbarkeitsmengen, insbesondere hinsichtlich deren Semilinearität, und stellte – gewissermassen auf den Spuren von van Leuwen, Hopcroft und Pansiot – fest, dass der Einfluss von nur einer i-Kante auf die dimensionsbezogenen Semilinearitätsgrenzen marginal ist und dass erst eine zweite i-Kante eine signifikante Verschiebung nach sich zieht. Auch das qualitative Enhancement von so genannten WPNC-Computern (Weak Petri-Net Computer) hielt sich demnach im Falle von nur einer i-Kante in Grenzen, während zwei oder mehr eine völlig andere Qualität darstelltenDennoch – mehr als eine Vermutung war es nicht. Denn auch eine einzige i-Kante verschärft offensichtlich die Inhibition der gewöhnlichen Petri-Netze, was die Struktur der betreffenden Erreichbarkeitsmengen ganz bestimmt nicht vereinfacht. Das Erreichbarkeitsproblem von Petri-Netzen mit genau einer i-Kante blieb auch in [RAS] offen und es sollte noch gute 10 Jahre halten, genau bis Anfang 2004, als Klaus Rheinhard in [KLR] einen Beweis für eben diese Vermutung lieferte.

Der Beweis von Klaus Rheinhard ist eine Folgerung aus einer sehr umfassenden Untersuchung von Petri-Netzen mit i-Kanten und deren Erreichbarkeitsmengen. So lernen wir aus [KLR], dass die i-Kanten in einer bestimmten Anordnung zueinander liegen müssen, damit das Erreichbarkeitsproblem unentscheidbar wird (sog. nested transitions). Zwangsläufig ist ein solches Konstrukt mit nur einer i-Kante nicht möglich, woraus, quasi als Beifang, die Bestätigung für die bis dato vermutete Entscheidbarkeit der betreffenden Fragestellung folgt.

Eine weitaus weniger umfassende Untersuchung, jedoch mit einer gezielten Beweisführung für die Entscheidbarkeit des allgemeinen Erreichbarkeitsproblems von Petri-Netzen mit genau einer i-Kante, findet der interessierte Leser demnächst im Nachtrag zu [RAS] auf unserer Website.

Literaturverzeichnis:

[ARK] T. Araki, T. Kasami, Decidable Problems on the Strong Connectivity of Petri Net Reachability Sets, Theoret. Comp. Sci. 4 (1977) 99-119;

[BLM] H.K. Büning, T. Lettmann, E.W. Mayr, Projections of Vector Addition System Reachability Sets Are Semilinear, Report No. STAN-CS-88-1199, Stanford, California (1988);

[CAP] C.A. Petri, Kommunikation mit Automaten, Institut für Instrumentelle Mathematik, Bonn, Schriften des IMM Nr. 2, (1962).

[DCO] D.C. Open, A Upper Bound on the Complexity of Presburger Arithmetic, J. Comput. Systems Sci., 16 (1978) 323-332.

[EWC] E.W. Cardoza, Computational Complexity of the Word Problem for Commutative Semigroups, MAC Technical Memorandum 67, M.I.T. (1975).

[EWM] An Algorithm for the General Petri Net Reachability Problem, Proc. 13th Ann. ACM STOC, 1981, Milwaukee, WI, 238-246.

[EWM] E.W. Mayr, An Algorithm for the General Petri Net Reachability Problem, SIAM J. Comput. 13,3 (1984) 441-460.

[EWM] E.W. Mayr, Persistence of Vector Replacement Systems is Decidable, Acta Informatica, 15 (1981) 309-318.

[FCO] F. Commoner, Deadlocks in Petri Nets, Applied Data Research, Wakefield MA, CA 7206-3211 (1972), Applied Data Research Inc.

[HGB] H.G. Baker, Rabin’s Proof of the Undecidability of the Reachability Set Inclusion Problem of Vector Addition Systems, MIT Project MAC, CSGM 79, Cambridge, Mass. (1973).

[HPA] J. Hopcroft, J.J. Pansiot, On the Reachability Problem for 5-Dimensional Vector Addition Systems, Theoret. Comp. Sci., 8 (1979) 135-159;

[JGR] J. Grabowski, The Decidability of Persistence for Vector Addition Systems, IPL, 11 (1980) 20-23;

[JVL] J. Van Leeuwen, A Partial Solution to the Reachability Problem for Vector Addition Systems, Sixth Ann. ACM Symp. on the Theory of Computing (1974) 303-309.

[KLR] K. Reinhardt Counting as Method, Model and Task in Theoretical Computer Science, Uni Tübingen, Habilitationskolloquium 16.02.2005, Kapitel V.

[KLT] K. Lautenbach, Exakte Bedingungen der Lebendigkeit für eine Klasse von Petri-Netzen, GMD Bonn (St. Augustin), Bericht Nr. 82, (1973).

[MLM] M. L. Minsky, Computation: Finite and Infinite Machines. Prentice-Hall, 1971.

[MH0] M. Hack, Decidability Questions for Petri Nets, MIT, LCS, TR 161, Cambridge, Mass., (1976).

[MH1] M. Hack, Petri Nets and Commutative Semigroups, MIT Project MAC, CSGN 18, Cambridge, Mass. (1974).

[MH2] M. Hack, The Equality Problem for Vector Additon Systems is Undecidable, C.S.G. Memo 121. Project MAC, M.I.T. (1975).

[MM1] E.W. Mayr, A.R. Meyer, The Complexity of the Finite Containment Problem for Petri Nets, Journal of the Association for Computing Machinery, Vol 28, No. 1 (1981) 561-576.

[MM2] E.W. Mayr, A.R. Meyer, The Complexity of the Word Problems for Commutative Semigroups and Polynomial Ideals, Advances in Mathematics 46,3 (1982), 305-329.

[HM] H. Müller, Decidability of Reachability in Persistent Vector Replacement Systems, Proc. 9th Symposium on MFCS (1980), LNCS 88, Springer, New York, 426-438.

[MPR] M. Presburger, Über die Vollständigkeit eines gewissen Systems der Arithmetik ganzer Zahlen, in welchem die Addition als einzige Operation hervortritt, Compute-Rendus du I. Congrés des Mathématiciens des pays, Warsaw (1930) 92-101.

[RAS] R.A. Stawarz, Über Petri-Netze mit inhibitor-Kanten, deren Leistungsfähigkeit und Erreichbarkeitsmengen, J.W. Goethe-Univ. Frankfurt/M, (1991);

[RKM] R. Karp, R. Miller, Parallel Program Schemata, J. Comp. Syst. Sci. 3 (1969) 147-195;

[RLN] R. Lipton, The Reachability Problem is Exponential-Space Hard, Dept. Computer Science Rep. 62, Yale Univ., New Haven, CT (1976).

[RMK] R.M. Keller, Vector Replacement Systems: a Formalism for Modelling Asynchronous Systems, Princeton Univ., Princeton, NJ, CSL, TR 117, (1972).

[SRK] S.R. Kosaraju, Decidability of Reachability in Vector Addition Systems, Proc. 14th Ann. ACM STOC, (1982) 267-281.

[STY] G. Sacerdote, L. Tenney, The Decidability of the Reachability Problem for Vector Addition Systems, Proc. 9th Ann. ACM Stoc, (1977) 61-76.

[1] Decision Problems for Petri Nets and Vector Addition Systems, MIT Project MAC, MAC-TM 59, Cambridge, Mass. (1975).

[1] Decidability Questions for Petri Nets, MIT, LCS, TR 161, Cambridge, Mass. (1976).

[1] The Recursive Equivalence of the Liveness Problem and the Reachability Problem for Petri Nets and Vector Addition Systems, 15th Annual Symposium on SWAT, New Orleans, LA, (Oct. 1974) 156-164;

Was ist das Wesen der „Objektorientierung“? Woher kommt es?

Man kann die Objektorientierung (im Folgenden verwenden wir das Präfix „oo“, jedoch immer mit einem Suffix versehen – etwa „oo-Technologie“ – um Missverständnissen vorzubeugen 😉 als Mainstream unserer Zeit ansehen; zu Deutsch ist es eine Art Geistesströmung, was allerdings weitaus mehr zu bedeuten hat, als nur eine vorübergehende Modeerscheinung oder gar ein Selbstzweck. Was genau dahinter steckt, wollen wir im Folgenden diskutieren; siehe auch FAQ-Artikel „Oo vs. SQL“ oder Sinn und Zweck von objektorientierten Datenbanken.

Noch bis in die 80’er Jahre hinein war die prozedurale Sicht der Dinge vorherrschend in der IT-Welt. Eine prozedurale Abbildung eines Systems (etwa mittels geeigneter Software) orientiert sich an den Funktionen und Prozeduren, die darin ablaufen. So werden einzelne Systemabläufe in Funktionen und Prozeduren zusammengefasst und diese in eine mehr oder weniger strukturierte zeitliche Abfolge gestellt. Es verwundert daher nicht, dass Phrasen wie „function“ oder „procedure“ feste Bestandteile älterer Programmiersprachen, wie z.B. FORTRAN oder PASCAL, sind.

Was ist denn so verkehrt an dieser Sichtweise? Auf den ersten Blick nicht allzu viel, denn schliesslich sind es primär die Abläufe, z.B. in einem produzierenden oder Dienst leistenden Betrieb, denen jede betriebswirtschaftliche Analyse gilt (vgl. transObjects® processPRO). Allerdings schlägt sich jede solche Analyse mit der äusserst unangenehmen Volatilität der Prozessstrukturen herum: Betriebswirtschaftliche Abläufe – oder sagen wir, die Art und Weise der Abarbeitung von betrieblichen Prozessen – unterliegen naturgemäss starken Veränderungen, bedingt etwa durch ständig wechselnde Marktanforderungen, Änderungen im Geschäftsumfeld etc. Auf der anderen Seite sind die grundlegenden betrieblichen Strukturen – etwa Datenstrukturen oder besser, deren Beziehungen zueinander (etwa Hierarchien?!) – doch weitgehend konstant. Im Umkehrschluss müsste es aber heissen, dass eine Software, die sich irgendwie an den Datenstrukturen bzw. deren (hierarchischen) Beziehungen zueinander orientieren würde, wesentlich seltener oder zumindest wesentlich weniger umfangreich zu mutieren sein müsste.

Etwas Ähnliches muss sich seinerzeit Bjarne Stroustrup gedacht haben, als er die als hocheffizient geltende (allerdings prozedurale) Programmiersprache „C“ hernahm und diese zu einem objektorientierten „C“ namens „C++“ erweiterte. Dieser linguistische Bestseller, den man inzwischen als den oo-Klassiker schlechthin ansieht, fand fortan viele Anhänger, bis hin zu den Microsofties, die deren 32-Bit-Betriebssysteme und -Anwendungen ebenfalls in C++ entwickelten und derzeit immer noch entwickeln, auch wenn demnächst Fortentwicklungen von C++ (etwa C#) nach und nach zum Zuge kommen sollten.

Die Erschliessung der oo-Technologie durch den Branchenführer Microsoft, aber auch die Bereitstellung von C++ – Entwicklungswerkzeugen durch diverse Softwarehersteller, setzten den Siegeszug von „oo“ und C++ fort. In den 90’ern wurde das „C++“ zu einem der wichtigsten Qualitätsmerkmale für Software und galt für immer mehr User als Inbegriff der Zukunftssicherheit und moderner Sicht der Dinge. Alles was Rang und Namen hatte, versuchte sich in der oo-Technologie. Dabei taten sich Neuentwicklungen, wie z.B. transObjects®, leichter, während z.B. SAP nur unter hohem Aufwand das rein prozedurale und höchst proprietäre „ABAP“ abzuschütteln suchte. Der Trend hin zu der objektorientierten Sicht der Dinge war jedoch ungebrochen und das ist es immer noch.

Im Jahre 1995 stellten sich die Entwickler der K&S Informatik GmbH die Frage, warum denn eine solch revolutionäre Sicht der Dinge an der Grenze zwischen dem Client und dem Datenbankserver ihre Vorzüge einbüssen muss. Warum muss denn die Ausrichtung nach Datenstrukturen ausgerechnet auf Seiten der Datenbank aufgegeben werden, wo es dort gerade um Datenstrukturen per se geht?

Diese Fragestellungen haben seinerzeit transObjects® die entscheidende Wendung hin zu den objektorientierten Datenbankservern gegeben, so dass wir aus heutiger Sicht etwas pathetisch von der Geburtsstunde der transObjects®-Technologie sprechen können. In der Tat punktet die oo-Technologie nirgendwo sonst so gewaltig, wie eben auf Seiten der Datenbankserver.