Itanium, Opteron, IA64, x64 – was bedeutet das alles? (Teil 1)

Die Intersystems Inc., der Hersteller von Caché-Server, der als Basis-Datenbankserver in transObjects® Anwendung findet, erschließt mit dem Windows-Release 5.0.21 sowie dem grundlegend überarbeiteten 5.1.0 die zweite 64-Bit Windows®-Plattform neben „IA64“, nämlich das „x64“. Für uns ist es Anlass genug, den Vergleich mit Intel’s „IA64“ (Itanium®) anzustellen, den wir bis dato mangels passender Caché-Version nicht machen konnten (zwar gab es bereits seit längerem Caché-Editions für die als „Opteron“ bzw. „AMD64/EM64T“ bekannt gewordene Plattform, jedoch leider nicht unter Windows® x64).

Wir sind gespannt auf das Verhalten von Caché auf einer EM64T-Hardware, auf der Caché bereits unter dem 32-Bit-Windows® exzellent lief und wir sind neugierig auf den Vergleich zu Inte®’s „IA64“, mit dem wir bereits seit 3 Jahren unsere Erfahrungen haben machen können. Wird Caché wirklich – wie viele prophezeien – mit einem 64-Bit-Xeon auf und davon ziehen oder wird eher Intel’s behäbig wirkender Itanium® das Rennen machen? Ist der von Intersystems erstellte Build wirklich optimal auf die spezifische Itanium®-Architektur getrimmt?

Wir wollen es ganz genau wissen – von daher sind derzeit in unserem Benchmark-Labor die Ärmel richtig hochgekrempelt. Vorerst aber wollen wir uns dem „IA64 vs. x64“ mehr von der theoretischen Seite her nähern und auf dieser Basis geben wir hier eine kleine Entscheidungshilfe in Sachen Anschaffung eines 64-Bit-Servers, insbesondere dann, wenn auch der Caché-Server hierauf betrieben werden sollte. Voilà:

Während die ursprünglich von AMD entwickelte und unter „Opteron“ bekannt gewordene 64-Bit-Plattform somit einen weiteren Punkt für sich verbuchen kann und nicht zuletzt auch für transObjects®-Anwender noch ein Stück relevanter wird, kontert der Markführer Intel® mit einer Multi-Core-Variante des Itanium®-Prozessors. Der für Herbst 2003 angekündigte „Montecito“ lässt gerade eingedenk der bereits bei dem Vorgänger „Madison“ überraschenden Benchmarks für das teils schon verloren geglaubte Rennen gegen „x64“ wieder Hoffnung schöpfen.

Wir versuchen nun grundlegende Unterschiede zwischen den beiden 64-Bit-Plattformen zu charakterisieren, ferner dem transObjects®-Anwender eine Entscheidungshilfe in Sachen geeigneter Plattform für den Caché-Server zu geben. Zu Guter letzt spekulieren wir darüber, welche der beiden Plattformen á la longue das Rennen machen könnte. Dass dies sehr gewagt ist, ist uns vollkommen klar.

Im Jahre 2001 brachte Intel® nach einer gut 5-jährigen Entwicklung in Zusammenarbeit mit Hewlett-Packard seinen ersten 64-Bit-Prozessor auf den Markt. Die erste Itanium®-CPU machte dem damaligen Ruf der 64-Bit-Welt, die von PA-RISC, ALPHA, Sparc etc. geprägt war, alle Ehren. Wenn man irgendwie das Kunststück vollbracht hatte, Windows 2000 Advanced Server Limited Edition oder eine Beta-Version von Windows 2003 auf die monströse und kaum erschwingliche Hardware drauf zu packen, konnte man diesem Windows bei der Arbeit im wahrsten Sinne des Wortes zusehen… Unsere Tests mit einem Compaq ProLiant DL590/64, immerhin einem 4-Wege Itanium1, erbrachten insofern auch nichts anderes. Es war schlicht fürchterlich langsam! Intel’s interner Codename „Merced“ war da wohl keine Anspielung auf die Automarke… jedenfalls wollen wir es nicht annehmen…

Aber wie dem auch sei. Bei aller Fortschrittlichkeit der Itanium®-Architektur (dazu im Folgenden mehr) wies die als „Itanium1“ bekannt gewordene CPU zahlreiche Merkmale auf, die sie doch sehr behäbig haben wirken lassen. Dazu zählten z.B. die Taktung von 800 MHz (in unserem Compaq DL590/64’er waren es gar jeweils nur 733 MHz’ler), das hohe Voltage von 1.6V und die Chipgrösse basierend auf einer Prozesslänge von 180 nm. So sprachen wir etwas vornehmer wir von einem „niedertourigen“ Server… und weniger vornehm von einem „Wäschetrockner“: Denn die Luftmengen, die mit ohrenbetäubendem Lärm umgewälzt wurden, hätten mit Sicherheit recht gute Dienste in dieser Hinsicht leisten können!

Ja, und da war noch der völlig fehlende „on-die“ Cache (sog. L3-Cache), der das Übrige tat, so dass der Betrieb von 32-Bit’er-Applikationen, z.B. von Caché-Server, schier unmöglich war und selbst Beta’s von Itanium®-Builds waren aufgrund von noch vollkommen unausgereiften Compiler-Tools (sofern es diese überhaupt gab !) vollkommen unzulänglich. So bestand für uns gar kein Zweifel daran, dass ein solches „IA64″ keine praktische Bedeutung fürs transObjects® haben wird.

Allerdings fielen unsere Tests Ende 2002 Anfang 2003 in einen Zeitraum hinein, in dem eine weitere Itanium®-CPU bereits in Einsatz war, nämlich die „Itanium2“. So konnten wir das diametral andere Verhalten eines HP Integrity mit 2 x Itanium2 je 900 MHz und 1.5 MB Cache gegenüber dem des „niedertourigen“ DL590/64’er am eigenen Leibe (oder besser gesagt an eigenen Ohren) erleben. Der unter dem internen Codenamen „McKinley“ geführte Prozessor hatte zwar gegenüber dem „Merced“ ein nur unwesentlich gemindertes Voltage, jedoch war der Gesamteindruck des HP-Integrity rx2600’er trotz seines L3-Cache und einer beinahe 10-fachen (!!!) Anzahl von Transistoren alles andere als monströs. Hewlett-Packard hat sogar mit der „ZX“-Reihe (ZX2600/ZX6000) eine Itanium-basierte Workstation konzipiert, deren Geräuschentwicklung beim Betrieb „unter dem Tisch“ einigermassen erträglich war.

Als die Itanium-Editions sowohl von Windows® 2003 als auch von Caché allmählich aus dem Beta-Stadium schlüpften, war die Geburtsstunde des IA64-Clusters im transObjects®-Datacenter nur noch eine Frage der Zeit. So kamen auch prompt die ersten Cluster-Nodes mit „McKinley’s“ im Gewande von HP-Intergrity zum Einsatz, zeitgleich mit den ersten Itanium®-Builds, des Caché-Servers.

Ein Problem stellte noch anfänglich diejenige Software dar, die damals noch nicht fürs Itanium-Windows® optimiert werden konnte und zwar immer noch mangels geeigneter Compiler. Dazu zählten immerhin auch die aus den Enterprise-Editions bekannten transObjects®-Module wie z.B. exmailPRO. Der auf dem „Die“ integrierte „IA-32-Execution-Layer“ war zum Gähnen langsam und machte die Ausführung von 32-Bit-Tasks schlicht nicht praktikabel. Aber völlig getreu dem Itanium®-Prinzip kam die Lösung nicht etwa durch eine Verbesserung auf dem Layer selbst, sondern durch einen Softwareemulator (man höre und staune!), der in Zusammenarbeit von Intel®/Microsoft® entwickelt worden war und der später Bestandteil des Service Pack 1 von „MS Windows 2003 Server Itanium-Edition“ wurde! Dennoch war auch diese Abhilfe nur von sehr begrenzter Wirksamkeit, so dass eine richtige Lösung dieses Problems erst mit echten Itanium-Builds herbeigeführt werden konnte. Die Ausführung von 32-Bit-Tasks übers WOW64 („Windows-On-Windows64″) blieb unterdessen die Achillesferse des „IA64″.

In den darauffolgenden Jahren profitierten die transObjects®-Itanium®-Cluster – sowie auch immer mehr User – von weiteren Entwicklungen des Itanium®-Prozessors. Nach und nach kam die unter dem Codenamen „Madison“ entwickelte jedoch handelstechnisch weiterhin als „Itanium2“ geführte CPU zum Einsatz. Insbesondere die Reduktion des Voltage auf 1.3 Volt sowie der Fertigungslänge auf 130 nm haben diese Prozessoren insgesamt kompakter ausfallen lassen, wobei die 9 MB L3-Cache sowie die bis zu 1.7 GHz Taktung, wie Sie in der letzten Madison-Ausprägung namens „Madison 9M“ zu finden sind, mehr als ein erster Warnschuss in Richtung AMD/x64 waren. Nicht zu vergessen ist, dass ein EM64T mit 3GHz / 2MB bereits von einem dualen Madison mit je 1.5 GHz / 6 MB in unserem Benchmarking buchstäblich in Grund und Boden gefahren wurde. Was ein „Madison 9M“ oder gar ein „Montecito“ daraus machen würde, können wir erst zum späteren Zeitpunkt empirisch belegen. Vorerst wäre es reine Spekulation.

loggPROnet2003

Ein Rack des transObjects®-Datacenters Mitte 2003. Zu oberst und ganz zu unterst sind Knoten des Itanium-Clusters zu sehen.
Zu oberst McKinley und unterhalb davon ein Madison (je HP Integrity rx2600), ganz zu unterst der Meced DL590/64
.

Inwieweit derartige „Warnschüsse“ AMD wirklich tangieren können, ist indes nur schwer abzuschätzen. Denn eigentlich hat die „ewige Nummer 2“, wie sich manche ausdrücken, seit der ersten Umsetzung der genial einfachen Idee im Opteron-Prozessor fast nur Erfolge verzeichnet. Das genial einfache dabei ist schlicht das nachzumachen, was Intel seinerzeit beim Übergang vom 286’er zum 386’er vollzogen hat. Damals hat man den 16-Bit AX-Register schlicht zum 32-Bit EAX-Register „enhanced“ und schon fanden wir uns alle im 32-Bit-Adressraum wieder. Beim Opteron ist AMD ähnlich vorgegangen, wenn auch nicht von Anfang an durch die Erweiterung auf den vollen 64-Bit-Adressraum (da waren es „nur“ 48 Bit).

Der Coup dabei ist und bleibt die Abwärtskompatibilität. Konfrontiert mit einem 32-Bit-Betriebssystem versetzt sich ein AMD64 in einen passenden Modus und arbeitet mit der gewohnten Performance des 32-Bit-Teils. Die 64-Bit-Erweiterungen werden dann zwar entweder gar nicht oder nur ganz partiell genutzt, aber das ist nichts im Vergleich zu Itanium® der dann ja gar nicht läuft.

Der Aspekt des Investitionsschutzes war es wohl auch, der AMD die vielen Erfolge bescherte. Und die kamen dann wirklich Schlag auf Schlag, von Implementierung passender Betriebssysteme (Windows® nennt entsprechende Editions „x64“) über die Lizenz an den Branchenprimus Intel®, der seitdem die Opteron-Philosophie auf eigenen „Xeon’s“ unter „EM64T“ umsetzt, bis hin zur zwischenzeitlicher Eroberung des Workstation-Segments.

Insbesondere bei einem Vergleich x64 zu IA64 schien die AMD-Plattform zuweilen haushoch überlegen, vor allem dann, wenn man eine 32-Bit-Applikation laufen lies. Während auf Itanium® der bereits zuvor erwähnte IA-32-Execution-Layer die IA-64-Register auf die 32’er mühselig abbildete und durch eine aufwändige Prozedur so den IA-64-Datenfluss generierte, verfügte der AMD64 über vollwertige 32-Bit-Einheiten und brauchte nicht weiter als die 64-Bit’er links liegen zu lassen. Da wurden so manche Apologeten von „x64“ schon ein wenig selbstherrlich – verkehrte Welten!

Wie sind dann die Resultate unseres Benchmarkings zu erklären? Nun, dazu ist ein kleiner Einblick in die IA64-Architektur vonnöten.

Die Involvierung von HP in die Itanium-Entwicklung hat die Kompatibilität der neuen CPU zu PA-RISC (mit HP-UX / Unix) zur Voraussetzung gemacht. Angelehnt an das „Reduced Intruction Set“ – Prinzip dachten sich wohl die Entwickler etwas Ähnliches und… gönnten dem neuen Itanium® weder Einheiten für Gleitkomma-Division, geschweige denn für andere Funktionen. Der so gewonnene Platz auf dem Die wurde vielmehr für andere Bausätze genutzt, die fürs Caching sowie eine optimale Atomisierung resp. Parallelisierung von Vorgängen sorgen sollten. Die Grundidee dabei: Der Compiler kann weitaus exakter die Unabhängigkeit von Teiloperationen aus seinem Kontext hearus erkennen (was die Voraussetzung für eine optimale Parallelisierung ist), als es die CPU aus ihrem Berechnungskontext heraus kann! So gesehen wird hier scheinbar die „Verantwortung“ auf die Compiler-Hersteller abgewälzt. Aber das Konzept kann durchaus aufgehen, wie wir aus unseren Tests nun wissen. Welche Features es im Einzelnen sind, die dem Compiler (bzw. auch einem Entwickler) einen solch grossen Gestaltungsspielraum eröffnen, wollen wir nachfolgend kurz skizzieren, wobei der Leser genaueres der Fachliteratur entnehmen mag.

Bereits beim „Merced“ spendierte Intel® seinem Itanium®-Sprössling neben der vollen 64-Bit-Adressiereung ein rekordverdächtiges Set an Registern: 128 Allzweck-Register, weitere 128 zur Gleitkomma-Verarbeitung und 64 sog. Predicate-Register und schliesslich noch eine Vielzahl von Spezialregistern, wie 128 Applikationsregister für den Kernel und die Stack-Engine sowie Branch-, ID-, und Performance-Monitor-Register.

Mit einem solchen Register-Set kann gut jongliert, genauer gesagt, rotiert werden. Denn das Prinzip der Registerrotation mit den so genannten dynamischen Registern gehört auch zu den wichtigsten Merkmalen der IA-64-Architektur. Die aufwändigen Kopieroperationen zwischen den Registern werden auf ein Minimum reduziert, indem man – vereinfacht dargestellt – mit Registerzeigern anstatt Registern arbeitet und diese Zeiger dann, z.B. in einer Schleife, inkrementiert (hierbei soll lt. Intel® ein anderes Feature eine wichtige Rolle spielen, nämlich die Inkrementierung der Register beim Abspeichern ohne einem zusätzlichen Schritt; als C++/C-Programmierer kennen wir alle den Postinkrement-Operator). Dieses sog. Software-Pipelining, d.h. die Parallelisierung von für unabhängig erkannten Teiloperationen, indem man sie (parallel) über virtuelle Register auf unterschiedliche physikalische Register zugreifen lässt, soll beispielsweise bei der typischen Punkt-für-Punkt Bildbearbeitung deutliche Vorteile gegenüber der IA-32-Architektur aufweisen.

Natürlich besitzt der Itanium als ein superskalarer Prozessor mehrere ALU’s, weshalb sich die Parallelisierung wirklich auszahlt, so sie denn richtig gemacht ist. Folglich ist eigentlich die Parallelisierung der Begriff, denn man verwenden müsste, wenn man die IA64-Architektur mit nur einem einzigen Begriff umschreiben möchte. Und Intel® leistet in der Tat auch einiges, um diese Parallelisierung zu verfeinern. Die Technik, die Intel® im gegensatz zu PA-RISC hierfür aufbietet, ist EPIC (Explicit Parallel Instruction Computing). EPIC basiert auf dem VLIW Very-Long-Instruction-Word-Prinzip. Hierbei wird ein relativ breites Befehlswort in mehrere Teilworte unterteilt, die einzelne unabhängige Instruktionen enthalten. Die CPU liest das lange Befehlswort und leitet die darin enthaltenen Instruktionen an voneinander unabhängige Ausführungseinheiten weiter. Die Entscheidung, welche Instruktionen wirklich unabhängig sind, muss dann allerdings der Compiler treffen.

Gewiss bringt Intel® mit IA64 etwas mehr, als nur den Ball den Compiler-Herstellern zuzuspielen. Neben der zuvor erwähnten Registerrotation, die letztendlich einer Optimierung der parallelen Abarbeitung dient, wartet Itanium® mit einer Reihe von Features auf, die die problematischen Charakteristika der IA32-Architektur umgehen sollten. So lässt man beispielsweise den Itanium® Programmsprünge erahnen oder man versucht sie gar mittels sog. Predicating gänzlich zu umgehen. Ein sehr häufig bemühtes Beispiel fürs Predicating ist ein „if-else“-Block, der die bekanntermassen problematischen bedingten Sprünge impliziert. Hier lässt man zwei Recheneinheiten parallel beide Eventualitäten berechnen und trägt zum Schluss nur das Zutreffende in das entsprechende Register ein (!). Aber auch diese Möglichkeit muss der Compiler erkennen, wodurch wir noch einmal das Prinzip der IA64-Architektur vor Augen geführt bekommen.

Fallstudie: Warum Shadowing anstatt z.B. Clustering?

Bei immer mehr Unternehmen spielt der Caché-Server, der als Basis-Datenbankserver in transObjects® Anwendung findet, eine zunehmend entscheidende Rolle; man kann mittlerweile gut und gerne sagen, alles steht und fällt mit Caché. Überlegung zu Steigerung der Verfügbarkeit dieser zentralen Serverinstanz, wie etwa in WhitePaper341 aufgezeigt, gewinnen daher immer mehr an Bedeutung.

Doch im Gegensatz zu dem in WhitePaper341 diskutierten Clustering kam das Shadowing in den letzten Jahren weitaus häufiger zum Zuge. Was das Grundprinzip – und vielleicht das Geheimnis des Erfolges – von Shadowing ist sowie diverse Fragen rund um den im transObjects® Datacenter etablierten Shadowing-Service sollte der vorliegende Artikel klären.

Shadowing (zu Deutsch Schatten-Kopien bzw. -Kopieren) ist ein Spezialfall des in faq.id=28 erörterten verteilten Datenbanksystems (DDS). Das Wesen des Shadowing besteht in einem sukzessiven Replizieren der Datenbankdateien auf einen anderswo etablierten Datenbankserver und zwar im Sinne einer Backup-Vorrichtung. Das nachfolgend noch einmal angeführte DDS-Schema aus faq.id=28 behält zwar grundsätzlich seine Gültigkeit, jedoch ist hier einer der beiden Standorte bzw. Nodes (z.B. „A“) in einer Art Wartestellung und der Datenaustausch mit Clients findet grundsätzlich nicht statt – höchstens im Sinne von Controlling-Aufgaben.

Ist nun der Hauptnode (in unserem Beispiel Standort „E“) aus welchem Grund auch immer indisponiert, muss an die Backup-Instanz, die ja aufgrund von Replikation denselben Datenbestand enthält, angedockt werden. Das bedeutet, dass alle Clients, die bis dato am Hauptnode „hingen“, entsprechend „verbogen“ werden müssen und zwar so, dass sie fortan nur mit der Backup-Instanz ihre Daten austauschen. Diese Massnahme kann mehr oder minder automatisch erfolgen, ist aber normalerweise etwas für den SysOp, der dieses Failover-Szenario ganz bewusst durchzuspielen hat, am besten anhand einer Checkliste.

An dieser Stelle zeigt sich schon mal der erste Unterschied zum Clustering: eine Failback-Funktion gibt es beim Shadowing nicht, jedenfalls nicht automatisch. Denn wurde in einem Shadowing-DDS ein Failover einmal durchgeführt, kann ein Failback, d.h. eine Reaktivierung des Hauptnodes und dessen Versorgung mit aktuellen Daten, nur manuell durchgeführt werden. Dennoch hat dieser unbestreitbare Vorteil des Clustering nicht sehr viele davon abgehalten, gerade auf das Shadowing zu setzen. Warum?

Ein Failover-Cluster kann seine automatische Failover/Failback-Funktion nur dann ausüben, wenn die Datasets des Caché-Servers auf einem von allen Nodes aus zugänglichem Laufwerk, sog. Shared-Storage, gespeichert werden. Da dieses Shared-Storage (SAN: storage area network, NAS: network attached storage) per se nicht clusterbar ist, muss es ganz anderen Sicherheitsanforderungen genügen als die Hardware jedes einzelnen Nodes. Das führt nicht selten dazu, dass ein adäquates SAN oder NAS 5-stellige Kosten verursacht und da vertrauen viele Anwender lieber auf eine vollwertige Kopie ihrer Daten auf einem anderen Server (evtl. an einem anderen Standort), als auf eine einzelne Kopie auf einem noch so guten SAN oder NAS. Schliesslich kommt noch ein nicht unwichtiger Faktor hinzu und das sind die Kosten entsprechender Betriebssystem-Lizenzen, die im Falle eines Windows® 2000/2003-Clusters entsprechend hoch ausfallen (erforderlich ist eine Windows® 2000/ 2003 Server Enterprise- oder Datacenter-Edition auf jedem Clusternode!) während ein DDS diese speziellen Betriebssystem-Editions nicht benötigt. *) **)

Soweit so gut. Die Frage, die uns sehr häufig gestellt wird, lautet meistens – etwa im Zusammenhang mit dem Shadowing übers transObjects®-Datacenter – folgendermassen: Wozu brauche ich das? Ich mache doch jeden Tag Datensicherungen! Nun, die Realität ist wie so häufig etwas anders, wie das nachfolgende Beispiel verdeutlicht.

Ein kleines Unternehmen aus der Schweiz wendet transObjects®-Applikationen nur für den Bereich Warenabfertigung an. Am Donnerstag-Abend crasht der Datenträger-Controller des Caché-Servers. Der Hersteller verspricht Ersatz erst Anfang kommender Woche, also nichts wie ran ans Aufsetzen des Caché-Servers auf einer anderen Hardware. Dann nehmen wir die Datensicherungsbänder und … uff, Datenbanken (Datasets) lassen sich wiederherstellen… aber: Der Datenbestand ist von vor 24 Stunden! „Wo bleiben denn die Zolldeklarationen von heute?“

Anschliessend gibt es Probleme über Probleme mit beiden Zollbehörden wg. Doppelverzollungen etc. bis dann in ein paar Wochen der alte Datenbestand rekonstruiert werden kann… um anschliessend wieder mal logische Widersprüche zu den Vorgängen unmittelbar nach dem Crash zu verursachen… Es war Nerven- und Kapital-aufreibend. Der Kunde bestellt schlussendlich den Shadowing-Service via transObjects®-Datacenter – shade nur, dass erst jetzt, nachdem der Schaden eingetreten ist…
________________________________________

*) Sowohl fürs Clustering als auch fürs Shadowing ist eine Multiserver-Lizenz des Caché-Servers erforderlich. Diese kostet ca. 50% Aufschlag auf den Lizenzpreis (je nach Edition), gilt dafür aber für beliebig viele Cluster- bzw. DDS-Nodes.
**) Bei einem Shadowing via transObjects® Datacenter ist eine Multiserver-Lizenz des Caché-Servers nicht erforderlich. Erhoben wird lediglich eine monatliche Shadowing-Gebühr, die sich nach der Größe des Servers richtet.
ItaniumDDS
DDS-Schema mit zwei Standorten – im Beispiel: Hewlett Packard 64-Bit (Itanium) Integrity – Reihe, mit Superdome-Servern in den RX2600’er Workstations.

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.

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.