Fehlertoleranz mobiler Agenten Von der Fakultät Informatik der Universität Stuttgart zur Erlangung der Würde eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigte Abhandlung Vorgelegt von Markus Straßer aus Urach, jetzt Bad Urach Hauptberichter: Prof. Dr. rer. nat. Dr. h. c. Kurt Rothermel Mitberichter: Prof. Dr.-Ing. habil. Bernhard Mitschang Tag der mündlichen Prüfung: 19. 11. 2002 Institut für Parallele und Verteilte Systeme (IPVS) der Universität Stuttgart 2003 Danksagung Mein besonderer Dank gilt meinem Doktorvater, Prof. Dr. Kurt Rothermel, der mich durch seine Bereitschaft zu Diskussionen und seine Denk- und Motivationsanstöße sehr konstruktiv bei der Durchführung meines Forschungsvorhabens unterstützt und betreut hat. Ebenfalls sehr herzlich bedanken möchte ich mich bei meinem Zweitbetreuer, Prof. Dr. Bern- hard Mitschang, für die Bereitschaft, als Mitberichter zur Verfügung zu stehen und für alle ge- führten Diskussionen und Tips, die er mir gegeben hat. Einen sehr positiven Einfluß auf das Gelingen dieser Arbeit hatten neben meinem langjährigen Büro- und Teamkollegen Wolfgang Theilmann insbesondere auch die anderen Mitglieder des Mole-Teams, Joachim Baumann, Fritz Hohl und Markus Schwehm. Ohne die vielen, konstruk- tiven Diskussionen und die Motivation, die sich aus der Gruppe heraus entwickelte, wäre der Weg zum Ziel wesentlich steiniger gewesen. Ein herzliches Dankeschön, auch für das Korrek- turlesen dieser Arbeit! Ebenfalls sehr hilfreich, interessant und angenehm war die Zusammenarbeit mit vielen Studen- ten, die in unserem Team ihre Studien- und Diplomarbeiten durchführten. Schließlich will ich mich auch bei den restlichen Kollegen der Abteilung Verteilte Systeme für die gute, hilfreiche und sehr humorvolle Zusammenarbeit und für viele nützliche Diskussionen bedanken. Meinem derzeitigen Kollegen Carl Mayer danke ich für das Korrekturlesen der englischen Zu- sammenfassung. Zu guter letzt möchte ich mich bei denen bedanken, ohne die diese Arbeit gar nicht möglich ge- wesen wäre: meinen Eltern. Sie waren immer für mich da, haben mir den Rücken gestärkt und haben trotz des für sie sehr trockenen Themas diese Arbeit Korrektur gelesen. Markus Straßer 5Kurzfassung Mobile Agenten sind Programme, die sich zur Ausführung ihrer Aufgabe autonom zwischen Ausführungsumgebungen in einem Rechnernetz bewegen können, um die jeweiligen lokalen Ressourcen der Rechner zu nutzen. Neben Lösungen im Bereich der Sicherheit und der Kon- trolle mobiler Agenten ist die Zuverlässigkeit der Ausführung von mobilen Agenten eine der Grundvoraussetzungen für die breite Anwendung dieser Technologie. Die vorliegende Arbeit erarbeitet Lösungen für die zuverlässige Ausführung mobiler Agenten und das zuverlässige, partielle Rücksetzen der Agentenausführung. Um den Ausfall von Rechnern, auf denen ein Agent einen Teil seiner Aufgabe ausführen möch- te, einfacher tolerieren zu können ist es vorteilhaft, wenn dem Agenten Alternativen zur Aus- wahl stehen. Als Basisbaustein für die fehlertolerante Ausführung wird daher ein flexibles Rei- seroutenkonzept entwickelt. Dieses Konzept erlaubt nicht nur die Spezifikation alternativer Ausführungsrechner sondern erlaubt auch, die einer Anwendung inhärenten Alternativen der Ausführungsreihenfolge der einzelnen Aufgabenteile offenzulegen. Für die fehlertolerante Ausführung werden zwei Mechanismen entwickelt. Der Basismechanis- mus stellt die genau-einmal Ausführung eines Agenten durch transaktionale Ausführung des Agenten sicher. Die blockierungsfreie Ausführung von Agenten wird durch eine Erweiterung dieses Basismechanismus sichergestellt, bei der die Ausführung des Agenten durch mehrere Rechner überwacht und im Fehlerfalle weitergeführt wird. Die Korrektheit der Mechanismen wird in einem informalen Beweis nachgewiesen und eine analytische Bewertung der Mechanis- men durchgeführt. Da für das partielle Rücksetzen der Agentenausführung ein einfaches Rücksetzen auf einen al- ten Zustand nicht ausreicht, kommen hierfür Kompensationsoperationen zum Einsatz. Die zu- verlässige Ausführung der Kompensation wird durch transaktionale Ausführung sichergestellt. Um den Anwendungsentwickler möglichst stark zu entlasten, werden die Daten des Agenten in zwei unterschiedliche Klassen aufgeteilt. Ein Teil der Daten des Agenten kann von der Ausfüh- rungsumgebung durch eine Kopie des alten Zustandes zurückgesetzt werden. Für den anderen Teil der Agentendaten und für die Ressourcen müssen Kompensationsoperationen zur Verfü- gung gestellt werden. Eine Klassifizierung der Kompensationsoperationen erlaubt Optimierun- gen bei der Kompensation. 6 7Fault-Tolerance of Mobile Agents Extended english abstract of the dissertation “Fehlertoleranz mobiler Agenten” 1 Introduction The current, rapid development of the information society comes along with the opening of the Internet to the broad masses. The increase of the Internet size and capacity during the last decade has been extraordinary and has been seconded only by the even vaster increase of Internet users. New developments in the area of consumer electronics provide easy access to the Internet (e.g. by using web pads) or allow the mobile access to the net. Additionally, the number and variety of services provided via Internet increases permanently. This development results in several problems and new challenges, for example the permanent overload of the Internet or the mobile Internet access using unstable GSM connections with low bandwidth. A technology to solve several of these problems has been introduced in the early 1990s: mobile agents. Mobile agents are programs, which autonomously execute a task on behalf of their own- er. While executing their task, mobile agents are able to move within a network of computers, i.e. they are able to shift their program execution from one computer to another (migration). This enables an agent to efficiently access resources locally instead of accessing these resources us- ing global communication. An example illustrates this: An agent has to search some specific in- formation in a huge database using a sophisticated information retrieval algorithm. Since the da- tabase allows only simple searches, the agent has to read most of the database to finally find the required information. If the database is not local to the agents execution environment, all the in- formation has to be transferred to the agent. However, if the agent is able to migrate to the da- tabase, only the agent (i.e. its program code and execution state) and the result has to be trans- ferred over the network. Depending on the agent size and the size of the result, this may be a considerable smaller amount of data which has to be transferred over the network. Although the technology of mobile agents seems to be promising for several application areas, it is not used wide-spread up to now. One of the main reasons is, that some of the topics which are very important for the commercial use of mobile agents – control mechanisms, security and fault-tolerance – are still subject to research. This thesis deals with the fault-tolerance of mobile agents. The following scenario from the area of electronic commerce outlines the importance of fault-tolerance in the area of mobile agents: A concierge agent has the task to organize a busi- ness trip. It first travels to the server of the airline and books the flight. Afterwards, it reserves a car and the hotel on the respective servers and sends the result to the user. Since the agent moves autonomously, the user can not directly monitor the agents actions. Therefore, it is im- possible for the user to detect that the agent has been lost or blocked due to a system failure. Furthermore, it is not acceptable that the agent executes only a part of its task or that it executes 8some parts more than once (e.g. books two flights). For reliable execution, it has to be ensured that the agent executes its task exactly-once as fast as possible without being blocked even in the presence of system failures. Currently available mobile agent platforms do not cover these requirements. Based on a realistic system and error model, this thesis develops an algorithm which ensures exactly-once execution of an agents task and prevents the agent from being blocked by system failures. As a prerequisite to this algorithm, an itinerary concept is developed which allows to specify the application-inherent alternatives regarding the execution order of the sub-tasks of an agent as well as the possible alternatives regarding the computers where the sub-tasks have to be executed. Finally, based on the mechanism for the exactly-once execution of mobile agents, a mechanism is developed which allows the partial rollback of an agents execution. 2 Mobile agents As defined by WHITE (1997), mobile agents are programs autonomously executing a task on be- half of their owner. In order to do this, they can move between execution environments (or hosts, also called places), use the resources offered by these environments and communicate with oth- er agents. For the mechanisms in the following sections, a more detailed model of mobile agents is neces- sary: The task of an agent consists of several sub-tasks which are executed sequential. A sub- task is also called a step. A step can be executed several times during an agents lifetime, e.g. the step queryPriceList has to be executed in several shops before the shopping agent buys some goods at the cheapest shop. Each step is executed entirely inside one execution environment. Several (not necessarily consecutive) steps may be executed in the same execution environment (place). During the execution of a step, the agent can access the resources and services offered by the place. On each physical host exists at most one execution environment for mobile agents. Migration between places is performed using weak migration, i.e. only the agents program code and data state (global variables) but not the execution state (stack, local variables) are trans- ferred to the target place (see CUGOLA ET AL. (1996)). Agents have a globally unique name which is non-mutable during the agents execution. Mobile agents can not communicate to other mobile agents and are not able to start new mobile agents (these last two restrictions are neces- sary for the mechanisms developed in the next sections). 3 Itineraries While performing a job, a mobile agent often has to visit several places to access local services. In many cases, some (or all) of these places are either known before agent initialization or can be determined by the agent several steps in advance. However, as in real life, there is no strict order in which the places have to be visited. For example, an agent having to order a CD and a theatre ticket, may perform these tasks in any sequence. Furthermore, if there are several branches of a music shop, the agent needs to visit only one of these branches. If this freedom in 9an agents travel plan is made visible to the mobile agent system, this can be exploited in different ways. One possibility is, that the agent system may calculate the shortest possible path for the agent. Another, more important possibility is that this information may be used to increase the level of fault-tolerance in the system. If the system can choose between several places which the agent can visit and one of these places is currently unavailable, it is able to postpone the visit of this place automatically or may choose an alternative place instead. To clarify this, let us consider the following scenario: Paul, planning to spend a romantic evening with his wife, instructs his personal concierge agent to order some flowers, to buy a ticket for the theatre and to make a reservation for a table in a nice restaurant close to the theatre. The play for which the agent has to buy tickets is currently enacted in two different theatres. To fulfil the job, the agent has to visit the place of the flower service, one of the two places offering the ticket service for the respective theatre (unfortunately, there is no central ticket service for both theatres), and, depending on the chosen theatre, the place of the restaurant. An itinerary for this example has to specify, that, besides ordering the flowers in a flower shop, the agent has to visit one of the two places offering the ticket service and, afterwards, the respective place of the restaurant. The tree in figure 3-1 shows all possible paths that can be taken by Paul’s agent. The path, where the agent first orders the flowers, then buys a ticket in the ModernArts theatre and finally makes a reservation for a table at the BeefHouse is marked bold. The tree shows, that in each step ex- cept the last one there is more than one possible target for the agent to be transferred to. If, for example, the agent has started by ordering the flowers, the system may chose to transfer the agent to the CentralTheatre or the ModernArts place alternatively. Therefore, the agent may pro- ceed even if one of those two places is unavailable. In the thesis, two itinerary concepts provid- ing the necessary flexibility are developed. The more flexible of the developed concepts allows to define itineraries by specifying preconditions which have to be fulfilled in order to execute a step and it supports the nesting of itineraries. A detailed description of those concepts can be found in STRASSER UND ROTHERMEL (1998). Figure 3-1. Tree of possible paths of the concierge agent. FlowerLand CentralTheatre ModernArts KingsInn BeefHouse CentralTheatre ModernArts KingsInn BeefHouse FlowerLand FlowerLand FlowerLand KingsInn BeefHouseFlowerLand 10 4 Exactly-once execution In this section, two algorithms for the exactly-once execution are developed based on the system model, the failure model and the definition for exactly-one execution of mobile agents given at the beginning of the section. The algorithms described in this chapter have already been published in ROTHERMEL UND STRASSER (1998), STRASSER UND ROTHERMEL (1998) and STRASSER, ROTHERMEL UND MAIHÖFER (1998). 4.1 System model and failure model This section defines the system and failure model used in the thesis. The system model describes the relevant parts of a system. A distributed system consists of several places (execution envi- ronments) which are interconnected by a network. A place consists of a processor and private volatile and stable storage. A program is executed within a process, concurrent threads within a process are possible. To manage timeouts, each place has a correct clock. Communication be- tween places is performed by message exchange using communication channels. There is a communication channel between each pair of processes. The system is asynchronous (no upper time limit for the execution of commands or for message transmission). The failure model defines the possible failures in the system. Places only suffer from crash fail- ures. If a place crashes, all programs on the place stop executing – the crash of a (real) subset of the processes is not possible. All information in the volatile storage (execution state of the proc- esses) is lost in case of a crash, information stored on stable storage is not lost. The stable storage and communication between processes in a place are error-free. The network also suffers from crash failures, failures always result in network partitions. Places within a network partition can communicate, places in different partitions can not. Communication within a partition is error- free. Since the system is asynchronous, place failures and network failures can not be distin- guished. Crashes are only temporary and the crashed component (place/network) is available again after restart/repair. 4.2 Definition “exactly-once execution” The exactly-once property has already been defined for RPC systems by SPECTOR (1982), where he defines the failure semantics of a single remote procedure. However, in the context of mobile agents, a sequence of agent steps is to be considered rather than a single procedure. Therefore, the definition of the exactly-once property of mobile agents is based on the informa- tion contained in the agent’s itinerary and on the steps to be performed at the visited places. Let P={P1,...,Pn} be the set of all possible paths the agent may take for a given itinerary, let L(Pi) be the number of places in path Pi=[Ni,1,Ni,2,...,Ni,L(Pi)] and let Si,j be the step to be performed 11on the j-th place Ni,j of path Pi (1≤i≤n, 1≤j≤L(Pi)). Then the execution of an agent is defined to be exactly-once iff • only places Ni,1,...,Ni,L(Pi) belonging to one path Pi∈P are visited, • the agent executes step Si,j before step Si,j+1, 1≤j spezifiziert, daß genau einer der Einträge e1, ..., en ausgewählt wer- den muß. Das folgende Szenario soll helfen, diese Definition besser zu verstehen: Paul plant, einen ro- mantischen Abend mit seiner Freundin zu verbringen. Hierzu beauftragt er seinen persönlichen Butler-Agenten, Blumen zu bestellen, eine Eintrittskarte für den aktuell in zwei Kinos der Stadt 3.1 Ein einfaches Reiseroutenkonzept 43laufenden Liebesfilm zu kaufen und einen Tisch in einem dem Kino nahegelegenen Restaurant zu reservieren. Um den Auftrag auszuführen, muß der Agent den Fleurop-Rechner besuchen, weiterhin einen der beiden für die jeweiligen Kinos zuständigen Rechner und schließlich den Knoten jenes Restaurants, das dem tatsächlich gewählten Kino näher ist. Die nachfolgend mit Hilfe der oben definierten Notation dargestellte Reiseroute i (von engl.: iti- nerary) spezifiziert den Reiseplan des Butler-Agenten: i = {(Fleurop, kaufeBlumen), <[ (Luna, kaufeEintrittskarte), (Rößle, reserviereTisch) ], [ (Planie, kaufeEintrittskarte), (Linde, reserviereTisch) ] > }. Eine graphische Repräsentation der Reiseroute zeigt Abbildung 3-1. Auf oberster Ebene spezi- fiziert ein Menge-Eintrag, daß der Agent auf dem Knoten “Fleurop” mittels der Methode “kau- feBlumen” Blumen einkaufen soll und daß der spezifizierte Alternative-Eintrag ausgeführt wer- den muß. Hierbei kann er zuerst die Blumen kaufen und dann den Alternative-Eintrag ausführen oder umgekehrt. Die Alternative spezifiziert zwei Möglichkeiten, die Eintrittskarte zu kaufen und einen Tisch zu reservieren. Jede dieser Möglichkeiten ist mittels einer Sequenz spezifiziert, in der festgelegt wird, daß zuerst das Ticket gekauft und anschließend im dazu passenden Re- staurant ein Tisch reserviert wird. Die Sequenz ist hierbei notwendig, da der Agent die zur Re- servierung notwendige Uhrzeit (“wann endet der Film?”) erst beim Kauf der Eintrittskarte er- fährt. Anhand dieser Reiseroute kann das System bestimmen, welche Knoten der Agent als nächstes besuchen kann. Für den ersten Schritt stehen hier entweder der Blumenladen oder eines der bei- den Kinos zur Auswahl. Der zweite und die darauffolgenden Schritte hängen jeweils von der Wahl der vorhergehenden Schritte ab. Anhand der in einer Reiseroute enthaltenen Informatio- nen kann ein Baum erstellt werden, welcher alle möglichen Ausführungspfade des Agenten ent- Abbildung 3-1. Reiseroute des Butler-Agenten Menge (Fleurop, kaufeBlumen) (Luna, kaufeEintrittskarte) (Planie, kaufeEintrittskarte) (Rößle, reserviereTisch) (Linde, reserviereTisch) Alternative Sequenz 44 Kapitel 3 Reiseroutenhält. Der Baum in Abbildung 3-2 zeigt alle möglichen Ausführungspfade von Pauls Agent. Der Pfad, bei dem der Agent zuerst Blumen kauft, danach Karten für die Planie kauft und einen Tisch in der Linde reserviert ist in der Abbildung hervorgehoben. Die Reiseroute stellt Abfrage- und Änderungsoperationen zur Verfügung. Die Abfrageoperatio- nen erlauben die Navigation durch die Einträge einer Reiseroute, ermöglichen abzufragen, wel- che Einträge schon abgearbeitet wurden und welche Knoten als nächstes besucht werden kön- nen. Die Änderungsoperationen erlauben das Einfügen und Löschen von Einträgen in jene Teile der Reiseroute, welche noch nicht abgearbeitet wurden. Dies erlaubt dem Agent einerseits, ei- nen Überblick über seine bisherige Ausführung zu gewinnen und andererseits, seine Reiseroute während der Ausführung dynamisch an die jeweiligen Gegebenheiten anzupassen. 3.2 Ein flexibleres Reiseroutenkonzept Obwohl das im vorherigen Unterkapitel vorgestellte Reiseroutenkonzept schon ein recht mäch- tiges Werkzeug zur Spezifikation von Reiseplänen bereitstellt, bietet es doch nur eingeschränkte Flexibilität sowohl hinsichtlich der Mächtigkeit der Definitionsmöglichkeiten bei der Erstellung der Reiseroute als auch hinsichtlich der sich aus einer Reiseroute ergebenden Wahlmöglichkei- ten während der Ausführung. Die folgenden Ausführungsreihenfolgebeziehungen können bei- spielsweise nicht (oder nur mit sehr viel Aufwand) mittels dieses Konzeptes spezifiziert werden: • Knoten Ni muß vor Knoten Nj besucht werden, dazwischen dürfen jedoch beliebige andere Knoten besucht werden. Im Beispiel aus dem letzten Unterkapitel ist beispielsweise die An- gabe, daß der Blumenladen auch zwischen dem Kauf der Eintrittskarte und dem Reservieren des Tisches besucht werden kann, nur schwerlich zu spezifizieren. • Prioritäten zwischen Einträgen (z.B. das Kino Planie gegenüber dem Luna bevorzugen). • Mindestens i Knoten aus einer Menge von j Knoten (j≥i) besuchen bevor man einen anderen Knoten besucht (z.B. vor einem Einkauf mindestens i Angebote einholen). • Den Besuch eines Knotens vom Zustand des Agenten abhängig machen, z.B. einen Knoten nur dann besuchen, wenn noch nicht genügend Informationen gesammelt wurden. Abbildung 3-2. Baum der möglichen Pfade des Butler-Agenten Fleurop Rößle Linde Luna Planie Luna Planie Rößle Fleurop FleuropLinde 3.2 Ein flexibleres Reiseroutenkonzept 45Das in diesem Unterkapitel vorgestellte, sehr flexible Reiseroutenkonzept hingegen unterstützt die Spezifikation solcher Reihenfolgebeziehungen beinahe vollständig. Lediglich die Einfüh- rung von Reihenfolgebeziehungen basierend auf dem Zustand des Agenten wird aus semanti- schen Gründen nicht unterstützt werden. Eine Implementierung des Reiseroutenkonzeptes und dessen Integration in das Agentensystem Mole (BAUMANN ET AL. (1998A)) findet man in BUSCHLE (1999). 3.2.1 Die flache Reiseroute Die Grundidee für das flexible Reiseroutenkonzept basiert auf der Beobachtung, daß die beim einfachen Reiseroutenkonzept mittels Sequenz und Alternative spezifizierten Reihenfolgebezie- hungen aus der Sicht eines einzelnen Schritteintrages implizit aussagen, welche Bedingungen für die Ausführung des Schrittes erfüllt sein müssen. Die Sequenzen der Reiseroute aus Ab- schnitt 3.1 spezifizieren beispielsweise, daß vor der Reservierung eines Tisches zuerst die Ein- trittskarte gekauft werden muß (d.h. der Schritt kaufeEintrittskarte muß auf dem Kino-Knoten ausgeführt worden sein). Die Alternative spezifiziert, daß der Kauf einer Eintrittskarte beim Luna-Theater nur erfolgen darf, wenn beim Planie-Theater noch keine Karte gekauft wurde (und umgekehrt). In dem flexiblen Reiseroutenkonzept wird daher der Ansatz gewählt, daß für jeden Eintrag einer Reiseroute explizit eine (boolesche) Bedingung spezifiziert wird. Nur wenn diese (Vor-)Bedingung wahr wird, kann der Eintrag ausgeführt werden. Zusätzlich wird die Spe- zifikation von Präferenzen zwischen Einträgen ermöglicht. Definition 3-1: Reiseroute ℜ Eine Reiseroute ℜ=(E, P) besteht aus einer Menge E={e1, e2, ..., en} von Reiserou- teneinträgen und einer Prioritätsrelation P ⊂ ExE zwischen diesen Einträgen. Definition 3-2: Reiserouteneintrag e Ein (Reiserouten-)Eintrag e ist ein Tripel (Vorbedingung, Knoten, Methode). Das Tripel spezifiziert, daß der Agent zu Knoten migrieren und die durch Methode im- plementierte Teilaufgabe ausführen kann (kurz: den Eintrag ausführen), falls die Vorbedingung zur Migrationszeit erfüllt ist und der Eintrag noch nicht ausgeführt wurde. Um nach der Durchführung eines Schrittes (oder zu Beginn der Ausführung des Agenten) den nächsten auszuführenden Schritt zu bestimmen, werden die Vorbedingungen der noch nicht aus- geführten Reiserouteneinträge ausgewertet und unter Berücksichtigung der Prioritätsrelation P wird einer der Einträge ausgewählt, dessen Vorbedingung zu wahr ausgewertet wurde. Wird keine der ausgewerteten Vorbedingungen wahr, ist die Bearbeitung des Agenten beendet. Im fehlerfreien Fall wird jeder Eintrag höchstens einmal ausgeführt. 46 Kapitel 3 ReiseroutenVorbedingung(e) bezeichnet die Vorbedingung eines Eintrages e. Eine Vorbedingung, welche ein boolescher Ausdruck p(e1, e2, ..., en) ist, wird als erfüllt bezeichnet, wenn sie zur Migrati- onszeit zu wahr ausgewertet werden kann. Hat ein Eintrag die triviale Vorbedingung wahr, dann bedeutet dies, daß er jederzeit ausgeführt werden kann. Ein Eintrag kann die triviale Vorbedin- gung falsch haben, wird dann aber nie ausgeführt (und ist deshalb sinnlos). Um sich in der Vor- bedingung auf andere Einträge der Reiseroute zu beziehen, wird das Prädikat D(e) (von engl.: done) verwendet. Eine vorläufige Definition von D(e) ist gegeben durch Definition 3-3: Prädikat D(e) D(e)≡wahr ⇔ Eintrag e wurde schon ausgeführt Prioritäten zwischen Einträgen einer Reiseroute werden durch die Prioritätsrelation P spezifi- ziert: Definition 3-4: Prioritätsrelation P ⊂ SxS (ei, ej)∈P ⇔ Eintrag ei hat höhere Priorität als Eintrag ej Die Priorität (ei, ej)∈P zwischen zwei Einträgen ei und ej spezifiziert nur, daß, falls die beiden Einträge zu einem Zeitpunkt alternativ ausgeführt werden können (d.h. die Vorbedingungen der beiden Einträge sind erfüllt und beide Einträge wurden noch nicht ausgeführt), die Ausführung des Eintrages ei bevorzugt wird. Ist die Ausführung von ei aus technischen Gründen nicht mög- lich (z.B. da der durch ei spezifizierte Ausführungsknoten nicht erreichbar ist) oder ist die Vor- bedingung von ei nicht erfüllt, kann ej ausgeführt werden falls dessen Vorbedingung erfüllt ist. Aus Konsistenzgründen darf die Relation P keine Zyklen (z.B. (ei,ej), (ej,ek), ..., (el,em), (em,ei)) enthalten. Das folgende Beispiel illustriert die durch die bisher beschriebenen Teile des Konzept gegebe- nen Möglichkeiten: Beispiel 3-1. Reiseroute ℜ=({e1, e2, e3, e4, e5}, P) für das Szenario aus Abschnitt 3.1: e1 = (wahr, Fleurop, kaufeBlumen) e2 = (¬D(e4), Luna, kaufeEintrittskarte) e3 = (D(e2), Rößle, reserviereTisch) e4 = (¬D(e2), Planie, kaufeEintrittskarte) e5 = (D(e4), Linde, reserviereTisch) P = {(e2, e4)} Die hiermit spezifizierte Reiseroute ist flexibler als die in Abschnitt 3.1 spezifizierte Rei- seroute, da bei dieser Definition der Einkauf der Blumen jederzeit möglich ist, und da- durch während der Ausführung des Agenten bei der Auswahl des nächsten durchzufüh- renden Schrittes im Durchschnitt mehr Alternativen zur Verfügung stehen als bei der einfachen Reiseroute. Die Bevorzugung der Kombination Luna/Rößle gegenüber der 3.2 Ein flexibleres Reiseroutenkonzept 47Kombination Planie/Linde stellt zumindest hinsichtlich der Fehlertoleranz keine (wesent- liche) Einschränkung der Flexibilität dar, da sie nur in dem Fall eine Rolle spielt, wenn beide Kino-Knoten verfügbar sind. Der Anwender erhält damit jedoch die zusätzliche Möglichkeit, seine Präferenzen zwischen Alternativen auszudrücken. Die Möglichkeit, jederzeit Blumen zu kaufen, ergibt sich daraus, daß der Eintrag e1, welcher das Kaufen der Blumen spezifiziert, die triviale Vorbedingung wahr hat und die anderen Einträge in keiner Weise von ihm abhängen. Die Einträge e2 und e4 beschreiben das Kaufen der Ein- trittskarte, wobei die Vorbedingungen sicherstellen, daß nur einer der Einträge ausgeführt werden kann: e2 kann nur ausgeführt werden, falls e4 (noch) nicht ausgeführt wurde (aus- gedrückt durch ¬D(e4)) und umgekehrt. Die Vorbedingungen e3 und e5 der Schritte zum Reservieren des Tisches stellen sicher, daß in einem der Restaurants nur dann reserviert wird, wenn im entsprechenden Kino die Karte gekauft wurde: Z.B. garantiert die Vorbe- dingung D(e2) von e3, daß nur dann im Rößle ein Tisch reserviert wird, falls in e2 im Luna die Eintrittskarte gekauft wurde. Die Bevorzugung der Kombination Luna/Rößle ergibt sich aus der Spezifikation der Prioritätsrelation P. Um die Semantik der in Abschnitt 3.1 spezifizierten Reiseroute zu erhalten, muß die Spe- zifikation der Prioritätsrelation in P=∅ geändert werden und die Vorbedingung von e1 we- sentlich komplexer ausfallen: e1 = ( (¬D(e2) ∧ ¬D(e4)) ∨ (D(e3) ∨ D(e5)), Fleurop, kaufeBlumen) Hiermit wird spezifiziert, daß die Blumen entweder vor dem Kauf der Eintrittskarten (¬D(e2) ∧ ¬D(e4), d.h. in keinem der Kinos darf eine Karte gekauft worden sein) oder nach der Reservierung des Tisches (D(e3) ∨ D(e5), d.h. in einem der Restaurants muß ein Tisch reserviert worden sein) gekauft werden müssen. Mit den bisher vorgestellten, recht einfachen Mitteln ist es sogar möglich zu spezifizieren, daß i Einträge aus einer Menge von j Einträgen e1, ..., ej (i≤j) ausgeführt werden müssen. Hierbei werden jedoch die Vorbedingungen der Einträge sehr komplex, solange nur das Prädikat D(e) verwendet werden kann: Beispiel 3-2. Ein Agent soll von zwei Anbietern je ein Angebot für einen Artikel einholen. Es stehen insgesamt 4 Anbieter zur Verfügung. Der Eintrag ek beschreibt das Abholen ei- nes Angebotes von Anbieter k auf dessen Knoten nk (k = 1...4): e1 = ( ¬((D(e2) ∧ (D(e3) ∨ D(e4))) ∨ (D(e3) ∧ D(e4))), n1, holeAngebot) e2 = ( ¬((D(e1) ∧ (D(e3) ∨ D(e4))) ∨ (D(e3) ∧ D(e4))), n2, holeAngebot) e3 und e4 analog Sollen hierbei Anbieter bevorzugt werden, dann kann dies zusätzlich mittels Prioritäten ge- schehen. 48 Kapitel 3 ReiseroutenOffensichtlich werden die Vorbedingungen für größere Mengen von Einträgen wesentlich kom- plexer. Aus diesem Grunde werden in den Vorbedingungen zusätzlich boolesche Terme der Form (Zahl Vergleichsoperator Ausdruck) zugelassen. Ein Ausdruck ist eine Summe in der Form d(ea) + d(eb) + ... + d(ez) Die Funktion d(e) ist definiert durch Definition 3-5: Funktion d(e) d: e → {0,1} d(e)≡1 ⇔ D(e)≡wahr Die Vergleichsoperator kann aus der Menge {<, ≤, =, ≥, >} entnommen werden. Wie die zwei folgenden Beispiele zeigen, lassen sich hiermit einfach Beziehungen wie “i Einträge aus j Ein- trägen ausführen” oder “mindestens i Einträge aus j Einträge ausführen bevor ...” spezifizieren. Beispiel 3-3. Analog zum vorherigen Beispiel soll ein Agent von i Anbietern Angebote einholen. Es stehen insgesamt j (i≤j) Anbieter zur Verfügung. Der Eintrag ek beschreibt das Abholen eines Angebotes von Anbieter k auf dessen Knoten nk (k = 1...j): ek = ((i > d(e1)+d(e2)+ ... +d(ej)), nk, holeAngebot) für k = 1 ... j Die Vorbedingungen werden falsch, sobald i Einträge ausgeführt wurden. Beispiel 3-4. Ein Agent soll von j Anbietern Angebote einholen und diese auf seinem Hei- matknoten abliefern. Sind von den j Anbietern momentan nicht alle erreichbar (Knoten- ausfall o.ä.), so kann der Agent auch weniger als j Angebote abliefern, er muß jedoch min- destens i (i≤j) Angebote eingeholt haben. Die Einträge ek, k=1...j beschreiben das Einholen von Angeboten, ej+1 das Abliefern der Angebote: ek = (¬D(ej+1), nk, holeAngebot) für k = 1 ... j ej+1 = ((i ≤ d(e1)+d(e2)+ ... +d(ej)), Heimatknoten, liefereAngeboteAb) P = {(e1, ej+1), (e2, ej+1), ..., (ej, ej+1), } Die Vorbedingung von ej+1 wird wahr, sobald mindestens i Einträge aus e1, ..., ej ausge- führt wurden. Ab diesem Zeitpunkt können die Angebote auf dem Heimatknoten abgelie- fert werden. Die Prioritäten legen jedoch fest, daß das Einholen von Angeboten Vorrang vor dem Abliefern hat, so daß der Agent nur bei Nichtverfügbarkeit eines Anbieter-Kno- tens die Angebote vorzeitig abliefert. Die Vorbedingungen der Einträge e1,..., ej stellen si- cher, daß nach dem Abliefern der Angebote keine neuen Angebote mehr eingeholt wer- den. 3.2 Ein flexibleres Reiseroutenkonzept 49Abbildung 3-3 zeigt eine bis auf die Definition der Syntax von Reiserouteneinträgen vollstän- dige Zusammenfassung der Syntax von Vorbedingungen in Erweiterter Backus-Naur-Form (EBNF): Hiermit werden die am Anfang von Abschnitt 3.2 aufgeführten Anforderungen an die Reiserou- te schon weitestgehend erfüllt. Ausnahme ist die Anforderung, daß der Besuch eines Knotens (im Endeffekt die Ausführung eines Reiserouteneintrages) vom Zustand des Agenten abhängig gemacht werden kann. Diese Anforderung könnte durch die Verwendung anwendungsspezifi- scher Prädikate in den Vorbedingungen der Reiserouteneinträge erfüllt werden. Soll ein Agent beispielsweise einen Eintrag der Reiseroute nur dann ausführen, nachdem er genügend Infor- mation gesammelt hat, dann könnte ein vom Agentenentwickler implementiertes Prädikat hatGenugInformation(...), welches genau dann wahr liefert, sobald genug Informationen im Agent enthalten sind, in der Vorbedingung zu dem betreffenden Eintrag verwendet werden. Es gibt jedoch mehrere Gründe, diesen Typ von Prädikat nicht in das Reiseroutenkonzept zu über- nehmen. Einer der Gründe ist, daß das Reiseroutenkonzept durch solche Prädikate wesentlich komplexer würde: Einerseits würden Reiserouten dadurch schwerer verständlich, da hiermit Entscheidungen, die der Agent selbst aktiv treffen sollte, in die Reiseroute verschoben würden. Andererseits müßten alle diese Prädikate bei jeder Migration neu ausgewertet werden, was bei komplex zu berechnenden Prädikaten sehr viel Mehraufwand für die Ausführung eines Agenten bedeuten würde. Der Hauptgrund gegen die Einführung dieses Typs von Prädikaten wird jedoch erst im Laufe des nächsten Abschnittes klar. Abbildung 3-3. Syntax einer Vorbedingung in EBNF Vorbedingung=( "(" Vorbedingung ")" | "¬" Vorbedingung | Vorbedingung "∧" Vorbedingung | Vorbedingung "∨" Vorbedingung | Lit ). Lit = ( Prädikat | Gleichung | "wahr" | "falsch" ). Prädikat = "D(" Eintrag ")". Gleichung= "(" Zahl Operator Ausdruck ")". Operator = ( "<" | "≤" | "=" | "≥" | ">" ). Ausdruck = ( Ausdruck "+" Ausdruck | Funktion ). Funktion = "d(" Eintrag ")". Zahl = ( “0” | ZifferON { ( "0" | ZifferON ) } ). ZifferON = ( "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ). 50 Kapitel 3 Reiserouten3.2.2 Geschachtelte Reiserouten Ein Nachteil der flachen Reiseroute besteht darin, daß es hiermit nicht möglich ist, eine Menge von Reiserouteneinträgen als eine logische Einheit zu behandeln: Beispiel 3-5. Ein Agent soll von i Anbietern Angebote für ein Produkt in 2 Runden ein- holen. In der ersten Runde wird zuerst von jedem Anbieter ein Angebot eingeholt: ek = (wahr, nk, holeAngebot) für k = 1 ... i Basierend auf dem Ergebnis der ersten Runde wird dann in der zweiten Runde versucht, bessere Angebote auszuhandeln. Die Einträge für die zweite Runde dürfen erst dann aus- geführt werden, wenn die Einträge für die erste Runde komplett ausgeführt wurden: ei+k = (e1 ∧ e2 ∧ ... ∧ ei, nk, verhandleAngebot) für k = 1 ... i Die Reiseroute des Agenten ergibt sich hieraus zu ℜ = ( {e1, e2, ..., e2i}, ∅ ) Dies (oder noch komplexere Szenarien) zu spezifizieren ist nicht nur mühsam und fehleranfäl- lig, es müssen darüberhinaus auch bei jeder Migration die Vorbedingungen zumindest teilweise neu berechnet werden. Kommt im Beispiel noch ein weiterer Anbieter nachträglich hinzu, müs- sen zudem noch alle Vorbedingungen der Einträge für die zweite Runde geändert werden. Um diese Nachteile zu überwinden, wird das Konzept der geschachtelten Reiserouten einge- führt. Geschachtelte Reiserouten erweitern die flachen Reiserouten um die Möglichkeit, zusätz- lich komplette Reiserouten als Einträge in einer Reiseroute zu spezifizieren. Hierdurch ergeben sich für viele komplexe Szenarien wesentliche Vereinfachungen bei der Spezifikation von Rei- serouten. Für jede geschachtelte Reiseroute läßt sich jedoch auch eine flache Reiseroute ange- ben, deren Einträge dann wesentlich komplexere Vorbedingungen enthalten als die Einträge der geschachtelten Reiseroute. Die folgenden Definitionen legen die Struktur geschachtelter Reiserouten und dabei verwendete Begriffe fest: Definition 3-6: Eintrag e einer geschachtelten Reiseroute Ein Eintrag e einer geschachtelten Reiseroute ist entweder ein Basis-Eintrag (B- Eintrag) oder eine Reiserouten-Eintrag (R-Eintrag). Definition 3-7: Basis-Eintrag (B-Eintrag) einer geschachtelten Reiseroute Ein Basis-Eintrag entspricht dem in Definition 3-2 definierten Tripel (Vorbedin- gung, Knoten, Methode). 3.2 Ein flexibleres Reiseroutenkonzept 51Definition 3-8: Reiserouten-Eintrag (R-Eintrag) einer geschachtelten Reiseroute Ein R-Eintrag e ist ein Quadrupel (Vorbedingung, E, P, Typ), welches eine komplet- te (Teil-)Reiseroute beschreibt. E={e1, e2, ..., en} ist die Menge der in dem Reise- routen-Eintrag direkt enthaltenen Einträge; die Einträge e1, e2, ..., en dürfen in kei- nem anderen R-Eintrag direkt enthalten sein. Um mit der Ausführung der in dem R- Eintrag e enthaltenen Einträge (d.h. mit der Ausführung der durch e beschriebenen Reiseroute) zu beginnen, muß die Vorbedingung erfüllt sein. P spezifiziert gemäß Definition 3-4 die Prioritätsrelation zwischen den Einträgen e1, e2, ..., en. Die Defi- nition des Typs eines R-Eintrages erfolgt weiter unten. Definition 3-9: Menge Einträge(e) der in einem R-Eintrag direkt enthaltenen Einträge e = (Vorbedingung, {e1, e2, ..., en}, P, Typ) ⇒ Einträge(e) ≡ {e1, e2, ..., en} Da ein R-Eintrag e eine vollständige Reiseroute spezifiziert, dürfen die Vorbedingungen der di- rekten Einträge von e jeweils nur von den direkten Einträgen von e (d.h. von Einträge(e)) ab- hängen, d.h. Vorbedingung(ei)=pi(e1, e2,..., en) für alle ei ∈ Einträge(e). Definition 3-10: (Geschachtelte) Reiseroute ℜ eines Agenten Die Reiseroute ℜ eines Agenten ist ein Spezialfall eines R-Eintrages mit dem Typ r (“Reiseroute”) und der Vorbedingung wahr: ℜ= (wahr, {e1, e2, ..., en}, P, r) vereinfacht (analog zu Definition 3-1): ℜ= ({e1, e2, ..., en}, P) Eine Reiseroute ℜ bildet einen Baum mit ℜ als Wurzel und den in der Reiseroute enthaltenen B-Einträgen als Blättern. Es ist daher möglich, die bei Bäumen üblichen Bezeichnungen Knoten für R-Einträge, Blätter für B-Einträge, Kinder eines R-Eintrages für die in einem R-Eintrag (di- rekt) enthaltenen Einträge, Nachfahren eines R-Eintrages für die rekursive Hülle der Kinder, Va- ter eines Eintrages für den R-Eintrag, in dem der Eintrag enthalten ist, Vorfahren für alle R-Ein- träge auf dem Weg zur Wurzel und Geschwister eines Eintrages e für die Einträge, die denselben Vater wie e haben, zu verwenden. Das folgende Beispiel verdeutlicht diese Definitionen. Beispiel 3-6. Spezifikation der Reiseroute ℜ aus dem vorherigen Beispiel mittels einer ge- schachtelten Reiseroute. Die B-Einträge ei+1, ..., e2i, welche die Verhandlungsrunde be- schreiben, müssen nach den B-Einträgen e1, ..., ei, die das anfängliche Einholen der An- gebote beschreiben, ausgeführt werden: ek = (wahr, nk, holeAngebot) für k = 1 ... i ei+k = (wahr, nk, verhandleAngebot) für k = 1 ... i e2i+1 = (D(e1) ∧ D(e2) ∧ ... ∧ D(ei), {ei+1, ei+2, ..., e2i}, ∅, Typ) 52 Kapitel 3 Reiseroutenℜ = (wahr, {e1, ..., ei, e2i+1}, ∅, r) bzw. ℜ = ({e1, ..., ei, e2i+1}, ∅) Der R-Eintrag e2i+1 spezifiziert, daß mit der Ausführung der in ihm enthaltenen B-Ein- träge ei+1, ..., e2i erst begonnen werden darf, nachdem die Einträge e1, ..., ei alle ausge- führt wurden. Der Einsatz des R-Eintrages ermöglicht es also, die komplexe Vorbedin- gung “zentral” an einer Stelle zu spezifizieren mit der Folge, daß alle B-Einträge nur die triviale Vorbedingung wahr besitzen. Bemerkenswert ist, daß die Einträge ei+1, ..., e2i durch die Verwendung des eingeschachtelten R-Eintrages e2i+1 gar nicht mehr direkt son- dern nur noch indirekt in der Reiseroute ℜ enthalten sind (d.h. Einträge(ℜ) ∩ {ei+1, ei+2, ..., e2i} = ∅). Für die Ausführung einer geschachtelten Reiseroute sind prinzipiell zwei verschiedene Seman- tiken denkbar: Wenn in der Reiseroute in Beispiel 3-6 ein weiterer B-Eintrag e2i+2 mit der tri- vialen Vorbedingung wahr existieren würde (zum Beispiel ein Eintrag zum Ausführen einer Geldüberweisung auf einer Bank), könnte dieser Eintrag dann verschränkt mit der Ausführung des R-Eintrages e2i+1 erfolgen (d.h. nachdem mit der Verhandlung der Angebote begonnen wur- de jedoch bevor das Nachverhandeln der Angebote in der zweiten Runde beendet ist)? In diesem Beispiel und in vielen anderen Anwendungen ist dies sicher möglich, in wiederum anderen An- wendungen jedoch nicht. Wenn die Ausführung der Einträge von e2i+1 beispielsweise innerhalb einer einzigen Transaktion geschehen müßten, dann wäre es im Sinne einer möglichst kurzen Blockierung der betroffenen Ressourcen wünschenswert, daß alle diese Einträge an einem Stück ausgeführt werden. Um diese beiden Semantiken zu unterstützen, werden zwei weitere Typen von R-Einträgen unterschieden: Definition 3-11: Offener R-Eintrag e=(Vorbedingung, {e1, ..., en}, P, o) Die Ausführung eines solchen R-Eintrages e darf mit der Ausführung von B-Einträ- gen, welche nicht zu den Nachfahren von e gehören (aber durchaus zu anderen R- Einträgen gehören dürfen), verschränkt werden. Hierbei kann theoretisch der – auf semantisch unsaubere Spezifikation der Vorbedingungen zu- rückzuführende – Fall auftreten, daß die Vorbedingung des R-Eintrages e oder die Vorbedin- gung eines seiner Vorfahren während der Ausführung des R-Eintrages zu falsch wird (durch die Ausführung von B-Einträgen, welche nicht zu den Nachfahren von e gehören). Die Ausführung von e wird dadurch jedoch nicht gestoppt, da die Vorbedingung nur zum Start der Ausführung von e relevant ist. Das folgende abstrakte Beispiel illustriert kurz die Problematik: Beispiel 3-7. Die Ausführung zweier Mengen e1, e2, ..., em und em+1, ..., en von Basis-Ein- trägen kann beliebig überlappen, mit der Ausführung der Menge e1, e2, ..., em soll jedoch nur begonnen werden, wenn der Basis-Eintrag en+1 noch nicht ausgeführt wurde: ei = ( wahr, ni, mi ) für i = 1 ... n+1 en+2 = ( ¬D(en+1), {e1, e2, ..., em}, ∅, o) en+3 = ( wahr, {em+1, em+2, ..., en}, ∅, o) 3.2 Ein flexibleres Reiseroutenkonzept 53ℜ = (wahr, {en+1, en+2, en+3}, ∅, r) Mit der Ausführung der B-Einträge e1, e2, ..., em darf nur begonnen werden, solange en+1 noch nicht ausgeführt wurde. Da en+2 ein offener R-Eintrag ist, kann en+1 ausgeführt wer- den nachdem mit der Ausführung der Einträge in en+2 begonnen wurde aber bevor der letzte Eintrag von en+2 ausgeführt wurde. Obwohl hierdurch die Vorbedingung von en+2 zu falsch wird, werden die noch nicht ausgeführten Einträge von en+2 vollends ausgeführt. Da sowohl en+2 als auch en+3 offene R-Einträge sind, ist die Ausführungsreihenfolge der B-Einträge e1, ..., en beliebig. Definition 3-12: Geschlossener R-Eintrag e=(Vorbedingung, {e1, ..., en}, P, g) Während der Ausführung eines solchen R-Eintrages dürfen nur dessen Nachfahren ausgeführt werden. Sobald also der erste B-Eintrag, welcher zu den Nachfahren von e gehört, ausgeführt wurde, dürfen nur noch Nachfahren von e ausgeführt werden, bis für alle B-Einträge, welche Nachfah- ren von e sind, gilt, daß sie entweder ausgeführt worden sind oder daß sie nicht mehr ausgeführt werden können (genauere Definition erfolgt weiter unten). Beispiel 3-8. Ein Agent soll eine Reise buchen und Informationen zum Urlaubsort sam- meln. Da gute Erfahrungen mit der Fluggesellschaft American Airlines und dem Autover- mieter Avis gemacht wurden, sollen bei diesen Firmen Flug und Mietauto gebucht wer- den. Das Hotel für den Urlaubsort kann bei einer Hotelagentur gebucht werden. Der Flug wird zuerst gebucht, damit die Termine der Reise feststehen. Danach können Hotel und Auto in beliebiger Reihenfolge gebucht werden: Flug = (wahr, AmericanAirlines, bucheFlug) Auto = (D(Flug), Avis, bucheAuto) Hotel = (D(Flug), HotelAgentur, bucheHotel) Um sicherzustellen, daß entweder alle drei oder keine der Buchungen erfolgreich sind, er- folgen die Buchungen innerhalb einer Transaktion. Um genauere Information über den Urlaubsort und die nähere Umgebung zu erlangen, soll der Agent noch bei 3 Tourismusinformationen Informationsmaterial besorgen: ti1 = (wahr, TourismusInformation1, holeInfos) ti2 = (wahr, TourismusInformation2, holeInfos) ti3 = (wahr, TourismusInformation3, holeInfos) Um die bei der Buchungstransaktion verwendeten Ressourcen nicht unnötig lange zu blockieren muß verhindert werden, daß während der Transaktion eine Tourismusinforma- tion besucht wird. Dies geschieht am einfachsten dadurch, daß die komplette Transaktion in einen geschlossenen R-Eintrag verlagert wird: Buchungen = (wahr, {Flug, Auto, Hotel}, ∅, g) 54 Kapitel 3 ReiseroutenDie komplette Reiseroute ergibt sich dann zu ℜ = ( wahr, {Buchungen, ti1, ti2, ti3}, ∅, r) Speziell durch die Einführung der offenen R-Einträge ist das Prädikat D(e) (mit der Bedeutung Eintrag e komplett ausgeführt) alleine nicht mehr ausreichend zur Spezifikation von Vorbedin- gungen, wie das folgende Szenario veranschaulicht: Eine Reiseroute enthält unter anderem zwei R-Einträge e1 und e2 die nicht verschränkt ausgeführt werden dürfen. Andere Einträge der Rei- seroute dürfen jedoch verschränkt mit e1 bzw. e2 ausgeführt werden. Dies bedeutet, daß e1 und e2 offen sein müssen und die sequentielle Ausführung von e1 und e2 durch die Vorbedingungen erzwungen werden muß. Die Vorbedingungen müssen daher festlegen, daß mit der Ausführung von e1 begonnen werden darf, falls e2 entweder schon komplett ausgeführt wurde oder falls noch keiner der Nachfahren von e2 ausgeführt wurde (und umgekehrt). Aus diesem Grunde wird ein weiteres Prädikat S(e) (von engl.: started) benötigt, welches angibt, ob mit der Ausführung eines Eintrages bereits begonnen wurde. Die rekursive Definition von S(e) ist gegeben durch Definition 3-13: Prädikat S(e) S(e)≡wahr⇔ ((e ist B-Eintrag) ∧ (e wurde schon ausgeführt)) ∨ ((e ist R-Eintrag) ∧ (∃ei ∈ Einträge(e): S(ei))) Die Definition sagt aus, daß S(e) genau dann wahr ist, wenn entweder e ein B-Eintrag ist und e schon ausgeführt wurde oder e ein R-Eintrag ist und mit der Ausführung einer der Einträge aus Einträge(e) bereits begonnen wurde. Der Fall, daß ein B-Eintrag im Moment der Prädikataus- wertung ausgeführt wird, muß hierbei nicht beachtet werden, da die Auswertung der Vorbedin- gungen (und dadurch der Prädikate) immer nur zum Migrationszeitpunkt (d.h. zwischen den Ausführungen von B-Einträgen) stattfindet. Analog zu d(e) wird die Funktion s(e) definiert: Definition 3-14: Funktion s(e) s: e → {0,1} s(e)≡1 ⇔ S(e)≡wahr Jetzt kann auch die endgültige Definition des Prädikates D(e) gegeben werden: Definition 3-15: Prädikat D(e) D(e)≡wahr⇔ ((e ist B-Eintrag) ∧ (e wurde schon ausgeführt)) ∨ ((e ist R-Eintrag) ∧ (∀ei ∈ Einträge(e): (D(ei) ∨ (¬S(ei) ∧ (Vorbedingung(ei)=falsch))))) 3.2 Ein flexibleres Reiseroutenkonzept 55Während der erste Teil der Definition, welcher D(e) für einen B-Eintrag e definiert, mit Defini- tion 3-3 übereinstimmt, bedarf der zweite Teil, welcher D(e) für einen R-Eintrag e definiert, der Erläuterung. Um für einen R-Eintrag die Entscheidung treffen zu können, daß er komplett aus- geführt wurde, müssen dessen einzelne Einträge die Bedingung erfüllen, daß sie entweder kom- plett ausgeführt wurden (wird rekursiv getestet) oder daß sie nicht mehr ausgeführt werden kön- nen. Notwendige Bedingung für die Entscheidung, daß keiner dieser noch nicht ausgeführten Einträge noch ausgeführt werden kann ist, daß deren Vorbedingungen alle zu falsch ausgewertet werden. Dies ist für B-Einträge auch die hinreichende Bedingung. Bei R-Einträgen existiert je- doch noch die Möglichkeit, daß deren Ausführung schon begonnen hat und (trotz nicht erfüllter Vorbedingung, siehe oben) noch nicht beendet ist. Deshalb muß hier zusätzlich auch noch gel- ten, daß mit der Ausführung des Eintrages noch nicht begonnen wurde. Da die Vorbedingung eines Eintrages nur von seinen Geschwistern abhängt, kann das Prädikat D(e) immer “lokal” und eindeutig berechnet werden. Die Anforderung, D(e) immer lokal und vor allem eindeutig berechnen zu können ist auch der Grund, weshalb keine anwendungsspezi- fischen Prädikate in den Vorbedingungen erlaubt sind. Wären solche anwendungsspezifischen Prädikate erlaubt, könnte bei einem offenen R-Eintrag e nur dann auf D(e)=wahr entschieden werden, wenn alle B-Einträge seiner Nachkommen ausgeführt wurden. Hätte nämlich einer die- ser B-Einträge ein anwendungsspezifisches Prädikat als Vorbedingung und wäre er noch nicht ausgeführt worden, könnte diese Vorbedingung jederzeit durch Änderungen im Agentenzustand erfüllt werden (somit wäre die Entscheidung D(e)=wahr nur am Ende der Ausführung des Agenten möglich). Die notwendigen Änderungen an der EBNF der Vorbedingungen zeigt Abbildung 3-4: Mit diesen Definitionen kann nun schließlich auch definiert werden, unter welchen Bedingun- gen ein B-Eintrag einer Reiseroute ausgeführt werden kann: Definition 3-16: Ausführbarkeit eines B-Eintrages e∈Nachfahren(ℜ) Ein B-Eintrag e, welcher in einer Reiseroute ℜ enthalten ist, kann ausgeführt wer- den wenn gilt: (Vorbedingung(e)=wahr) ∧ (∀Vorfahren ei von e: ((Vorbedingung(ei)=wahr) ∨ (S(ei)=wahr))) ∧ (∀geschlossenen Einträge ej aus der Menge der Nachfahren von ℜ: ((S(ej) ∧ ¬D(ej)) ⇒ ej ist Vorfahr von e)) Abbildung 3-4. Änderungen an der Syntax einer Vorbedingung in EBNF Prädikat = ( "D(" Eintrag ")" | "S(" Eintrag ")" ). Funktion = ( "d(" Eintrag ")" | "s(" Eintrag ")" ). 56 Kapitel 3 ReiseroutenUm einen B-Eintrag ausführen zu können muß nicht nur dessen Vorbedingung erfüllt sein (er- ster Teil der Bedingung aus Definition 3-16), sondern der Zustand der Reiseroute muß mit in Betracht gezogen werden. Offensichtlich ist, daß die Ausführbarkeit vom Zustand der Vorfahren des B-Eintrages abhängt: entweder muß deren Vorbedingung erfüllt sein oder es muß schon mit ihrer Ausführung begonnen worden sein (zweiter Teil der Bedingung aus Definition 3-16). We- niger offensichtlich ist, daß beachtet werden muß, ob momentan geschlossene R-Einträge aus- geführt werden (ein (geschlossener) R-Eintrag e wird dann momentan ausgeführt, falls S(e) ∧ ¬D(e) zu wahr ausgewertet wird). Ist dies der Fall, dann müssen alle momentan ausgeführten geschlossenen R-Einträge Vorfahren des B-Eintrages sein (dritter Teil der Bedingung aus Defi- nition 3-16). Die Flexibilität und Mächtigkeit des vorgestellten Konzeptes demonstriert das folgende Bei- spiel. 3.2.3 Beispiel einer komplexen Reiseroute Das in dem Beispiel betrachtete Szenario ist die Organisation einer Konferenzreise. Der hierfür zuständige Agent muß dazu seinen Auftraggeber bei der Konferenz als Teilnehmer registrieren, einen Flug, ein Auto und die Unterbringung buchen, bei Touristeninformationen allgemeine In- formationen über touristische Attraktionen und Veranstaltungen am Konferenzort sammeln und letztendlich das Ergebnis seiner Tätigkeit beim Auftraggeber abliefern. Um die Reiseroute zu- sammenzustellen, benötigt der Agent auftragsspezifische Informationen von seinem Auftragge- ber (welche Konferenz, wo muß registriert werden, Aufenthaltszeit am Konferenzort, etc.), all- gemeine Informationen aus dem Benutzerprofil des Auftraggebers (welche Fluggesellschaften werden bevorzugt, etc.) und andere Informationen, welche über Informationsdienste bereitge- stellt werden (wo können Flüge gebucht werden, etc.). Nachdem die Informationen vorliegen, kann in diesem Fall die Reiseroute auch schon komplett spezifiziert werden. Da die Konferenzgebühren bei der Registrierung per (elektronischem) Bankscheck bezahlt wer- den müssen, muß der Agent zuerst einen Scheck bei einer der Banken des Benutzers abholen, bevor er die Registrierung bei der Konferenz durchführen kann. Bei den Banken hat er die Aus- wahl zwischen der Barclays Bank oder der CityBank. Das Abholen des Schecks und die Regi- strierung spezifizieren die folgenden Einträge: bank1 = (¬D(bank2), Barclays, holeScheck) bank2 = (¬D(bank1), CityBank, holeScheck) Konferenz = (D(bank1) ∨ D(bank2), IEEE, RegistriereFürTeilnahme) Der Auftraggeber bevorzugt die Barclays Bank. Deshalb wird (bank1, bank2) in die Prioritäts- relation des R-Eintrages aufgenommen, der bank1 und bank2 enthält. Um das Beispiel in überschaubaren Grenzen zu halten werden hier nur zwei Fluggesellschaften und zwei Autovermieter verwendet. Hierbei bestehen jeweils zwischen einer Fluggesellschaft 3.2 Ein flexibleres Reiseroutenkonzept 57und einem Autovermieter Verträge, die den Kunden Rabatte gewähren, wenn beim jeweils an- deren Vertragspartner der Flug gebucht bzw. das Auto gemietet wird. Aus diesem Grund werden Buchungen nur in den Kombinationen AmericanAirlines/Avis (was die bevorzugte Kombinati- on ist) und AirCanada/Hertz gemacht. Für jede dieser Firmen gibt es mehrere Geschäftsstellen, welche alternativ besucht werden können. Der Einfachheit halber werden das Buchen des Flu- ges und des Autos in einem R-Eintrag “versteckt”: FlugAuto= (wahr, {AmericanAvis, CanadaHertz}, {(AmericanAvis, CanadaHertz)}, o) Da bei der ersten Alternative AmericanAirlines/Avis die Flugbuchung und die Reservierung des Autos in einer Transaktion durchgeführt werden muß, wird hierfür ein geschlossener R-Eintrag verwendet. AmericanAirlines hat drei Niederlassungen, Avis hat deren zwei. Um den Rabatt ge- währt zu bekommen, muß der Flug vor dem Auto gebucht werden: AmericanAvis = (¬S(CanadaHertz), {American1, American2, American3, Avis1, Avis2},∅, g) American1 = (¬(D(American2) ∨ D(American3)), AmericanAirlines1, bucheFlug) American2 = (¬(D(American1) ∨ D(American3)), AmericanAirlines2, bucheFlug) American3 = (¬(D(American1) ∨ D(American2)), AmericanAirlines3, bucheFlug) Avis1 = ((D(American1)∨D(American2)∨D(American3))∧¬D(Avis2), AvisNode1, bucheAuto) Avis2 = ((D(American1)∨D(American2)∨D(American3))∧¬D(Avis1), AvisNode2, bucheAuto) Da CanadaHertz ein offener R-Eintrag ist (siehe weiter unten), muß in der Vorbedingung von AmericanAvis mit dem Prädikat S(...) gearbeitet werden, um ein gleichzeitiges Buchen bei bei- den Gesellschaften zu verhindern. Sollte es noch mehr alternative Fluggesellschafts- oder Au- tovermietungsniederlassungen geben, ist natürlich auch hier die Verwendung zusätzlicher R- Einträge sowohl für die Fluggesellschaften als auch die Autovermieter ratsam. Bei AirCanada und Hertz gibt es jeweils nur zwei Niederlassungen. Auch hier muß der Flug zuerst gebucht werden: CanadaHertz= (¬D(AmericanAvis), {Canada1, Canada2, Hertz1, Hertz2}, ∅, o) Canada1 = (¬D(Canada2), AirCanada1, bucheFlug) Canada2 = (¬D(Canada1), AirCanada2, bucheFlug) Hertz1 = ((D(Canada1)∨D(Canada2))∧¬D(Hertz2), HertzNode1, bucheAuto) Hertz2 = ((D(Canada1)∨D(Canada2))∧¬D(Hertz1), HertzNode2, bucheAuto) In diesem Falle reicht es, daß CanadaHertz in der Vorbedingung mit dem Prädikat D(...) arbei- tet, da AmericanAvis ein geschlossener R-Eintrag ist. Wird zuerst ein Eintrag von AmericanAvis ausgeführt, dann wird dieser R-Eintrag zuerst komplett fertig ausgeführt bevor mit irgend einem anderen Eintrag weitergemacht wird. Für CanadaHertz ist damit die Vorbedingung falsch. Wird jedoch zuerst ein Eintrag von CanadaHertz ausgeführt, dann wird sofort die Vorbedingung für 58 Kapitel 3 ReiseroutenAmericanAvis falsch. Somit ist sichergestellt, daß nur einer dieser beiden R-Einträge abgearbei- tet wird. Um das Hotel zu buchen, muß der Agent die genauen Daten für die Übernachtung wissen. Aus diesem Grund kann das Buchen des Zimmers erst geschehen, nachdem der Flug bereits gebucht wurde. Aus Gründen der Übersichtlichkeit wurden auch hier nur zwei Agenturen zum Buchen des Hotels berücksichtigt: Hotel = (D(FlugAuto), {hotelAgentur1, hotelAgentur2}, ∅, o) hotelAgentur1 = (¬D(hotelAgentur2), HotelAgentur1, bucheZimmer) hotelAgentur2 = (¬D(hotelAgentur1), HotelAgentur2, bucheZimmer) Es gibt insgesamt fünf verschiedene Touristik-Zentren, welche verschiedene Arten an Informa- tionen bieten. Bevor der Agent diese Zentren besucht, muß er zuerst den Flug gebucht haben, um die genaue Zeitspanne zu kennen, für welche er Informationen sammeln muß: ti1 = (D(FlugAuto)∧¬D(home), TourismusInformation1, holeInfos) ti2 = (D(FlugAuto)∧¬D(home), TourismusInformation2, holeInfos) ti3 = (D(FlugAuto)∧¬D(home), TourismusInformation3, holeInfos) ti4 = (D(FlugAuto)∧¬D(home), TourismusInformation4, holeInfos) ti5 = (D(FlugAuto)∧¬D(home), TourismusInformation5, holeInfos) Bevor der Agent zu seinem Heimatort zurückkommt, um seinem Auftraggeber die Ergebnisse zu übergeben, muß er alle aufgeführten Arbeiten erledigen. Ausnahme hierbei ist der Besuch der Touristik-Informationen. Sollten hier nicht alle erreichbar sein (z.B. wegen Rechner-/Netz- werkausfällen) ist es ausreichend, wenn der Agent mindestens drei davon besucht. Dies wird im R-Eintrag home spezifiziert: home = (D(Konferenz)∧D(Hotel)∧(3≤d(ti1)+d(ti2)+d(ti3)+ d(ti4)+d(ti5)), BenutzerRechner, berichteErgebnisse) Um jedoch festzulegen, daß der Agent nach Möglichkeit trotzdem alle 5 Touristik-Informatio- nen besucht, kann die Prioritätsrelation verwendet werden: wird den Touristik-Informationen eine größere Priorität als dem home-Eintrag zugeordnet, so werden diese auch – sofern möglich – alle besucht, bevor der home-Eintrag ausgeführt wird. Der zweite Teil der Vorbedingungen der Touristik-Informationen-Einträge stellt sicher, daß der Agent nach Beendigung seiner eigentli- chen Aufgabe nicht noch den Besuch bei einer Touristik-Information nachholt, falls er diese vor dem Abliefern seiner Ergebnisse nicht besuchen konnte. Die komplette Reiseroute wird spezifiziert mit ℜ = (wahr, {bank1, bank2, Konferenz, FlugAuto, Hotel, ti1, ti2, ti3, ti4, ti5, home}, {(bank1, bank2), (ti1, home), (ti2, home), (ti3, home), (ti4, home),(ti5, home)}, r) Die erste Ebene und einen Teil der zweiten Ebene des Baums der möglichen Pfade, welche der Agent laut der spezifizierten Reiseroute durchlaufen kann, zeigt Abbildung 3-5. Die riesige An- zahl der Knoten im gesamten Baum zeigt die Mächtigkeit und Flexibilität des Reiseroutenkon- zeptes: Wenn der Agent alle Touristik-Informationen besucht, muß er insgesamt lediglich 11 3.2 Ein flexibleres Reiseroutenkonzept 59Knoten besuchen. Der Baum hat folglich 11 Ebenen. Während es in der ersten Ebene nur sieben und in der zweiten nur 26 Knoten gibt, umfaßt die dritte Ebene 136 und die vierte Ebene bereits über 900 Knoten. Der Agent hat also bei der Wahl des ersten Zielortes 7 Wahlmöglichkeiten, bei der Wahl des zweiten Zielortes im Durchschnitt ca. 4 Wahlmöglichkeiten, bei der Wahl des dritten Zielortes ca. 5 Wahlmöglichkeiten und bei der Wahl des vierten Zielortes durchschnitt- lich ca. 7 Wahlmöglichkeiten. Im weiteren Verlauf reduziert sich dies jedoch wieder, bis letzt- endlich beim letzten zu besuchenden Knoten nur noch der Heimatknoten zur Auswahl steht. 3.2.4 Diskussion Wie vor allem das Beispiel des vorhergehenden Abschnittes zeigt, ist das in diesem Kapitel vor- gestellte Reiseroutenkonzept der geschachtelten Reiseroute sehr flexibel und mächtig. Inwie- weit das Ziel, bei der Migration mehrere alternative Migrationsziele zur Auswahl zu haben, er- reicht werden kann hängt jedoch letztendlich von der Anwendung selbst ab. Je weniger die Aufgabe die Reihenfolge der notwendigen Schritte impliziert, desto stärker kann mittels dem hier vorgestellten Reiseroutenkonzept daraus Vorteil gezogen werden. Ist die Reihenfolge der notwendigen Schritte von der Aufgabenstellung jedoch fest vorgegeben, kann auch das Reise- routenkonzept keine alternativen Migrationsziele zur Auswahl stellen. Die Beispiele des Kapitels haben gezeigt, daß die manuelle Spezifikation einer Reiseroute und hierbei vor allem die Spezifikation der Vorbedingungen sehr aufwendig sein kann. BUSCHLE (1999) beschreibt eine Implementierung des Reiseroutenkonzeptes, welche den An- wendungsprogrammierer hierbei sehr stark unterstützt. Abbildung 3-5. Baum der möglichen Pfade des Konferenzplanungsagenten AmericanAirlines1 AmericanAirlines2 AmericanAirlines3 AirCanada1 AirCanada2 IEEE Avis1 Avis2 Barclays CityBank Hertz1 Hertz2 Barclays CityBank AmericanAirlines1 AmericanAirlines2 AmericanAirlines3 AirCanada1 AirCanada2 60 Kapitel 3 Reiserouten Kapitel 4 Genau-einmal Ausführung Die zuverlässige, fehlertolerante Ausführung mobiler Agenten ist Voraussetzung für deren Ein- satz in kommerziellen Anwendungen. In diesem Kapitel wird ein Protokoll entwickelt, welches die blockierungsfreie genau-einmal Ausführung mobiler Agenten garantiert. Voraussetzung für die Entwicklung fehlertoleranter Anwendungen ist die Kenntnis der zu tole- rierenden Fehler. Der folgende Abschnitt führt deshalb zuerst die den Algorithmen zugrunde liegenden System- und Fehlermodelle ein. Anschließend wird der Begriff der “genau-einmal Ausführung” im Kontext mobiler Agenten definiert. Das eigentliche Protokoll wird daraufhin in zwei Schritten entwickelt. Zuerst wird ein Basisprotokoll entwickelt, welches die genau-ein- mal Ausführung von Agenten realisiert. Da dieses Protokoll jedoch noch anfällig für die Blok- kierung eines Agenten durch Rechner- und Netzwerkausfälle ist, wird es dann um eine Über- wachungskomponente ergänzt. Hierbei überwachen mehrere Beobachterknoten, welche zusammen mit dem ausführenden Knoten eine Stufe (engl.: stage) bilden, die Ausführung des Agenten. Fällt der ausführende Knoten aus, kann einer der Beobachter die Ausführung des Agenten übernehmen. Daran anschließend wird die Nachrichtenkomplexität des entwickelten Protokolles untersucht und ein Algorithmus entwickelt, welcher durch geschickte Auswahl der Knoten einer Stufe die Nachrichtenkomplexität reduziert. Eine ausführliche analytische Bewer- tung des Protokolls und Leistungsmessungen einer in die Agentenplattform Mole integrierten Implementierung des Protokolls schließen das Kapitel. Die in diesem Kapitel vorgestellten Protokolle und Mechanismen wurden erstmals in ROTHER- MEL UND STRASSER (1997), ROTHERMEL UND STRASSER (1998) und STRASSER, ROTHERMEL UND MAIHÖFER (1998) veröffentlicht. Teilaspekte dieses Kapitels wurden in Diplomarbeiten von MAIHÖFER (1997), FRIEDEL (1998) und PAPOULIDIS (1999) erarbeitet. 62 Kapitel 4 Genau-einmal Ausführung4.1 System- und Fehlermodell Um fehlertolerante verteilte Systeme zu entwickeln ist es notwendig, die Bestandteile des Sy- stems und deren Fehler zu kennen. Einen detaillierten Überblick über Fehlertoleranz in verteil- ten Systemen gibt JALOTE (1994), dessen Terminologie und Klassifikationen weitestgehend (in deutscher Übersetzung) in der vorliegenden Arbeit übernommen wurden. Um das Verständnis zu erleichtern, wird auf die relevanten Begriffe an dieser Stelle kurz eingegangen. Ein Systemmodell beschreibt die relevanten Bestandteile eines Systems, das Fehlermodell die im System möglichen Fehler. Ein (verteiltes) System kann hierbei aus zwei verschiedenen Blickwinkeln betrachtet werden. Die eine Sicht ist die der physischen Komponenten, aus denen das System besteht. Dies wird auch das physische Systemmodell genannt. Die andere Sicht ist die der Verarbeitung, d.h. die Sicht des Benutzers auf das System und die vom System angebo- tenen Dienste. Diese Sicht wird auch als das logische Systemmodell bezeichnet. Fehlertoleranz, vor allem in verteilten Systemen, beschäftigt sich häufig damit, die Eigenschaften bzw. Dienste des logischen Modells trotz Ausfällen (engl.: failure) in den Komponenten des physischen Sy- stems sicherzustellen. 4.1.1 Fehlerklassifikation Ein Ansatz der Klassifikation von Fehlern in verteilten Systemen beruht darauf, wie sich die physischen Komponenten des Systems bei einem Ausfall verhalten. Die Ausfälle (engl.: failure) der physischen Komponenten sind hierbei aus Sicht der Anwendung Fehler (engl.: fault) des Systems. CRISTIAN, AGHILI UND STRONG (1986) schlagen eine Klassifikation in die 4 Katego- rien Crash, Omission, Zeit und byzantinisch vor: Crash. Bei einem Crash hält eine Komponente sofort an. Sie macht keine falschen Zustands- übergänge und produziert keine falschen Ausgaben. In diesem Modell verhält sich eine Komponente also entweder gemäß Spezifikation oder hält an. Oftmals ist es nicht einfach festzustellen, ob eine Komponente ausgefallen ist. Aus diesem Grunde gibt es eine von SCHNEIDER (1984) vorgestellte Variante dieses Fehlertyps, bei welcher der Ausfall einer Komponente festgestellt werden kann. Die von Schneider vorgestellte Version eines Pro- zessors mit diesem Fehlertyp wird fail stop processor genannt. Omission. Durch einen Fehler dieser Art reagiert eine Komponente sporadisch nicht auf Ein-/ Ausgaben. Hier kann man unterscheiden zwischen einer Receive-Omission, bei der eine Komponente eine Nachricht nicht empfängt, und einer Send-Omission, bei der eine Kom- ponente eine Nachricht nicht sendet. Zeitfehler (engl.: timing fault). Ein Fehler dieser Art veranlaßt eine Komponente, zu früh oder zu spät zu reagieren. 4.1 System- und Fehlermodell 63Byzantinischer Fehler (engl.: byzantine fault). Ein Fehler, bei dem das Verhalten einer Kompo- nente vollkommen zufällig von der Spezifikation abweicht (und dabei auch unerwartete/ falsche Ausgaben liefern kann). Diese Fehler bilden eine Hierarchie. Hierbei ist der Crash-Fehler der einfachste, aber auch spe- ziellste der Fehler, der byzantinische Fehler der allgemeinste der Fehler. Die aus SCHNEIDER (1984) übernommene Abbildung 4-1 zeigt, daß die allgemeineren Fehler die spezi- elleren Fehler als echte Teilmenge enthalten. 4.1.2 Verwendetes Systemmodell In diesem Abschnitt wird das in der vorliegenden Arbeit durchgängig verwendete Systemmo- dell vorgestellt. Ein verteiltes System besteht aus mehreren autonomen Knoten (d.h. Rechnern) und einem diese Knoten verbindenden Netzwerk. Ein Knoten besteht aus einem Prozessor und privatem flüchtigen und stabilen Speicher. Pro Knoten können mehrere Programme ausgeführt werden. Ein Programm wird innerhalb eines Prozesses ausgeführt. Innerhalb eines Prozesses ist die nebenläufige Ausführung mehrerer Threads möglich. Prozesse auf einem Knoten können miteinander nur über Nachrichten kom- munizieren. Um Alarme (z.B. Timeouts) verwalten zu können, besitzt jeder Knoten eine kor- rekte Uhr. Die Kommunikation zwischen den Knoten erfolgt mittels Nachrichtenaustausch über das Netz- werk. Die Kommunikation erfolgt über Kommunikationskanäle. Zwischen je zwei Rechnern des Systems existiert ein Kommunikationskanal. Alle Komponenten des Systems arbeiten asynchron, d.h. es existiert keine obere Zeitschranke für die Ausführung einer Sequenz von Anweisungen oder für die Übertragung einer Nachricht. Die in dieser Arbeit entwickelten Algorithmen funktionieren jedoch auch in synchronen Syste- men, d.h. wenn obere Zeitschranken für das Ausführen von Anweisungen und die Nachrichten- übertragung existieren. Abbildung 4-1. Fehlerklassifikation Crash Omission Timing Byzantinisch 64 Kapitel 4 Genau-einmal Ausführung4.1.3 Verwendetes Fehlermodell Analog zum Systemmodell wird im Fehlermodell zwischen Knotenfehlern und Netzfehlern un- terschieden. Knoten unterliegen lediglich Crash-Fehlern. Bei einem Knotenfehler hält der Knoten die Aus- führung aller Programme an; der systembedingte Ausfall einer echten Teilmenge der Prozesse eines Knotens ist ausgeschlossen. Alle im flüchtigen Speicher liegenden Informationen (Aus- führungszustand der laufenden Prozesse, Daten der Prozesse) gehen hierbei verloren. Auf sta- bilem Speicher abgelegte Daten gehen bei einem Knotenzusammenbruch nicht verloren. Der stabile Speicher selbst ist fehlerfrei (vgl. LAMPSON (1981)). Die Kommunikation zwischen Pro- zessen eines Knotens ist fehlerfrei. Auch das Netzwerk unterliegt nur Crash-Fehlern. Hierbei treten jedoch nur Netzwerkpartitio- nierungen auf. Knoten innerhalb einer Partition können kommunizieren, Knoten unterschiedli- cher Partitionen nicht. Die Kommunikation zwischen Knoten innerhalb einer Partition ist feh- lerfrei. Alle Komponenten des Systems arbeiten asynchron (d.h. es gibt keine obere Zeitschranke für die Ausführung von Operationen). Knoten- und Netzwerkausfall sind nicht unmittelbar erkenn- bar. Insbesondere sind Knoten- und Netzwerkausfall nicht unterscheidbar, da Kommunikation über das Netzwerk die einzige Möglichkeit der Kontaktaufnahme zu anderen Knoten ist. Dies bedeutet letztendlich, daß der Ausfall einer Komponente lediglich vermutet werden kann, Ge- wißheit besteht jedoch nicht. Gängige Praxis in realen Systemen ist, daß eine Komponente bei einem Fehler repariert wird. Aus diesem Grunde wird angenommen, daß die obigen Fehler jeweils nur vorübergehend sind und die Komponenten nach Reparatur und/oder Neustart wieder zur Verfügung stehen. Der Pro- grammzustand und der Zustand des flüchtigen Speichers eines Knotens wird nach Reparatur bzw. Neustart des Knotens nicht automatisch wieder hergestellt. Dieser Fehlertyp wird in AGUI- LERA, CHEN UND TOUEG (1998) vorgeschlagen und Crash-Recovery Model genannt. 4.2 Definition “Genau-einmal Ausführung” Die Eigenschaft der genau-einmal Ausführung von Operationen in verteilten Systemen wurde erstmalig im Bereich der Client/Server-Interaktion definiert. SPECTOR (1982) spezifizierte die nur-einmal-Typ-2 Fehlersemantik (engl.: only-once-type-2), nach SCHILL (1992A) später auch unter dem Begriff genau-einmal Fehlersemantik (engl.: exactly-once) bekannt, für die Ausfüh- rung eines einzelnen Aufrufes einer entfernten Prozedur. Im Kontext mobiler Agenten ist diese Definition jedoch nicht ausreichend. Anstatt der Ausführung einer einzelnen Prozedur muß hier die Ausführung der gesamten (in der Reiseroute spezifizierten) Aufgabe des Agenten, welcher die Ausführung einer ganzen Sequenz von Schritten des Agenten entspricht, betrachtet werden. 4.3 Basisprotokoll 65Sei P={P1, P2, ..., Pn} die Menge der durch eine gegebene Reiseroute spezifizierten möglichen Pfade eines Agenten, sei L(Pi) die Anzahl der Knoten in Pfad Pi=[Ni,1, Ni,2, ..., Ni,L(Pi)] und sei Si,j der auf dem j-ten Knoten Ni,j des Pfades Pi auszuführende Schritt (1≤i≤n, 1≤j≤L(Pi)). Die genau-einmal Ausführung ist dann wie folgt definiert: Definition 4-1: Genau-einmal Ausführung eines mobilen Agenten Ein Agent wird genau einmal ausgeführt ⇔ ((der Agent führt ausschließlich die zu einem Pfad Pi∈P gehörigen Schritte Si,1, ..., Si,L(Pi) auf den ihnen zugewiesenen Knoten Ni,1, ..., Ni,L(Pi) aus) ∧ (der Agent führt Schritt Si,j vor Schritt Si,j+1 aus (1≤j tST,i ergibt sich für Stufengrößen von 3 bzw. 5 Knoten pro Stufe eine Nachrichtenanzahl von 26 bzw. 46 Nachrichten im Normalfall und 20 bzw. 36 Nachrichten bei Anwendung der Optimierung im 2-Phasen-Commit. In der Schritt-Transaktion der letzten Stufe entfällt der Transport des Agenten auf die Knoten der nachfolgenden Stufe. Jedoch muß vor der Durchführung der Schritt-Transaktion in der er- sten Stufe der Agent auch innerhalb einer Transaktion auf die Knoten der ersten Stufe transpor- tiert werden, wobei hierzu (bei konstanter Knotenanzahl pro Stufe) derselbe Aufwand notwen- dig ist wie der, der in der letzten Stufe entfällt. Bei fehlerfreier Ausführung des Agenten berechnet sich die Gesamtzahl nFT der zur Ausfüh- rung des Agenten notwendigen Nachrichten bei einer Anzahl nS von Stufen mittels (4-9) beziehungsweise bei Anwendung der oben genannten Optimierung im 2-Phasen-Commit (4-10) Unter der Annahme, daß für die Ausführung eines Agenten in allen Stufen dieselbe Anzahl nK von Knoten verwendet wird, vereinfacht sich dies auf (4-11) beziehungsweise bei Anwendung der Optimierung im 2-Phasen-Commit (4-12) Treten während der Ausführung des Agenten Fehler auf, versucht das Protokoll, diese zu elimi- nieren. Dabei werden weitere Nachrichten erzeugt. Sind während des Votierprotokolles Knoten der Stufe nicht erreichbar, werden Nachrichten des Votierprotokolles an diese Knoten mehrfach nFT 6 nK 1, 6 nK i 1+, 4 tST i, tp -------- +   nK i, 1–( )⋅+⋅   i 1= nS 1– ∑ 4 tST nS, tp ----------- +   nK nS, 1–( )⋅ + + ⋅= nFT opt, 4 nK 1, 4 nK i 1+, 4 tST i, tp -------- +   nK i, 1–( )⋅+⋅   i 1= nS 1– ∑ 4 tST nS, tp ----------- +   nK nS, 1–( )⋅ + + ⋅= nFT 10 nK 4–⋅( ) ns⋅ nK 1–( ) tST i, tp -------- i 1= nS ∑⋅+= nFT opt, 8 nK 4–⋅( ) ns⋅ nK 1–( ) tST i, tp -------- i 1= nS ∑⋅+= 114 Kapitel 4 Genau-einmal Ausführungverschickt. Fallen Knoten der nächsten Stufe während der Phase des Transports des Agenten zu diesen Knoten aus, so muß entweder die Zusammensetzung der Stufe neu ermittelt werden und diese Informationen neu mittels einiger weniger Nachrichten an die Knoten der nächsten Stufe verteilt werden oder, falls nicht eindeutig festgestellt werden kann, ob der Agent bei einem Kno- ten ankam oder nicht, die gesamte Schritt-Transaktion abgebrochen und wiederholt werden. Fällt während der Ausführung des Agenten der Arbeiter aus bzw. ist der Arbeiter nicht mehr erreichbar, so wird das Auswahlprotokoll gestartet. Ist der nicht mehr erreichbare Arbeiter der Knoten mit der höchsten Priorität, so starten im ungünstigsten Falle bei nK Knoten in der Stufe nK-1 Knoten gleichzeitig das Auswahlprotokoll. Hierbei verschickt jeder Knoten ARE_YOU- THERE(..)-Nachrichten an die Knoten mit höherer Priorität. Da aber im ungünstigsten Fall dies alle Knoten zur selben Zeit tun, bekommt jeder Knoten von allen Knoten mit geringerer Priorität eine ARE_YOU_THERE(..)-Nachricht, auf die er mit einer I_AM_THERE(..)-Nachricht ant- worten muß. Es verschickt also jeder der nK-1Knoten Nachrichten an alle anderen Knoten der Stufe außer an sich selbst – eine ARE_YOU_THERE(..)-Nachricht an die Knoten mit höherer Priorität und eine I_AM_THERE(..)-Nachricht an die Knoten mit niedrigerer Priorität – insge- samt also nK-1 Nachrichten pro Knoten. Inklusive der nK-1 I_AM_SELECTED(..)-Nachrichten des Gewinners ergeben sich also im ungünstigsten Fall nK*(nK-1) Nachrichten. Vergleicht man den Kommunikationsaufwand für einen Schritt des Basisprotokolls mit dem blockierungsfreien Protokoll, so ergibt sich bei fehlerfreier Ausführung des/der i-ten Schrittes/ Stufe für das blockierungsfreie Protokoll mit konstanter Anzahl nK von Knoten pro Stufe ein Mehraufwand von (4-13) beziehungsweise bei Anwendung der Optimierung im 2-Phasen-Commit (4-14) Der Mehraufwand setzt sich zusammen aus (kurzen) I_AM_ALIVE(..)- Nachrichten, (kurzen) Nachrichten des Votierprotokolles, Migrationsnach- richten, (kurzen) Bestätigungsnachrichten und (kurzen) Nachrichten des 2PC-Protokolles (bzw. Nachrichten bei der optimierten Version). Auch hier kann man, zumindest bei “größeren” Agenten, die durch den zusätzlich transportierten Stufen- Record verursachte Zunahme der Größe der Migrationsnachricht vernachlässigen, da der Stu- fen-Record für sinnvolle Stufengrößen von 3-7 Knoten im Vergleich zu Code und Datenzustand des Agenten vergleichsweise klein ist. noverhead i, 10 tST i, tp -------- +   nK 1–( )⋅= noverhead i opt, , 8 tST i, tp -------- +   nK 1–( )⋅= tST i, tp⁄ nK 1–( )⋅ 4 nK 1–( )⋅ nK 1– nK 1– 4 nK 1–( )⋅ 2 nK 1–( )⋅ 4.5 Kommunikationsaufwand und Stufenkonstruktion 1154.5.2 Möglichkeiten zur Reduktion des Kommunikationsaufwandes Eine sehr offensichtliche Möglichkeit zur Reduktion des Kommunikationsaufwandes des blok- kierungsfreien Protokolles ergibt sich direkt aus Gleichung (4-13) bzw. Gleichung (4-14): je weniger Knoten eine Stufe besitzt, desto geringer ist der Nachrichtenmehraufwand. Für eine Stufe mit nur einem Knoten entspricht das blockierungsfreie Protokoll weitgehend dem Basis- protokoll und besitzt in diesem Fall auch keinen Nachrichtenmehraufwand im Vergleich zum Basisprotokoll. Wie sich allerdings in Abschnitt 4.6 zeigen wird, bedeutet eine Verringerung der Anzahl von Knoten pro Stufe (präziser: die Verringerung der Knotenanzahl pro Stufe um 2) eine Erhöhung der Wahrscheinlichkeit, daß der Agent blockiert wird – und widerspricht somit der Zielsetzung des Protokolles. Ebenfalls offensichtlich ergibt sich aus den genannten Gleichun- gen, daß sich die Anzahl der Nachrichten durch die Wahl einer langen Periodendauer tp zwi- schen zwei I_AM_ALIVE(..)-Nachrichten in gewissem Umfang reduzieren läßt – wodurch aller- dings die Zeit erhöht wird, bis auf einen Fehler reagiert wird. Der Anwender hat jedoch die Möglichkeit, durch Adaption der beiden Parameter “Anzahl der Knoten pro Stufe” und “Peri- odendauer tp” den gewünschten Grad der Fehlertoleranz für seine Anwendung anzupassen: Be- nötigt eine Anwendung nur einen geringen Grad an Fehlertoleranz, so wird der Anwender kei- nen zu großen Mehraufwand akzeptieren und deshalb sollte in diesem Fall vom Agent bzw. der Anwendung eine kleine Anzahl Knoten pro Stufe (eventuell nur ein Knoten) und eine lange Pe- riodendauer tp gewählt werden. Ist dem Benutzer jedoch für die Ausführung einer Anwendung ein hoher Grad an Fehlertoleranz wichtig, so wird er dafür auch einen größeren Mehraufwand akzeptieren (den er eventuell zu bezahlen hat), wodurch der Agent bzw. die Anwendung die Möglichkeit besitzt, eine größere Anzahl an Knoten pro Stufe und eine kurze Periodendauer tp zu wählen. Steht die Anzahl der Knoten pro Stufe und die Periodendauer tp fest, kann beim Beobachtungs- protokoll und beim Votierprotokoll der Aufwand nicht weiter reduziert werden. Es besteht je- doch die Möglichkeit, durch entsprechende Auswahl der Knoten einer Stufe den für die Migra- tion des Agenten notwendigen Kommunikationsaufwand zu reduzieren. Ist beispielsweise wie in Abbildung 4-20 ein Knoten K2 Mitglied zweier aufeinanderfolgender Stufen Si und Si+1, so kann offensichtlich bei der Versendung des Agenten auf die Knoten der Stufe Si+1 bei der zu K2 versendeten Migrationsnachricht auf den Code des Agenten verzichtet werden, da dieser ja noch aus Stufe Si dort vorhanden ist. Hierdurch reduziert sich allerdings nur die Menge der zu ver- sendenden Daten, nicht jedoch die Anzahl der zu versendenden Nachrichten. Eine Reduzierung der zu versendenden Nachrichten kann erreicht werden, wenn der Arbeiter der Stufe Si auch Mitglied der Stufe Si+1 ist. Besitzt die Stufe Si+1 insgesamt nK,i+1 Knoten, so muß der Agent in diesem Fall nur auf nK,i+1-1 Knoten übertragen werden, wodurch eine Migra- tionsnachricht, deren Bestätigung und 4 (bzw. 2) Nachrichten des 2PC-Protokolles wegfallen. Abbildung 4-21 zeigt ein Szenario, in dem der Knoten K1 in Stufen Si und Si+1 teilnimmt und in der Stufe Si den Agenten ausführt. Um den Agent für Stufe Si+1 in die Eingangswarteschlange 116 Kapitel 4 Genau-einmal Ausführungvon K1 zu schreiben müssen in diesem Fall keine Nachrichten über das Netzwerk verschickt werden – die Kommunikation geschieht nur lokal. Der Kommunikationsmehraufwand im Ver- gleich zum Basisprotokoll wird jedoch nur bedingt verringert. Der genannte Fall, daß der Ar- beiter der Stufe Si auch Mitglied der Stufe Si+1 ist, kann nämlich in zwei Situationen auftreten, von denen nur eine eine tatsächliche Reduktion des Kommunikationsmehraufwandes darstellt. In der ersten Situation verfügt die Stufe Si+1 nicht über genügend reguläre Knoten. In diesem Falle wird der Arbeiter der Stufe Si als Ausnahmebehandlungsknoten in die Stufe Si+1 aufge- nommen, wodurch eine tatsächliche Reduktion des Kommunikationsmehraufwandes erreicht wird. In der zweiten Situation ist der Arbeiter der Stufe Si regulärer Knoten der Stufe Si+1. Die- ser Fall – der Agent führt zwei Schritte hintereinander auf demselben Knoten aus – wurde bei Abbildung 4-20. Einsparung von Code-Transport durch Teil- nahme desselben Knotens in zwei aufeinanderfolgenden Stufen Abbildung 4-21. Einsparung von Nachrichten durch Teil- nahme des Arbeiters einer Stufe in der darauffolgenden Stufe Si Si+1 Agent (Code+Daten), Bestätigungen, 2-Phasen-CommitK1 K2 K3 K5 K2 K4 Agen t (Code +Date n), Bes tätigu ngen , 2-P hase n-Co mmi t Agent (Daten ), Bestätigung en, 2-Pha sen-Com mit Si Si+1 Agent, Bestätigungen, 2-Phasen-CommitK1 K2 K3 K5 K1 K4 Agen t, Bes tätigu ngen , 2-P hase n-Co mmi t Agent, Bes tätigunge n, 2-Phas en-Comm it globale Kommunikation zwischen verschiedenen Knoten lokale Kommunikation innerhalb eines Knotens 4.5 Kommunikationsaufwand und Stufenkonstruktion 117den obigen Betrachtungen explizit ausgeschlossen. Wird der Agent mittels des Basisprotokolles ausgeführt, werden in diesem Falle natürlich auch beide Schritte hintereinander auf demselben Knoten ausgeführt. Insofern ergibt sich in diesem Fall keine Reduktion des durch das blockie- rungsfreie Protokoll eingeführten Kommunikationsmehraufwandes. Weitere Reduktionen des Kommunikationsaufwandes sind nur durch Abänderung des Protokol- les zu erreichen. So könnte beispielsweise das Votierprotokoll dahingehend geändert werden, daß in einem ersten Schritt nur von so vielen Knoten Voten angefordert werden, daß, unter der Voraussetzung, daß diese alle mit YES antworten, schon eine Mehrheit an Voten erreicht würde. Nur wenn nicht genug YES-Voten ankommen (z.B. weil einige dieser Knoten ausgefallen sind), müßten von weiteren Knoten der Stufe Voten angefordert werden. Treten keine Fehler auf, wür- de hierdurch für die knappe Hälfte der Knoten einer Stufe die erste Stufe des Votierprotokolles entfallen. Bei nK Knoten in einer Stufe würde dies einer Einsparung von (kurzer) Votiernachrichten pro Stufe entsprechen. Allerdings verzögert sich hierdurch jedoch auch der Abschluß der Transaktion, falls nicht alle zur Abgabe einer Stimme aufgeforderten Knoten ihre Stimme abgeben. Wie schon in Abschnitt 4.4.3.2 erwähnt ist es weiterhin möglich, durch Wahl eines anderen Algorithmus den Nachrichtenaufwand für das Auswahlprotokoll zu reduzieren – allerdings auch auf Kosten der Zeit. 4.5.3 Algorithmus zur Stufenkonstruktion Der in diesem Abschnitt beschriebene Algorithmus hat zum Ziel, die Knoten einer Stufe derart auszuwählen, daß der Kommunikationsmehraufwand so weit wie möglich reduziert wird. Dabei wird auf die im letzten Abschnitt erlangten Erkenntnisse zurückgegriffen. Die grundlegende Idee des Algorithmus ist, so viele reguläre Knoten wie möglich zur Konstruktion der Stufe zu verwenden und dabei – sofern Freiheiten in der Wahl der Knoten bestehen – sicherzustellen, daß aufeinanderfolgende Stufen möglichst viele Knoten gemeinsam haben. Als Eingabeparameter erhält der Algorithmus die Anzahl n der Knoten, aus denen die nächste Stufe Si+1 bestehen soll, die Reiseroute des Agenten und die Menge der Knoten der aktuellen Stufe Si. Der Algorithmus wird auf dem Arbeiter Wi der Stufe Si ausgeführt und bestimmt die Knoten der Stufe Si+1 nebst deren Priorität. Zur Vereinfachung bezeichnen im folgenden Si und Si+1 jeweils auch die Menge der Knoten der Stufen Si und Si+1 (aus Kontext ersichtlich). In einem ersten Schritt (1)1 bestimmt der Algorithmus mittels der Reiseroute die Menge Nexti. Nexti enthält jene Knoten, auf denen der Agent laut Reiseroute als nächstes einen Schritt aus- führen kann. Die hierzu notwendige Funktionalität hat die Reiseroute zur Verfügung zu stellen. Der Inhalt dieser Menge ist im allgemeinen davon abhängig, welcher Knoten der Stufe (hier der Arbeiter Wi) den Agent (und damit den Algorithmus zur Stufenkonstruktion der folgenden Stufe) ausführt. Sowohl die Menge Nexti als auch Si kann Knoten enthalten, von denen Wi weiß, 1. Die Zahlen in Klammern beziehen sich auf die Numerierung in Algorithmus 4-9 nK 1–( ) 2⁄ 118 Kapitel 4 Genau-einmal Ausführungdaß sie momentan nicht verfügbar sind – z.B. weil die Migration eines anderen Agenten dorthin gerade fehlschlug. Ist dies der Fall, so werden diese Knoten aus Nexti und Si vor der Ausführung der weiteren Schritte des Algorithmus entfernt (2). Im zweiten Schritt werden dann die Knoten in Si+1 bestimmt. Hierbei kann man drei verschie- dene Fälle unterscheiden. In den ersten beiden Fällen enthält Nexti ausreichend Knoten, sodaß alle Knoten in Si+1 reguläre Knoten sind. Während im ersten Fall die Anzahl der Knoten in Nexti genau der Anzahl der Knoten in der nächsten Stufe entspricht und somit die Knoten der näch- sten Stufe feststehen, muß im zweiten Fall (mehr Knoten in Nexti als für nächste Stufe notwen- dig) aus Nexti eine Untermenge bestimmt werden. Dies geschieht, indem man versucht, die Schnittmenge zwischen aktueller Stufe und der nächsten möglichst groß zu machen (kein Code- Transport auf die Knoten der aktuellen Stufe notwendig) und vor allem möglichst den aktuellen Arbeiter mit einzubeziehen (kein Transport des Agenten notwendig). Im dritten Fall enthält Nexti zu wenig Knoten für die nächste Stufe und man muß Ausnahmebehandlungsknoten su- chen. Hier werden aus den oben genannten Gründen bevorzugt der momentane Arbeiter und die Knoten der aktuellen Stufe verwendet, bevor auf andere Knoten zurückgegriffen wird. Die fol- genden Absätze beschreiben diese drei Fälle detailliert: Fall 1: (3) Im einfachsten Fall ist die Kardinalität von Nexti (|Nexti|) gleich der gewünschten An- zahl von Knoten in Si+1. In diesem Fall können die Knoten in Nexti direkt als Knoten in Si+1 Algorithmus 4-9. Stufenkonstruktion buildStage(stageSize, Si, itinerary){ next = itinerary.getNextPossibleNodes() (1) remove non-available nodes from Si and next (2) Si+1 = {} W = current worker if (|next| == stageSize){ (3) Si+1 = next } else if (|next| > stageSize){ (4) Si+1 = Si ∩ next if (Si+1 > stageSize){ (5) determine priority of nodes in Si+1 remove |Si+1|-stageSize nodes with lowest priorities from Si+1 if (W ∈ next AND W ∉ Si+1){ (6) remove node with lowest priority from Si+1 add W to Si+1 } } else if (Si+1 < stageSize){ (7) determine priority of nodes in next\Si+1 add stageSize-|Si+1| nodes with highest priorities from next\Si+1 to Si+1 } } else { // |next| < stageSize (8) Si+1 = next (9) if (W ∉ Si+1){ add W to Si+1 (10) } m = stageSize - |Si+1| if (m≤|Si\Si+1|){ (11) determine priorities of nodes in Si\Si+1 add m nodes from Si\Si+1 with highest priorities to Si+1 }else{ (12) add Si\Si+1 to Si+1 add stageSize-|Si+1| arbitrary available nodes to Si+1 } determine priorities of nodes in Si+1 } 4.5 Kommunikationsaufwand und Stufenkonstruktion 119verwendet werden, d.h. Si+1=Nexti. Somit enthält Si+1 nur reguläre Knoten. Die Zuordnung von Prioritäten zu diesen Knoten wird weiter unten beschrieben. Fall 2: (4) Ist die Kardinalität von Nexti größer als die gewünschte Anzahl n von Knoten in Si+1, so besteht auch hier die resultierende Stufe nur aus regulären Knoten. Um die aus Nexti für die Bildung von Si+1 zu verwendenden Knoten zu bestimmen, wird zuerst Si+1=Si∩Nexti berechnet. Hierdurch wird sichergestellt, daß Si und Si+1 möglichst viel gemeinsame Knoten enthalten, wo- durch der Transport vom Agentencode auf diese Knoten eingespart werden kann. Falls Si+1 da- nach noch zu viele Knoten enthält (5), d.h. falls |Si+1|>n, werden die Prioritäten der Knoten be- stimmt (siehe weiter unten) und die n Knoten mit der höchsten Priorität verbleiben dann in Si+1. Ist jedoch |Si+1|n bedeutet dies, daß nur die n-1 Knoten mit der höchsten Priorität und zusätzlich Wi in Si+1 aufgenommen werden, falls Wi nicht in den n Knoten mit der höchsten Priorität enthalten ist (6). Die letztendliche Zuordnung der Prioritä- ten zu den Knoten wird weiter unten beschrieben. Fall 3: (8) Ist die Kardinalität von Nexti kleiner als n (d.h. |Nexti||Si\Nexti| (12), werden alle Knoten aus Si\Nexti als Ausnahmebe- handlungsknoten verwendet. Für die Auswahl der jetzt noch fehlenden m-|Si\Nexti| Ausnahme- behandlungsknoten können entweder beliebige Knoten oder Knoten, die als zukünftige (poten- tielle) Ziele des Agenten in der Reiseroute stehen, verwendet werden. Insgesamt enthält die Stufe Si+1 im Falle |Nexti|n) reduziert zwar möglicherweise die Anzahl der Nachrichten und die Menge der zu übertragenden Daten, es sorgt aber dafür, daß die in einer Reiseroute möglicherweise definierten Prioritäten nicht eingehalten werden. Um die Prioritäten der Reiseroute möglichst einzuhalten, müßten für diesen Fall die n Knoten mit der höchsten Priorität aus Nexti für Si+1 genommen werden – ohne Rücksicht auf Si. Sollte die Ein- haltung der Prioritäten wichtiger sein als die Reduktion des Kommunikationsaufwandes, so darf also für den Fall Nexti>n nicht nach der oben beschriebenen Weise vorgegangen werden, son- dern es müssen für die Bildung der Stufe die n Knoten mit der höchsten Priorität aus Nexti ver- wendet werden. In einem letzten Schritt werden die Prioritäten für die Knoten der Stufe Si+1 endgültig festge- legt. Hierbei wird prinzipiell so vorgegangen, daß zuerst die Prioritäten der Ausnahmebehand- lungsknoten festgelegt werden und danach die Prioritäten der regulären Knoten so festgelegt werden, daß die Priorität der regulären Knoten höher ist als die Priorität der Ausnahmebehand- lungsknoten. Es muß hierbei auf jeden Fall darauf geachtet werden, daß jeder Knoten der Stufe eine eindeutige Priorität besitzt (d.h. es darf keine 2 Knoten mit derselben Priorität in einer Stufe geben). Bei der Festlegung von Prioritäten sind im Kontext dieses Algorithmus mehrere Strate- gien möglich. Legt die Reiseroute Prioritäten zwischen den regulären Knoten der Stufe fest, so muß sich dies in den Stufenprioritäten der regulären Knoten widerspiegeln, d.h. sind Knoten x und Knoten y reguläre Knoten der Stufe und spezifiziert die Reiseroute, daß x eine höhere Prio- rität als y besitzt, so muß x in der Stufe eine höhere Priorität haben als y. Spezifiziert die Reise- route zwischen zwei Knoten keine Priorität bzw. für zwei Knoten dieselbe Priorität, so kann man die Priorität der beiden Knoten mit einer der folgenden Strategien festlegen. Eine mögliche Strategie zur Festlegung der Prioritäten der Ausnahmebehandlungsknoten bzw. der Prioritäten von regulären Knoten, zwischen denen die Reiseroute keine Prioritäten festlegt, ist die Verwendung zufälliger Prioritäten. Eine effizientere Strategie ist möglich, wenn Wissen über die Zuverlässigkeit von Knoten verfügbar ist. In diesem Falle bekommen Knoten mit hö- herer Verfügbarkeit eine höhere Priorität (die Priorität zwischen Knoten mit gleicher Zuverläs- sigkeit kann dann wieder zufällig festgelegt werden). Bei Verwendung dieser Heuristik werden Knoten mit höherer Zuverlässigkeit für die Ausführung des Agenten bevorzugt. Die durch den Algorithmus erreichbare Reduktion des Kommunikationsmehraufwandes zeigt Tabelle 4-1. Bei einer Stufengröße von n=3 Knoten reduziert sich beispielsweise bei der Ver- wendung von nur einem Knoten der aktuellen Stufe als Knoten der nächsten Stufe die Anzahl der notwendigen Agentencode-Transporte um ein Drittel. Die in Abbildung 4-22 abgebildete (einfache) Beispielreiseroute, welche mit einer konstanten Stufengröße von n=3 Knoten abgearbeitet werden soll, zeigt einen optimalen Fall für den Algo- rithmus zur Stufenkonstruktion. Die erste Stufe enthält die Knoten N1 bis N3 als reguläre Knoten sortiert nach ihrer Priorität. Zum Start des Agenten wird der Stufen-Record, der Code des Agen- ten und eventuell Datenzustand mittels 3 Migrationsnachrichten und 3 Bestätigungen auf die 4.5 Kommunikationsaufwand und Stufenkonstruktion 121Knoten der ersten Stufe transportiert. Für den Abschluß der Starttransaktion werden 4*3 Nach- richten für das 2PC-Protokoll benötigt. In der zweiten Stufe wird der Arbeiter der ersten Stufe (z.B. N1) als Ausnahmebehandlungsknoten verwendet, N2 und N3 sind reguläre Knoten. In die- sem Fall sind nur zwei Migrationsnachrichten (auf N2 und N3) und deren Bestätigung notwen- dig, wobei hier jedoch kein Transport des Agentencodes mehr notwendig ist. Auch die zur Be- endigung der Schritt-Transaktion der ersten Stufe notwendigen Nachrichten des 2PC- Protokolles reduzieren sich auf 4*2. In der dritten Stufe werden N1 und der Arbeiter der zweiten Stufe (z.B. N2) als Ausnahmebehandlungsknoten verwendet, N3 ist der (einzige) reguläre Kno- ten. Auch hier fallen wieder nur zwei Migrationsnachrichten (auf N1 und N3) und deren Bestä- tigung sowie 4*2 Nachrichten des 2PC-Protokolles an. Insgesamt ergibt sich für Migration und 2PC-Protokoll also ein Aufwand von 7 Migrationsnachrichten, davon nur 3 Nachrichten mit Agentencode, 7 Bestätigungsnachrichten und 4*7=28 Nachrichten für das 2PC-Protokoll. Im Vergleich zum Basisprotokoll ist das ein Mehraufwand von 4 Migrationsnachrichten, deren 4 Bestätigungen und 16 Nachrichten für das 2PC-Protokoll. Da die 4 zusätzlichen Migrations- nachrichten jeweils keinen Agentencode enthalten, entsteht kein überflüssiger Code-Transport. Ohne die Flexibilität in der Reiseroute und ohne die Optimierung des Algorithmus zur Stufen- konstruktion würde sich (bei Auswahl von jeweils 2 beliebigen Ausnahmebehandlungsknoten pro Stufe) für die Migration und das 2PC-Protokoll ein Aufwand von 9 Migrationsnachrichten (jeweils inklusive Agentencode), deren 9 Bestätigungen und 36 Nachrichten für das 2PC-Pro- tokoll ergeben. Auch für das in Abbildung 4-23 nochmals abgebildete Beispiel aus Abschnitt 3.1 liefert der Al- gorithmus gute Ergebnisse. Die erste Stufe (n=3) besteht aus den zwei für die Kinos zuständigen Code-Transporte Migrationsnachrichten + Bestätigungen Nachrichten für 2PC Si ∩ Si+1 = ∅ n 2n 4n Si ∩ Si+1 ≠ ∅ ∧ Wi∉Si+1 n-|Si ∩ Si+1| 2n 4n Si ∩ Si+1 ≠ ∅ ∧ Wi∈Si+1 n-|Si ∩ Si+1| 2(n-1) 4(n-1) Tabelle 4-1. Reduktion des Kommunikationsaufwandes durch den Algorithmus zur Stufenkonstruktion Abbildung 4-22. Einfache Beispielreiseroute Menge (N3, m) (N1, m) (N2, m) 122 Kapitel 4 Genau-einmal AusführungKnoten und dem Fleurop-Knoten (3 Migrationsnachrichten, 3 Bestätigungen, 4*3 2PC-Nach- richten). Wird der Agent in der ersten Stufe auf dem Knoten des Blumenladen ausgeführt, so besteht die zweite Stufe aus den zwei für die Kinos zuständigen Knoten (reguläre Knoten) und dem Fleurop-Knoten als Ausnahmebehandlungsknoten (zwei Migrationsnachrichten ohne Agentencode, 3 Bestätigungen, 4*2 2PC-Nachrichten). Die dritte Stufe besteht dann aus einem der Restaurant-Knoten (abhängig davon, welcher der Kino-Knoten verwendet wurde), dem Ar- beiter der zweiten Stufe und einem weiteren Knoten der zweiten Stufe (zwei Migrationsnach- richten, davon eine ohne Agentencode, 2 Bestätigungen, 4*2 2PC-Nachrichten). Dies ergibt ei- nen Gesamtaufwand von 7 Migrationsnachrichten (Mehraufwand im Vergleich zum Basisprotokoll: 4 Nachrichten), 7 Bestätigungen (Mehraufwand: 4 Nachrichten) und 28 2PC- Nachrichten (Mehraufwand: 16 Nachrichten). Im Gegensatz zum vorhergehenden Beispiel ent- hielten hier jedoch nur 3 Migrationsnachrichten keinen Agentencode, sodaß hier ein Mehrauf- wand von einem Codetransport entstand. Wird der Agent in der ersten Stufe anstatt auf dem Fleurop-Rechner auf einem der Restaurant-Knoten ausgeführt, so kann es einen zusätzlichen Code-Transport geben, wenn der Fleurop-Knoten nicht in der zweiten Stufe enthalten ist, da Next2 nur einen Restaurant-Knoten enthält und daher der Algorithmus eventuell die zwei Kino- Knoten als Ausnahmebehandlungsknoten verwendet. In diesem Falle muß der Agentencode in der dritten Stufe erneut auf den Fleurop-Knoten transportiert werden. Es zeigt sich also, daß die intelligente Zusammensetzung der Knoten einer Stufe den Kommu- nikationsmehraufwand deutlich senken kann. Eine Implementation des Algorithmus in Kombi- nation mit der von BUSCHLE (1999) entwickelten Reiseroute findet man in PAPOULIDIS (1999). 4.6 Analytische Bewertung der Fehlertoleranz Die Bewertung der durch ein Protokoll gewonnenen Fehlertoleranz kann prinzipiell auf zwei Arten geschehen: durch Messung aufgrund der Implementierung (entweder in einer realen Um- gebung oder einer Simulationsumgebung) des Protokolles oder durch analytische Bewertung. Da in der analytischen Bewertung der Zusammenhang zwischen den Elementen des Protokolles und deren Auswirkung auf die Fehlertoleranz offensichtlicher zu Tage tritt als in der Bewertung mittels Messungen, wird in diesem Abschnitt der analytische Ansatz verfolgt. Der Abschnitt 4.7 Abbildung 4-23. Beispiel aus Abschnitt 3.1 Menge (Fleurop, kaufeBlumen) (Luna, kaufeEintrittskarte) (Planie, kaufeEintrittskarte) (Rößle, reserviereTisch) (Linde, reserviereTisch) Alternative Sequenz 4.6 Analytische Bewertung der Fehlertoleranz 123befaßt sich dann mit der Messung des durch das Protokoll erzeugten Mehraufwandes. Um die entwickelten Protokolle analytisch untersuchen zu können ist ein Verfahren notwendig, das die Modellierung der Protokollausführung so exakt wie möglich erlaubt. Hierzu ist die ein- fache Wahrscheinlichkeitsrechnung, welche i.a. die Unabhängigkeit der betrachteten Ereignisse voraussetzt, nicht geeignet. Es ist daher notwendig, auf die Theorie der stochastischen Prozesse zurückzugreifen. Für die Beschreibung technischer Probleme eignen sich bevorzugt Markov- Modelle (vgl. z.B. SCHNEEWEISS (1992)). Der folgende Abschnitt bietet eine kurze Einführung in die Grundlagen der Markov-Modelle. Anschließend erfolgt die Analyse der entwickelten Protokolle. Die Analyse basiert auf der von FRIEDEL (1998) durchgeführten Diplomarbeit. 4.6.1 Markov-Modelle Im Gegensatz zu booleschen Modellen, welche die Komponenten eines Systems nur mit den Zuständen “intakt” und “defekt” beschreiben (vgl. SCHNEEWEISS (1973)), erlauben Markov- Modelle die Beschreibung von Systemen mit beliebig großen diskreten oder kontinuierlichen Zustandsmengen. Neben der Berechnung von Ausfallwahrscheinlichkeiten ermöglichen Mar- kov-Modelle auch noch die Berechnung weiterer, für die vorzunehmende Analyse interessanter Kenngrößen (z.B. die mittlere Aufenthaltsdauer in Zustandsmengen). Eine Einschränkung in der Anwendbarkeit der Markov-Modelle ergibt sich aus der Grundvor- aussetzung, daß die betrachteten Lebensdauern und Reparaturzeiten voneinander unabhängig und exponentiell verteilt sein müssen. Eine exponentielle Verteilung der Lebensdauer einer Komponente bedeutet, daß deren Ausfallwahrscheinlichkeit zu jedem Zeitpunkt gleich hoch ist. Die betrachteten Zufallsgrößen besitzen also eine Verteilungsfunktion der Form (4-15) Für eine -exponentiell verteilte Zufallsgröße ergibt sich der Erwartungswert E(T) von T zu (4-16) Diese Voraussetzung trifft jedoch auf technische Systeme, also auch auf das hier betrachtete Sy- stem, weitgehend zu und stellt deshalb keine wesentliche Einschränkung dar. In diesem Abschnitt werden nun die Grundbegriffe und einige wesentliche Sätze aus dem Be- reich der Markov-Modelle basierend auf GAEDE (1977) und HÖFLE-ISPHORDING (1978) einge- führt. F t( ) 0 für t 0< 1 e λt– – für t 0 λ 0>,≥  = λ E T( ) 1λ--= 124 Kapitel 4 Genau-einmal AusführungDefinition 4-2: Markov Prozeß Ein diskreter stochastischer Prozeß {X(t), t∈T} mit der Wertemenge E={0,1,2,...} heißt ein (diskreter) Markov Prozeß, wenn für beliebige t1 < t2 < ... < tn ∈ T und für beliebige Zahlen i1, i2, ..., in-2, i, j ∈ E folgende Bedingung erfüllt ist: (4-17) Die Gleichung (4-17) heißt Markov-Eigenschaft, die bedingten Wahrscheinlichkei- ten heißen Übergangswahrscheinlichkeiten. Anschaulich bedeutet die Markov-Eigenschaft, daß die Wahrscheinlichkeit, sich zum Zeitpunkt tn in einem Zustand j zu befinden, nur davon abhängt, in welchem Zustand sich das System zum Zeitpunkt tn-1 befunden hat (X(t) bezeichnet den Zustand des Systems zum Zeitpunkt t). Definition 4-3: Homogenität von Markov Prozessen Ein (diskreter) Markov Prozeß heißt homogener Markov Prozeß, wenn für ihn wei- terhin die folgende Bedingung erfüllt ist: (4-18) Anschaulich bedeutet dies, daß bei einem homogenen Markov Prozeß die Übergangswahr- scheinlichkeiten pij(t) nur von der Differenz tn-tn-1 (und nicht von der absoluten Zeit tn) abhän- gen. In diesem Falle gilt dann für die Übergangswahrscheinlichkeiten auch die Beziehung (4-19) Definition 4-4: Absolute Wahrscheinlichkeit Pk(t) Die absolute Wahrscheinlichkeit Pk(t) = p(X(t)=k) bezeichnet die Wahrscheinlich- keit, daß sich das System zum Zeitpunkt t im Zustand k befindet. p X tn( ) j X tn 1–( ) i X tn 2–( ) in 2– … X t1( ), i1=,=,==( ) p X tn( ) j X tn 1–( ) i==( ) = p X t s+( ) j X t0 s+( ) i==( ) p X t( ) j X t0( ) i==( ) pij t( )= = i j E s∀,∈, 0 t 0 t0 0≥,≥,≥∀ pij t( ) j E∈ ∑ 1 i E t 0≥;∈( ),= 4.6 Analytische Bewertung der Fehlertoleranz 125Satz 4-1: Ist {X(t), t∈T} ein diskreter homogener Markov Prozeß mit den Zuständen 1, 2, ..., n und sind die Übergangswahrscheinlichkeiten pij(t) stetig an der Stelle t=0 und differenzierbar für alle t≥0, dann gilt für die zeitlichen Ableitungen : (4-20) (4-21) Hierbei ist aji die Ableitung von pij(t) an der Stelle t=0 und heißt Übergangsrate von Zustand i nach Zustand j. Da die betrachteten Zufallsgrößen exponentiell verteilt sind, ergibt sich der Er- wartungswert für die Übergangszeit von Zustand i in Zustand j zu 1/aji. Der Beweis für Glei- chung (4-20) und Gleichung (4-21) findet man in HÖFLE-ISPHORDING (1978). Gleichung (4-21) läßt sich mittels Vektoren und Matrizen einfacher darstellen: (4-22) (4-23) Die Matrix A wird im weiteren auch als Übergangsmatrix bezeichnet. Das Differentialgleichungssystem kann mittels der Laplace-Transformation einfach gelöst wer- den. Bezeichne die Laplace-Transformierte von . p· ik P · k, p· ik t( ) akjpij t( ) j 1= n ∑= i k,∀ P · k t( ) akiPi t( ) i 1= n ∑= k∀ A a11 a12 … a1n a21 a22 … … an1 ann = P t( ) P1 t( ) P2 t( ) … Pn t( ) =, P · t( ) A P t( )⋅= P s( ) P 1 s( ) … P n s( ) = ) ) ) P t( ) P1 t( ) … Pn t( ) = 126 Kapitel 4 Genau-einmal AusführungFür die Lösung des Gleichungssystems kann man weiterhin die folgende Eigenschaft der La- place-Transformation für differenzierbare f(t) ausnutzen: Damit läßt sich Gleichung (4-23) umformen zu (4-24) Nach aufgelöst ergibt sich (mit n-reihiger quadratischer Einheitsmatrix I) (4-25) Für größere n wird die Berechnung der Lösung dieser Gleichung durch die aufwendige Matri- zeninversion recht komplex. Definition 4-5: Stationärer Zustand, stationäre Lösung Existiert der Grenzwert , so existiert ein stationärer Zustand, dem der Pro- zeß zustrebt. In diesem Fall wird als stationäre Lösung bezeichnet. Satz 4-2: Ist für einen homogenen Markov Prozeß mit endlich vielen Zuständen die Bedin- gung , so daß gilt (4-26) erfüllt, dann existieren die Grenzwerte und es gilt Den Beweis für diesen Satz findet man in LAHRES (1964). Vereinfacht sagt der Satz aus, daß es einen stationären Zustand gibt, falls zu einem beliebigen Zeitpunkt t0 jeder Zustand von jedem anderen Zustand aus erreichbar ist. Existiert ein stationärer Zustand, so gilt weiter . Dadurch läßt sich Gleichung (4-23) im Grenzwert vereinfachen zu (4-27) L td d f t( )   s f s( ) f 0( )–⋅= ) s P s( ) P 0( )–⋅ A P s( )⋅= ) ) P s( ) ) P s( ) s I A–⋅( ) 1– P 0( )⋅= ) P t( ) t ∞→ lim P t( ) t ∞→ lim P ˜ = t0 T∈∃ pij t0( ) 0 i j,∀> pij t( ) t ∞→ lim und Pj t( ) t ∞→ lim pij t( ) t ∞→ lim = Pj t( ) t ∞→ lim P · t( ) 0 für t ∞→= 0 A P ˜ ⋅= 4.6 Analytische Bewertung der Fehlertoleranz 127Weiterhin gilt (4-28) Definition 4-6: absorbierender Zustand Ein Zustand i heißt absorbierender Zustand wenn gilt Ein absorbierender Zustand wird also, sobald er einmal erreicht wird, nicht wieder verlassen. Satz 4-3: Ist I eine Zustandsmenge, und sind alle Elemente ∉I absorbierend und zum Zeit- punkt t=0 liegt ein Zustand aus I vor, so ist (4-29) die Wahrscheinlichkeit, daß bis zum Zeitpunkt t ein Zustand aus I vorliegt. Bedeutet weiter TI die Aufenthaltsdauer in der Zustandsmenge I, und existiert der Erwar- tungswert von TI, so gilt (4-30) Wegen der Additivität der Laplace-Transformation gilt damit auch: (4-31) Definition 4-7: Verfügbarkeit, Dauerverfügbarkeit Die Wahrscheinlichkeit, ein System zum Zeitpunkt t im Zustand “intakt” anzutref- fen wird als die Verfügbarkeit V(t) des Systems zum Zeitpunkt t bezeichnet: V(t) = P[ System ist zum Zeitpunkt t intakt ] Im allgemeinen interessiert man sich bei einem System vor allem für die Dauerver- fügbarkeit V= die angibt, mit welcher Wahrscheinlichkeit das System zu einem beliebigen Zeitpunkt sich im Zustand “intakt” befindet. P ˜ i i 1= n ∑ 1= für die Zustandsmenge E, 1 2 … n, ,{ , }= pii t( ) 1 t 0≥∀,= R t( ) Pi t( ) i I∈ ∑= µ1 µ1 R s( ) s 0→ lim= ) µ1 P i s( ) s 0→ lim i I∈ ∑= ) V t( ) t ∞→ lim 128 Kapitel 4 Genau-einmal Ausführung4.6.2 Einschränkung des Fehlermodells Für die Modellierung der zu untersuchenden Protokolle muß das in Abschnitt 4.1.3 festgelegte Fehlermodell eingeschränkt werden. Bei den Knoten ist keine Einschränkung des Fehlermo- dells notwendig. Knoten unterliegen Crash-Fehlern, d.h. bei einem Knotenfehler hält der Kno- ten die Ausführung aller Programme an; der Ausfall einer echten Teilmenge der Prozesse eines Knotens ist ausgeschlossen. Netzwerkfehler, auch nicht eingeschränkt auf Netzwerkpartitionen, können bei der Untersu- chung nicht berücksichtigt werden. Bei Markov-Modellen müssen die zu untersuchenden Zu- fallsgrößen voneinander unabhängig sein. Dies trifft im Falle der Netzwerkpartitionierung (wel- che laut Abschnitt 4.1.3 der einzige betrachtete Netzwerkfehler ist) jedoch weder in realen Netzwerken noch in dem in Abschnitt 4.1.2 eingeführten Netzwerkmodell (je ein Kommunika- tionskanal zwischen zwei Rechnern) zu: entsteht eine Netzwerkpartition, so müssen mehrere Verbindungen gleichzeitig (d.h. abhängig) ausfallen. Neben den Markov-Modellen gibt es zwar weitere, noch wesentlich komplexere Modelle, welche auch mit solchen Fällen zurecht kom- men. Mathematisch ist dies aber bei einem derart komplexen Problem kaum noch erfaßbar. Au- ßerdem könnte auch eine Anwendung dieser komplexeren Modelle keine allgemeingültigen Er- gebnisse liefern, da die Wahrscheinlichkeiten für Netzwerkpartitionierungen – und damit die Wahrscheinlichkeiten für den Ausfall der Kommunikationskanäle zwischen den Knoten – stark von der Topologie des die Knoten verbindenden Netzwerkes abhängen. Es wäre also jeweils nur eine Aussage für eine bestimmte Ausprägung der Netzwerktopologie möglich. 4.6.3 Verfügbarkeit eines Knotens Die Verfügbarkeit eines einzelnen Knotens wird in den folgenden Abschnitten immer wieder benötigt und daher an dieser Stelle berechnet. Laut Fehlermodell befindet sich ein Knoten in ex- akt einem der Zustände “intakt” oder “defekt”. Abbildung 4-24. Modell eines Knotens 0 1 f r intakt defekt 4.6 Analytische Bewertung der Fehlertoleranz 129Die zwei Zustände des Knoten und die Übergänge zwischen diesen Zuständen zeigt Abbildung 4-24. Mit der Übergangsrate f (Ausfallrate) geht ein Knoten vom Zustand “intakt” in den Zu- stand “defekt” über. Der Erwartungswert für diesen Übergang (d.h. die mittlere Zeit bis von Zu- stand “intakt” in den Zustand “defekt” übergegangen wird) beträgt 1/f. Ist der Knoten im Zu- stand “defekt”, so wird er repariert und geht mir der Übergangsrate r (Reparaturrate) in den Zustand “intakt” über. Auch hier beträgt der Erwartungswert für diesen Übergang 1/r. Die bei- den Erwartungswerte werden i.a. auch mit MTTF (Mean Time To Failure, mittlere Zeit bis zum Ausfall) und MTTR (Mean Time To Repair, mittlere Reparaturzeit) bezeichnet: MTTF = 1/f, MTTR = 1/r. Im weiteren wird davon ausgegangen, daß r und f für alle Knoten gleich sind. Die Verfügbarkeit VK(t) des Knotens entspricht der Wahrscheinlichkeit, den Knoten im Zustand 0 (“intakt”) vorzufinden, d.h. VK(t) = P0(t). Die Übergangsmatrix für das System ergibt sich zu (4-32) Für diesen Fall trifft Satz 4-2 zu, somit kann VK durch lösen des Gleichungssystems (4-27) unter Berücksichtigung von Gleichung (4-28) berechnet werden: Hieraus ergibt sich für die Verfügbarkeit Vk: (4-33) Durch Einsetzen von MTTF = 1/f und MTTR = 1/r und anschließender Umformung erhält man die bekanntere Formel (4-34) 4.6.4 Systemverfügbarkeit und Blockierwahrscheinlichkeit Ein wichtiges Maß bei der Untersuchung von Fehlertoleranz ist die Verfügbarkeit eines Sy- stems. Bei den in diesem Kapitel vorgestellten Protokollen ist jedoch die Definition, was unter Verfügbarkeit des Systems zu verstehen ist, nicht auf den ersten Blick klar. Die Unterteilung der Verarbeitung des Agenten in abgeschlossene, innerhalb einer Schritt-Transaktion ausgeführte A f– r f r– = 0 f– r f r– P ˜ ⋅= 0 f P˜0 r P˜1⋅–⋅= 1 P ˜ 0 P ˜ 1+= VK P ˜ 0 r r f+---------= = VK MTTF MTTF MTTR+ --------------------------------------= 130 Kapitel 4 Genau-einmal AusführungSchritte legt jedoch die Festlegung nahe, daß das System genau dann verfügbar ist, wenn die zum Abschluß einer Schritt-Transaktion notwendigen Knoten verfügbar sind. 4.6.4.1 Basisprotokoll Bei der Ausführung eines mobilen Agenten mittels des in Abschnitt 4.3 vorgestellten Basispro- tokolls sind während der Ausführung einer Schritt-Transaktion zwei Knoten beteiligt: der Kno- ten, auf dem der aktuelle Schritt ausgeführt wird und, da der Agent noch innerhalb der Trans- aktion migriert, der Knoten, auf dem der folgende Schritt ausgeführt werden soll. Der Beitrag dieser beiden Knoten zum Gelingen einer Schritt-Transaktion ist jedoch sehr verschieden: Der Knoten, auf dem der aktuelle Schritt ausgeführt wird ist unverzichtbar, d.h. wenn dieser ausfällt, ist das System für den auszuführenden Agent auf jeden Fall nicht verfügbar. Unter der Annah- me, daß für den nächsten auszuführenden Schritt ausreichend viele alternative Knoten zur Ver- fügung stehen, kann noch vor der Migration getestet werden, welcher dieser Knoten momentan verfügbar ist und einer der verfügbaren Knoten als Ziel der Migration verwendet werden. Den- noch kann natürlich der gewählte Knoten nach diesem Test noch ausfallen. Dieser Ausfall kann jedoch nur zum (verzögerten) Rücksetzen der Schritt-Transaktion (und nicht zum Blockieren) führen, da der Koordinator des 2PC-Protokolles der Schritt-Transaktion auf dem Knoten sitzt, auf dem der aktuelle Schritt ausgeführt wird. In diesem Fall kann die Schritt-Transaktion ein- fach wiederholt werden – das System steht also immer noch zur Ausführung des Agenten zur Verfügung. Daher läßt sich beim Basisprotokoll die Verfügbarkeit Vs des Systems auf die Ver- fügbarkeit des Knotens, der den aktuellen Schritt ausführt, reduzieren: (4-35) Die Blockierwahrscheinlichkeit Bs bei der Ausführung eines Schrittes, d.h. die Wahrscheinlich- keit daß der Agent während der Ausführung eines Schrittes blockiert wird, berechnet sich mit- tels (4-36) 4.6.4.2 Blockierungsfreies Protokoll Bei der Ausführung eines mobilen Agenten mittels des in Abschnitt 4.4 vorgestellten blockie- rungsfreien Protokolls sind während der Ausführung einer Schritt-Transaktion sowohl die Kno- ten der aktuellen Stufe als auch die Knoten der nächsten Stufe beteiligt. Eine analog dem vor- herigen Abschnitt geführte Argumentation erlaubt auch hier, die Betrachtung der Verfügbarkeit auf die Knoten der aktuellen Stufe einzuschränken. Vs Vk r r f+---------= = Bs 1 V– s= 4.6 Analytische Bewertung der Fehlertoleranz 131Während für die Ausführung des Schrittes als solchem die Verfügbarkeit eines einzelnen Kno- tens der Stufe ausreicht, ist für eine erfolgreiche Durchführung des Votierens (und damit den Abschluß der Schritt-Transaktion) die Verfügbarkeit der Mehrheit der Knoten der Stufe zwin- gend notwendig. Bei einer Stufengröße von n Knoten müssen also mindestens Knoten der Stufe verfügbar sein (die Gauß-Klammer bedeutet hierbei, daß zur nächst größeren ganzen Zahl aufgerundet wird). Abbildung 4-25 zeigt das Markov-Modell einer Stufe. Im Zu- stand i der Stufe sind genau i Knoten der Stufe intakt. Da im Zustand i also i Knoten ausfallen können, erfolgt der Übergang zum Zustand i-1 (ein weiterer Knoten ausgefallen) mit der i-fa- chen Ausfallrate if. Analoges gilt für die Reparaturrate: im Zustand i sind n-i Knoten ausgefal- len, also erfolgt der Übergang zum Zustand i+1 mit der Reparaturrate (n-i)r. Aus dem Modell ergibt sich dann (nach Gleichung (4-21)) das dazugehörige Differentialglei- chungssystem: Da das vorliegende System die Bedingung (4-26) aus Satz 4-2 erfüllt, gilt Gleichung (4-27) und man erhält zusammen mit Gleichung (4-28) für den stationären Fall Abbildung 4-25. Modell zur Berechnung der Verfügbarkeit einer Stufe n 1+ 2 ----------- 0 1 f nr 2 2f (n-1)r n-1 n nf r P · 0 t( ) n r⋅– P0 t( ) f P1 t( )⋅+⋅= P · i t( ) r n i– 1+( )Pi 1– t( ) i f⋅ r n i–( )+( )Pi t( ) i 1+( ) f Pi 1+ t( )⋅ ⋅+–= i 1 2 …n 1–, ,{ }∈ P · n t( ) r Pn 1– t( ) n f Pn t( )⋅ ⋅–⋅= 0 n r⋅– P ˜ 0 f P˜1⋅+⋅= 0 r n i– 1+( )P˜ i 1– i f⋅ r n i–( )+( )P˜ i i 1+( ) f P˜ i 1+⋅ ⋅+–= i 1 2 …n 1–, ,{ }∈ 0 r P ˜ n 1– n f P˜n⋅ ⋅–⋅= P ˜ i i 0= n ∑ 1= 132 Kapitel 4 Genau-einmal AusführungDie Lösung dieser Gleichung ergibt für die Aufenthaltswahrscheinlichkeit im Zustand i (d.h. Wahrscheinlichkeit, daß genau i Knoten der Stufe verfügbar sind) (4-37) Herleitung und Beweis dieser Lösung findet man in HÖFLE-ISPHORDING (1978). Diese Lösung läßt sich unter Verwendung von Gleichung (4-33) umformen zu (4-38) Für p=(Wahrscheinlichkeit, daß ein Knoten verfügbar ist)=VK ist dies die Binomialverteilung (vgl. HUGHES UND GRAWOIG (1971)) welche die Wahrscheinlichkeit berechnet, daß aus n Ele- menten genau i Elemente gezogen werden. Die Verfügbarkeit Vs,n eines Systems mit n Knoten pro Stufe ergibt sich dann zu (4-39) Für den Spezialfall n=1 ergibt sich aus dieser Formel erwartungsgemäß die Verfügbarkeit des Basisprotokolles. Die Blockierwahrscheinlichkeit Bs,n einer Stufe mit n Knoten berechnet sich zu (4-40) Die relative Blockierwahrscheinlichkeit Br,n einer Stufe mit n Knoten berechnet sich mittels (4-41) Eine relative Blockierwahrscheinlichkeit Br,n=0.4 bedeutet beispielsweise, daß die Wahrschein- lichkeit, daß ein Agent in einer Stufe mit n Knoten blockiert wird nur 40% der Wahrscheinlich- keit beträgt, daß ein Agent bei der Ausführung mittels des Basisprotokolles blockiert wird. P ˜ i n i   r f-   i f f r+---------   n i 0 1 …n, ,{ }∈,= P ˜ i n i   r f r+---------   i 1 rf r+---------–   n i– n i   VK( ) i 1 VK–( ) n i– = = Vs n, P ″System in einem der Zustände n 1+ 2 ----------- …n″ P ˜ i i n 1+ 2 ----------- = n ∑= = Bs n, 1 V– s n,= Br n, Bs n, Bs ---------= 4.6 Analytische Bewertung der Fehlertoleranz 133Tabelle 4-2 und Abbildung 4-26 zeigen die relative Blockierwahrscheinlichkeit Br abhängig von der Anzahl der Knoten n und der Einzelverfügbarkeit Vk eines Knotens. Auf ersten Blick fällt auf, daß der Wert für die Blockierwahrscheinlichkeit für ungerade n immer kleiner ist als der Wert für das größere n+1, sich die Blockierwahrscheinlichkeit also bei der Erhöhung der Kno- tenzahl von einem ungeraden n auf ein gerades n+1 erhöht. Dies ist jedoch verständlich, da für eine Stufe mit einer ungeraden Knotenzahl n für das erfolgreiche Votieren relativ gesehen we- niger Knoten ((n/2)+0.5) vorhanden sein müssen als bei einer Stufe mit einer geraden Knoten- anzahl ((n/2)+1). Insgesamt zeigt sich, daß ab einer Knotenanzahl von 3 Knoten pro Stufe die relative Blockierwahrscheinlichkeit wesentlich verringert wird und daß die Verwendung einer ungeraden Anzahl von Knoten pro Stufe empfehlenswert ist. 4.6.5 Verweildauer in einer Stufe Die Ergebnisse des letzten Abschnittes sind nur begrenzt aussagekräftig, da sie auf der Betrach- tung von Dauerverfügbarkeiten basieren, die über den zeitlichen Verlauf der Verfügbarkeit we- nig aussagen. Die Dauerverfügbarkeit hängt jedoch nur vom Verhältnis zwischen Ausfallrate und Reparaturrate ab, d.h. ein Knoten hat auch dann eine hohe Dauerverfügbarkeit, wenn die Ausfallrate zwar recht hoch ist, die Reparaturrate aber entsprechend kurz ausfällt. Bei hoher Ausfallrate sinkt die Zeit zwischen Knotenausfällen. Wird diese Zeit kürzer als die durch- schnittliche Zeit zur Ausführung eines Schrittes eines Agenten, so sinkt die Wahrscheinlichkeit, daß ein Schritt eines Agenten vollständig ausgeführt werden kann gegen null – der Agent wird trotz hoher Verfügbarkeit blockiert. Ein besseres Maß zur Bewertung der gewonnenen Fehlertoleranz, welches auch die Problematik des Verhältnisses zwischen Knotenausfallzeit und Zeit zur Ausführung eines Schrittes berück- sichtigt, besteht darin, die durchschnittliche Verweildauer eines Agenten in einer Stufe zu be- rechnen. Diese Zeit umfaßt den Zeitraum von der Ankunft des Agenten in der Stufe bis zum Tabelle 4-2. Relative Blockier- wahrscheinlichkeit einer Stufe Abbildung 4-26. Relative Blockier- wahrscheinlichkeit einer Stufe n Vk 0.75 0.9 0.99 1 100% 100% 100% 2 175% 190% 199% 3 62% 28% 3% 4 105% 52% 6% 5 41% 9% ~0% 6 68% 16% ~0% 7 28% 3% ~0% 1 3 5 7 9 0,7 0,8 0,9 0,95 0,99 0% 50% 100% B r n Vk 134 Kapitel 4 Genau-einmal AusführungCommit der Schritt-Transaktion und berücksichtigt auch zusätzliche Zeiten, die durch Ausfälle von Knoten entstehen können. Einen Ansatz zur Berechnung dieser durchschnittlichen Verweildauer bietet Satz 4-3. Während der Verarbeitung eines Agenten in einer Stufe tritt nie ein absorbierender Zustand ein, nur der Abschluß der Schritt-Transaktion mündet in einen absorbierenden Zustand. Da die bei der Be- rechnung der Verweildauer des blockierungsfreien Protokolles entstehenden Übergangsmatri- zen sehr groß werden, ist es sinnvoll, das Problem soweit als möglich in kleinere Teilprobleme zu zerlegen. Die 2-Phasigkeit des Commit-Protokolles bietet eine einfache Möglichkeit der Un- terteilung in 2 Abschnitte: Der erste Abschnitt beginnt mit dem Eintreffen des Agenten in der Stufe und endet mit der Commit-Entscheidung des Koordinators. Sobald der Koordinator sich für ein Commit entschieden hat, ist sichergestellt, daß die Transaktion und damit auch die Stufe vollends beendet werden kann - ein Zurücksetzen der Transaktion (und somit ein Übergang in den ersten Abschnitt) ist dann nicht mehr möglich. Der zweite Abschnitt umfaßt lediglich die Verteilung der Commit-Entscheidung an die beteiligten Ressourcen. Die gesamte Verweildauer TV,b eines Agenten in einer Stufe beim Basisprotokoll ist dann die Summe der Verweildauer TW,b des ersten Abschnitts und der Verweildauer TC,b des zweiten Ab- schnitts: (4-42) 4.6.5.1 Basisprotokoll Erster Abschnitt: Bei der Ausführung des ersten Abschnittes sind insgesamt zwei Knoten beteiligt: Der den Agenten ausführende Knoten und der Zielknoten der Migration. Um die Verweildauer zu be- rechnen macht jedoch eine Modellierung, in der die Zustände direkt mit der Anzahl der verfüg- baren Knoten korreliert sind (d.h. ein Modell des physischen Systems), wenig Sinn. Vielmehr müssen Zustände des Protokolles selbst modelliert werden. Abbildung 4-27 zeigt das Modell zur Berechnung der Verweildauer im ersten Abschnitt. Die Verarbeitung des ersten Abschnittes gliedert sich in drei verschiedene Zustände und einen zusätzlichen Endzustand. Sobald ein Agent bei einem Knoten eintrifft, befindet er sich im Zu- stand “Ausführen”. Hier wird die Schritt-Transaktion begonnen und der auszuführende Schritt abgearbeitet. Danach geht die Verarbeitung in den Zustand “Vorbereiten” über, in dem der Agent in die Eingangswarteschlange des nächsten Knotens geschrieben wird und in dem der Koordinator der Transaktion rm_prepare auf allen beteiligten Ressourcen aufruft. Neben der lo- kalen Eingangswarteschlange und der Eingangswarteschlange des nächsten Knotens sind dies noch jene lokalen Ressourcen, auf die der Agent während seiner Ausführung zugegriffen hat. TV b, TW b, TC b,+= 4.6 Analytische Bewertung der Fehlertoleranz 135Fällt der ausführende Knoten aus während sich das System in den Zuständen “Ausführen” oder “Vorbereiten” befindet, so ist die Ausführung des Agenten blockiert und geht in den Zustand “Arbeiterausfall” über. Fällt der Zielknoten der Migration im Zustand “Vorbereiten” aus, so wird die Transaktion abgebrochen und der Agent erneut im Zustand “Ausführen” ausgeführt. Entscheidet der Transaktionskoordinator mit “Commit”, so wird in den 2. Abschnitt des Proto- kolles übergegangen. Entscheidet der Transaktionskoordinator aus irgendwelchen Gründen mit “Abort” (z.B. Probleme in Ressourcen, Deadlocks,...), so ist die Transaktion ebenfalls abgebro- chen und es wird in den Zustand “Ausführen” übergegangen. Die Übergänge zum Zustand “Arbeiterausfall” finden mit der Ausfallrate f eines einzelnen Kno- tens statt. Die Übergangsrate f1 vom Zustand “Vorbereiten” setzt sich zusammen aus der Aus- fallrate f eines Knotens und einer Ausfallrate, welche sich aus der Wahrscheinlichkeit ergibt, mit der eine Transaktion vom Koordinator abgebrochen wird. Da dies nur sehr selten geschieht und quantitativ nur schlecht erfaßt werden kann (da abhängig von den Ressourcen, auf die der Agent während seiner Ausführung zugreift), wird f1 durch f angenähert. Die mittlere Ausführungszeit 1/w setzt sich zusammen aus der Zeit 1/b zum Starten einer Transaktion, der mittleren Zeit 1/l zum Lesen des Agenten aus der Eingangswarteschlange und der mittleren Zeit 1/e zur (fehler- freien) Ausführung des auszuführenden Schrittes. Es gilt . Geht man davon aus, daß die Zeiten zum Start einer Transaktion und zum Lesen des Agenten aus der Eingangswarteschlange wesentlich kleiner als die Zeit zur Ausführung des Schrittes sind, so ist 1/w ungefähr die mittlere Dauer der Ausführung eines Schrittes. Die mittlere Aus- führungszeit 1/vb setzt sich zusammen aus der mittleren Ausführungszeit 1/s zum Schreiben des Agenten in die Warteschlange des nächsten Knotens und der mittleren Ausführungszeit 2*1/ps Abbildung 4-27. Modell zur Berechnung der Verweildauer des ersten Abschnitts des Basisprotokoll 0 1 2 3 f f f1 r w vb Ausführen Vorbereiten Arbeiterausfall Abschnitt 2 1 w --- 1 b -- 1 l -- 1 e --+ += 136 Kapitel 4 Genau-einmal Ausführungder ersten Phase des 2PC-Protokolles (2*mittlere Zeit zum Aufruf von rm_prepare auf eine Ein- gangswarteschlange). Hier gilt . Als Übergangsmatrix für das System erhält man Die Laplace-Transformierte berechnet sich nach Gleichung (4-25) zu Da der Agent sich nach dem Eintreffen auf dem Knoten nur im Zustand “Ausführen” befinden kann (im Zustand “Arbeiterausfall” hätte er gar nicht in die Eingangswarteschlange geschrieben werden können), ist die Anfangsbedingung für die Aufenthaltswahrscheinlichkeiten Nach Berechnung der Inversen der Laplace-Transformierten und dem Einsetzen von P(0) kann man dann den Grenzwert von für berechnen: 1 vb ---- 1 s -- 2 1 ps ----+= A f w+( )– r f 0 f r– f 0 w 0 2f vb+( )– 0 0 0 vb 0 = P s( ) s I A–⋅( ) 1– P 0( )⋅ s f w+ + r– f– 0 f– s r+ f– 0 w– 0 s 2f vb+ + 0 0 0 vb– s 1– P 0( )⋅= = ) P 0( ) 1 0 0 0 = P s( )) s 0→ P s( ) s 0→ lim 2f vb+ vbw --------------- f 2f vb w+ +( ) rvbw --------------------------------- 1 vb ---- ∞ = ) 4.6 Analytische Bewertung der Fehlertoleranz 137Nach Satz 4-3, Gleichung (4-31) erhält man den Erwartungswert TW der Aufenthaltsdauer in der Zustandsmenge {0,1,2}, und damit die Verweildauer in Abschnitt 1 des Basisprotokolles, mit- tels (4-43) Zweiter Abschnitt: Im zweiten Abschnitt des Basisprotokolles muß nur noch die zweite Phase des 2PC-Protokolles abgehandelt werden, genauer gesagt es muß die Commit-Entscheidung des Transaktionskoor- dinators an die beteiligten Ressourcen übermittelt werden (beim Abbruch der Transaktion wür- de der erste Abschnitt nicht verlassen). Beteiligte Ressourcen sind die lokale Eingangswarte- schlange, die Eingangswarteschlange des nachfolgenden Knotens und weitere lokale Ressourcen, auf die der Agent während der Schritt-Transaktion zugegriffen hat. Die Commit-Entscheidung kann den Ressourcen seriell oder parallel mitgeteilt werden. Bei der seriellen Mitteilung wird einer Ressource die Commit-Entscheidung mitgeteilt und auf deren Antwort gewartet, bevor einer weiteren Ressource die Commit-Entscheidung mitgeteilt wird. Beim parallelen Fall werden an alle Ressourcen die Commit-Entscheidungen verschickt und dann auf die Antworten gewartet. An dieser Stelle wird der zeitlich ungünstigere Fall, die seri- elle Mitteilung, betrachtet. Es wird hierbei angenommen, daß, sobald eine Ressource die Com- mit-Mitteilung bestätigt hat, die Ressource die Commit-Entscheidung auch bei auftretenden Fehlern nicht erneut übermittelt bekommt. Somit kann man die Commit-Mitteilungen der ein- zelnen Ressourcen getrennt betrachten. Abhängig davon, wo der Koordinator der Transaktion sitzt und wo sich die zu benachrichtigen- de Ressource befindet, müssen unterschiedliche Fehlermodelle betrachtet werden. Sitzen Koor- dinator und Ressource auf demselben Knoten (lokale Ressource), so trifft das Modell aus Ab- bildung 4-28 zu. In diesem Falle kommt es nur darauf an, ob der Knoten, auf dem sich der Transaktionskoordi- nator und die Ressource befinden, intakt ist oder nicht. Fällt der Knoten aus, während bei der lokalen Ressource der Commit durchgeführt wird, so wird der Ressource nach Reparatur des Knotens erneut die Commit-Entscheidung mitgeteilt. Die mittlere Commit-Dauer im fehlerfrei- en Fall, und somit die mittlere Zeit bis zum Übergang in den (End-)Zustand 2, beträgt 1/cl. Im hier betrachteten Basisprotokoll sitzt der Transaktionskoordinator i.a. auf dem Knoten, auf dem die Schritt-Transaktion durchgeführt wird. Lokale Ressourcen sind in diesem Falle die Ein- gangswarteschlange des Knotens und jene Ressourcen, auf die der Agent während der Ausfüh- rung des Schrittes zugegriffen hat. Da diese für den allgemeinen Fall nicht bekannt sind, wird hier nur die Zeit des lokalen Commit für die Eingangswarteschlange (mit mittlerer Commit- Dauer 1/cl) betrachtet. Die Berechnung der Zeiten für weitere lokale Ressourcen erfolgt analog. TW b, P 0( ) i 0= 2 ∑ 2f w vb+ +( ) f r+( )wrvb----------------------------------------------= = ) 138 Kapitel 4 Genau-einmal AusführungDa für den Beginn dieser Phase der den Agenten ausführende Knoten intakt sein muß, ergibt sich die Anfangsbedingung zu Die Übergangsmatrix ergibt sich wie folgt: Analog zum letzten Abschnitt wird die mittlere Aufenthaltsdauer Tcl,b in der Zustandsmenge {0,1} berechnet: Abbildung 4-28. Modell für lokales Commit 0 1 2 f r cl Knoten Commit Knoten intakt erfolgreich ausgefallen P 0( ) 1 0 0 = A f cl+( )– r 0 f r– 0 cl 0 0 = P s( ) s I A–⋅( ) 1– P 0( )⋅ s f cl+ + r– 0 f– s r+ 0 cl– 0 s 1– 1 0 0 ⋅= = ) P s( ) s 0→ lim 1 cl --- f clr ------ ∞ = ) 4.6 Analytische Bewertung der Fehlertoleranz 139(4-44) Befinden sich der Koordinator der Transaktion und die Ressource (hier: Eingangswarteschlange des Knotens, auf den Agent migriert) auf unterschiedlichen Knoten, so trifft das Modell aus Ab- bildung 4-29 zu. Hier spielen sowohl der Knoten des Transaktionskoordinators als auch der Knoten der Ressource eine Rolle. Nur wenn diese beide Knoten intakt sind, kann die Commit-Entscheidung der Ressource mit- geteilt und von der Ressource verarbeitet werden, daher ist ein Übergang in den (End-)Zustand 3 nur aus Zustand zwei möglich. Die Ausfallrate im Zustand “beide Knoten intakt” entspricht dem doppelten der normalen Ausfallrate f, dasselbe gilt für die Reparaturrate, wenn beide Kno- ten ausgefallen sind. Die Anfangsbedingungen sind auch hier einfach zu bestimmen. Wird diese Phase des Protokol- les erreicht, dann ist der Knoten des Transaktionskoordinators auf jeden Fall nicht ausgefallen. Somit kann also nur ein Knoten (der Knoten der Zielwarteschlange) oder kein Knoten ausgefal- len sein. Die Wahrscheinlichkeit, daß der Knoten der Zielwarteschlange verfügbar ist erhält man analog Gleichung (4-33). Da sich das System anfangs nicht im Endzustand befinden kann, er- hält man die Anfangsbedingungen Abbildung 4-29. Modell für entferntes Commit Tcl b, P 0( ) i 0= 1 ∑ r f+clr---------= = ) 0 1 f 2r beide Knoten ein Knoten 2 2f r 3 cr ausgefallen ausgefallen beide Knoten intakt Commit erfolgreich P 0( ) 0 1 r r f+ ---------– r r f+--------- 0 0 f r f+--------- r r f+--------- 0 = = 140 Kapitel 4 Genau-einmal AusführungDie Übergangsmatrix des Modells ergibt sich zu Wie zuvor kann man hieraus nun Tcr als mittlere Aufenthaltsdauer in der Zustandsmenge {0,1,2,3} berechnen: (4-45) Die Gesamtzeit TC,b für den Commit ergibt sich also zu (4-46) Zusammenfassung: Als Verweildauer eines Agenten in einer Stufe ergibt sich beim Basisprotokoll der Wert (4-47) A 2r– f 0 0 2r f r+( )– 2f 0 0 r 2f cr+( )– 0 0 0 cr 0 = P s( ) s I A–⋅( ) 1– P 0( )⋅ s 2r+ f– 0 0 2– r s– f r+ + 2–( )f 0 0 r– s 2f cr+ + 0 0 0 cr– s 1– 0 f r f+--------- r r f+--------- 0 ⋅= = ) P s( ) s 0→ lim 1 2 -- f2 2f cr 2r+ +( ) r 2 cr r f+( ) ------------------------------------ f 2f cr 2r+ +( ) rcr r f+( ) ---------------------------------- 1 cr --- ∞ = ) Tcr b, P 0( ) i 0= 2 ∑ 12-- f 2f cr 2r+ +( ) f 2r+( ) r 2 cr r f+( ) -----------------------------------------------------= = ) TC b, Tcl b, Tcr b,+ r f+ clr --------- 1 2 -- f 2f cr 2r+ +( ) f 2r+( ) r 2 cr r f+( ) -----------------------------------------------------+= = TV b, TW b, TC b,+ 2f w vb+ +( ) f r+( ) wrvb ---------------------------------------------- 1 2 -- f 2f cr 2r+ +( ) f 2r+( ) r 2 cr r f+( ) ----------------------------------------------------- r f+ clr ---------+ += = 4.6 Analytische Bewertung der Fehlertoleranz 1414.6.5.2 Blockierungsfreies Protokoll Da das blockierungsfreie Protokoll wesentlich komplexer als das Basisprotokoll ist, wird auch die Modellierung des Protokolles wesentlich komplexer. Um die Komplexität in einem akzep- tablen Rahmen zu halten, werden deshalb an einigen Stellungen Abschätzungen nach oben vor- genommen, d.h. es wird meist der jeweils schlechteste Fall angenommen. Für die Verweildauer bedeutet dies, daß der reale Wert günstiger (d.h. kleiner) ausfällt als der hier berechnete Wert. Auch hier wird wieder dieselbe Unterteilung wie beim Basisprotokoll in zwei Protokollab- schnitte vorgenommen. Für die Berechnungen wird der ungünstigere Fall angenommen, daß die Knotenmengen zweier aufeinanderfolgender Stufen disjunkt sind. Erster Abschnitt: Bei der Aufstellung des in Abbildung 4-30 dargestellten Modells wurde, wie schon im vorher- gehenden Abschnitt, der “Verarbeitungszustand” einer Stufe als Basis für die Zustände des Mo- dells genommen. Nachdem der Agent in der Stufe angekommen ist, wird er vom Arbeiter (i.a. der Knoten mit der höchsten Priorität) ausgeführt, befindet sich im Modell also im Zustand 0. Die Ausführung um- faßt den Start der Schritt-Transaktion, das Lesen des Agenten aus der Eingangswarteschlange, die Ausführung des Schrittes und die Bestimmung der Knoten der nachfolgenden Stufe. Hierbei kann davon ausgegangen werden, daß immer genug Knoten vorhanden sind, um eine Stufe mit n Knoten zu bilden. Danach geht das Modell mit der Übergangsrate w in den Zustand 3, “Schrei- ben&Votieren”, über. Die mittlere Ausführungszeit 1/w setzt sich zusammen aus der Zeit 1/b zum Starten einer Transaktion, der mittleren Zeit 1/l zum Lesen des Agenten aus der Eingangs- warteschlange, der mittleren Zeit 1/e zur (fehlerfreien) Ausführung des auszuführenden Schrit- Abbildung 4-30. Modell zur Berechnung der Verweildauer des ersten Abschnitts des blockierungsfreien Protokolles 0 1 3 5 fw1 fv1 sel w vf Ausführen Schreiben&Votieren Selektion Abschnitt 2 42 fv2 r Nicht genügend Voten verfügbar Alle Knoten defekt fw2 nr fd 142 Kapitel 4 Genau-einmal Ausführungtes (inklusive der Berechnung der Knoten der nächsten Stufe). Es gilt . Da die Zeit zur Ausführung eines Schrittes i.a. wesentlich höher ist als die Zeit zur Ermittlung der Knoten der nächsten Stufe, kann für 1/e die mittlere Zeit zur Ausführung eines Schrittes an- genommen werden. Im Zustand “Schreiben&Votieren” wird zuerst der Agent in die Eingangswarteschlangen der Knoten der nächsten Stufe geschrieben und dann die erste Phase des 2PC-Protokolles durchge- führt. Diese schließt das Votieren ein, bei dem der Orchestrator von allen Votierern der Stufe ein Votum eintreibt. Hat der Orchestrator eine Mehrheit der Voten erhalten und haben alle Ressour- cen dem Abschluß der Transaktion zugestimmt, geht die Verarbeitung in den zweiten Abschnitt über. Die Übergangsrate in den zweiten Abschnitt berechnet sich aus der für das Schreiben des Agenten in die nächste Stufe benötigten Zeit n*1/s (für n Knoten in der nächsten Stufe) und der für die Durchführung der ersten Phase des 2PC-Protokolles. In der ersten Phase des 2PC-Pro- tokolles wird rm_prepare bei den beteiligten Ressourcenmanagern aufgerufen. Dies betrifft in diesem Falle die Eingangswarteschlangen der Knoten der nächsten Stufe, die Eingangswarte- schlange des Arbeiters, den Orchestrator und die Ressourcen, auf die der Agent während dem Schritt zugegriffen hat. Nimmt man für den Aufruf von rm_prepare auf eine Eingangswarte- schlange eine mittlere Ausführungszeit von 1/ps an, so ergibt sich eine mittlere Ausführungszeit für die erste Phase des 2PC-Protokolles von und damit gilt für die Übergangsrate von Zustand 3 in Zustand 5 (4-48) Hierbei wird der ungünstigere Fall des sequentiellen Aufrufes von rm_prepare auf die Ein- gangswarteschlangen angenommen. Tv bezeichnet die vom Orchestrator benötigte Zeit für den rm_prepare-Aufruf und umfaßt vor allem die für das Votieren benötigte Zeit. Die Berechnung von Tv hängt von der Verfügbarkeit der Knoten der aktuellen Stufe ab und ist ziemlich komplex. Aus Gründen der Übersichtlichkeit erfolgt die Berechnung deshalb weiter unten. Treten Knotenausfälle auf, so ist die Auswirkung des Ausfalls stark von dem Zustand abhängig, in dem sich die Verarbeitung befindet. Im Zustand “Ausführen” wird das System nur dann be- einflußt, wenn der Arbeiter, d.h. der den Agent ausführende Knoten, ausfällt. Fällt der Arbeiter aus, sind zwei Alternativen denkbar. Solange noch mindestens ein Knoten der Stufe verfügbar ist, geht das System in den Zustand “Selektion” über. War der Arbeiter der letzte verfügbare Knoten der Stufe, so geht das System in den Zustand “Alle Knoten defekt” über. Die Ausfallrate 1 w --- 1 b -- 1 l -- 1 e --+ += T2pc1 n 1+( ) 1 ps ---- Tv+= 1 vf --- n 1 s -- n 1+( ) 1ps ---- Tv+ += 4.6 Analytische Bewertung der Fehlertoleranz 143des Arbeiters ist f (Ausfall eines Knotens). Diese Rate muß nun aufgeteilt werden zwischen dem Übergang in den Zustand “Selektion” und dem Übergang in “Alle Knoten defekt”. Fällt der Ar- beiter aus, so ist die Wahrscheinlichkeit, daß er in den Zustand “Alle Knoten defekt” übergeht gleich der Wahrscheinlichkeit Pw1, daß alle n-1 restlichen Knoten der Stufe ausgefallen sind. Diese Wahrscheinlichkeit berechnet sich nach Gleichung (4-38) zu (4-49) Für die Übergangsrate fw1 vom Zustand “Ausführen” in den Zustand “Alle Knoten defekt” erhält man dann (4-50) Die Übergangsrate fw2 vom Zustand “Ausführen” in den Zustand “Selektion” ergibt sich dann zu (4-51) Im Zustand “Schreiben&Votieren” wirkt sich (beinahe) jeder Ausfall eines der an der Verarbei- tung der Stufe beteiligten Knoten auf das System aus. Fällt einer der Knoten der nächsten Stufe aus, so wird die Schritt-Transaktion zurückgesetzt und das System geht in den Zustand “Selek- tion” über. Fallen Beobachter der Stufe aus, so kann das Auswirkungen auf die zum Votieren benötigte Zeit Tv (siehe oben) haben, falls nicht genug Knoten für das Erlangen einer Voten- Mehrheit verfügbar sind. Fällt der Arbeiter selbst aus, dann hat der Orchestrator zu diesem Zeit- punkt schon von 0,...,n Knoten eine Stimme bekommen. Hat der Orchestrator schon die benö- tigte Stimmenzahl erhalten, so kann kein weiterer Orchestrator die notwendige Anzahl an Stim- men erhalten. In diesem Fall ist das System blockiert, bis der Arbeiter-Knoten neu startet (und die erhaltenen Voten zurückgeben kann). Hat der Arbeiter jedoch noch nicht genug Stimmen be- kommen, dann könnte das System entweder in den Zustand “Selektion” oder in den Zustand “Alle Knoten defekt” übergehen. Problem hier ist, daß einerseits nur sehr schlecht eine Aussage getroffen werden kann, mit welcher Wahrscheinlichkeit nach Ausfall eines Arbeiters noch ge- nügend Stimmen vorhanden sind und andererseits umfaßt das Modell nicht die Möglichkeit, daß eventuell mehrere “ehemalige” (d.h. während dem Votieren ausgefallene) Arbeiter Teile der Stimmen blockieren. Aus diesem Grunde wird der für die Ausführungszeit ungünstigere Fall angenommen, daß bei Ausfall des Arbeiters prinzipiell nicht mehr genügend Voten vorhanden sind, sodaß hier immer in den Zustand “Nicht genügend Voten” übergegangen wird. Die Rate fv1 für den Übergang vom Zustand “Votieren” in den Zustand “Selektion” hängt demnach nur Pw1 f f r+---------   n 1– = fw1 Pw1 f⋅ f ff r+---------   n 1– = = fw2 f fw1– f 1 ff r+---------   n 1– –  = = 144 Kapitel 4 Genau-einmal Ausführungvom Ausfall eines der Knoten der nachfolgenden Stufe ab und ergibt sich daher zu (4-52) Dabei wurde (der ungünstigere Fall) angenommen, daß der Ausfall eines Knotens der nächsten Stufe auch dann den Abbruch der Transaktion bewirkt, wenn die Eingangswarteschlange bereits mit rm_yes auf das rm_prepare geantwortet hat. Die Rate fv2 für den Übergang vom Zustand “Votieren” in den Zustand “Nicht genügend Voten verfügbar” hängt nach obiger Festlegung nur vom Ausfall des Arbeiters ab und ergibt sich deshalb zu (4-53) Befindet sich das System im Zustand “Nicht genügend Voten verfügbar”, dann wird in der Rea- lität nach der Wahl eines neuen Arbeiters bereits mit der Ausführung des Agenten begonnen.Im Modell wird jedoch (der ungünstigere Fall) angenommen, daß die Auswahl des neuen Arbeiters erst dann beginnt, wenn der alte Arbeiterknoten wieder verfügbar ist. Die Übergangsrate von “Nicht genügend Knoten verfügbar” in den Zustand “Selektion” entspricht daher der Repara- turrate eines einzelnen Knotens r. Vom Zustand “Selektion” aus kann das System in zwei Nachfolgezustände übergehen. Wird ein neuer Arbeiter gewählt, so geht das System in den Zustand “Ausführen” über. Die Übergangs- rate hierfür sei sel. Bei der Wahl dieser Rate wird auch berücksichtigt, daß der Knoten mit der höchsten Priorität verfügbar sein kann (und in diesem Fall die Selektionsphase sehr kurz ist). Fällt im Zustand “Selektion” ein Knoten aus ändert dies nichts – es sei denn, alle anderen (n-1) Knoten der Stufe sind schon ausgefallen. In diesem Falle geht das System in den Zustand “Alle Knoten defekt” über. Da dies dieselbe Situation ist wie beim Übergang vom Zustand “Ausfüh- ren” in den Zustand “Alle Knoten defekt” ergibt sich für den Übergang “Selektion” nach “Alle Knoten defekt” die Übergangsrate analog zu Gleichung (4-50): (4-54) Der Zustand “Alle Knoten defekt” wird in Richtung “Selektion” verlassen, sobald einer der n Knoten repariert ist. Die Übergangsrate für diesen Übergang ist nr (d.i. die n-fache Reparatur- rate eines einzelnen Knotens). Bevor nun die Verweildauer des Protokolles im ersten Abschnitt berechnet werden kann, muß noch die mittlere Zeit ausgerechnet werden, die der Orchestrator zum Votieren benötigt. Sind von der aktuellen Stufe ausreichend (d.h. ) Knoten verfügbar (blockierungsfreier Fall), so bewegt sich die Dauer Tvn für das Votieren in der Größenordnung der Round-Trip- fv1 nf= fv2 f= fd fw1 f ff r+---------   n 1– = = n 1+( ) 2⁄ 4.6 Analytische Bewertung der Fehlertoleranz 145Time (Zeit, um Datenpaket zu einem Knoten hin und wieder zurück zu transportieren) zwischen den Knoten der Stufe. Sind jedoch nicht ausreichend Knoten vorhanden ist der Agent blockiert und muß warten, bis ausreichend Knoten für eine Stimmenmehrheit verfügbar sind. Die mittlere Dauer Tv des Votierens ergibt sich aus der mittleren Dauer Tvn im blockierungsfrei- en Fall gewichtet mit dessen Wahrscheinlichkeit Pn und der mittleren Dauer Tvb im Fehlerfall gewichtet mit dessen Wahrscheinlichkeit Pb: (4-55) Für die Berechnung von Pn und Pb kann davon ausgegangen werden, daß der Arbeiter immer verfügbar ist (fällt der Arbeiter aus wird in einen Zustand übergegangen, der momentan nicht Gegenstand der Betrachtung ist). Das Protokoll blockiert folglich nicht, wenn von den n-1 Be- obachtern mindestens Beobachter verfügbar sind. Der Wert für Pn ergibt sich di- rekt analog zu Gleichung (4-39) und mit Gleichung (4-38) zu (4-56) Die Wahrscheinlichkeit Pb ergibt sich dann einfach zu (4-57) Die Berechnung der mittleren Zeit für das Votieren bei einer Blockierung hängt vor allem von der Anzahl der Knoten in einer Stufe ab. Abbildung 4-31, welche Modelle für das Votieren für unterschiedliche Anzahlen von Knoten pro Stufe zeigt, läßt vermuten, daß hier nur sehr schwer eine geschlossene Form zur Berechnung der mittleren Zeit zu finden ist. Die Zustände im Mo- dell modellieren jeweils die Anzahl der für ein vollständiges Votum noch fehlenden Stimmen. In einer Stufe mit 5 Knoten werden neben der Stimme des Arbeiters (die in diesem Fall voraus- gesetzt werden kann, siehe oben) noch die Stimmen von mindestens zwei Beobachtern benötigt (also insgesamt drei Stimmen). Fehlen beide Beobachter-Stimmen bedeutet dies, daß von den 4 Beobachtern momentan keiner verfügbar ist. Fehlt nur eine Stimme, ist ein Beobachter verfüg- bar. Die Übergangsrate von “2 Stimmen fehlen” nach “1 Stimme fehlt” ist demnach die 4-fache Reparaturrate eines Knotens, die Gegenrichtung ist die Ausfallrate eines Knotens (des einen verfügbaren Beobachters). Der Übergang von “1 Stimme fehlt” zu “Votieren erfolgreich” setzt sich aus mehreren Komponenten zusammen. Für eine Stufe mit 5 Knoten ist dies zum einen die 3-fache Reparaturrate eines Knotens. Sind alle Knoten verfügbar muß jedoch erst die Aufforde- rung zum Votieren bei den Knoten eintreffen. Diese wird periodisch vom Orchestrator ver- schickt und trifft im Schnitt nach der halben Periodendauer bei den Votierern ein. Die Rate in Tv PnTvn PbTvb+= n 1–( ) 2⁄ Pn r f-   i n 1– i   f f r+---------   n 1– i n 1– 2 ----------- = n 1– ∑ ff r+---------   n 1– r f-   i n 1– i   i n 1– 2 ----------- = n 1– ∑= = Pb 1 Pn–= 146 Kapitel 4 Genau-einmal Ausführungden Zustand “Votieren erfolgreich” setzt sich bei einer Stufe mit fünf Knoten daher wie folgt zusammen: (4-58) wobei Tresend die Zeit zwischen dem Verschicken von 2 Votier-Aufforderungen ist. Im Modell wird hierbei vom ungünstigeren Fall ausgegangen, daß die Beobachter ihre Stimme erst dann abgeben, wenn wirklich genug Beobachter vorhanden sind. Besitzt eine Stufe 6 oder 7 Knoten, so werden zusätzlich zur Stimme des Arbeiters noch 3 Stim- men von Beobachtern benötigt, wodurch diese Modelle einen Zustand mehr haben als das Mo- dell für 5 Knoten. Obwohl beide Modelle dieselbe Anzahl von Zuständen besitzen unterschei- den sich die Übergangsraten zwischen den Zuständen. Die mittlere Dauer für das Votieren im Fall des Blockierens ergibt sich, indem die mittlere Auf- enthaltsdauer in der Zustandsmenge {1, 2, ..., } berechnet wird. Da keine geschlos- sene Form für diese Aufenthaltsdauer gefunden wurde, wird im folgenden die Berechnung des Wertes anhand einer Stufe mit 5 Knoten demonstriert, Tabelle 4-3 zeigt die Werte für Stufen der Größe 2 bis 7. Abbildung 4-31. Modell des Votierens für Stufen mit 5, 6 und 7 Knoten bei Blockierung 0 1 r1 Votieren 1 Stimme fehlt 2 4r f 5 Knoten: erfolgreich 2 Stimmen fehlen 0 1 r1 Votieren 1 Stimme fehlt 2 4r 2f 6 Knoten: erfolgreich 2 Stimmen fehlen 3 5r f 3 Stimmen fehlen 0 1 r1 Votieren 1 Stimme fehlt 2 5r 2f 7 Knoten: erfolgreich 2 Stimmen fehlen 3 6r f 3 Stimmen fehlen r1 1 Tresend 2 ---------------- 1 3r -----+ ----------------------------= n 1–( ) 2⁄ 4.6 Analytische Bewertung der Fehlertoleranz 147Für eine Stufe mit 5 Knoten ergibt sich aus Abbildung 4-31 die folgende Übergangsmatrix Die Laplace-Transformierte berechnet sich dann zu Die Anfangsbedingung P(0) erhält man aus den folgenden Überlegungen: Da das Modell nur für den Fall gilt, daß das Votieren tatsächlich blockiert, kann es sich am Anfang nicht im Zu- stand 0 (“Votieren erfolgreich”) befinden: (4-59) Die Wahrscheinlichkeiten für die anderen Zustände sind bedingte Wahrscheinlichkeiten: und Mit Gleichung (4-38) und analog Gleichung (4-39) ergibt sich dann (4-60) (4-61) Av 0 r1 0 0 r1 f+( )1– 4r 0 f 4r– = P s( ) s I Av–⋅( ) 1– P 0( )⋅ s r– 1 0 0 s r1 f+ + 4r– 0 f– s 4r+ 1– P 0( )⋅= = ) P0 0( ) 0= P1 0( ) P genau 1 Beobachter verfügbar | höchstens 1 von 4 Beobachtern verfügbar( )= P genau 1 Beobachter verfügbar( ) P höchstens 1 von 4 Beobachtern verfügbar( )------------------------------------------------------------------------------------------------------------= P2 0( ) P kein Beobachter verfügbar | höchstens 1 von 4 Beobachtern verfügbar( )= P kein Beobachter verfügbar( ) P höchstens 1 von 4 Beobachtern verfügbar( )-------------------------------------------------------------------------------------------------------------= P1 0( ) 4 1   rf-   1 f f r+---------   4 4 i   rf-   i f f r+---------   4 i 0= 1 ∑ ---------------------------------------------- 4 r 4r f+-------------= = P2 0( ) 4 0   rf-   0 f f r+---------   4 4 i   rf-   i f f r+---------   4 i 0= 1 ∑ ---------------------------------------------- f 4r f+-------------= = 148 Kapitel 4 Genau-einmal AusführungNach Berechnung der Inversen der Laplace-Transformierten und dem Einsetzen von P(0) kann man dann den Grenzwert von für berechnen: woraus sich dann direkt die gesuchte mittlere Aufenthaltsdauer Tvb in den Zuständen {1,2} er- gibt: (4-62) Mit Gleichung (4-58) erhält man schließlich (4-63) Die Werte für Stufengrößen von 2 bis 7 Knoten zeigt Tabelle 4-3. Stufen- größe Tvb 2 3 4 5 Tabelle 4-3. Mittlere Dauer der Blockierung des Votierens für verschiedene Stufengrößen P s( )) s 0→ P s( ) s 0→ lim ∞ 1 r1 ---- 1 4 -- f 4r r1 f+ +( ) r1r f 4r+( ) ------------------------------- = ) Tvb P 0( ) i 1= 2 ∑ 1r1---- 1 4 -- f 4r r1 f+ +( ) r1r f 4r+( ) -------------------------------+ 1 4 -- 16r2 8rf fr1 f 2 + + + r1r f 4r+( ) ------------------------------------------------= = = ) Tvb 32r2 48r3Tresend 22fr 24r 2 fTresend 2f 2 3f2rTresend+ + + + + 24 f 4r+( )r2 --------------------------------------------------------------------------------------------------------------------------------------------------= 2 rTresend+ 2r ----------------------------- 1 rTresend+ 2r ----------------------------- 9r2 9r3Tresend 8rf 6r 2fTresend f 2 f2rTresend+ + + + + 6 f 3r+( )r2 ----------------------------------------------------------------------------------------------------------------------------------- 32r2 48r3Tresend 22fr 24r 2fTresend 2f 2 3f2rTresend+ + + + + 24 f 4r+( )r2 ------------------------------------------------------------------------------------------------------------------------------------------------------ 4.6 Analytische Bewertung der Fehlertoleranz 149Nachdem nun alle Übergangsraten für den ersten Abschnitt des blockierungsfreien Protokolles bestimmt wurden, kann die Übergangsmatrix für das Modell aus Abbildung 4-30 aufgestellt werden: (4-64) Da die Knoten der Stufe die Commit-Entscheidung der Schritt-Transaktion der vorherigen Stufe sequentiell bekommen ist es möglich, daß der Transaktionskoordinator dieser Transaktion wäh- rend dem Versenden der Commit-Entscheidung ausfällt und somit nur ein Teil der Knoten der Stufe den Agent schon aus ihrer Eingangswarteschlange lesen können. Da der Zustand “Selek- tion” auch schon den Fall beinhaltet, daß der Knoten mit der höchsten Priorität verfügbar ist, wird daher die (für den fehlerfreien Fall ungünstigere) Annahme getroffen, daß sich das System zu Beginn im Zustand “Selektion” befindet. Die Anfangsbedingung lautet demnach (4-65) 6 7 Stufen- größe Tvb Tabelle 4-3. Mittlere Dauer der Blockierung des Votierens für verschiedene Stufengrößen 300r4fTresend 135r 3f2Tresend 132r 2f2 3f4rTresend 30r 2f3Tresend+ + + + 60 r3 f2 5rf 10r2+ +( )( ) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 275r3f 300r5Tresend 200r 4 2f4 23rf3+ + + + 60 r3 f2 5rf 10r2+ +( )( ) ------------------------------------------------------------------------------------------------------------ 360r4fTresend 132r 3f2Tresend 100r 2f2 2f4rTresend 24r 2f3Tresend+ + + + 60 r3 f2 6rf 15r2+ +( )( ) --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + 252r3f 450r5Tresend 225r 4 f4 14rf3+ + + + 60 r3 f2 6rf 15r2+ +( )( ) --------------------------------------------------------------------------------------------------------- A fw1 fw2 w+ +( )– sel 0 0 0 0 fw2 sel fd+( )– nr nf r 0 fw1 fd nr– 0 0 0 w 0 0 nf f vf+ +( )– 0 0 0 0 0 f r– 0 0 0 0 vf 0 0 = P 0( ) 0 1 0 0 0 0 = 150 Kapitel 4 Genau-einmal AusführungFür die Bestimmung der Aufenthaltsdauer muß nun zuerst wieder die Laplace-Transformierte nach Gleichung (4-25) berechnet werden: Nach Berechnung der Inversen der Laplace-Transformierten und dem Einsetzen von P(0) kann man dann den Grenzwert von für und daraus dann die mittlere Aufenthaltsdauer TW,f in der Zustandsmenge {0,1,2,3,4} berechnen: mit Gleichung (4-51) und Gleichung (4-54) ergibt sich (4-66) P s( ) s fw1 fw2 w+ + + sel– 0 0 0 0 f– w2 s sel fd+ + n– r n– f r– 0 f– w1 f– d s nr+ 0 0 0 w– 0 0 s nf f vf+ + + 0 0 0 0 0 f– s r+ 0 0 0 0 v– f 0 s 1– P 0( )⋅= ) P s( )) s 0→ P s( ) s 0→ lim vf n 1+( )f+ vfw ----------------------------- fw1 fw2 w+ +( ) n 1+( )f vf+( ) vfwsel ---------------------------------------------------------------------- fw1 fw2 w+ +( )fd fw1sel+( ) vf n 1+( )f+( ) nrvfwssel ---------------------------------------------------------------------------------------------------- 1 vf --- f rvf ------ ∞ = ) TW f, P 0( ) i 0= 4 ∑ vf n 1+( )f+ vfw----------------------------- fw1 fw2 w+ +( ) n 1+( )f vf+( ) vfwsel ---------------------------------------------------------------------- 1 vf --- f rvf ------+ + + += = fw1 fw2 w+ +( )fd fw1sel+( ) vf n 1+( )f+( ) nrvfwsel ---------------------------------------------------------------------------------------------------- ) TW f, P 0( ) i 0= 4 ∑ vf n 1+( )f+( ) sel w f+ +( ) nr fw1+( )( )nrvfwsel--------------------------------------------------------------------------------------------- 1 vf --- f rvf ------+ += = ) 4.6 Analytische Bewertung der Fehlertoleranz 151Zweiter Abschnitt: Im zweiten Abschnitt muß, wie auch beim Basisprotokoll, nur noch die zweite Phase des 2PC- Protokolles abgehandelt werden, genauer gesagt es muß die Commit-Entscheidung des Trans- aktionskoordinators an die beteiligten Ressourcen übermittelt werden (beim Abbruch der Transaktion würde der erste Abschnitt nicht verlassen). Beteiligte Ressourcen sind die lokale Eingangswarteschlange, der lokale Orchestrator, die Eingangswarteschlange der Knoten der nächsten Stufe und weitere lokale Ressourcen, auf die der Agent während der Schritt-Transak- tion zugegriffen hat. Ziel der gesamten Betrachtung ist zu berechnen, wie lange ein Agent in einer Stufe benötigt. Sobald irgend ein Knoten der nächsten Stufe die Commit-Entscheidung erhalten hat, beginnt für den Agent schon die nächste Stufe (im Zustand “Selektion”). Dies bedeutet für diesen Abschnitt zweierlei. Erstens wird beim Orchestrator die Zeit, die für Versand der FORGET-Nachrichten und Empfang der Bestätigungen benötigt wird, hier nicht eingerechnet, da die FORGET-Phase erst nach Zurücksenden der Bestätigung an den Transaktionskoordinator beginnt (und daher den restlichen Verlauf der zweiten Phase des 2PC-Protokolles nicht beeinflußt). Zweitens muß nur die Zeit eingerechnet werden, bis einer der Knoten der nächsten Stufe die Commit-Entschei- dung erhalten hat. Bei der Berechnung der Commit-Zeiten kann man auf die Ergebnisse aus Abschnitt 4.6.5.1 zu- rückgreifen. Geht man davon aus, daß der Orchestrator für die zweite Phase des 2PC-Protokol- les nicht länger braucht als die lokale Eingangswarteschlange (die Zeit ist sogar eher kürzer, da, wie oben erwähnt, die FORGET-Phase hier nicht berücksichtigt werden muß) und daß die ent- fernten Ressourcen erst nach den lokalen Ressourcen die Commit-Entscheidung erhalten, dann berechnet sich die Zeit Tcl,f für den Commit der lokalen Ressourcen zu (4-67) Da die nächste Stufe bereits (im Zustand “Selektion”) beginnt, nachdem der erste Knoten der nächsten Stufe die Commit-Entscheidung erfahren hat, ergibt sich (4-68) Die mittlere Zeit TC,f für die zweite Phase berechnet sich also zu (4-69) Tcl f, 2Tcl b, 2 r f+ clr ---------= = Tcr f, Tcr b, f 2f cr 2r+ +( ) f 2r+( ) 2r 2 cr r f+( ) -----------------------------------------------------= = TC f, Tcl f, Tcr f,+ 2 r f+ clr --------- f 2f cr 2r+ +( ) f 2r+( ) 2r 2 cr r f+( ) -----------------------------------------------------+= = 152 Kapitel 4 Genau-einmal AusführungGesamtzeit: Die mittlere Verweildauer TV,f eines Agenten in einer Stufe beim blockierungsfreien Protokoll ergibt sich dann aus der Summe von Gleichung (4-66) und Gleichung (4-69): (4-70) 4.6.5.3 Vergleich der Protokolle Um die beiden Protokolle vergleichen zu können wird zunächst das Verhältnis QV zwischen Verweildauer TV in einer Stufe und der Ausführungszeit 1/e des Agenten berechnet: (4-71) Der Wert (QV - 1)*100 gibt dann den Mehraufwand in Prozent an, der durch das Protokoll, durch Knotenausfälle und durch die Mobilität des Agenten entsteht. Mit den Werten QV,b=eTV,b für das Basisprotokoll und QV,f = eTV,f für das blockierungsfreie Protokoll kann man dann den durch das blockierungsfreie Protokoll erreichten Gewinn G berechnen: (4-72) Der Gewinn G ist das Verhältnis von Mehraufwand Basisprotokoll zu Mehraufwand blockie- rungsfreies Protokoll. Ist der Gewinn G größer 1.0, so ist der Mehraufwand des blockierungs- freien Protokolles kleiner als der des Basisprotokolles. Ein Gewinn von G=2.0 bedeutet bei- spielsweise, daß der Mehraufwand des Basisprotokolles doppelt so hoch ist wie der des blockierungsfreien Protokolles. Abbildung 4-32 zeigt Gewinn G des blockierungsfreien Protokolles in Abhängigkeit von der Verfügbarkeit der Knoten und der Anzahl der Knoten pro Stufe. Für die Berechnung des Gewin- nes wurden die Parameter verwendet, welche sich aus den Messungen in Abschnitt 4.7 ergeben: Rate “Transaktionsstart” b=1/0.005 (5ms), Rate “Lesen aus Eingangswarteschlange” l=1/0.02 (20 ms), Rate “Schreiben in Eingangswarteschlange” s=1/0.04 (40ms), Rate “Prepare Ein- gangswarteschlange” ps=1/0.07 (7ms), Rate “Commit lokal” cl = 1/0.005 (5ms), Rate “Commit entfernt” cr=1/0.007 (7ms), Rate “Selektion” sel=1/.05 (50ms), Zeit zwischen wiederholtem Versenden von Votier-Aufforderungen Tresend=50ms und Dauer des Votierens im fehlerfreien TV f, vf n 1+( )f+( ) sel w f+ +( ) nr fw1+( )( ) nrvfwsel --------------------------------------------------------------------------------------------- 1 vf --- f rvf ------+ + += 2 r f+ clr --------- f 2f cr 2r+ +( ) f 2r+( ) 2r 2 cr r f+( ) -----------------------------------------------------+ QV TV 1 e --⁄ eTV= = G QV b, 1– QV f, 1– --------------------= 4.6 Analytische Bewertung der Fehlertoleranz 153Fall Tvn=4ms. Für die Reparaturrate r wurde ein Wert von 1/120 gewählt, was einer mittleren Reparaturdauer von 2 Minuten entspricht, die Ausfallrate f berechnet sich dann aus der Knoten- verfügbarkeit und der Reparaturrate. Die mittlere Ausführungszeit eines Agenten beträgt 128 Sekunden. Anhand der Graphik ergeben sich mehrere Beobachtungen. Aus demselben Grund wie schon in Abschnitt 4.6.4 fällt auch bei der Verweildauer das Ergebnis für ungerade Knotenanzahlen n (zumindest teilweise) schlechter aus als das Ergebnis bei der jeweilig zugehörigen geraden Kno- tenzahl n-1. Allerdings zeigt die Abbildung auch, daß dies für höhere Knotenverfügbarkeiten nicht mehr gilt, ja daß mit steigender Knotenverfügbarkeit der Gewinn mit zunehmender Anzahl an Knoten pro Stufe sogar generell abnimmt. In Abbildung 4-32 beispielsweise ist bei einer Knotenverfügbarkeit von 0,99 der Gewinn für 3 Knoten maximal und nimmt dann mit jedem weiteren Knoten ab. Weiterhin zeigt sich, daß der Gewinn für einen gegebenen Satz an Ein- gangsparametern ab einer bestimmten Einzelknotenverfügbarkeit mit steigender Einzelknoten- verfügbarkeit wieder abnimmt. In Abbildung 4-32 beispielsweise ist der Gewinn bei einer Ver- fügbarkeit von 0,99 niedriger als bei einer Verfügbarkeit von 0,95. Dieses Verhalten erklärt sich durch die folgenden Überlegungen: Durch die konstante Reparaturrate werden Fehler eines ein- zelnen Knotens mit steigender Verfügbarkeit eines Knotens sehr selten sodaß sich Knotenfehler zunehmend weniger auf den Erwartungswert der Verweildauer beim Basisprotokoll auswirken. Abbildung 4-32. Gewinn des blockierungsfreien Protokolles in Abhängigkeit von der Verfügbarkeit eines Knotens und der Anzahl der Knoten pro Stufe 0 0,2 0,4 0,6 0,8 1 1,2 1,4 1,6 1,8 2 G ew in n 0,7 0,8 0,9 0,95 0,99 Zuverlässigkeit eines Knotens 2 Knoten 3 Knoten 4 Knoten 5 Knoten 6 Knoten 7 Knoten 154 Kapitel 4 Genau-einmal AusführungDa der durch das blockierungsfreie Protokoll eingeführte Mehraufwand (Verteilung auf mehre- re Knoten, Votieren) nicht von der Verfügbarkeit eines Knotens sondern nur von der Anzahl der Knoten pro Stufe abhängt, wirkt sich dieser konstante Mehraufwand zunehmend negativ auf den Gewinn aus. Der geringere Gewinn bei geringerer Einzelknotenverfügbarkeit ergibt sich vor allem dadurch, daß hier die Wahrscheinlichkeit einer Blockierung des Votierens höher ist und dadurch die Rate vf relativ klein ausfällt (dies läßt sich zeigen, indem man bei der Berechnung von vf eine kon- stante mittlere Zeit für das Votieren verwendet). Beide Faktoren zusammen bestimmen, wievie- le Knoten pro Stufe bei gegebener Knotenverfügbarkeit den höchsten Gewinn ergeben. Eine weitere Eigenschaft des blockierungsfreien Protokolles zeigt Abbildung 4-33. Die Abbil- dung zeigt den Gewinn abhängig von der Ausführungszeit des Agenten (in einer Stufe) und der Anzahl der Knoten pro Stufe. Die Parameter wurden wie oben gewählt, für die Verfügbarkeit eines einzelnen Knotens wurde ein Wert von 95% angenommen. Der Abbildung kann man ent- nehmen, daß sich nennenswerte Gewinne nur bei langen Ausführungszeiten eines Agenten in einer Stufe erreichen lassen. Wird die Zeit, die ein Agent zur Erledigung seiner Aufgabe auf ei- nem Knoten braucht, sehr kurz, dann ist die mittlere Verweildauer in der Stufe beim blockie- rungsfreien Protokoll länger als beim Basisprotokoll. Analog zu oben läßt sich dies dadurch er- klären, daß die Wahrscheinlichkeit eines Knotenausfalls während der Ausführung bei kürzeren Ausführungszeiten geringer ist und daher den Erwartungswert der Verweildauer beim Basispro- Abbildung 4-33. Gewinn des blockierungsfreien Protokolles in Abhängigkeit von der Ausführungszeit eines Agenten und der Anzahl der Knoten pro Stufe 10 24 51 2 25 6 12 8 64 32 16 8 4 2 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 G ew in n Ausführungszeit Agent [s] Anz ahl Kno ten 4.7 Leistungsmessungen 155tokoll weniger beeinflußt während der Protokoll-Mehraufwand beim blockierungsfreien Proto- koll konstant ist. Es zeigt sich also, daß mit dem blockierungsfreien Protokoll unter realen Bedingungen – Ver- fügbarkeit eines einzelnen Knotens mindestens 99% bei administrierten Systemen (vgl. z.B. GRAY UND REUTER (1993)) und Ausführungszeiten eines Agenten auf einem Knoten im Be- reich von mehreren hundert Millisekunden bis wenigen Sekunden – ein Gewinn laut obiger De- finition nicht zu erreichen ist, d.h. die mittlere Verweildauer in einer Stufe und damit die mittlere Ausführungszeit eines Agenten steigt durch die Verwendung des blockierungsfreien Protokol- les. Aus diesen Beobachtungen zu schließen, daß der Einsatz des blockierungsfreien Protokolles nutzlos ist, wäre allerdings falsch, da in diesem Abschnitt Mittelwerte betrachtet wurden. Ziel des Protokolles ist jedoch nicht, den Agenten im Mittel so schnell wie möglich auszuführen son- dern den Agenten zuverlässig auszuführen und Blockierungen der Ausführung durch System- fehler zu vermeiden. Abschnitt 4.4.4.2 zeigt, daß das Protokoll den Agenten zuverlässig aus- führt und Abschnitt 4.6.4 zeigt, daß die Blockierwahrscheinlichkeit des Agenten durch das Protokoll drastisch verringert wird. Für Anwendungen, bei denen eine blockierungsfreie, zuver- lässige Ausführung des Agenten notwendig ist, ist die Verwendung des Protokolles – auf Kosten der durchschnittlichen Ausführungszeit – unumgänglich. Ist für eine Anwendung jedoch eine zuverlässige, im Durchschnitt möglichst schnelle Ausführung notwendig, bei der auch seltene, längerandauernde Blockierungen toleriert werden können, dann empfiehlt sich für diese An- wendung die Verwendung des Basisprotokolles. 4.7 Leistungsmessungen In diesem Abschnitt wird untersucht, wieviel Mehraufwand durch den Einsatz des in diesem Kapitel entwickelten blockierungsfreien Protokolles entsteht. Hierzu wird zuerst ein sehr grober Überblick über die Protokollimplementation gegeben, der vor allem die Verteilung der Kompo- nenten des Protokolles auf verschiedene Prozesse und die Kommunikationsmechanismen zwi- schen diesen Prozessen beschreibt. Nach Einführung der Messmethodik werden die Messergeb- nisse präsentiert und diskutiert. 4.7.1 Protokollimplementation Für die Implementation des Protokolles wurde der am Institut verwendete CORBA-ORB von Iona und dessen Transaktionsservice verwendet. Dieser Transaktionsservice erlaubt in der ver- wendeten Version 1.0 die Implementation von Servern lediglich in C++, Klienten dieser trans- aktionalen Server können sowohl in C++ als auch in Java implementiert werden. Da das Proto- koll in das am Institut implementierte Agentensystem Mole integriert werden sollte, welches in 156 Kapitel 4 Genau-einmal AusführungJava implementiert wurde, war eine Trennung von in C++ implementierten Teilen (transaktio- nale Ressourcen) und in Java implementierten Teilen unumgänglich. Eine erste Implementation des Protokolles erfolgte durch FRIEDEL (1998), eine effiziente trans- aktionale Nachrichtenwarteschlange wurde von MESSNER (1999) realisiert, der Algorithmus zur Stufenkonstruktion und die Integration des Protokolles wurden von PAPOULIDIS (1999) vor- bereitet. Um klarere Schnittstellen zwischen den in Java und C++ implementierten Teilen des Protokolles zu erhalten und die Leistung zu erhöhen, wurde die Protokollimplementation noch- mals komplett neu gemacht. Einen groben Überblick über die resultierende Architektur gibt Ab- bildung 4-34. Der Orchestrator und die Nachrichtenwarteschlange (Message Queue) sind in C++ implemen- tiert und werden auf jedem Knoten in jeweils einem eigenen Prozeß ausgeführt. Der Rest des Protokolles ist in Java implementiert und wird zusammen mit der Agenten-Ausführungsumge- bung Mole in einer Java Virtual Machine (in einem Prozeß) ausgeführt. CORBA wird nur dann zur Kommunikation verwendet, wenn dies zum Austausch von Transaktionskontext-Informa- tionen notwendig ist, beschränkt sich also auf das Lesen von Agenten aus bzw. das Schreiben von Agenten in die Nachrichtenwarteschlange und auf die Registrierung der Schritt-Transaktion beim Orchestrator. Alle andere Kommunikation wird aus Effizienzgründen mittels UDP (User Datagram Protocol) erledigt. Die Implementierung des blockierungsfreien Protokolles enthält als Spezialfall das Basisprotokoll. Abbildung 4-34. Architektur der Implementierung Java VM O rc he st ra to r Mole M es sa ge Qu eu e A u sf üh re r V ot ie re r B eo ba ch te r Betriebssystem Beobachter Message Queues Votierer CORBA-Kommunikation UDP-Kommunikation 4.7 Leistungsmessungen 1574.7.2 Messungen Ziel der Messungen ist es, eine Aussage über den durch das blockierungsfreie Protokoll erzeug- ten Mehraufwand bei fehlerfreiem System (keine Ausfälle) zu treffen und zu untersuchen, wie sich dieser auf die verschiedenen Komponenten des Protokolles verteilt. Für die Messungen wurde der Code des Protokolles instrumentiert, um Messwerte über die zur Verarbeitung eines Agenten in einer Stufe notwendigen Aktionen zu erhalten. Für die Messungen wurde ein Meß-Agent geschrieben, welcher zwischen zwei Knoten insge- samt 50 Migrationen durchführt und hierbei insgesamt 51 Schritte ausführt – 26 Schritte auf dem Knoten, auf dem der Agent gestartet wurde und 25 Schritte auf dem anderen Knoten. Um die Transportgröße des Agenten während der Ausführungszeit des Agenten konstant auf 12KB zu halten, enthält jeder Schritt einige wenige (kurz laufende) Code-Anweisungen, die für einen Ausgleich der Transportgröße sorgen. Dieser Ausgleich ist notwendig, da sich durch die Ver- wendung des von BUSCHLE (1999) implementierten Reiseroutenalgorithmus die Größe des Agenten bei jeder Migration ändert, selbst wenn sonst keinerlei Änderungen an den Daten vor- genommen werden. Zusätzlich ermittelt der Agent bei der Ausführung des ersten Schrittes die lokale Zeit Tstart, bei der Ausführung des letzten Schrittes (der ebenfalls auf dem Startknoten ausgeführt wird) wird die lokale Zeit Tstop genommen. Ansonsten enthalten die Schritte keinen zusätzlichen Code. Die durchschnittliche Zeit zur Ausführung einer Stufe ergibt sich dann durch (Tstop-Tstart)/50. Die Division durch 50 und nicht durch 51 ergibt sich deshalb, weil die Zeiten während des ersten und des letzten Schrittes genommen wurden und nicht vor dem ersten Schritt und nach dem letzten Schritt Während der gesamten Ausführung des Meß-Agenten werden durch den instrumentierten Code des Protokolles jeweils auf dem Start-Knoten die Zeiten der einzelnen Aktionen des Protokolles gemessen und nach vollständiger Ausführung der statistische Mittelwert und die statistische Standardabweichung berechnet. Um hierbei die erhaltenen Werte nicht zu verfälschen, werden die Werte des letzten ausgeführten Schrittes nicht mehr berücksichtigt, da hier keine weitere Mi- gration durchgeführt wird. Die Messungen wurden auf 5 Ultra10-Rechnern (440MHz CPU-Taktfrequenz, 256 MB Haupt- speicher) in einem lokalen Netzwerk durchgeführt. Der Start-Knoten und die drei Rechner, wel- che nur als Beobachter zum Einsatz kamen, sind mit einem 100Mb-Ethernet (über einen Switch) verbunden. Der Knoten, welcher neben dem Start-Knoten ebenfalls zur Ausführung des Meß-Agenten herangezogen wurde, ist über einen Hub mit einem 10Mb-Ethernet an den Switch angeschlossen, über den die restlichen 4 Knoten verbunden sind. Mit dem Programm ping ge- messene Rundlaufzeiten (engl.: round-trip-time) liegen zwischen allen Rechnern unter 1ms. So- wohl die Rechner als auch das Netzwerk waren während den Messungen anderweitig nur un- wesentlich (durch Systemprozesse und -nachrichten) belastet. Die Messungen wurden so angelegt, daß der Agent die 51 Schritte jeweils mit Stufengrößen von 158 Kapitel 4 Genau-einmal Ausführung1 Knoten (Basisprotokoll), 2 Knoten, 3 Knoten, 4 Knoten und 5 Knoten ausführt. Diese Mes- sungen wurden zur Kontrolle insgesamt 3 mal ausgeführt. Die durch die Messungen mit dem Meß-Agenten erhaltenen durch- schnittlichen Ausführungszeiten für eine Stufe/einen Schritt zeigen Tabelle 4-4 und Abbildung 4-35 Es zeigt sich, daß die Ausführungszeiten annähernd linear mit der Anzahl der Knoten pro Stufe ansteigen, wobei die Zunahme pro Knoten (zwischen 63ms und 86 ms) sehr deutlich unter der Ausführungszeit beim Basisprotokoll (206ms) ist, d.h. doppelte Anzahl Knoten bedeutet nicht doppelte Zeit. Wie sich diese Zeiten zusammensetzen zeigen Tabelle 4-5 und Abbildung 4-36. Es zeigt sich, daß bei allen Phasen des Protokolles, in denen der Mehraufwand von der Anzahl der Knoten in der Stufe abhängig ist, die Ausführungszeiten annähernd linear mit der Anzahl der Knoten pro Stufe anwachsen. In der Phase “Ausführen & Stufenkonstruktion” geht der Zu- wachs alleine auf das Konto des Stufenkonstruktionsalgorithmus, hält sich jedoch mit rund 7- 10ms pro zusätzlichem Knoten in Grenzen. Der stärkste Zuwachs erfolgt durch das Schreiben des Agenten in die Eingangswarteschlangen der Knoten der nachfolgenden Stufe. Dies ist vor allem darauf zurückzuführen, daß bei der Protokollimplementation auf Portabilität auf andere Transaktions-Middleware geachtet wurde und deshalb das Schreiben des Agenten in die Ein- gangswarteschlangen der nächsten Stufe seriell erfolgt (nicht jedes Transaktionssystem erlaubt parallelen Zugriff auf verschiedene Ressourcen innerhalb derselben Transaktion). Messungen in der Arbeit von FRIEDEL (1998) zeigen, daß durch paralleles Schreiben in die Eingangswarte- schlangen der nächsten Stufe diese Zeit nochmals drastisch reduziert werden kann. Die für das Abbildung 4-35. Durchschnittliche Ausführungszeit pro Stufe Nr. Knoten 1 2 3 4 5 T [ms] 206 269 347 411 497 Tabelle 4-4. Durchschnittliche Ausführungszeit pro Stufe 0 100 200 300 400 500 600 1 2 3 4 5 K noten pro Stufe m s 4.7 Leistungsmessungen 159Commit der Transaktion benötigte Zeit steigt ebenfalls nur leicht mit zunehmender Anzahl an Knoten pro Stufe (ca. 12ms pro zusätzlichem Knoten). Messungen beim Orchestrator haben ge- zeigt, daß dieser für das Votieren unabhängig von der Anzahl der Knoten pro Stufe zwischen 3ms und 4 ms benötigt. Der zusätzliche Zeitaufwand beim Commit ist also alleine darauf zu- rückzuführen, daß zusätzliche Eingangswarteschlangen im 2PC-Protokoll teilnehmen. Auffällig an den Werten in Tabelle 4-5 sind die teilweise sehr hohen statistischen Standardab- Anzahl Knoten 1 2 3 4 5 Beginn Transaktion 4.6 (0.74) 4.64 (0.67) 5.52 (1.43) 5.82 (0.58) 7.52 (9.09) Lesen und Deseriali- sieren Agent 71.56 (11.20) 67.92 (7.31) 67.92 (5.95) 68.24 (4.37) 72.64 (11.56) Ausführen & Stufen- konstruktion 11.16 (7.92) 18.64 (11.57) 25.00 (14.47) 35.88 (18.94) 42.44 (24.97) Serialisieren und Schreiben Agent 65.48 (29.19) 98.88 (40.60) 148.68 (84.75) 183.8 (89.32) 235.52 (126.62) Registrierung Orchestrator 0 7.84 (10.07) 5.92 (3.38) 5.96 (3.58) 6.16 (3.38) Commit Transaktion 27.12 (3.49) 39.36 (6.15) 52.56 (7.62) 64.96 (8.77) 81.84 (13.88) Tabelle 4-5. Ausführungszeiten in ms (Standardabweichungen in ms) der verschiedenen Abschnitte bei der Ausführung einer Stufe Abbildung 4-36. Ausführungszeiten der verschiedenen Abschnitte bei der Ausführung einer Stufe 0 50 100 150 200 250 300 350 400 450 1 2 3 4 5 Knoten pro Stufe m s Transaktion beenden Bei Orchestrator registrieren Serialisieren und in Queue schreiben Ausführung und Stufen- konstruktion Lesen von Queue und deserialisieren Beginn Transaktion 160 Kapitel 4 Genau-einmal Ausführungweichungen. Diese sind aber leicht nachvollziehbar, wenn man bedenkt, daß die Messungen in einem Multitaskingsystem und über ein Netzwerk hinweg erfolgen und daher einzelne Mess- werte je nach aktuellem System- und Netzwerkzustand stark voneinander abweichen können. Zusammenfassend kann man sagen, daß die Messungen gezeigt haben, daß der Mehraufwand annähernd linear zur Anzahl der Knoten zunimmt: Diese lineare Zunahme der Zeit läßt sich bei allen Phasen des Protokolles, bei denen der Mehr- aufwand von der Anzahl der Knoten abhängig ist, beobachten. Einen wesentlichen Beitrag zur benötigten Zeit steuert die Serialisierung des Agenten und (vor allem) der Transport des seria- lisierten Agenten in die Warteschlangen der nachfolgenden Stufe bei. Die für den Transport des Agenten in die nächste Stufe benötigte Zeit kann in einer optimierten Implementation durch paralleles Schreiben in die Warteschlangen der nachfolgenden Stufe reduziert werden. 4.8 Verwandte Arbeiten Im Bereich der mobilen Agenten existieren bisher nur wenige verwandte Arbeiten. In den klas- sischen Bereichen der Transaktionsverarbeitung und Fehlertoleranz hingegen gibt es eine Viel- zahl unterschiedlichster Ansätze zur blockierungsfreien bzw. genau-einmal Ausführung von Programmen. Im folgenden werden zuerst die klassischen Ansätze dargestellt. 4.8.1 Bereiche Transaktionsverarbeitung und Fehlertoleranz In den Bereichen der Transaktionsverarbeitung und der Fehlertoleranz reicht die Spanne der Ansätze vom Aufbau fehlertoleranter Hardware bis zur replizierten Programmausführung auf mehreren Rechnern. Die Konstruktion fehlertoleranter Hardware setzt schon auf unterster Ebene im Bereich der Schaltkreise an. Die hier verwendeten Mechanismen haben zu dieser Arbeit keinen wesentli- chen Bezug, deshalb sei hierfür auf eine Zusammenfassung in JALOTE (1994) verwiesen. Ein auf höherer Ebene verwendetes Konzept ist das der schon erwähnten N modular redundancy. Idee hier ist, ein (beliebiges) Modul n-fach auszulegen. Die replizierten Module bekommen die- selben Eingaben und die Ausgaben dieser Module werden über (einen oder mehrere) Votierer zu einer Ausgabe (welche der Mehrzahl der produzierten Ausgaben entspricht) zusammenge- fasst. Hiermit lassen sich sowohl transiente als auch permanente Hardwaredefekte in einem Mo- dul maskieren. Eine Abwandlung dieses Konzepts, das N version programming, dient dazu, De- signfehler auf der Softwareebene zu maskieren. Das Problem der Fehlertoleranz gegen Fehler Zeit für Stufe mit n Knoten Zeit für Basisprotokoll n-1( ) Zeit für Stufe mit 2 Knoten Zeit für Basisprotokoll–( ) +≈ 4.8 Verwandte Arbeiten 161im Design liegt nicht im Blickpunkt dieser Arbeit liegt und wird deshalb hier nicht weiter aus- geführt. Im Bereich der Client/Server-Interaktion stellte SPECTOR (1982) schon sehr früh verschiedene Fehlersemantiken des entfernten Prozeduraufrufs (engl.: remote procedure call, kurz: RPC) vor. Die hierin definierte nur-einmal-Typ-2 Ausführung (engl.: only-once-type-2) entspricht laut SCHILL (1992A) der später weit verbreiteten Definition der genau-einmal Ausführung (engl.: exactly-once). Diese Fehlersemantik garantiert, daß ein Aufruf einer Server-Prozedur auch bei Ausfall und Wiederanlauf des Client- oder Server-Rechners genau einmal durchgeführt wird bzw. daß das System das Resultat genau einer einzigen Ausführung der Prozedur widerspiegelt. Sowohl SPECTOR (1982) als auch SCHILL (1992B) skizzieren Möglichkeiten zur Implementie- rung dieser Fehlersemantik – unter anderem mittels Transaktionen. ACID-Transaktionen (vgl. GRAY UND REUTER (1993) für eine Übersicht) sind ein Konzept im Bereich der Datenbanken und der fehlertoleranten Systeme. Sie stellen sicher, daß eine Menge von Operationen atomar ausgeführt wird. Atomare Ausführung bedeutet einerseits, daß entwe- der alle Operationen erfolgreich ausgeführt werden oder bei einem Abbruch der Transaktion keinerlei Effekte der in der Transaktion ausgeführten Operationen sichtbar werden. Anderer- seits bedeutet atomar auch, daß die Ausführung der Operationen, von außerhalb der Transaktion betrachtet, wie die Ausführung einer einzelnen Operation aussehen - Zwischenzustände sind nicht sichtbar. In einer Datenbank oder in anderen Ressourcen gespeicherte Ergebnisse von er- folgreich abgeschlossenen Transaktionen sind dauerhaft und gehen selbst bei einem Systemaus- fall nicht verloren. Der Programmzustand einer eine Transaktion ausführenden Applikation wird hingegen bei gängigen Transaktionssystemen bei Transaktionsende nicht auf stabilen Speicher geschrieben (und geht daher bei einem Rechnerausfall verloren). Daher realisiert das Konzept der Transaktionen zwar von sich aus noch keine genau-einmal Ausführung, es ist je- doch bei vielen Mechanismen zur fehlertoleranten Ausführung – auch bei dem in dieser Arbeit vorgestellten – ein essentieller Bestandteil. Einen großen Schritt in Richtung der genau-einmal Ausführung von langandauernden Transak- tionen geht das in GARCIA-MOLINA UND SALEM (1987) vorgestellte Transaktionsmodell für langandauernde Aktivitäten, die Sagas, auf dem auch der in dieser Arbeit vorgestellte Ansatz basiert. Um eine langfristige Blockierung von Ressourcen durch eine Transaktion zu verhin- dern, wird die langandauernde Aktivität in mehrere Teile, die sogenannten Schritte (engl.: steps), zerlegt. Jeder Schritt wird innerhalb einer ACID-Transaktion ausgeführt. Das Commit- ment eines Schrittes beginnt automatisch eine Transaktion für den nächsten Schritt. Für jeden Schritt muß ein Kompensationsschritt spezifiziert werden, der die Auswirkungen eines Schrittes rückgängig machen kann. Die Laufzeitumgebung einer Saga garantiert, daß letztendlich entwe- der alle Schritte einer Saga erfolgreich beendet werden oder die Saga abgebrochen wird. Bricht ein Schritt ab, wird Backward-Recovery durchgeführt, indem für die schon erfolgreich beende- ten Schritte die Kompensations-Schritte ausgeführt werden, wobei der abgebrochene Schritt die für einen Transaktionsabbruch übliche Recovery erfährt. Damit nach einem Fehler nicht die 162 Kapitel 4 Genau-einmal Ausführungganze bisher geleistete Arbeit verloren geht, können von der Anwendung zwischen Schritten Rücksetzpunkte geschrieben werden, auf die bei den genannten Fehlerfällen mittels Backward- Recovery zurückgesetzt werden kann und bei denen dann die Saga fortgesetzt werden kann (Forward-Recovery). Bei explizitem Abbruch der Saga durch die Anwendung werden natürlich immer alle bisher erfolgreich beendeten Schritte kompensiert. Die in GARCIA-MOLINA ET AL. (1991) vorgestellten Erweiterungen wie geschachtelte Sagas (engl.: nested sagas) und non- vital Sub-Sagas ermöglichen eine flexiblere Definition des Aufbaus einer Saga. Vor allem durch die Möglichkeit Rücksetzpunkte zu setzen realisiert das Saga-Konzept die genau-einmal Aus- führung einer Anwendung (sofern die Anwendung Rücksetzpunkte setzt). Allerdings bietet das Saga-Konzept keinerlei Vorkehrungen, die auf einem ausgefallenen Rechner zum Ausfallzeit- punkt ausgeführten Anwendungen auf einem anderen Rechner neu aufzusetzen, d.h. die An- wendungen sind so lange blockiert, bis der ausgefallene Rechner neu startet und die Recovery für die laufenden Sagas durchführt. Zwei Konzepte zur fehlertoleranten Implementierung von Servern, die nach einem Server- Ausfall möglichst schnell wieder zur Verfügung stehen sollen, sind das Warm-Backup (warmes Backup) und das Hot-Backup (heißes Backup). BERNSTEIN UND NEWCOMER (1997) bieten ei- nen guten Überblick über die Konzepte. Bei beiden Konzepten gibt es neben dem eigentlichen Server, genannt Primär-Server (engl.: primary server), noch den Backup-Server. Solange keine Fehler auftreten ist der Primär-Server für die Bearbeitung der Client-Anfragen zuständig. Beim Warm-Backup überwacht der Backup-Server nur den Primär-Server. Sobald der Primär-Server ausfällt führt der Backup-Server anhand des Logs Recovery durch, d.h. er stellt bei sich einen Zustand her der dem letzten konsistenten und ins Log geschriebenen Zustand des Primär-Ser- vers entspricht. Anschließend übernimmt der Backup-Server die Aufgaben des Primärservers. Beim Hot-Backup – auch Prozeßpaare (engl.: process pairs) genannt, vgl. GRAY UND REUTER (1993) – wird der Zustand des Backup-Servers konstant mit dem Zustand des Primär- Servers konsistent gehalten. Dies geschieht entweder, indem der Backup-Server laufend die neuen Log-Einträge des Primär-Servers mitliest und damit seinen Zustand aktualisiert (andau- erndes Recovery), oder indem die Client-Anfragen auch an den Backup-Server geschickt wird und dieser die Anfragen ebenfalls bearbeitet, aber keine Antworten an den Client schickt. So- wohl Warm-Backup als auch Hot-Backup setzen absolut zuverlässige Kommunikation (ohne Ausfall) und daher physikalische Nähe zwischen Primär- und Backup-Server voraus. Vorteil des Warm-Backup ist, daß ein Server als Backup für mehrere Primär-Server verwendet werden kann, da er nur im Falle eines Ausfalles eines Primärservers dessen Arbeit übernehmen muß. Um gegen den gleichzeitigen Ausfall mehrerer Primär-Server gewappnet zu sein sind entspre- chend mehr Backup-Server vorzusehen. Es entsteht also ein relativ geringer Mehraufwand. Nachteil des Warm-Backup ist, daß der Backup-Server nach Ausfall des Primär-Servers erst ei- nen konsistenten Zustand herstellen muß und er daher die Bearbeitung von Client-Anfragen nur mit Verzögerung aufnehmen kann. Beim Hot-Backup hingegen wird, vorausgesetzt daß die Pri- mär-Server ausgelastet sind, für jeden Primär-Server ein Backup-Server benötigt, da der 4.8 Verwandte Arbeiten 163Backup-Server andauernd damit beschäftigt ist, auf dem gleichen Stand zu sein wie der Primär- Server. Der hierdurch eingeführte Mehraufwand ist erheblich. Allerdings kann hier der Backup- Server unverzüglich die Arbeit der Primär-Servers bei dessen Ausfall übernehmen. Bei der Ent- scheidung Warm-Backup versus Hot-Backup gilt es folglich abzuwägen, ob die schnelle Über- nahme der Arbeit den durch Hot-Backup eingeführten Mehraufwand für den Einsatzzweck rechtfertigt. Warm-Backup und Hot-Backup führen jedoch nur Fehlertoleranz für den Server ein, eine fehlertolerante Ausführung der Client-Anwendungen ist hiermit nicht gegeben. Das Prinzip des Hot-Backup findet man in Erweiterungen in einigen Arbeiten vor. YAP, JALOTE UND TRIPATHI (1988) stellen einen fehlertoleranten RPC vor, bei dem die Anfrage der Clients an einen Primär-Server und mehrere Backup-Server verschickt wird. Alle Server bearbeiten die Anfrage, nur der Primär-Server schickt die Antwort an den Client. Fällt der Primär-Server aus, übernimmt einer der Backup-Server. Eine Übertragung dieses Prinzips auf das modernere Pro- grammierparadigma der objektorientierten Programmierung führen BEEDUBAIL ET AL. (1995) durch. Auch hier hat jedes Primär-Objekt mehrere Backup-Objekte. Die Methodenaufrufe auf das Primär-Objekt werden gleichzeitig an die Backup-Objekte verteilt und von diesen bearbei- tet. Auch hier ist eine fehlertolerante Ausführung der Client-Anwendungen nicht gegeben. Eine für den Anwendungsprogrammierer transparente fehlertolerante Ausführung der Anwen- dung präsentiert der auf dem Konzept des Hot-Backup basierende Ansatz von BRESSOUD (1998). Die Ausführung einer Anwendung erfolgt repliziert auf mehreren Rechnern, wobei eine Ausführungsinstanz die Primär-Instanz ist, die anderen Ausführungsinstanzen sind Backup-Instanzen. Die transparente Replikation wird erreicht, indem einerseits eine Zwischen- schicht zwischen Applikation und Betriebssystem eingefügt wird und andererseits transparente Änderungen am Code der Anwendung zur Laufzeit durchgeführt werden. Die Zwischenschicht zwischen Applikation und Betriebssystem bietet der Applikation dabei dieselbe Schnittstelle wie das Betriebssystem. Die Zwischenschicht und die Codemodifikationen garantieren, daß Be- triebssystemaufrufe und die Auslieferung von Ausnahmen (engl.: exceptions) auf allen Replika- ten in derselben Reihenfolge ausgeführt werden, wobei nichtdeterministische Betriebssystem- aufrufe (z.B. Uhrzeit auslesen) auf der Primärinstanz ausgeführt und die Ergebnisse den Replikaten zugeschickt werden. Fällt die Primärinstanz aus, wird eines der anderen Replikate zur Primärinstanz gewählt. Neben dem bei Hot-Backup typischen hohen Mehraufwand hat der Ansatz noch die Nachteile, daß die Transparenz im Fehlerfalle nicht garantiert wird und daß der Mechanismus keine Netzwerkpartitionierungen toleriert. WÄCHTER UND REUTER (1992) und REUTER, SCHNEIDER UND SCHWENKREIS (1997) stellen mit dem ConTract Modell einen dem in dieser Arbeit vorgestellten Ansatz im Ziel sehr ähnlichen Ansatz vor. Das ConTract Modell hat ebenfalls die fehlertolerante genau-einmal Ausführung langandauernder Berechnungen (z.B. Workflows) in einer verteilten Umgebung zum Ziel. Eine Anwendung besteht aus einer Menge von Schritten, deren Ablaufreihenfolge sehr flexibel durch ein Script definiert wird. Im Gegensatz zu unserem Ansatz ist hier auch die parallele Abarbei- tung von Schritten möglich. Ein Schritt selbst ist ein Programm das einen Teil der Anwendungs- 164 Kapitel 4 Genau-einmal Ausführunglogik implementiert. Es wird im allgemeinen in einer Transaktion ausgeführt. Der Zustand eines Scripts, welcher den Gesamtzustand der Anwendung repräsentiert, wird in persistenten Varia- blen, den sogenannten Kontext-Variablen, gehalten. Dies ermöglicht den einfachen Neustart ei- nes Schrittes im Falle eines (System-)Fehlers während der Ausführung des Schrittes. Schwer- punkt der Forschung beim ConTract Modell ist vor allem die Wahrung der Konsistenz bei der Ausführung eines Scripts und weniger die Problematiken der Tolerierung von Netzwerkparti- tionierungen oder der Weiterführung einer Anwendung bzw. eines Scripts auf anderen Rech- nern im Falle eines Rechnerausfalles. Beispielsweise wird im Gegensatz zu dem in dieser Arbeit vorgestellten Ansatz die Koordination der Ausführung eines Scripts von einer stationären Con- Tract Engine ausgeführt, welche die Ausführung des Scriptes bei Rechnerausfall erst nach Neustart des Rechners fortsetzt. Einen Überblick über eine prototypische Implementation bie- ten SCHNEIDER (1997B) und SCHNEIDER (1998). 4.8.2 Mobile Agenten Bei den Ansätzen aus dem Bereich der mobilen Agenten reicht die Spanne von Algorithmen, die nur einzelne Teile der Ausführung mobiler Agenten, beispielsweise die Migration, mit mehr Fehlertoleranz versehen bis zu Algorithmen zur Erkennung bzw. Vermeidung byzantinischer Fehler bei der Ausführung der Agenten. Alle Ansätze bis auf den zuletzt vorgestellten berück- sichtigen bei Knoten nur Crash-Fehler, Netzwerkfehler bzw. die Partitionierung von Netzwer- ken werden oft nicht toleriert. Ein Ansatz der vor allem die fehlerfreie Migration von Agenten sicherstellt wird sowohl in VOG- LER, KUNKELMANN UND MOSCHGATH (1997A) als auch in VOGLER, KUNKELMANN UND MOSCHGATH (1997B) beschrieben. Hierbei wird die Migration eines Agenten – ähnlich wie in dem in dieser Arbeit entwickelten Ansatz – innerhalb einer verteilten Transaktion durchgeführt. Dies stellt sicher, daß der Agent entweder erfolgreich auf dem Zielrechner der Migration an- kommt oder noch auf dem Ursprungsrechner der Migration ist, d.h. daß der Agent bei der Mi- gration nicht verloren gehen kann. Bricht ein Rechner wegen eines Fehlers zusammen, so wird ein auf diesem Rechner zum Zeitpunkt des Zusammenbruchs ausgeführter Agent nach Neustart des Rechners erneut gestartet – im selben Zustand, in dem der Agent direkt nach seiner Ankunft auf dem Rechner gestartet wurde. Da keine weiteren Maßnahmen getroffen werden, führt der Agent bei einem Neustart die vor dem Zusammenbruch des Rechners ausgeführten Operationen erneut aus. Gibt der Agent beispielsweise vor dem Rechnerausfall eine Bestellung von Waren auf, so macht er dies nach dem Neustart erneut und hat somit zwei Bestellungen aufgegeben, obwohl nur eine gewünscht ist. Es ist hier also nicht sichergestellt, daß ein Agent die von ihm zu erledigenden Arbeiten nur einmal ausführt. Ähnliche Ansätze werden in DALMEIJER ET AL. (1998) und WALSH, PACIOREK UND WONG (1999) beschrieben. Hier haben die Agenten al- lerdings die Möglichkeit, Rücksetzpunkte (engl.: savepoints) zu schreiben und nach einem Neustart beim aktuellsten Rücksetzpunkt mit der Ausführung zu beginnen. Bei entsprechender 4.8 Verwandte Arbeiten 165(aufwendiger) Programmierung der Agenten ermöglicht dies eine genau-einmal Ausführung der Agenten. Defizit aller dieser Verfahren ist, daß die Ausführung eines Agenten blockiert bleibt, solange sein momentaner Aufenthaltsort (d.h. der ihn momentan ausführende Rechner) wegen eines Fehlers oder einer Rechnerabschaltung außer Betrieb ist. Ist der ausführende Rech- ner wegen eines Netzwerkfehlers vom Netzwerk abgeschnitten, kann der Agent erst nach Be- hebung des Netzwerkfehlers auf einen anderen Rechner migrieren. Einen Ansatz, in dem die fehlertolerante Ausführung mobiler Agenten durch den Einsatz eines hochverfügbaren Systems (Tandem Himalaya Server) erreicht wird beschreibt BADER (1998). Der Ansatz stellt sicher, daß ein Agent seine Aufgaben genau einmal ausführt, verhindert jedoch nicht, daß Agenten durch eine Netzwerkpartitionierung langfristig blockiert werden. Die Blockierung von Agenten im Falle von Fehlern durch einen Warm-Backup-Ansatz zu ver- hindern wird von JOHANSEN, VAN RENESSE UND SCHNEIDER (1995) vorgeschlagen. Eine Nach- hut (engl.: Rear-Guard), die bei der Migration zurückgelassen wird, soll die Ausführung des Agenten auf dem Zielrechner der Migration überwachen. In JOHANSEN ET AL. (1999) wird die- ser Vorschlag konkretisiert. Sobald ein Agent bei der Migration auf dem Zielrechner ankommt, wird der Agent mittels eines zuverlässigen Broadcast-Protokolls auf eine Menge weiterer Rech- ner – zum Beispiel einige der Rechner, welche den Agent in der Vergangenheit ausgeführt haben – zusätzlich versendet. Diese Rechner sind dafür zuständig, die Ausführung des Agenten zu überwachen. Sobald der Agent auf diesen Überwachungsrechnern angekommen ist, wird auf dem Zielrechner die ihm zugeordnete Aktion gestartet. Als eine Aktion werden von JOHANSEN ET AL. (1999) die auf einem einzelnen Rechner auszuführenden Operationen bezeichnet. Für jede Aktion gibt es eine Wiederherstellungsaktion (engl.: recovery action). Ein in das Broad- cast-Protokoll integriertes, kombiniertes Auswahl- (engl.: election) und Überwachungs-Proto- koll (engl.: monitoring protocol) stellt sicher, daß bei Abbruch der Aktion (zum Beispiel durch Rechnerabsturz) auf genau einem der Überwachungsrechner die der abgebrochenen Aktion zu- geordnete Wiederherstellungsaktion ausgeführt wird. Hierdurch werden jedoch die auf dem ausgefallenen Rechner bereits durchgeführten Operationen nicht automatisch zurückgesetzt. Hat der Agent dort zum Beispiel den Inhalt einer nur lokal zugreifbaren Datenbank geändert, so bleiben diese Änderungen erhalten, da diese von dem Überwachungsrechner aus gar nicht rück- gängig gemacht werden können. Es ergibt sich also eine äußerst unklare Semantik der Ausfüh- rung eines Agenten. Weiterhin toleriert das Protokoll in der vorgestellten Version keine Netz- werkpartitionierung. Mit einem auf dem in diesem Kapitel vorgeschlagenen blockierungsfreien Protokoll aufbauen- den Protokoll stellen ASSIS SILVA UND POPESCU-ZELETIN (1998) einen weiteren Warm- Backup-Ansatz vor. Das Protokoll basiert ebenfalls auf einem Stufenkonzept (engl.: stage con- cept). Bei der Migration wird ein Agent innerhalb einer Transaktion auf mehrere Rechner (die Stufe) transportiert. Einer der Rechner führt den Agent aus, die anderen überwachen die Aus- führung. Um die Wiederherstellung eines Agenten nach Rechnerausfall zu unterstützen, schreibt der Agent regelmäßig Rücksetzpunkte - sowohl in kürzeren Abständen lokal auf dem 166 Kapitel 4 Genau-einmal Ausführungausführenden Rechner als auch in längeren Abständen in einer “Verteilten Datenbank”. Die ver- teilte Datenbank besteht aus Datenreplikaten auf den Rechnern der aktuellen Stufe. Der Zugriff auf die Replikate der verteilten Datenbank wird durch Votieren mit Mehrheitsentscheid gere- gelt. Fällt der einen Agenten ausführende Rechner aus, so wird nach Neustart des Rechners der Agent beim aktuellsten lokalen oder globalen Rücksetzpunkt aufgesetzt. Fällt der Rechner län- gerfristig aus, wird dies durch die überwachenden Rechner erkannt. Ein Auswahl-Protokoll stellt sicher, daß nur einer der überwachenden Rechner den Agenten beim aktuellsten globalen Rücksetzpunkt aufsetzt. Der Mechanismus stellt sicher, daß immer nur der zuletzt für einen Agenten ausgewählte Ausführungsrechner auf die verteilte Datenbank schreiben darf. Hier- durch toleriert das Protokoll einerseits Netzwerkpartitionierungen und kann andererseits damit umgehen, daß ein nach einem längerfristigen Ausfall neu startender Rechner einen beim Ausfall des Rechners ausgeführten Agenten neu startet, obwohl dieser Agent zwischenzeitlich längst auf einem der überwachenden Rechner gestartet wurde. Stellt ein Agent auf einem Rechner fest, daß es eine “aktuellere” Ausführungsinstanz gibt (d.h. es wurde zwischenzeitlich ein anderer Rechner als Ausführungsrechner ausgewählt), dann wird der Agent auf den letzten von ihm ge- schriebenen globalen Rücksetzpunkt zurückgesetzt und die Ausführung auf dem Rechner been- det. Nachteil des Mechanismus ist, daß eine genau-einmal Ausführung eines Agenten nur durch aufwendige Programmierung (Rücksetzpunkte setzen, Rücksetzoperationen zur Herstellung des letzten globalen Rücksetzpunktes) zu erreichen ist. Ein weiterer Nachteil des Protokolls ist der gegenüber dem in diesem Kapitel vorgestellten Protokoll wesentlich höhere Aufwand. Die- ser ist einerseits dadurch bedingt, daß bei der Migration relativ zu unserem Protokoll etwa 50% mehr Rechner in der verteilten Transaktion beteiligt sind und daß zur (recht gering ausfallenden) Erhöhung der Fehlertoleranz ein 3-Phasen-Commit-Protokoll verwendet wird. ASSIS SILVA UND KRAUSE (1997) stellen ein dem unseren Modell sehr ähnliches Modell für verteilte Transaktionen basierend auf mobilen Agenten vor. Ein Agent hat eine Menge von Auf- gaben (engl.: tasks) zu erledigen. Jede Aufgabe wird auf einem Rechner innerhalb einer Trans- aktion bearbeitet. Es besteht zusätzlich die Möglichkeit, mehrere Aufgaben hintereinander auf mehreren Rechnern innerhalb einer Transaktion zu bearbeiten. Die Ausführung von Agenten wird überwacht, um die sich auf einem längerfristig ausgefallenen Rechner befindlichen Agen- ten auf anderen Rechnern neu starten zu können. Hierfür wird bei jeder Migration der Zustand des Agenten in einer zentralen Kontextdatenbank geschrieben. Die Überwachung von Agenten geschieht zentral. Wird die Bearbeitung eines Agenten abgebrochen, werden die bisherigen Ak- tionen des Agenten per Kompensation zurückgesetzt. Leider werden in der Veröffentlichung keinerlei Algorithmen zum Erreichen der beschriebenen Semantik angegeben. Die zentrale Kontextdatenbank und Überwachung der Agenten deuten darauf hin, daß das dem beschriebe- nen Modell zugrundeliegende Fehlermodell keine Netzwerkpartitionierung zuläßt. Einen wesentlich höheren Grad an Fehlertoleranz bietet der von MINSKY ET AL. (1996) und SCHNEIDER (1997A) vorgestellte Mechanismus. Während die bisher vorgestellten Ansätze da- von ausgehen, daß Rechner nur unter Crash-Fehlern leiden, umfaßt das diesem Mechanismus 4.9 Diskussion 167zugrundeliegende Fehlermodell auch byzantinische Fehler. Auch dieser Mechanismus basiert auf einem Stufenkonzept. Im Gegensatz zu den bisherigen Ansätzen führt hier ähnlich einem Hot-Backup-Ansatz jeder der Rechner einer Stufe den Agent aus. Im Gegensatz zum Hot- Backup sind hier jedoch alle Rechner gleichberechtigt - es wird nicht zwischen Primärrechner und Backup-Rechner unterschieden. Nach der Ausführung des Agenten verschickt jeder Rech- ner den Agent bei der Migration zu allen Rechnern der nächsten Stufe. Die Rechner jeder Stufe erhalten daher mehrere Agenten (maximal n Agenten wenn die vorhergehende Stufe n Rechner umfaßte; weniger als n Agenten bei Rechner-/Netzwerkausfällen), aus denen sie mittels einer Mehrheitsentscheidung den auszuführenden Agenten ermitteln. Hiermit können bei n Rechnern pro Stufe n/2-1 (Rechner- und Netzwerk-) Fehler maskiert werden. Dieser Ansatz ist dem NMR- Ansatz (N modular redundancy, vgl. JALOTE (1994)) nachempfunden, welcher erfolgreich in fehlertoleranter Hardware angewandt wurde. Obwohl dieser Ansatz den bestmöglichen Grad an Fehlertoleranz bietet, ist er in der Realität aus drei Gründen in nur sehr wenigen Situationen an- wendbar. Erstens führt der Mechanismus einen extremen Mehraufwand ein. Bei n Rechnern pro Stufe findet die Berechnung n-fach statt. Zusätzlich muß jeder Rechner noch aus n erhaltenen Agenten den auszuführenden bestimmen. Zweitens setzt der Algorithmus voraus, daß die durch den Agenten genutzten Dienste auf allen Rechnern einer Stufe repliziert sind und diese Repli- kate auch bei Fehlern konsistent gehalten werden. Und schließlich setzt der Algorithmus vor- aus, daß die Ausführung eines Agenten auf einem Rechner determiniert ist, d.h. daß bei gleicher Ausgangssituation die gleichen Resultate erzeugt werden. Um dies zu erreichen, müßte zum Beispiel eine Abfrage der Uhrzeit auf den Rechnern einer Stufe den Replikaten eines Agenten dieselbe Uhrzeit liefern. Der Mehraufwand des Mechanismus wird wohl nur für sehr wenige Anwendungsgebiete tolerierbar sein, replizierte Dienste und garantiert determinierte Ausfüh- rung auf mehreren Rechnern dürfte nur in den seltensten Anwendungen gegeben sein. 4.9 Diskussion Ergebnisse In diesem Kapitel wurden Protokolle entwickelt, welche die in Definition 4-1 festgelegte genau- einmal Ausführung für mobile Agenten implementieren. Der Entwicklung der Protokolle zu- grundegelegt wurden hierbei das in Abschnitt 2.2 beschriebene Agentenmodell und die in Ab- schnitt 4.1 beschriebenen System- und Fehlermodelle. Das zuerst entwickelte Basisprotokoll stellt zwar die genau-einmal Ausführung mobiler Agenten sicher, bietet jedoch keinen Schutz vor Blockierung bei Knoten- oder Netzwerkausfall. Deshalb wurde das Basisprotokoll zu einem Protokoll weiterentwickelt, welches bei Systemfehlern die Blockierung der Ausführung der mobilen Agenten verhindert. Abschnitt 4.6 zeigt, daß durch das blockierungsfreie Protokoll eine signifikant geringere Blockierwahrscheinlichkeit im Vergleich zum Basisprotokoll erreicht wurde. Jedoch zeigen Abschnitt 4.5 und Abschnitt 4.7, daß diese Verbesserung nur durch einen wesentlichen Mehr- 168 Kapitel 4 Genau-einmal Ausführungaufwand bei der Ausführung der mobilen Agenten erkauft wird. Abschnitt 4.6.5.2 zeigt, daß im Mittel die für diesen Mehraufwand benötigte Zeit unter realen Bedingungen größer ist als die durch die Vermeidung von Blockierungen gewonnene Zeit. Durch die Funktionsweise des Pro- tokolls ist es der Anwendung bzw. dem Anwender allerdings möglich, die Fehlertoleranz und damit den erforderlichen Mehraufwand an die Erfordernisse der Anwendung zu adaptieren: Wird ein hoher Grad an Fehlertoleranz erwartet, d.h. ist eine Vermeidung von Blockierungen notwendig, so wird eine große Stufengröße verwendet welche viel Mehraufwand erzeugt. Für einen geringen Grad an Fehlertoleranz reicht eine kleine Stufengröße mit entsprechend gerin- gerem Mehraufwand aus. Hierbei ist das Basisprotokoll der Sonderfall des blockierungsfreien Protokolls mit einer Stufengröße von 1. Einschränkungen des Agentenmodells Zwei Besonderheiten des in Abschnitt 2.2 vorgestellten Agentenmodells stehen in direkter Be- ziehung mit der Funktionsweise der in diesem Kapitel vorgestellten Protokolle. Sowohl die Ein- schränkung, daß ein mobiler Agent nicht mit einem anderen mobilen Agent direkt kommuni- zieren darf als auch die Einschränkung, daß ein mobiler Agent keinen neuen mobilen Agent starten bzw. einen Klon von sich selbst erzeugen darf, hängt eng damit zusammen, daß die ein- zelnen Schritte der mobilen Agenten in einer Transaktion ausgeführt werden. Zu den Eigen- schaften einer Transaktion gehört unter anderem, daß die Ergebnisse der Transaktion für andere Transaktionen erst nach erfolgreichem Transaktionsabschluß sichtbar sein dürfen. Kommuni- zieren zwei mobile Agenten direkt, wird diese Eigenschaft der Transaktionen verletzt, wie die zwei folgenden Beispiele zeigen. Beispiel 4-1. Zwei Agenten A1 und A2 werden beide jeweils in einer Schritt-Transaktion ausgeführt. A1 liest den Wert einer Ressource R und teilt diesen Wert dem Agenten A2 mit. Sowohl A1 als auch A2 berechnen aufgrund dieses Wertes unterschiedliche neue Werte für R. Da die Ressource von Agent A1 gesperrt ist, schreibt zuerst A1 seinen neuen Wert für R und schließt die Schritt-Transaktion ab. Erst dann kann A2 seinen Wert in R schreiben – und überschreibt damit den von A1 geschriebenen Wert. Diese Konstellation in Konflikt stehender Operationen wird im Bereich der Datenbanken auch “verlorengegangene Ände- rung” (engl.: lost update) genannt (vgl. HÄRDER UND RAHM (1999)). Beispiel 4-2. Agent A1 berechnet innerhalb einer Schritt-Transaktion einen Wert und kom- muniziert diesen Wert noch innerhalb der Transaktion an A2. Agent A2 beendet die Schritt-Transaktion, in der er den Wert von A1 erhalten hat, und setzt seine Ausführung mit dem nächsten Schritt fort. A1 bricht danach seine Schritt-Transaktion ab. A2 rechnet jetzt mit einem Wert, den A1 logisch gesehen nie berechnet hat (auch “Zugriff auf schmut- zige Daten (engl.: dirty read)” genannt, vgl. ebenfalls HÄRDER UND RAHM (1999)). Die beiden Beispiele zeigen, daß eine direkte Kommunikation zwischen zwei Agenten bei der Funktionalität der in diesem Kapitel vorgestellten Protokolle nicht möglich ist. Indirekte Kom- munikation mittels einer Kommunikationsressource hingegen, beispielsweise mittels einer 4.9 Diskussion 169transaktionalen Nachrichtenwarteschlange, kann natürlich problemlos realisiert werden. Dies eignet sich jedoch nicht zur Realisierung von Dialogen, da beispielsweise eine von einem Agent A1 in eine transaktionale Nachrichtenwarteschlange geschriebene Nachricht erst dann von ei- nem anderen Agent gelesen werden kann, wenn A1 die Schritt-Transaktion, innerhalb der die Nachricht geschrieben wurde, erfolgreich beendet hat. Wie jedoch Kapitel 5 zeigen wird, wird selbst diese Art der Kommunikation problematisch, wenn die Möglichkeit besteht, die Ausfüh- rung des Agenten teilweise zurückzusetzen. Ein sehr ähnliches Problem ergibt sich, wenn ein Agent A1 einen weiteren Agenten A2 startet bzw. einen Klon A2 von sich selbst erzeugt. Bricht nämlich die umgebende Schritt-Transaktion ab, so muß dafür gesorgt werden, daß A2 auch abgebrochen wird. Hat dieser jedoch zwischen- zeitlich den Knoten, auf dem er erzeugt wurde, verlassen, ist dies nicht mehr ohne weiteres möglich. Eine mögliche Lösung ist, A2 innerhalb der Schritt-Transaktion von A1 auf die Knoten der ersten Stufe von A2 zu verteilen. Somit erscheint A2 auf den Knoten seiner ersten Stufe, so- bald A1 die Schritt-Transaktion, innerhalb der A2 erzeugt wurde, beendet. Wie Kapitel 5 zeigen wird, ist auch diese Lösung sehr problematisch, wenn die Möglichkeit besteht, die Ausführung eines Agenten teilweise zurückzusetzen. 170 Kapitel 4 Genau-einmal Ausführung Kapitel 5 Partielles Rücksetzen Die im letzten Kapitel vorgestellten Mechanismen realisieren im Fehlerfall eine strikte Forward Recovery: Schlägt aus beliebigem Grund die Durchführung einer Schritt-Transaktion fehl, so werden die bereits ausgeführten Schritte des Agenten nicht zurückgesetzt (Backward Recove- ry), sondern die Ausführung des Agenten entweder durch eine Wiederholung des abgebroche- nen Schrittes oder durch die Ausführung eines alternativen Schrittes “nach vorne” fortgesetzt. Es gibt jedoch Situationen, in denen der Abbruch und der Neustart eines Schrittes nicht zur Be- handlung einer Fehlersituation ausreichen. Stellt der Agent fest, daß die von ihm bisher verfolg- te Strategie nicht zum Ziel führt – weil ihm beispielsweise die Zugriffsberechtigung zu einer Ressource fehlt oder weil das bisherige Vorgehen nicht die gewünschten Ergebnisse liefert – so kann es notwendig sein, Teile der bisherigen Ausführung des Agenten rückgängig zu machen. Das partielle Rücksetzen der Ausführung eines mobilen Agenten kann prinzipiell auf zwei ver- schiedene Arten realisiert werden. Eine Möglichkeit ist, daß der Entwickler des Agenten die dazu notwendige Funktionalität in den Agenten direkt integriert. In diesem Fall unterscheidet sich für die Agentenplattform das Rücksetzen nicht von der normalen Agentenausführung, der Entwickler eines Agenten muß jedoch – für jeden Agenten erneut – das Rücksetzen des Agenten vollständig ausprogrammieren. Diese Aufgabe ist schon für normale Programme mit (mehr oder weniger) feststehendem Programmablauf nicht ganz einfach. Beinahe unmöglich wird die- se Aufgabe jedoch, wenn durch die Verwendung des in Abschnitt 3.2 vorgestellten Reiserouten- konzeptes die Schritte des Agenten in sehr unterschiedlicher Reihenfolge ausgeführt werden können, da das Rücksetzen von Operationen im allgemeinen von deren Ausführungsreihenfolge abhängt. Die deshalb zu bevorzugende Möglichkeit zum Rücksetzen der Agentenausführung ist, daß die Agentenplattform Mechanismen zur Verfügung stellt, die auf Anforderung das Rücksetzen weitestgehend automatisiert durchführen. Die Entwicklung solcher Mechanismen ist Ziel dieses Kapitels. Erste Versionen der hier entwickelten Mechanismen und Konzepte wur- den in STRASSER UND ROTHERMEL (2000) publiziert. 172 Kapitel 5 Partielles Rücksetzen5.1 Problemstellung Die exakte Problemstellung des partiellen Rücksetzens der Ausführung mobiler Agenten eröff- net sich nur durch die Betrachtung des Ausführungsmechanismus für mobile Agenten. Im Kon- text dieser Arbeit wird nur betrachtet, wie das partielle Rücksetzen für die im vorherigen Kapitel vorgestellten Mechanismen zur genau-einmal Ausführung mobiler Agenten realisiert werden kann. Eine direkte Übertragung der dabei entwickelten Konzepte auf andere Ausführungsme- chanismen ist nur eingeschränkt möglich. Es wird im Laufe dieses Kapitels offensichtlich werden, daß das für das partielle Rücksetzen relevante Grundprinzip – nämlich die Ausführung des Agenten in einer Schritt-Transaktion mit- tels Lesen des Agenten von stabilem Speicher, Ausführen des Agenten und Schreiben des Agen- ten auf stabilen Speicher – sowohl beim Basisalgorithmus als auch bei der blockierungsfreien Erweiterung dasselbe ist. Deshalb wird der Mechanismus zum partiellen Rücksetzen vorerst an- hand des Basisprotokolls zur genau-einmal Ausführung mobiler Agenten entwickelt und dann gezeigt, wie dieser Mechanismus in das erweiterte Protokoll integrierbar ist. Abbildung 5-1 zeigt die Ausführung der Schritte i, i+1 und i+2 des Agenten A, wobei die Schrit- te i und i+1 schon vollständig abgeschlossen sind und Schritt i+2 sich noch in Ausführung be- findet. Die Ausführung eines Schrittes erfolgt dabei wie in Abschnitt 4.3 beschrieben: Innerhalb einer Transaktion, der Schritt-Transaktion, wird der Agent aus der Eingangswarteschlange des ausführenden Knotens gelesen, ausgeführt und in die Eingangswarteschlange des nachfolgen- den Knotens geschrieben. Während der Ausführung ändert der Agent hierbei die lokalen Res- sourcen Rk (k=i, i+1, i+2) der ausführenden Knoten. Im Laufe der Ausführung des Schrittes i+2 stellt der Agent fest, daß ein partielles Rücksetzen notwendig ist. Da die meisten heutzutage ver- fügbaren Transaktionsmanagementsysteme keine Rücksetzpunkte für Ressourcen innerhalb ei- ner Transaktion unterstützen, kann nur auf Zustände zwischen (beziehungsweise vor) den Abbildung 5-1. Ausführung eines Agenten Ki+2 R read access Ai+2Ki+1 read write access Ai Ai+1Ki read write access Ai: Agentenzustand vor Ausführung von Schritt i Ki: Knoten, welcher Schritt i ausführt R : Zustand der Ressourcen von Knoten i R : Ri nach Ausführung des Schrittes i Ti Ti+1 Ti+2 Ti: Schritt-Transaktion i 1 i+2R 1 i R 2 i R 1 i+1 R 2 i+1 R 2 i+2 vor Ausführung des Schrittes i 1 i 2 i execute si execute si+1 execute si+2 5.1 Problemstellung 173Schritt-Transaktionen, d.h. zwischen (beziehungsweise vor) Schritten, zurückgesetzt werden. Im vorliegenden Beispiel bedeutet dies, daß der Agent nur auf die Zustände Ai+2, Ai+1, Ai,..., A1 zurückgesetzt werden kann. Muß der Agent nur auf den Zustand Ai+2 zurückgesetzt werden, ist dies einfach realisierbar, in- dem die Schritt-Transaktion Ti+2 abgebrochen wird. Das Transaktionsmanagement sorgt in die- sem Falle automatisch dafür, daß der Agent im Zustand Ai+2 in der Eingangswarteschlange des Knotens Ki+2 vorliegt und daß die während der Ausführung des Schrittes an den Ressourcen Ri+2 durchgeführten Änderungen rückgängig gemacht werden. Wesentlich problematischer ist das Rücksetzen des Agenten auf die Zustände A1, A2, ..., Ai+1. Das Problem hierbei ist, daß nach Abschluß der Schritt-Transaktionen T1, T2, ..., Ti+1 andere Anwendungen auf die durch den Agenten geänderten Ressourcen R1, R2, ..., Ri+1 zugreifen können. Somit ist ein einfaches Rück- setzen der Ressourcen auf den ursprünglichen Zustand durch das Transaktionsmanagement nicht mehr möglich. Aus diesem Grunde muß das Rücksetzen der Ressourcen in diesem Fall mittels Kompensationstransaktionen (engl.: compensation transaction) erfolgen (vgl. auch KORTH, LEVY UND SILBERSCHATZ (1990)). Wie sich in den folgenden Absätzen zeigen wird, kann nicht einmal der Zustand des Agenten zurückgesetzt werden, indem einfach der alte Da- tenzustand des Agenten wieder hergestellt wird. Im Gegensatz zu gängigen Ansätzen (z.B. GARCIA-MOLINA UND SALEM (1987)) muß also zusätzlich zum Zustand der Ressourcen auch der Zustand des Agenten mittels Kompensation zurückgesetzt werden. Zum Zwecke der Ver- einheitlichung wird in Anlehnung an KORTH, LEVY UND SILBERSCHATZ (1990) der Begriff des erweiterten Zustandsraumes eingeführt: Definition 5-1: Erweiterter Zustandsraum Der erweiterte Zustandsraum ist die Vereinigung des Zustandes des Agenten mit dem Zustand der Ressourcen, auf die der Agent zugreift. Hiermit kann die Ausführung eines Schrittes als Folge von Operationen auf diesem erweiterten Zustandsraum beschrieben werden. Das Zurücksetzen eines bereits abgeschlossenen Schrittes geschieht dann mittels Kompensationsoperationen auf dem erweiterten Zustandsraum. Im Gegensatz zum Rücksetzen der Ausführung eines sich in Ausführung befindlichen Schrittes durch Abbruch der Schritt-Transaktion werden für Kompensationsoperationen zusätzliche In- formationen benötigt. Löscht ein Agent beispielsweise während eines Schrittes Daten, welche er in vorherigen Schritten gesammelt hat, aus seinem Datenzustand, so werden diese verworfe- nen Daten für die Kompensation dieses Schrittes benötigt. Es ist also notwendig, während der Ausführung eines Schrittes die für die Kompensation des Schrittes notwendigen Informationen zu sammeln und im Falle einer Kompensation des Schrittes wieder zur Verfügung zu stellen. Der folgende Abschnitt diskutiert das Konzept der Kompensation und dessen Einschränkungen. Anschließend wird das in Abschnitt 2.2 eingeführte Agentenmodell detailliert und um das Rücksetzen von Agenten erweitert. Abschnitt 5.4 präsentiert einen auf diesem erweiterten Mo- 174 Kapitel 5 Partielles Rücksetzendell basierenden Mechanismus zum Rücksetzen, Abschnitt 5.5 beschreibt mögliche Optimie- rungen dieses Mechanismus’. Mögliche Erweiterungen des Reiseroutenkonzeptes zur Integra- tion des Rücksetzmechanismus’ und eine Diskussion der Ergebnisse schließen das Kapitel ab. 5.2 Kompensation Die Kompensation einer Operation hat zum Ziel, die semantischen Effekte dieser Operation zu beseitigen. Unglücklicherweise ist dies jedoch nicht immer möglich. Inwieweit die Kompensa- tion einer Operation möglich ist hängt hierbei sowohl von der Operation als solcher als auch vom Anwendungsprogramm ab. In diesem Abschnitt wird diese Problematik der Kompensation näher betrachtet. Eine sehr ausführliche Diskussion findet man in dem Artikel von KORTH, LEVY UND SILBERSCHATZ (1990). Der bei Kompensationsoperationen wünschenswerte Fall ist, daß die Kompensationsoperation den Effekt der zu kompensierenden Operation komplett eliminiert. Wird die Kompensations- operation CO1 direkt nach der zu kompensierenden Operation O1 ausgeführt, so wird in diesem Falle der ursprüngliche, erweiterte Zustandsraum Z wieder hergestellt, d.h. CO1(O1(Z))≡Z. Wird zwischen der Ausführung von O1 und CO1 eine beliebige andere Operation (oder Menge von Operationen) O2 auf den ursprünglichen, erweiterten Zustandsraum ausgeführt, dann spie- gelt in diesem Fall der nach der Kompensationsoperation CO1 resultierende Zustandsraum nur noch die Auswirkungen der Operation(en) O2 wider, d.h. CO1(O2(O1(Z)))≡O2(Z). Anwendun- gen, bei denen diese Art der Kompensation möglich ist, sind in der realen Welt nur sehr selten anzutreffen. Kann auf ein Bankkonto mit unbegrenztem Kredit nur mittels den Operationen Abheben(Geld) und Einzahlen(Geld) zugegriffen werden, so sind Abheben(..) und Einzahlen(..) die Kompensationsoperationen der jeweils anderen Operation. Wird von kurzfristig anfallenden Zinsen abgesehen, so kann in diesem Fall ein Abheben(x) durch ein Einzahlen(x) jederzeit voll- ständig kompensiert werden und umgekehrt. Dies gilt schon nicht mehr, wenn das Konto keinen unbegrenzten Kredit erlaubt. Wird nach einem Einzahlen(x) eine Operation Abheben(y) ausge- führt, welche das Konto bis zum maximalen Kredit leert, dann ist die Kompensationsoperation Abheben(x) zur Kompensation von Einzahlen(x) nicht erfolgreich, da der Kreditrahmen über- zogen würde. Besitzt das Konto zwar einen unbegrenzten Kreditrahmen, jedoch eine zusätzli- che (und durchaus übliche) Operation zum Lesen des Kontostandes, dann ist auch hier die voll- ständige Kompensation nicht immer möglich, da Operationen abhängig gemacht werden können von der Höhe des Kontostandes. Beispiel: Anwendung 1 führt Einzahlen(x) aus. Da der Kontostand eine gewisse Summe übersteigt, führt Anwendung 2 danach Abheben(y) aus. Setzt danach Anwendung 1 ihre Ausführung zurück, kann man zwei Fälle unterscheiden. Hätte An- wendung 2 auch ohne das Einzahlen(x) das Abheben(y) ausgeführt, so wird mit Abheben(x) das Einzahlen(x) vollständig kompensiert. Im anderen Falle müßten jedoch für eine vollständige Kompensation auch die Operationen der zweiten Anwendung zurückgesetzt werden. 5.2 Kompensation 175Vollständige Kompensation ist also eher selten möglich, jedoch reicht es bei vielen Anwendun- gen aus, daß durch die Kompensation entweder ein semantisch äquivalenter Zustand oder ein im Rahmen der Anwendung akzeptabler Zustand hergestellt wird. Verwendet beispielsweise ein Agent (die Aussagen gelten auch entsprechend für beliebige Programme) digitales Geld (vgl. z.B. CHAUM (1985)), welches er in seinem Datenzustand mit sich führt, um Waren einzukaufen, dann bekommt er bei der Kompensation des Einkaufs denselben Geldbetrag vom Händler zu- rück. Da der Händler die vom Agent erhaltenen elektronischen Münzen jedoch im allgemeinen nicht mehr besitzt – bei heute gängigen Systemen werden die Münzen beispielsweise sofort bei der Bank eingelöst – bekommt der Agent andere Münzen zurück, die sich zumindest in der Se- riennummer unterscheiden. Hierdurch wird zwar ein semantisch äquivalenter Zustand im Agen- ten hergestellt – der Agent enthält dieselbe Geldsumme wie vor dem Einkauf. Die Repräsenta- tion des Zustandes jedoch unterscheidet sich vom Original. Es ist jedoch auch denkbar, daß der Händler für die Kompensation des Einkaufs eine Aufwandsentschädigung erhebt. In diesem Falle bekommt der Agent weniger Geld zurück, als er beim Einkauf ausgegeben hat, womit der resultierende Zustand nicht mehr semantisch äquivalent ist – der Agent hat weniger Geld als im Ausgangszustand. Ob dies für den Agent bzw. den Anwender akzeptabel ist, muß dieser schon vor dem Einkauf entscheiden – und gegebenenfalls bei einem Händler kaufen, der im Falle einer Kompensation keine Gebühren erhebt. Noch ungünstiger ist der Fall, wenn der Händler bei ei- ner Kompensation anstatt von Geld nur eine Gutschrift zurückgibt. In diesem Falle enthält der Agent nach der Kompensation vom Typ her andere Information als vor dem Einkauf. Unabhän- gig davon, ob der Agent nun anderes Geld, weniger Geld oder gar nur eine Gutschrift erhält, muß der Agent nach der Kompensation mit dieser geänderten Situation zurechtkommen, d.h. die verschiedenen möglichen Resultate einer Kompensation müssen dem Entwickler des Agen- ten bekannt sein und von ihm bei der Implementation des Agenten berücksichtigt werden. Wie schon weiter oben erwähnt gibt es Fälle, in denen Kompensation nur bedingt möglich ist. Beispielsweise ist die Kompensation einer Einzahlung auf ein Bankkonto nur dann möglich, wenn zwischen der Einzahlung und der Kompensation nicht soviel Geld vom Konto entnommen wird, daß die Kompensation den Kreditrahmen überzieht. Die Lösung dieses Problems liegt au- ßerhalb des Rahmens dieser Arbeit. Lösungsansätze werden in GARCIA-MOLINA UND SALEM (1987) und REUTER, SCHNEIDER UND SCHWENKREIS (1997) diskutiert. Schließlich gibt es noch Fälle, in denen gar keine Kompensation möglich ist. Klassische Bei- spiele sind hier Interaktionen mit der realen Welt wie das Bohren eines Loches durch einen pro- grammgesteuerten Bohrautomat oder die Ausgabe von Bargeld am Bankautomat. Aber auch in- nerhalb des Rechners gibt es Operationen, bei denen eine Kompensation nicht möglich ist. Ist beispielsweise ein Händler nicht bereit oder durch Konkurs nicht in der Lage, einen Einkauf rückgängig zu machen, kann die Kaufoperation nicht im Sinne des Käufers kompensiert wer- den. Hier muß also im Falle einer “Kompensation” der Verlust der ausgegebenen Summe in Kauf genommen werden. Ein weiteres Beispiel ist das Löschen einer sehr großen Datenmenge. Um diese Operation zu kompensieren, müßten die gelöschten Daten bekannt sein – beispiels- 176 Kapitel 5 Partielles Rücksetzenweise durch Logging der gelöschten Daten. Aus Effizienzgründen ist es jedoch nicht sinnvoll, solch große Datenmengen in ein Log zu schreiben. Ist es notwendig, solch nicht kompensierbare Operationen zurückzusetzen, ist im allgemeinen ein manueller Eingriff zur Durchführung des Rücksetzens notwendig. Da der Schwerpunkt dieses Kapitels auf den Aspekten des verteilten Rücksetzens mobiler Agenten und möglicher Optimierungen liegt, wird für den Rest des Kapitels davon ausgegan- gen, daß die in den einzelnen (Agenten-)Schritten ausgeführten Operationen immer kompen- siert werden können in dem Sinne, daß durch die Kompensation ein aus Sicht der Anwen- dung(en) akzeptabler Systemzustand entsteht. 5.3 Erweiterung des Agentenmodells Mit den in den letzten Abschnitten gewonnenen Erkenntnissen ist es nun möglich, das in Ab- schnitt 2.2 vorgestellte Agentenmodell um das partielle Rücksetzen von Agenten zu erweitern. Beim Rücksetzen eines einzelnen Schrittes ändert sich sowohl der Datenzustand des Agenten als auch der Zustand jener Ressourcen, auf die der Agent während des rückzusetzenden Schrit- tes zugegriffen hatte. Wie die vorhergehenden Abschnitte zeigten, werden beim Rücksetzen des Agenten im allgemeinen weder der originale Zustand des Agenten noch die originalen Zustände der Ressourcen wieder hergestellt. Deshalb sind die folgenden Definitionen notwendig: Definition 5-2: Agentenzustand Ai Der Agentenzustand Ai beschreibt den Datenzustand des Agenten A nach dem Rücksetzen des i-ten Schrittes. Definition 5-3: Ressourcenzustände Die Ressourcenzustände beschreiben die Zustände der Ressourcen des Kno- tens Ki vor ( ) beziehungsweise nach ( ) dem Rücksetzen des i-ten Schrittes des Agenten. Da zwischen der Ausführung des i-ten Schrittes und seinem Rücksetzen andere Agenten bzw. Anwendungen auf die Ressourcen zugreifen können ist im allgemeinen ungleich (Zu- stand der Ressourcen nach der Ausführung des Schrittes). Definition 5-4: Rücksetzinformationen Ii Die Rücksetzinformationen Ii beschreiben die zusätzlich zu Agenten- und Ressour- cenzustand notwendigen Daten zum Rücksetzen des Schrittes i. Ri 3 Ri 4 , Ri 3 Ri 4 , Ri 3 Ri 4 Ri 3 Ri 2 5.3 Erweiterung des Agentenmodells 177Zur Gewinnung der Rücksetzinformationen Ii muß die in Abschnitt 2.2 eingeführte Schrittfunk- tion si erweitert werden: (5-1) Die Rücksetzfunktion ri beschreibt die Änderung des Agenten- und Ressourcenzustandes durch das Rücksetzens eines einzelnen, bereits abgeschlossenen Schrittes i: (5-2) Wurde zuvor auch Schritt i+1 schon zurückgesetzt, gilt (5-3) Die Ausführung der Rücksetzfunktion ri ist nur dann möglich, wenn sich der Agent momentan im Zustand Ai+1 (bzw. Ai+1) befindet. Das Rücksetzen der n Schritte i, i-1,..., i-n+1 (n≤i) wird durch (5-4) beziehungsweise (5-5) beschrieben. Die Funktion ri,n ist hierbei eine Verkettung der Rücksetzfunktionen der einzelnen Schritte, d.h. auf Ai+1, und Ii wird ri angewendet, auf das resultierende Ai und die und Ii-1 wird dann ri-1 angewendet und so weiter. Wird das Modell in der bis hierher beschriebenen Version in die Praxis umgesetzt, bedeutet dies für den Entwickler eines Agenten, daß er für jeden Schritt des Agenten Code bereitstellen muß (nämlich die Rücksetzfunktion), der sämtliche Auswirkungen des Schrittes auf Ressourcen und auf den Agent selbst kompensiert. Außerdem müssen während der Ausführung eines Schrittes die Rücksetzinformationen für den Code zur Kompensation manuell gesammelt werden, d.h. das Sammeln der notwendigen Rücksetzinformationen muß in den Code des Schrittes integriert werden. Dies ist sowohl sehr unkomfortabel als auch fehleranfällig. si: Ai Ri 1( , ) | Ai 1+ Ri 2 Ii,( , )→ ri: Ai 1+ Ri 3 Ii,( , ) | Ai Ri 4( , )→ ri: Ai 1+ Ri 3 Ii,( , ) | Ai Ri 4( , )→ ri n, : Ai 1+ Ri 3 Ri 1– 3 Ri 2– 3 … Ri n– 1+ 3 Ii Ii 1– … Ii n– 1+,,,,,,,,( , ) | Ai n– 1+ Ri 4 Ri 1– 4 Ri 2– 4 … Ri n– 1+ 4 ,,,,( , ) → ri n, : Ai 1+ Ri 3 Ri 1– 3 Ri 2– 3 … Ri n– 1+ 3 Ii Ii 1– … Ii n– 1+,,,,,,,,( , ) | Ai n– 1+ Ri 4 Ri 1– 4 Ri 2– 4 … Ri n– 1+ 4 ,,,,( , ) → ri n, ri n– 1+ ri n– 2+ … rio o o= Ri 3 Ri 1– 3 178 Kapitel 5 Partielles RücksetzenEine Verfeinerung des Agentenmodelles ermöglicht in gewissem Umfang die Unterstützung des Agentenentwicklers durch die Agentenplattform. Die Verfeinerung ergibt sich aus der Beobach- tung, daß man die im Datenzustand des Agenten enthaltenen Daten in zwei Kategorien klassi- fizieren kann: Definition 5-5: Stark reversible Objekte (engl.: strongly reversible objects), AS,i Stark reversible Objekte sind Datenobjekte im (privaten) Datenzustand des Agen- ten, die nach dem Rücksetzen eines Schrittes immer dieselben Daten enthalten wie vor der Ausführung des rückzusetzenden Schrittes und daher mittels einer Kopie der Objekte wiederhergestellt werden können. Der Zustand der stark reversiblen Objek- te eines Agenten A vor der Ausführung des Schrittes i wird mit AS,i bezeichnet. Definition 5-6: Schwach reversible Objekte (engl.: weakly reversible objects), AW,i Schwach reversible Objekte sind Datenobjekte im (privaten) Datenzustand des Agenten, die nach dem Rücksetzen eines Schrittes Daten enthalten können, welche sich von den originalen Daten vor der Ausführung des rückzusetzenden Schrittes unterscheiden. Der Zustand der schwach reversiblen Objekte eines Agenten A vor der Ausführung des Schrittes i wird mit AW,i bezeichnet. Der Zustand der schwach reversiblen Objekte eines Agenten A nach dem Rücksetzen des Schrittes i wird mit AW,i bezeichnet. Sammelt beispielsweise ein Agent Daten und speichert diese in einem Vektor in seinem Daten- zustand ab, so kann diese Operation einfach dadurch rückgängig gemacht werden, indem der originale Zustand des Vektors wiederhergestellt wird. Datenobjekte, für die dies bei jedem Schritt zutrifft, sind stark reversible Objekte. Deklariert der Agentenentwickler diese Objekte als stark reversible Objekte, so kann das Rücksetzen dieser Objekte automatisch von der Lauf- zeitumgebung des Agenten durchgeführt werden, ohne daß der Agentenentwickler hierfür Kompensationsoperationen bereit stellen muß. Die hierzu notwendige Rücksetzinformation wird von der Laufzeitumgebung in Form von Kopien – auch bezeichnet als Before Image, vgl. HÄRDER UND RAHM (1999) – der stark reversiblen Objekte im Rücksetz-Log (vgl. Abschnitt 5.4.2) gespeichert. Ein Beispiel für schwach reversible Objekte wurde bereits in Abschnitt 5.2 beschrieben. Bezahlt ein Agent eingekaufte Ware beim Händler mittels elektronischem Geld welches auf dem in CHAUM (1985) beschriebenen Algorithmus basiert, so löst der Händler dieses Geld i.a. noch während des Bezahlvorganges bei der Bank ein. Soll diese Bezahlung später rückgängig ge- macht werden, so erhält der Agent deshalb vom Händler nicht dieselben digitalen Münzen zu- rück, die zur Bezahlung verwendet wurden. Erhebt der Händler eine Gebühr für das Rücksetzen der Kauftransaktion, erhält der Agent weniger Geld zurück. Im Extremfall bekommt der Agent sogar nur eine Gutschrift anstatt des Geldes. In allen diesen Fällen enthalten jene Datenobjekte 5.3 Erweiterung des Agentenmodells 179im Agent, die die elektronische Geldbörse verwalten, nach dem Rücksetzen der Transaktion nicht die ursprünglichen Daten. Sie sind somit schwach reversible Objekte. Es liegt in der Ver- antwortung des Entwicklers eines Agenten, daß er die zum Rücksetzen dieser Objekte notwen- digen Kompensationsoperationen inklusive Rücksetzinformationen zur Verfügung stellt, wel- che ebenfalls im Rücksetz-Log gespeichert werden. Details hierzu findet man in den folgenden Abschnitten. Um den Agent auf jeden beliebigen Zustand Ai rücksetzen zu können, ist es notwendig, daß die Laufzeitumgebung bei jeder Migration die zur Wiederherstellung der stark reversiblen Objekte notwendige Information im Rücksetz-Log abspeichert. Abhängig davon, wie die Rücksetzinfor- mation im Log gespeichert wird und wieviel stark reversible Objekte im Agent enthalten sind, können hierbei sehr viele Daten anfallen. Je nach Anwendung ist es jedoch eventuell gar nicht notwendig, auf jeden Zustand Ai zurücksetzen zu können. Bilden beispielsweise mehrere nach- einander ausgeführte Schritte eine logische Einheit, so ist möglicherweise nur das vollständige Rücksetzen aller dieser Schritte sinnvoll; Zustände zwischen diesen Schritten müssen nicht wie- derhergestellt werden können. Aus diesem Grunde wird zusätzlich noch das Konzept des Agen- ten-Rücksetzpunktes eingeführt: Definition 5-7: Agenten-Rücksetzpunkt (engl.: agent savepoint) Ein Agenten-Rücksetzpunkt ist ein Zustand in der Ausführung eines Agenten, auf den der Agent zurückgesetzt werden kann. Agenten-Rücksetzpunkte können sich nur zwischen den Schritten der Agentenausführung befinden (vgl. Abschnitt 5.1). Soll es möglich sein, einen Agent auf den Zustand Ai (d.h. auf den Zustand vor der Ausführung des Schrittes i) zurückzusetzen, muß vom Code des Agenten am Schluß des Schrittes i-1 ein Rücksetzpunkt etabliert werden. Der Rücksetzpunkt befindet sich in diesem Falle dann zwi- schen Schritt i-1 und Schritt i. Nur wenn ein solcher Agenten-Rücksetzpunkt veranlaßt wird, muß die zum Rücksetzen der stark reversiblen Objekte notwendige Information ins Rücksetz- Log geschrieben werden. Umgekehrt heißt dies, daß beim Rücksetzen eines Agenten der Zu- stand von dessen stark reversiblen Objekten jeweils nur beim Erreichen eines Rücksetzpunktes wieder hergestellt wird. Die erweiterte Rücksetzfunktion berücksichtigt dies, indem sich die stark reversiblen Objek- te nur dann ändern, wenn ein Rücksetzpunkt erreicht wird. Wird kein Rücksetzpunkt erreicht, ändern sich die stark reversiblen Objekte des Agenten nicht: (5-6) rˆi rˆi: AW i, 1+ AS i k+, Ri 3 , Ii,( , ) | AW i, AS i, Ri 4 ,( , ) falls Ai Rücksetzpunkt AW i, AS i k+, Ri 4 ,( , ) sonst   → für k 1≥ 180 Kapitel 5 Partielles Rücksetzenbeziehungsweise (5-7) wobei Ai+k der “letzte” Rücksetzpunkt (bzw. der Ausgangspunkt des Rücksetzens) ist. Die Rücksetzfunktion setzt sich hierbei aus der (den) vom Agentenentwickler bereitgestellten Kom- pensationsoperation(en) zum Rücksetzen der schwach reversiblen Objekte und – falls ein Rück- setzpunkt erreicht wird – dem Rücksetzen der stark reversiblen Objekte (durch die Laufzeitum- gebung) zusammen. Die Funktion kann nur dann isoliert ausgeführt werden, wenn Ai ein Rücksetzpunkt ist und der Schritt i der einzige bereits abgeschlossene Schritt ist, der zurückgesetzt werden muß. In diesem Falle gilt für den Eingabeparameter AS,i+k, daß k=1 ist (d.h. der Zustand der stark rever- siblen Objekte nach der Ausführung von Schritt i). In allen anderen Fällen wird nur als Teil des Rücksetzens mehrerer Schritte ausgeführt: (5-8) beziehungsweise (5-9) Hierbei beschreibt das partielle Rücksetzen der vollständig ausgeführten Schritte i, i-1,..., i-n+1 auf den Rücksetzpunkt zwischen den Schritten i-n und i-n+1. Auch hier ist diese Rück- setzfunktion eine Verkettung der Rücksetzfunktionen der einzelnen Schritte. Abbildung 5-2 il- lustriert dies anhand der Ausführung der Schritte i, i+1,..., i+4 eines Agenten mittels der Schritt- funktion si,5 (Erweiterung der Schrittfunktion si aus Abschnitt 2.2 um die Ausführung mehrerer Schritte) und dem Rücksetzen dieser Schritte mittels der Rücksetzfunktion (die bei der Ausführung des Agenten erzeugten und beim Rücksetzen verwendeten Rücksetzinformationen rˆi: AW i, 1+ AS i k+, Ri 3 , Ii,( , ) | AW i, AS i, Ri 4 ,( , ) falls Ai Rücksetzpunkt AW i, AS i k+, Ri 4 ,( , ) sonst   → für k 1≥ rˆi rˆi rˆi n, : AW i, 1+ AS i 1+, R, i 3 Ri 1– 3 Ri 2– 3 … Ri n– 1+ 3 Ii Ii 1– … Ii n– 1+,,,,,,,,( , ) | AW i, n– 1+ AS i n– 1+, Ri 4 , Ri 1– 4 Ri 2– 4 … Ri n– 1+ 4 ,,,,( , ) → rˆi n, : AW i, 1+ AS i 1+, R, i 3 Ri 1– 3 Ri 2– 3 … Ri n– 1+ 3 Ii Ii 1– … Ii n– 1+,,,,,,,,( , ) | AW i, n– 1+ AS i n– 1+, Ri 4 , Ri 1– 4 Ri 2– 4 … Ri n– 1+ 4 ,,,,( , ) → rˆi n, rˆi 4+ 5, 5.3 Erweiterung des Agentenmodells 181wurden zur Wahrung der Übersichtlichkeit weggelassen). Bei der Ausführung des Agenten wur- de vor den Schritten i und i+2 jeweils ein Rücksetzpunkt gesetzt. In der Abbildung ist zu erken- nen, daß, wie oben beschrieben, der Zustand der stark reversiblen Objekte nur beim Erreichen der Rücksetzpunkte durch die Rücksetzfunktionen der Schritte i+2 und i ( und )aktuali- siert wird, die Rücksetzfunktionen der anderen Schritte ändern an den stark reversiblen Objek- ten nichts. Dies hat zur Folge, daß sich die stark reversiblen Objekte des Agenten während der Ausführung der Rücksetzfunktion von Schritt i+3 noch im selben Zustand befinden wie nach der Ausführung des Schrittes i+4. Die stark reversiblen Objekte enthalten also während der Aus- führung von Rücksetzfunktionen, d.h. während der Ausführung der vom Agentenentwickler zur Verfügung gestellten Kompensationsoperation(en), potentiell “zukünftige” Daten. Aus diesem Grund können die stark reversiblen Objekte von den vom Agentenentwickler zur Verfügung ge- stellten Kompensationsoperationen nicht verwendet werden. Da durch das Rücksetzen die stark Abbildung 5-2. Ausführen und Rücksetzen eines Agenten AW,i+3 AS,i+5 AW,i+5 AS,i+5 si R Ai 1 i R 2 i si+1 R Ai+1 1 i+1 R 2 i+1 si+2 R Ai+2 1 i+2 R 2 i+2 si+3 R Ai+3 1 i+3 R 2 i+3 si+4 R Ai+4 1 i+4 R 2 i+4 Ai+5 Rücksetzpunkt j Rücksetzpunkt j+1 ri R Ai 4 i R 3 i ri+1 R Ai+1 4 i+1 R 3 i+1 ri+2 R Ai+2 4 i+2 R 3 i+2 ri+3 R Ai+3 4 i+3 R 3 i+3 ri+4 R Ai+4 4 i+4 R 3 i+4 AW,i+4 AS,i+5 Ai+5 Ausführung des Agenten mittels si,5: Rücksetzen mittels ri+4,5: AW,i AS,i AW,i+2 AS,i+2 AW,i+1 AS,i+2 AW,i AS,i AW,i+1 AS,i+1 AW,i+2 AS,i+2 AW,i+3 AS,i+3 AW,i+4 AS,i+4 AW,i+5 AS,i+5 Ai: Agentenzustand vor Ausführung von Schritt i Ai: Agentenzustand nach Rücksetzen von Schritt i AW,i: schwach reversible Objekte des Agenten vor Ausführung von Schritt i AW,i: schwach reversible Objekte des Agenten nach Rücksetzen von Schritt i AS,i: stark reversible Objekte des Agenten vor Ausführung / nach Rücksetzen von Schritt i si: Schrittfunktion für Schritt i : Zustand der Ressourcen von Knoten i vor Ausführung des Schrittes i : Zustand der Ressourcen von Knoten i nach Ausführung des Schrittes i : Zustand der Ressourcen von Knoten i vor Rücksetzen des Schrittes i : Zustand der Ressourcen von Knoten i nach Rücksetzen des Schrittes i : Rücksetzfunktion für Schritt i R i 1 R i 2 R i 3 R i 4 rˆi Rücksetzpunkt j rˆi 2+ rˆi 182 Kapitel 5 Partielles Rücksetzenreversiblen Objekte im Originalzustand wieder hergestellt werden, bleibt der Rücksetzpunkt (im Beispiel Rücksetzpunkt j), auf welchen die Ausführung des Agenten zurückgesetzt wurde, erhalten. Vorausgesetzt der Entwickler eines Agenten stellt korrekte Operationen zur Kompensation der schwach reversiblen Objekte zur Verfügung, stellt die Funktion einen Zustand Ai-n+1 her, welcher ein im Sinne der Anwendung zum Zustand Ai-n+1 semantisch äquivalenter Zustand ist. Im Idealfall wurden während der Ausführung der Schritte i-n+1, i-n,..., i nur stark reversible Ob- jekte geändert. In diesem Fall wäre Ai-n+1=Ai-n+1. Ein bisher nicht betrachtetes Problem tritt al- lerdings dann auf, wenn der Agent nach dem (partiellen) Rücksetzen seine Arbeit basierend auf dem wiederhergestellten, zum Ausgangszustand äquivalenten Zustand, fortsetzt. Da die Reise- route des Agenten beim Rücksetzen wieder in ihren ursprünglichen Zustand zurückgesetzt wird, kann es passieren, daß der Agent nach dem Rücksetzen dieselben Schritte ausführt wie zuvor. Dies ist kein Problem wenn die Ausführung des Agenten beispielsweise wegen der temporären Nichtverfügbarkeit einer Ressource zurückgesetzt wurde. Hat jedoch der Agent das Rücksetzen beispielsweise veranlaßt, weil die von ihm momentan durchgeführte Strategie nicht zum Ziel führt, dann müssen dem Agent nach dem Rücksetzen Informationen zur Verfügung gestellt wer- den, die es ihm erlauben, seine Strategie zu ändern – beispielsweise durch Änderungen in sei- nem Datenzustand oder durch Änderungen in der Reiseroute. Aus diesem Grunde wird zusätz- lich nach dem Erreichen des Rücksetzpunktes eine Wiederaufnahme-Funktion rpost ausgeführt, in der die notwendigen Änderungen durchgeführt werden können. Da die gewünschte Funktionalität von rpost im allgemeinen von der Situation, in der das Rück- setzen initiiert wird, abhängt, kann rpost inklusive ihrer Parameter vom Agent bei der Initiierung des Rücksetzens angegeben werden (vgl. auch nächster Abschnitt). Abbildung 5-3 zeigt, wie nach dem Rücksetzvorgang aus Abbildung 5-2 die normale Abarbeitung des Agenten wieder aufgenommen wird, indem zuerst die Funktion rpost ausgeführt wird und erst dann der nächste Schritt des Agenten ausgeführt wird. Die Funktion rpost kann dabei als eine Art Schritt interpre- tiert werden, der nach Schritt i-1 in die Reiseroute eingefügt wird, wobei dieser Schritt wieder aus der Reiseroute entnommen werden muß, falls später auf einen noch früheren Rücksetzpunkt zurückgesetzt werden soll. Die Ausführung von rpost kann dabei auf einem beliebigen Knoten erfolgen. Da rpost konzeptionell nur dafür zuständig ist, den Zustand des Agenten, speziell auch dessen Reiseroute, so zu ändern, daß der Grund des Rücksetzens bei der weiteren Verarbeitung des Agenten berücksichtigt werden kann, sollte durch rpost kein Ressourcenzustand geändert werden. Da rpost jedoch sowohl stark reversible als auch schwach reversible Objekte ändern kann, müssen für den Fall, daß später auf einen noch früheren Rücksetzpunkt zurückgesetzt werden soll, sowieso Kompensationsoperationen für die Änderungen der schwach reversiblen Objekte in rpost angegeben werden. Somit stehen aus technischer Sicht Änderungen von Res- sourcen durch rpost nichts im Wege, solange auch hierfür die entsprechenden Kompensations- operationen zur Verfügung gestellt werden. Wie schon weiter oben erwähnt, bleibt der Rück- setzpunkt, auf den ein Agent zurückgesetzt wurde, erhalten – in Abbildung 5-3 beispielsweise rˆi n, 5.3 Erweiterung des Agentenmodells 183der Rücksetzpunkt j. Da die weitere Ausführung des Agenten jedoch auf dem durch rpost herge- stellten Zustand basiert, ist es sehr wahrscheinlich, daß im Falle eines Rücksetzens nicht auf den originalen Rücksetzpunkt j zurückgesetzt werden soll sondern auf den durch rpost hergestellten Zustand. Um dies zu ermöglichen, wird nach der Ausführung von rpost automatisch ein weiterer Rücksetzpunkt eingefügt (Rücksetzpunkt j’ in Abbildung 5-3). Im folgenden Abschnitt wird ein auf dem hier vorgestellten, erweiterten Agentenmodell basie- render Mechanismus präsentiert, welcher auch für das Rücksetzen von Agenten eine genau-ein- mal Semantik garantiert. Weitere Verfeinerungen und Erweiterungen des Modells werden an- schließend verwendet, um den vorgestellten Mechanismus zu optimieren. Abbildung 5-3. Fortsetzen der Ausführung eines Agenten nach Rücksetzen Ai: Agentenzustand vor Ausführung von Schritt i Ai: Agentenzustand nach Rücksetzen von Schritt i AW,i: schwach reversible Objekte des Agenten vor Ausführung von Schritt i AW,i: schwach reversible Objekte des Agenten nach Rücksetzen von Schritt i AS,i: stark reversible Objekte des Agenten vor Ausführung / nach Rücksetzen von Schritt i si: Schrittfunktion für Schritt i : Zustand der Ressourcen von Knoten i vor Ausführung des Schrittes i : Zustand der Ressourcen von Knoten i nach Ausführung des Schrittes i : Zustand der Ressourcen von Knoten i vor Rücksetzen des Schrittes i : Zustand der Ressourcen von Knoten i nach Rücksetzen des Schrittes i : Rücksetzfunktion für Schritt i R i 1 R i 2 R i 3 R i 4 rˆi ri R Ai 4 i R 3 i ri+1 R Ai+1 4 i+1 R 3 i+1 rpost AW,i+1 AS,i+2 AW,i AS,i s’i A’i Rücksetzpunkt j’ A’W,i A’S,i Rücksetzpunkt j 184 Kapitel 5 Partielles Rücksetzen5.4 Basismechanismus Der in diesem Abschnitt vorgestellte Mechanismus realisiert das partielle Rücksetzen der Aus- führung von Agenten, welche mittels des in Abschnitt 4.3 vorgestellten Basisprotokolls zur ge- nau-einmal Ausführung mobiler Agenten ausgeführt werden. Ziel des Mechanismus ist hierbei, sowohl die im vorherigen Abschnitt beschriebene Semantik des partiellen Rücksetzens zu bie- ten als auch – analog zur genau-einmal Ausführung des Agenten – das Rücksetzen des Agenten ebenfalls genau einmal auszuführen. 5.4.1 Überblick Die in Abschnitt 4.3 vorgestellte Idee zur Realisierung der genau-einmal Ausführung eines Agenten läßt sich auf das partielle Rücksetzen von Agenten übertragen. Bei der Ausführung ei- nes Schrittes eines Agenten werden innerhalb einer Transaktion der Agent aus der Eingangs- warteschlange des ausführenden Knotens entnommen, die Schrittfunktion auf dem Agenten (und den Ressourcen) ausgeführt und dann der Agent in die Eingangswarteschlange des Kno- tens, auf dem der nächste Schritt ausgeführt werden soll, geschrieben. Wie in Abschnitt 4.3 aus- geführt wird dadurch garantiert, daß der Agent nicht verloren gehen kann und daß alle Aktionen des Agenten (logisch gesehen) exakt einmal ausgeführt werden. Das Rücksetzen eines Schrittes S des Agenten unterscheidet sich nicht wesentlich von der Ausführung dieses Schrittes S. Da beim Rücksetzen auch der Zustand der Ressourcen des Knotens N, auf dem der Schritt S ausge- führt wurde, zurückgesetzt werden muß, muß auch die Rücksetzfunktion des Agenten auf die- sem Knoten N ausgeführt werden. Es bietet sich daher an, beim Rücksetzen eines Schrittes des Agenten ebenso zu verfahren wie bei der Ausführung des Schrittes: Innerhalb einer Rücksetz- transaktion wird der Agent aus der Eingangswarteschlange des Knotens, auf dem die Rücksetz- funktion ausgeführt werden muß, entnommen, die Rücksetzfunktion wird ausgeführt und dann wird der Agent in die Eingangswarteschlange des Knotens geschrieben, auf dem die nächste Rücksetzfunktion ausgeführt werden muß. Abbildung 5-4 zeigt die Ausführung der Schritte i, i+1, i+2 und i+3 eines Agenten A und das Rücksetzen dieser Schritte mittels des Basismechanismus’ zum Rücksetzen. Die Schritte i, i+1 und i+2 werden komplett ausgeführt. Während des Schrittes i+3 beschließt der Agent, seinen Zustand auf den Rücksetzpunkt j, welcher direkt vor Schritt i gesetzt wurde, zurückzusetzen. Der Basismechanismus bekommt hierzu als Parameter das Ziel des Rücksetzens (Rücksetz- punkt j) und die nach dem Rücksetzen auszuführende Funktion rpost übergeben (siehe weiter un- ten). Um die durch die Ausführung des Schrittes i+3 an Agent und Ressourcen verursachten Än- derungen zurückzusetzen, reicht es aus, die Schritt-Transaktion Ti+3 abzubrechen. Dies bewirkt, daß der Ausgangszustand der Ressourcen des Knotens Ki+3 wiederhergestellt wird und daß sich der Agent wieder im Zustand Ai+3 in der Eingangswarteschlange Qi+3 des Knotens Ki+3 befindet. Um den Schritt i+2 auf dem Knoten Ki+2 zurücksetzen zu können, muß sich der Agent Ri 3+ 1 5.4 Basismechanismus 185in dessen Eingangswarteschlange Qi+2 befinden. Daher wird in einer Transaktion RTinit der Agent von Qi+3 nach Qi+2 verschoben. Jetzt beginnt erst die eigentliche Kompensation der voll- ständig ausgeführten Schritte. Innerhalb einer Rücksetztransaktion RTk wird dann jeweils der Agent aus der Eingangswarteschlange Qk gelesen, der Schritt k mittels zurückgesetzt und der Agent in Qk-1 (Qi für k=i) geschrieben (in der Reihenfolge k=i+2, i+1, i). Erwähnenswert ist hierbei nochmal, daß beim Rücksetzen der Schritte i+2 und i+1 nur die schwach reversiblen Ob- jekte des Agenten und die Ressourcen kompensiert werden. Erst beim Rücksetzen des Schrittes i (und damit beim Erreichen eines Rücksetzpunktes) werden zusätzlich auch die stark reversi- blen Objekte des Agenten zurückgesetzt. Sobald der gewünschte Rücksetzpunkt nach Rückset- zen des Schrittes i erreicht wird, wird der Agent nicht in Qi-1 sondern in Qi geschrieben. Danach wird in einer weiteren Transaktion die Funktion rpost ausgeführt, mittels der der Agent durch das Rücksetzen notwendig gewordene Änderungen in seinem Zustand durchführen kann (z.B. die Reiseroute abändern). Dies geschieht ebenfalls, indem innerhalb einer Transaktion der Agent aus Qi gelesen wird, die Funktion rpost ausgeführt wird, und schließlich der Agent in die Eingangswarteschlange jenes Knoten geschrieben wird, auf dem der nächste Schritt auszu- Abbildung 5-4. Rücksetzen mittels des Basismechanismus’ read write execute rpost ’ Rücksetzpunkt j’ Ki Ri write read execute ri compensate RTi 4 Ai Qi Ri 3 AW,i AS,i Ai Ki+1 Ri+1 write read execute ri+1 compensate RTi+1 4 Ai+1 Qi Ri+1 3 AW,i+1 AS,i+3 Ai+1 Ki Ri read write execute si access Ti 1 Ai Qi Ri 2 Ki+1 Ri+1 read write execute si+1 access Ai AW,i AS,i Ti+1 abort Rücksetzpunkt j e x e c u t i o n r o l l b a c k 1 AW,i+3 AS,i+3 Ai+3 Rücksetzpunkt j RTinit RTfinish Ai+1 Qi+1 Ri+1 2 Ki+2 Ri+2 read write execute si+2 access Ti+2 1 Ai+2 Qi+2 Ri+2 2 Ki+3 Ri+3 read execute si+3/rollback access 1 Ai+3 Qi+3 Ri+3 2 Ti+3 Ri+3 1 Ai+3 Qi+3 Ki+2 Ri+2 write read execute ri+2 compensate RTi+2 4 Ai+2 Qi+1 Ri+2 3 Ai+3 Qi+2 AW,i+3 AS,i+3 Ai+3 AW,i+2 AS,i+3 Ai+2 Ki Ki read write execute si access Ti A Qi AW,i AS,i Ai ’ ’ ’ ’ ’ ’ ’ ’ rˆk Ki’ 186 Kapitel 5 Partielles Rücksetzenführen ist. Wurde in rpost die Reiseroute des Agenten geändert, so ist i.a. . Wie in Ab- schnitt 5.3 ausgeführt wird hierbei auch noch der Rücksetzpunkt j’ geschrieben. Damit ist das Rücksetzen des Agenten beendet und die reguläre Ausführung des Agenten analog Abschnitt 4.3 kann wieder aufgenommen werden. 5.4.2 Logging Die für das Rücksetzen der einzelnen Schritte eines Agenten notwendigen Daten werden im Agenten-Rücksetz-Log (engl.: agent rollback log) abgelegt. Hierzu gehört neben der zum Rück- setzen von Ressourcen- und Agentenzustand notwendigen Rücksetzinformation I auch die In- formation, welche Kompensationsoperationen für die Kompensation eines Schrittes ausgeführt werden müssen. Das Rücksetz-Log wird an den Agenten angehängt und migriert daher mit dem Agenten von Knoten zu Knoten. Da das Rücksetz-Log nur Daten enthält, welche zum Rückset- zen von erfolgreich abgeschlossenen (d.h. mit Commit beendeten) Schritten notwendig sind, reicht es aus, das Rücksetz-Log am Ende einer Transaktion (sowohl Schritt- als auch Rücksetz- Transaktion) persistent zu machen, d.h. mit dem Agenten in die Eingangswarteschlange des nächsten Knotens zu schreiben. Das Anhängen des Rücksetz-Logs an den Agenten hat zwei Vorteile. Erstens ist es nach dem Beenden der Ausführung eines Agenten nicht notwendig, globale Aktionen zum Löschen des Rücksetz-Logs auf den durch den Agenten besuchten Knoten durchzuführen. Zweitens ist das Rücksetz-Log immer genau dann verfügbar, wenn auch der Agent verfügbar ist. Dadurch kann der Agent immer dann zurückgesetzt werden, wenn die rückzusetzenden Ressourcen verfügbar sind. Dieser zweite Vorteil ist zwar im Kontext des Basismechanismus nicht relevant, gewinnt jedoch im Zuge der weiter hinten vorgestellten Optimierungen wesentlich an Bedeutung. Der Nachteil des Anhängens des Rücksetz-Logs an den Agenten ist offensichtlich, daß die Größe des Rücksetz-Logs und damit die Menge der zu migrierenden Daten im Verlauf der Ausführung des Agenten stetig zunimmt. Wie stark der Zuwachs der Größe des Rücksetz-Logs ausfällt, hängt hierbei vor allem von der Anwendung ab. Im hier vorgestellten Mechanismus wird eine Mischung aus physischem und logischem Logging (engl.: physical and logical logging, vgl. auch HÄRDER UND REUTER (1983) bzw. HÄRDER UND RAHM (1999)) verwendet. Für die stark reversiblen Objekte wird physisches Logging verwen- det. Hier kann entweder ein komplettes Abbild (engl.: image) dieser Objekte ins Rücksetz-Log geschrieben werden (Zustands-Logging, engl.: state logging) oder nur die Zustands-Differenzen dieser Objekte zwischen zwei aufeinanderfolgenden Rücksetzpunkten (Übergangs-Logging, engl.: transition logging). Diese Informationen werden als Bestandteil eines Rücksetzpunktein- trages (RP, engl.: savepoint entry) in das Log geschrieben. Ein solcher Rücksetzpunkteintrag wird genau dann in das Rücksetz-Log geschrieben, wenn vom Agent ein Rücksetzpunkt initiiert wird. Neben dem Abbild der stark reversiblen Objekte enthält ein Rücksetzpunkteintrag zusätz- lich noch einen (eindeutigen) Bezeichner. Zur Vereinfachung wird im folgenden davon ausge- Ki Ki≠ ’ 5.4 Basismechanismus 187gangen, daß Zustands-Logging verwendet wird. Das Format, in dem das Abbild der stark rever- siblen Objekte im Rücksetz-Log gespeichert wird, hängt von der zur Programmierung des Agenten verwendeten Programmiersprache ab. Für die Kompensation der schwach reversiblen Objekte und der Ressourcenzustände wird logi- sches Logging verwendet. Hierbei werden die Kompensationsoperationen und deren Parameter in das Rücksetz-Log geschrieben. Eine Kompensationsoperation mit den zugehörigen Parame- tern wird als Operationseintrag (OE, engl.: operation entry) bezeichnet. Die Anzahl der zur Kompensation eines Schrittes notwendigen Kompensationsoperationen (und damit die Anzahl der im Rücksetz-Log enthaltenen Operationseinträge für einen Schritt) kann zwischen einer (komplexen) Operation, welche die Auswirkungen des gesamten Schrittes kompensiert, und be- liebig vielen Operationen liegen. Die Agenten-Plattform muß Operationen zur Verfügung stel- len, mit denen Operationseinträge an das Rücksetz-Log angehängt werden können. Existieren für einen Schritt mehrere Operationseinträge, so werden beim Rücksetzen die Operationseinträ- ge (genauer: die in den Operationseinträgen spezifizierten Kompensationsoperationen) in um- gekehrter Reihenfolge, d.h. beginnend mit dem zuletzt angehängten Eintrag, abgearbeitet. Hin- tergrund ist, daß bei der Kompensation im allgemeinen “von hinten nach vorne” vorgegangen wird, d.h. die zuletzt ausgeführte Operation muß zuerst kompensiert werden, dann die vorletzte ausgeführte Operation und so weiter. Wird beispielsweise zuerst ein Betrag von einem Konto A auf ein Konto B überwiesen und Konto B anschließend zur Bezahlung beim Einkaufen verwen- det, dann muß zuerst der Einkauf kompensiert werden, bevor die Rücküberweisung erfolgen kann. Wird nun das Rücksetz-Log wie oben beschrieben abgearbeitet, dann kann dadurch direkt jeweils nach Ausführung der zu kompensierenden Operation die Kompensationsoperation ins Rücksetz-Log geschrieben werden. Das Format, in dem die Kompensationsoperationen und deren Parameter im Rücksetz-Log abgespei- chert werden, hängt von der zur Programmierung des Agenten verwendeten Programmiersprache ab. Wird eine objektorientierte Sprache wie Java ver- wendet, so kann beispielsweise der Vererbungsme- chanismus und die damit einhergehende Polymor- phie als Lösungsansatz dienen. Die Idee hierbei ist, die Kompensationsoperation in einem Objekt als Methode des Objekts und die Parameter der Kom- pensationsoperation als Attribute des Objektes zu realisieren. Hierbei dient eine abstrakte Oberklasse CompensationObject mit einer abstrakten (d.h. nicht implementierten) Methode compensate() als Grundbaustein. Für jede Kompensationsoperation muß dann eine Unterklasse von Compen- sationObject implementiert werden, in der die Kompensationsoperation von der compensate()- Methode realisiert wird und deren Attribute als Parameter der Kompensationsoperation dienen. Abbildung 5-5. CompensationObject abstract class CompensationObject{ abstract void compensate(); } class CompensateTransfer extends CompensationObject{ Bank theBank; Account account1, account2; Amount amount; void compensate(){ theBank.transfer(account2, account1,amount) } } 188 Kapitel 5 Partielles RücksetzenAbbildung 5-5 demonstriert die Idee anhand der Rücksetzoperation für eine Überweisung zwi- schen zwei Konten, welche in einem Objekt der Klasse CompensateTransfer gekapselt wird. Die für die Rücksetzoperation notwendigen Parameter Bank (theBank), Ursprungskonto der Überweisung (account1), Zielkonto der Überweisung (account2) und der überwiesene Betrag (amount) sind als Attribute der Klasse im Objekt enthalten. Die Methode compensate() imple- mentiert die Kompensationsoperation – in diesem Falle die Rücküberweisung. Bei dieser Rea- lisierung enthält ein Operationseintrag des Rücksetz-Logs einfach ein Objekt einer Unterklasse der Klasse CompensationObject – im Beispiel also ein Objekt der Klasse CompensateTransfer, welches die zur Kompensation notwendigen Daten und die Kompensationsoperation enthält. Zur Kompensation muß nur dieses Objekt aus dem Rücksetz-Log gelesen werden und die com- pensate()-Methode auf diesem Objekt aufgerufen werden. Zusätzlich zu diesen Eintragstypen enthält das Rücksetz-Log noch Einträge für den Beginn und das Ende der Abarbeitung eines Schrittes (begin-of-step (BS), end-of-step (ES)). Diese Einträge enthalten unter anderem den Bezeichner des Knotens, auf dem der Schritt ausgeführt wurde. Mögliche weitere Inhalte dieser Einträge werden weiter unten diskutiert. Für den Fall daß ein Schritt nicht rücksetzbar ist, da er, entgegen der in Abschnitt 5.2 getroffenen Annahme, nicht rücksetzbare Operationen durchführt, können alle bisherigen Einträge des Rücksetz-Log verworfen und nach der Ausführung des Schrittes ein Rücksetzpunkteintrag ins Log geschrieben werden. In diesem Falle kann die Ausführung des Agenten nicht mehr auf ei- nen früheren Zustand zurückgesetzt werden. Dieser Fall wird, da nicht mit den getroffenen An- nahmen konform, im weiteren Verlauf nicht mehr betrachtet. Abbildung 5-6 zeigt einen Auszug aus einem Rücksetz-Log. Er enthält die Einträge OEn,1, OEn,2, ..., OEn,p zur Kompensation des n-ten Schrittes des Agenten inklusive der Einträge für den Beginn und das Ende der Abarbeitung dieses Schrittes sowie den k-ten Rücksetzpunktein- trag, welcher sich direkt vor Schritt n befindet. Um den Agenten auf diesen k-ten Rücksetzpunkt zurückzusetzen, muß das Rücksetz-Log beginnend von seinem aktuellsten (d.h. zuletzt in das Log geschriebenen) Eintrag bis zum Rücksetzpunkteintrag abgearbeitet werden. Wird bei- spielsweise das Rücksetzen des Agenten in Schritt n+1 initiiert, dann ist ESn der aktuellste Ein- trag, da alle Änderungen des Schrittes n+1 inklusive der Änderungen am Rücksetz-Log durch Abbildung 5-6. Beispiel-Log ... RPk BSn OEn,1 OEn,2 ... OEn,p ESn BSn+1 ... Eq Eq+1 Eq+2 Eq+3 Eq+p+1 Eq+p+2 Eq+p+3 Ex - Log-Eintrag RPx - Rücksetzpunkteintrag BSx - begin-of-step-Eintrag OEx - Operationseintrag ESx - end-of-step-Eintrag abarbeiten anfügen 5.4 Basismechanismus 189den Abbruch der Schritt-Transaktion des Schrittes n+1 verworfen werden. In diesem Falle muß nur Schritt n kompensiert werden, was durch sukzessive Ausführung der Operationseinträge von Schritt n in der Reihenfolge OEn,p, OEn,p-1, ..., OEn,1 (genauer: Ausführung der in diesen Einträgen spezifizierten Kompensationsoperationen) geschieht. Die Details des Rücksetzme- chanismus zeigt der folgende Abschnitt. 5.4.3 Algorithmus Nachdem in Abschnitt 5.4.1 bereits die wesentlichen Grundzüge des Algorithmus und in Ab- schnitt 5.4.2 das Logging vorgestellt wurden, klärt dieser Abschnitt die noch verbleibenden De- tails und präsentiert in Pseudo-Code-Form den Basismechanismus zum Rücksetzen der Ausfüh- rung mobiler Agenten. Wie schon in Abschnitt 5.1 ausgeführt, wird der Rücksetzalgorithmus zuerst als Erweiterung des Basisprotokolles zur genau-einmal Ausführung mobiler Agenten (Algorithmus 4-1) konzi- piert, bevor er dann im folgenden Abschnitt in das blockierungsfreie Protokoll integriert wird. Da zum Rücksetzen des Agenten notwendige Informationen allerdings schon während der Aus- führung des Agenten erzeugt und im Rücksetz-Log gespeichert werden, müssen auch Änderun- gen am Basisprotokoll zur Agentenausführung vorgenommen werden. Algorithmus 5-1 zeigt (in Fettschrift) die notwendigen Modifikationen des Basisprotokolles. Neben der Erweiterung des Protokolles um Lesen bzw. Schreiben des Logs von der bzw. in die Eingangswarteschlange der Knoten sind dies vor allem das Schreiben der Einträge für den Beginn und das Ende der Aus- führung eines Schrittes sowie – falls notwendig – das Schreiben eines Rücksetzpunkteintrages. Für das Schreiben der Operationseinträge in das Log ist der Agent selbst zuständig. Zusätzlich ForEach (Agent a, Log log) in localNodeInputQueue q{ Begin Transaction // step transaction q.ReadAndDestroy(Agent a, Log log) log.insertBeginOfStepEntry(idOfLocalNodeInputQueue) safepointId = Execute(Agent a) log.insertEndOfStepEntry(idOfLocalNodeInputQueue) if (savepointID≠null){// agent initiated savepoint log.writeSavepointEntry(savepointID) } nextPossibleSteps = QueryItinerary() if (nextPossibleSteps≠∅){ // execution not yet finished nextStep = ChooseOneOf(nextPossibleSteps) Write(Agent a, Log log) to NodeInputQueue of node on which nextStep takes place if not successful then Abort Transaction } Commit Transaction } Algorithmus 5-1. Modifiziertes Basisprotokoll zur genau-einmal Ausführung mobiler Agenten 190 Kapitel 5 Partielles Rücksetzenzu den gezeigten Modifikationen muß noch beim Start des Agenten (also vor der Ausführung der ersten Schritt-Transaktion) ein Rücksetzpunkteintrag geschrieben werden, sodaß der Agent auch ganz auf den Anfang seiner Ausführung zurückgesetzt werden kann. Algorithmus 5-2 realisiert den Basisalgorithmus zum Rücksetzen der Agentenausführung. Be- schließt ein Agent, auf einen früheren Punkt zurückzusetzen, ruft er die in Algorithmus 5-2a dargestellte rollback(..)-Methode. Diese Methode bekommt als Parameter den Bezeichner spID des Rücksetzpunktes, auf den zurückgesetzt werden soll, und die Funktion r_post, welche nach dem Erreichen des Ziel-Rücksetzpunktes ausgeführt wird. Algorithmus 5-2. Basisalgorithmus zum Rücksetzen der Agentenausführung rollback(SpID spID, CompObject r_post){ Abort Transaction // step transaction Begin Transaction // move to correct queue localNodeInputQueue.get (Agent a, Log log) if (savepoint spID reached){ (1) target=localInputQueue }else{ (2) if (last log entry is savepoint){ (3) log.pop() // remove entry } target = determine from last end-of-step entry in log } Write(a, log, spId, r_post) To target (4) Commit Transaction } a. Start des Rücksetzalgorithmus ForEach (Agent a, Log log, SpID spID, ResumeObject r_post) in localNodeInputQueue q{ (5) Begin Transaction q.ReadAndDestroy(a, log, spID, r_post) if (savepoint spID not reached){ (6) rollbackOneStep(a, log, spID, r_post) }else{ (7) resumeExecution(a, log, r_post) } End Transaction } // Main Loop rollbackOneStep(Agent a, Log log, SpID spID, ResumeObject r_post){ log.pop() // remove end-of-step (8) entry=log.pop() while (entry≠begin-of-step){ entry.compensate() (9) entry=log.pop() } if (last entry in log is savepoint){ (10) restore strongly reversible objects if (savepoint spID not reached){ (11) log.pop() // sp not needed anymore } } if (savepoint spID reached){ (12) target=localNodeInputQueue }else{ (13) target = determine from last end-of-step entry in log } Write(a,log,spID,r_post) To target (14) } resumeExecution(Agent a, Log log, ResumeObject r_post){ log.insertBeginOfStepEntry() newSpID = r_post.resume() (15) log.insertEndOfStepEntry() log.writeSavepointEntry(newSpID) (16) nextPossibleSteps = QueryItinerary() if nextPossibleSteps≠∅ then{ (17) // execution not yet finished nextStep = ChooseOneOf( nextPossibleSteps) target = GetInputQueue( node on which nextStep takes place) Write(Agent a, Log log) To target } } b. Auf jedem Knoten ausgeführter Rücksetzalgorithmus 5.4 Basismechanismus 191Für die Repräsentation von r_post wurde hier eine Repräsentation analog zu der in Abschnitt 5.4.3 vorgeschlagenen Repräsentation für Operationseinträge angenommen: Es existiert eine abstrakte Klasse ResumeObject mit der (ebenfalls abstrakten) Methode resume(). Unterklassen dieser Klasse enthalten in der resume()-Methode dann die auszuführende Funktion r_post, die Parameter sind als Attribute in der Klasse enthalten. In der rollback()-Methode wird zuerst die aktuelle Schritt-Transaktion abgebrochen. Danach wird der Agent innerhalb einer neuen Transaktion in die Eingangswarteschlange des Knotens geschrieben, auf dem die nächste Aktion durchzuführen ist. Hierzu wird zuerst der ursprüngli- che Zustand (d.h. der Zustand vor Ausführung des gerade abgebrochenen Schrittes) inklusive Log aus der Eingangswarteschlange gelesen. Hat der Agent den gewünschten Rücksetzpunkt schon erreicht (1)1 – erkennbar dadurch daß der aktuellste Log-Eintrag ein Rücksetzpunkt mit dem Bezeichner spID ist – dann wird der Agent wieder in die lokale Eingangswarteschlange ge- schrieben (4). Hat der Agent den gewünschten Rücksetzpunkt noch nicht erreicht (2), dann wird aus dem ak- tuellsten end-of-step-Eintrag des Logs ermittelt, auf welchem Knoten die nächste Rücksetz- transaktion auszuführen ist. Hierbei wird zuerst ein eventuell am Ende des Logs stehender Rücksetzpunkteintrag entfernt (3), welcher in diesem Falle nicht abgearbeitet werden muß, da sich die stark reversiblen Objekte schon in dem Zustand befinden, der in diesem Eintrag enthal- ten ist. Der Agent wird dann in die Eingangswarteschlange des ermittelten Knotens geschrieben (4). In beiden Fällen (sowohl beim Schreiben in die lokale als auch in die entfernte Warteschlange) wird zusätzlich zu Agent und Log auch der Bezeichner spID des Rücksetzpunktes, auf den der Agent zurückgesetzt werden soll, und die Funktion r_post mit Parametern geschrieben. Ist die Transaktion, in der dies alles ausgeführt wird, erfolgreich, so steht der Agent zur weiteren Be- arbeitung des Rücksetzens in der Warteschlange des Knotens, auf dem die nächste Aktion er- folgen muß. Schlägt die Transaktion jedoch beispielsweise wegen Ausfall des Knotens fehl, so steht immer noch der Agent inklusive Log in der Eingangswarteschlange des lokalen Knotens. Dies ist äquivalent zu der Situation, daß die Schritt-Transaktion schon vor Aufruf von roll- back(..) abbricht und ist daher ein akzeptabler Zustand. In diesem Falle wird der (abgebrochene) Schritt auf dem Knoten erneut gestartet, kommt (eventuell) erneut zu der Erkenntnis daß zu- rückgesetzt werden muß und ruft erneut rollback(..) auf. Da der Abbruch der Transaktion nur durch Fehler des lokalen Knotens, des Netzwerkes und des Zielknotens geschehen kann und diese Fehler laut dem zugrundeliegenden Fehlermodell nur temporär sind, wird dieser Teil des Rücksetzens letztendlich erfolgreich sein. Der Hauptteil des Rücksetzens wird von Algorithmus 5-2b durchgeführt. Sobald ein Tupel (Agent, Log, SpId, ResumeObject) in der Eingangswarteschlange eines Knotens erscheint, wird dieses innerhalb einer Transaktion aus der Warteschlange entnommen und bearbeitet (5). Hier- 1. Die Zahlen in Klammern beziehen sich auf die Fall-Numerierungen in Algorithmus 5-2 192 Kapitel 5 Partielles Rücksetzenbei sind zwei Fälle zu unterscheiden. Wurde der Ziel-Rücksetzpunkt spID noch nicht erreicht – auch hier daran erkennbar ob der aktuellste Log-Eintrag ein Rücksetzpunkt mit dem Bezeichner spID ist – dann muß auf diesem Knoten ein Schritt rückgesetzt werden (6), ansonsten muß die Ausführung des Agenten wieder aufgenommen werden (7). Das Rücksetzen eines Schrittes wird von der Methode rollbackOneStep() erledigt, das Wiederaufnehmen der Ausführung ge- schieht in der Methode resumeExecution(). Beim Rücksetzen eines Schrittes in rollbackOneStep() werden nach dem Entfernen des end-of- step-Eintrages des rückzusetzenden Schrittes (8) sukzessive die Operationseinträge aus dem Log entnommen und die darin enthaltenen Kompensationsoperationen ausgeführt (9), bis der begin-of-step-Eintrag des Schrittes dem Log entnommen wurde. Ist nun der aktuellste Eintrag des Logs ein Rücksetzpunkt (10), dann wird anhand dieses Eintrages der Zustand der stark re- versiblen Objekte wieder hergestellt und der Rücksetzpunkteintrag wird entfernt, falls er nicht der Ziel-Rücksetzpunkt des Rücksetzens, d.h. der Rücksetzpunkt mit Bezeichner spID, ist (11). Ist der gewünschte Rücksetzpunkt erreicht (12), wird der Agent in die lokale Eingangswarte- schlange geschrieben. Wenn nicht (13), wird aus dem aktuellsten Log-Eintrag, welcher in die- sem Falle ein end-of-step-Eintrag ist, der Knoten ermittelt, auf dem die nächste Rücksetztrans- aktion stattfinden muß, und der Agent in die dortige Eingangswarteschlange geschrieben. In beiden Fällen wird wieder das Tupel (Agent, Log, SpID, ResumeObject) in die Warteschlange geschrieben (14). Ist die Transaktion erfolgreich, dann wurde durch rollbackOneStep() die rückzusetzenden Kom- pensationsoperationen genau einmal durchgeführt und die Änderungen an Ressourcen (durch Kompensationsoperationen) und Agent (schwach reversible Objekte: durch Kompensations- operationen; stark reversible Objekte: durch Info aus Rücksetzpunkt, falls vorhanden) sind per- manent. Der Agent befindet sich dann in der Eingangsschlange des Knotens, auf dem die näch- ste Aktion, d.h. entweder eine weitere Kompensation oder die Wiederaufnahme der Ausführung, stattfinden soll. Bricht die Transaktion wegen eines System-Fehlers ab, dann wer- den die Änderungen der Transaktion automatisch zurückgesetzt und die Rücksetztransaktion wird nach Beheben des Fehlers erneut gestartet. Da die Ausführung der Kompensationsopera- tionen selbst nach Voraussetzung auf jeden Fall erfolgreich sein muß und Systemfehler nach Voraussetzung nur temporär sind, wird eine Rücksetztransaktion letztendlich erfolgreich durch- geführt werden. Um die Ausführung eines Agenten wieder aufzunehmen, wird in resumeExecution() zuerst die Funktion r_post ausgeführt (15). Da hierfür, wie in Abschnitt 5.3 ausgeführt, auch Kompensa- tionsoperationen zur Verfügung gestellt werden müssen, werden entsprechend ein begin-of- step-Eintrag und ein end-of-step-Eintrag geschrieben. Danach wird, wie ebenfalls in Abschnitt 5.3 ausgeführt wurde, ein Rücksetzpunkteintrag geschrieben (16). Den hierzu notwendigen Rücksetzpunkt-Bezeichner gibt r_post als Ergebnis zurück. Nun ist das Rücksetzen vollständig beendet und die normale Schrittausführung kann beginnen. Hierzu wird analog zu Algorithmus 5-1 aus der Reiseroute einer der nächsten möglichen Schritte bestimmt, dafür der Zielknoten er- 5.4 Basismechanismus 193mittelt und dann das Tupel (Agent, Log) in die Eingangswarteschlange des Zielknotens ge- schrieben (17). Die weitere Ausführung des Agenten geschieht dann wieder mittels Algorith- mus 5-1. Auch hier stellt die Transaktion die Atomizität der gesamten Operation (Lesen aus Eingangs- warteschlange, r_post ausführen, Schreiben in Eingangswarteschlange des Zielknotens) sicher. Um sicherzustellen, daß die Transaktion erfolgreich ausgeführt wird, muß – analog zu den Kompensationsoperationen – durch den Entwickler des Agenten sichergestellt werden, daß die Funktion r_post erfolgreich ausgeführt werden kann. Unter der Voraussetzung, daß die vom Agentenentwickler implementierten Kompensationsope- rationen und die Wiederaufnahme-Funktionen r_post korrekt implementiert sind, d.h. die Ope- rationen schlagen nicht fehl bzw. sind letztendlich erfolgreich, führt der vorgestellte Algorith- mus das Rücksetzen der Ausführung des Agenten nach dem Modell aus Abschnitt 5.3 durch: Die schwach reversiblen Objekte und die durch den Agenten geänderten Ressourcen werden durch vom Entwickler vorgegebene Kompensationsoperationen in der korrekten Reihenfolge (umgekehrte Ausführungsreihenfolge) kompensiert und die stark reversiblen Objekte werden durch die in Rücksetzpunkten enthaltenen Informationen zurückgesetzt. Um den Zugriff des Agenten auf die zu kompensierenden Ressourcen zu gewährleisten, werden die zu einem Schritt gehörenden Kompensationsoperationen jeweils auf dem Knoten ausgeführt, auf dem der zu kompensierende Schritt ausgeführt wurde. Nach erfolgreichem Rücksetzen wird vor Wieder- aufnahme der Ausführung des Agenten noch die Funktion r_post ausgeführt, die es dem Agen- ten erlaubt, den Grund für das Rücksetzen bei der weiteren Ausführung zu berücksichtigen. Die Ausführung der Kompensationsoperationen eines Schrittes innerhalb einer Transaktion in Kom- bination mit dem persistenten Speichern des Agenten innerhalb derselben Transaktion garan- tiert analog zum in Abschnitt 4.3 vorgestellten Basisprotokoll zur genau-einmal Ausführung mobiler Agenten, daß das Rücksetzen eines Agenten genau einmal geschieht. 5.4.4 Integration in den blockierungsfreien Mechanismus Die Integration des Basismechanismus’ zum Rücksetzen in das in Abschnitt 4.4 vorgestellte Protokoll zur blockierungsfreien Ausführung ist nicht sehr aufwendig. Analog zu Algorithmus 5-1 muß der Teil des Protokolles, welcher für das Lesen des Agenten aus der Eingangswarte- schlange, die Ausführung des Agenten und das Schreiben des Agenten in die nächste Stufe zu- ständig ist (vgl. Algorithmus 4-2), um die Verwaltung des Rücksetz-Logs (Lesen von/Schreiben in Eingangswarteschlange, Schreiben der begin-of-step-, end-of-step- und savepoint-Einträge in das Log) erweitert werden. Auch beim Rücksetzalgorithmus selbst sind nur wenige Änderungen notwendig – und zwar nur beim Übergang von Ausführung auf Rücksetzen und umgekehrt. Ruft der Agent beim Protokoll zur blockierungsfreien Ausführung rollback(..) auf, wird analog zu Algorithmus 5-2a die Schritt-Transaktion abgebrochen und der Agent innerhalb einer neuen 194 Kapitel 5 Partielles RücksetzenTransaktion von der lokalen Eingangswarteschlange gelesen und inklusive des Bezeichners des Ziel-Rücksetzpunktes in die Eingangswarteschlange des Knotens geschrieben, auf dem die nächste Aktion (Kompensation/r_post) durchgeführt werden soll. Eine möglichst einfache Inte- gration in das blockierungsfreie Protokoll wird dadurch erreicht, indem dafür gesorgt wird, daß diese Transaktion für alle anderen Knoten der aktuellen Stufe aussieht wie eine Schritt-Trans- aktion. Dies erreicht man, indem man einerseits das Monitoringprotokoll nicht abbricht (d.h. es werden weiterhin I_AM_ALIVE(..)-Nachrichten an die anderen Knoten der Stufe verschickt) und andererseits den Koordinator des aktuellen Knotens an dieser Transaktion teilnehmen läßt. Hierdurch wird am Ende der Transaktion analog zu den Schritt-Transaktionen das Votier-Pro- tokoll durchgeführt. Ist das Votieren erfolgreich, so wird einerseits für die Knoten der Stufe die Stufe abgeschlossen und andererseits die Transaktion erfolgreich abgeschlossen, sodaß sich der Agent nun mitsamt Log und Ziel-Rücksetzpunkt in einer Eingangswarteschlange befindet und von Algorithmus 5-2b weiterverarbeitet werden kann. Hiermit ist der Übergang von der Aus- führung des Agenten zum Rücksetzalgorithmus abgeschlossen. Ist das Votieren nicht erfolg- reich, so wird die Transaktion vom Koordinator abgebrochen. In diesem Falle wird ein anderer Knoten die Stufe beenden und die Entscheidung zum Rücksetzen des Agenten wird hierdurch obsolet. Der Übergang von Rücksetzen des Agenten zur weiteren Ausführung geschieht analog der Me- thode resumeExecution(..) aus Algorithmus 5-2b. Anstatt der Auswahl eines einzelnen Knotens wird jedoch mittels dem in Abschnitt 4.5.3 vorgestellten Algorithmus zur Stufenkonstruktion die nächste Stufe zusammengestellt und der Agent in die Eingangswarteschlangen der Knoten in dieser Stufe geschrieben. Diese geringfügigen Änderungen integrieren das Protokoll zum Rücksetzen von Agenten in das blockierungsfreie Protokoll zur Agentenausführung. Die Integration stellt auch hier sicher, daß der Agent nicht verloren geht und daß das Rücksetzen und anschließend die weitere Ausführung des Agenten sichergestellt wird. Im Gegensatz zur Ausführung des Agenten im blockierungs- freien Protokoll ist natürlich das Rücksetzen des Agenten bei dieser Art der Integration nicht blockierungsfrei: fällt ein Knoten aus, auf dem Kompensationsoperationen ausgeführt werden sollen, so ist das Rücksetzen solange blockiert, bis der Knoten wieder funktionsbereit ist. 5.5 Optimierungen Zwei Möglichkeiten zur Optimierung des vorgestellten Rücksetzmechanismus sind die Vermei- dung unnötiger Agententransporte und die Reduzierung der Größe des Rücksetz-Log. Die bei- den folgenden Abschnitte präsentieren Mechanismen für diese Optimierungen. 5.5 Optimierungen 1955.5.1 Vermeidung unnötiger Agententransporte Der in Abschnitt 5.4 vorgestellte Algorithmus transportiert (bzw. migriert) den Agenten zum Kompensieren eines Schrittes jeweils auf den Knoten, auf dem der zu kompensierende Schritt ausgeführt wurde. Häufig ist dies jedoch nicht unbedingt notwendig. Greift der Agent beispiels- weise bei der Kompensation nicht auf die Ressourcen des Knoten zu oder sind zum Rücksetzen eines Schrittes gar keine Kompensationsoperationen notwendig, dann ist der Transport des Agenten auf diesen Knoten überflüssig. Ein Beispiel ist ein Agent, der auf einem Knoten wäh- rend eines Schrittes nur Informationen sammelt, aber dabei den Zustand der Ressourcen (lo- gisch) nicht ändert. Beim Rücksetzen dieses Schrittes müssen nur die auf dem Knoten gesam- melten Informationen aus dem Zustand des Agenten entfernt werden – der Zugriff auf die Ressourcen des Knotens (und daher ein Transport des Agenten auf den Knoten) ist nicht not- wendig. Weiterhin gibt es Fälle, bei denen zwar auf die Ressourcen zur Kompensation zugegrif- fen werden muß, sich der Transport des gesamten Agenten auf den entsprechenden Knoten aber nicht lohnt. Dieser Abschnitt präsentiert die für diese Optimierungen notwendigen Erweiterun- gen des Basisalgorithmus’ zum Rücksetzen der Agentenausführung. Eine etwas einfachere, we- niger mächtige Version dieser Erweiterungen wurde bereits in STRASSER UND ROTHERMEL (2000) vorgestellt. 5.5.1.1 Typen von Operationseinträgen Damit entschieden werden kann, ob ein Agent zur Durchführung der Kompensation eines Schrittes migrieren muß oder nicht, muß das Rücksetz-Log entsprechende Informationen ent- halten. Da die Notwendigkeit der Migration eng mit den durchzuführenden Kompensationsope- rationen zusammenhängt, ist es naheliegend, die Operationseinträge des Rücksetz-Logs um die notwendigen Informationen und/oder Funktionalität zu erweitern. Um ein möglichst flexibles und effizientes Rücksetzen zu ermöglichen, werden vier verschiedene Typen von Operations- einträgen im Log unterschieden. Definition 5-8: Agentenkompensationseintrag. Ein Agentenkompensationseintrag enthält eine Kompensationsoperation, welche nur schwach reversible Objekte des Agentenzustandes kompensiert und keinerlei Zugriff auf Ressourcen benötigt. Die für die Ausführung dieser Kompensationsoperation notwendigen Informationen müssen im Operationseintrag und in den schwach reversiblen Objekten des Agenten enthalten sein. Wie schon in Abschnitt 5.3 erläutert, haben Kompensationsoperationen keinen Zugriff auf die stark reversiblen Objekte. Die Kompensationsoperation wird auf dem Knoten ausgeführt, auf dem sich der Agent befindet. Da kein Zugriff auf Ressourcen erlaubt ist, kann dies ein beliebiger Knoten sein. Da sich der Begriffs der schwach reversiblen Objekten direkt auf die Abhängigkeit 196 Kapitel 5 Partielles Rücksetzenvon der Kompensation von Ressourcen gründet (vgl. Abschnitt 5.3), wird dieser Typ von Ope- rationseintrag eher selten benötigt. Definition 5-9: Ressourcenkompensationseintrag. Ein Ressourcenkompensationseintrag enthält eine Kompensationsoperation welche nur den Zustand der durch den Agenten geänderten Ressourcen kompensiert und keinen Zugriff auf den Datenzustand des Agenten benötigt. Die für die Ausführung dieser Kompensationsoperation notwendigen Informationen, z.B. Daten aus den stark reversiblen Objekten, müssen komplett im Operationseintrag und im Zustand der Ressourcen enthalten sein. Ein Zugriff auf den Datenzustand des Agenten ist nicht erlaubt. Hat ein Agent beispielsweise auf einem Knoten mehrere Überweisungen zwischen verschiedenen Bankkonten ausgeführt, dann muß die Kompensationsoperation die entsprechenden Rücküber- weisungen durchführen. Hierzu müssen die Daten der Überweisungen wie Konten und Über- weisungsbeträge im Operationseintrag enthalten sein. Ressourcenkompensationseinträge (ge- nauer: die in ihnen enthaltenen Kompensationsoperationen) müssen auf dem Knoten der zu kompensierenden Ressourcen, d.h. auf dem Knoten auf dem der zu kompensierende Schritt ausgeführt wurde, ausgeführt werden. Da die auszuführende Kompensationsoperation keinen Zugriff auf den Agent benötigt, ist es möglich, den Ressourcenkompensationseintrag ohne Agent auf den Knoten zu schicken, auf dem die Operation ausgeführt werden muß. Definition 5-10: Gemischter Kompensationseintrag Typ I. Ein gemischter Kompensationseintrag Typ I enthält eine Kompensationsoperation, welche gleichzeitig Zugriff auf die schwach reversiblen Objekte des Agenten und auf die zu kompensierenden Ressourcen benötigt. Ein Beispielszenario für diesen Eintragstyp ist ein Schritt, in dem der Agent auf der Bank digi- tales Geld von US$ in Euro umtauscht. Da digitales Geld nicht in stark reversiblen Objekten ge- speichert werden kann (dies folgt aus der Diskussion in Abschnitt 5.2), benötigt die zum Um- tausch gehörende Kompensationsoperation Zugriff auf das schwach reversible Objekt, welches den Euro-Betrag enthält, auf das schwach reversible Objekt, in dem der US$-Betrag gespeichert werden soll, und auf die Ressource, die das Geld tauscht. Für die Ausführung eines gemischten Kompensationseintrages Typ I muß sich der Agent auf dem Knoten der zu kompensierenden Ressource(n) befinden, damit die Kompensationsoperation sowohl auf den Agent als auch auf die Ressourcen zugreifen kann. Somit entspricht dieser Eintragstyp den im Basisalgorithmus verwendeten Operationseinträgen. Ist im eben skizzierten Währungstausch-Szenario der Rücktausch des Geldes die einzige Kom- pensationsoperation welche Zugriff auf die Ressourcen des Knotens benötigt, so ist der Trans- port des Agenten auf den Knoten der zu kompensierenden Ressource ein nicht unerheblicher 5.5 Optimierungen 197Aufwand im Verhältnis zur Aktion des Geldrücktausches. Da jedoch nach dem in Abschnitt 2.2 beschriebenen Agentenmodell der Zugriff auf Ressourcen lokal geschieht, kann nicht einfach ein entfernter Prozeduraufruf zum Rücktausch des Geldes verwendet werden. Aus diesem Grund wird noch der nachfolgende Eintragstyp eingeführt. Definition 5-11: Gemischter Kompensationseintrag Typ II Ein gemischter Kompensationseintrag Typ II beinhaltet insgesamt drei (Kompensa- tions-)Operationen: Vor-, Haupt- und Nachoperation. Vor- und Nachoperation ha- ben nur Zugriff die schwach reversiblen Objekte des Agenten, die Hauptoperation hat nur Zugriff auf die zu kompensierenden Ressourcen. Die Parameter der Vorope- ration sind im Kompensationseintrag vollständig enthalten, die Parameter der Haupt- bzw. Nachoperation sind nur zum Teil im Kompensationseintrag enthalten. Der fehlende Teil der Parameter wird für die Hauptoperation von der Voroperation und für die Nachoperation von der Hauptoperation generiert. Vor- und Nachoperation müssen auf dem Knoten ausgeführt werden, auf dem sich der Agent befindet, die Hauptoperation auf dem Knoten der zu kompensierenden Ressource(n). Die die- sem Eintragstyp zugrundeliegende Idee ist, daß mit der Voroperation die für die Hauptoperati- on notwendigen Daten aus den schwach reversiblen Objekten des Agenten gelesen werden und diese der Hauptoperation als Parameter übergeben werden. Entstehen bei der Hauptoperation neue Informationen, welche wieder in die schwach reversiblen Objekte des Agenten integriert werden müssen, so bekommt die Nachoperation diese Informationen von der Hauptoperation als Parameter geliefert, welche diese Daten wieder in den Agenten integriert. Für das Szenario des Geldrücktausches würde dies bedeuten, daß die Voroperation die digitalen Euro-Münzen aus dem Agent liest und diese der Hauptoperation als Parameter übergibt. Die Hauptoperation tauscht die Euro-Münzen in US$-Münzen und übergibt die US$-Münzen an die Nachoperation, welche die US$-Münzen dann in die schwach reversiblen Objekte des Agenten schreibt. Ent- weder die Voroperation oder die Nachoperation kann eine leere Operation sein – wären beide Operationen leer, entspräche dies einem Ressourcenkompensationseintrag. Ist die Voroperation eine leere Operation, dann benötigt die Hauptoperation keine Daten aus den schwach reversi- blen Objekten. Ist die Nachoperation eine leere Operation, müssen keine bei der Hauptoperation entstehenden Daten in den Agent integriert werden. Wie die verschiedenen Operationseintragstypen realisiert werden, hängt von der zur Program- mierung des Agenten verwendeten Programmiersprache ab. Eine Möglichkeit der Realisierung ist die Erweiterung des in Abschnitt 5.4.2 (Abbildung 5-5) vorgestellten Ansatzes. Für jeden Operationseintragstyp existiert eine Unterklasse von CompensationObject. Abbildung 5-7 zeigt dies anhand der Klassen für Ressourcenkompensationseinträge und gemischte Kompensations- einträge Typ II. 198 Kapitel 5 Partielles RücksetzenFür einen Ressourcenkompensationsein- trag muß der Agentenentwickler eine Un- terklasse von ResourceCompensationOb- ject implementieren. Diese Unterklasse muß die zur Kompensation notwendigen Informationen als Attribute enthalten und die compensate()-Methode implementie- ren. Wird bei der Ausführung eines Schrit- tes ein Objekt dieser Unterklasse ins Rück- setzlog geschrieben, dann reicht es beim Rücksetzen dieses Schrittes aus, dieses Ob- jekt auf den Knoten, auf dem der Schritt ausgeführt wurde, zu schicken und die compensate()-Methode des Objektes aus- zuführen. Bei Agentenkompensationsein- trägen und gemischten Kompensationsein- trägen Typ I ist das Vorgehen analog, die Kompensationseinträge werden jedoch di- rekt beim Agent ausgeführt. Bei einem ge- mischten Kompensationseintrag Typ II weicht das Vorgehen etwas von den ande- ren Eintragsarten ab. Die compensate()- Methode ist in diesem Falle die Hauptope- ration des Eintrags, pre()- und post()-Me- thode stellen die Voroperation und die Nachoperation dar. Sämtliche Parameter dieser Methoden sind als Attribute im Ob- jekt enthalten. Die von pre() für compensate() generierten Parameter werden genauso in Attri- buten des Objektes abgelegt wie die von compensate() für post() generierten Parameter. hasPre() bzw. hasPost() geben an, ob eine Voroperation oder eine Nachoperation existiert. Wird bei der Ausführung eines Schrittes ein solches Objekt ins Rücksetzlog geschrieben, dann wird beim Rücksetzen dieses Schrittes zuerst pre() beim Agenten ausgeführt (falls hasPre() wahr lie- fert). Das Objekt wird dann auf den Knoten, auf dem der Schritt ausgeführt wurde, geschickt und die compensate()-Methode des Objektes wird ausgeführt. Falls hasPost() wahr liefert, wird das Objekt dann wieder zurückgeschickt und post() ausgeführt. Die Klasse Compensate- MoneyExchange zeigt die für das oben angeführte Szenario des Rücktausches von digitalem Geld notwendige Unterklasse von MixedCompensationObjectII. Die Methode pre() liest die zu tauschenden Dollar aus dem Agent und speichert sie im Attribut forDollars, compensate() tauscht diese bei der Ressource theChangeMachine in Euro um und speichert das Ergebnis in Abbildung 5-7. Verschiedene Typen von Operationseinträgen abstract class CompensationObject{ abstract void compensate(); } abstract class ResourceCompensationObject extends CompensationObject{}; abstract class MixedCompensationObjectII extends CompensationObject{ abstract void pre(); abstract void post(); abstract boolean hasPre(); abstract boolean hasPost(); }; class CompensateMoneyExchange extends MixedCompensationObjectII{ Purse forDollars, for Euros; MoneyExchange theChangeMachine; void pre(){ forEuros = getMoneyFromAgent(); } void compensate(){ forDollars = theChangeMachine.toUSD(forEuros); } void post(){ writeMoneyToAgent(forDollars); } boolean hasPre(){return true}; boolean hasPost(){return true}; } 5.5 Optimierungen 199forEuros, post() schreibt das Ergebnis schließlich in den Agenten zurück. 5.5.1.2 Möglichkeiten der Optimierung Die Vermeidung unnötiger Agententransfers als Ziel der Optimierung führt nicht unbedingt zu einer verbesserten Leistung: Aus der Definition der verschiedenen Typen von Operationseinträ- gen wird ersichtlich, daß die Migration des Agenten zur Kompensation eines Schrittes nur dann zwingend notwendig ist, wenn das Rücksetz-Log für diesen Schritt einen gemischten Kompen- sationseintrag Typ I enthält. Daraus den Schluß zu ziehen, daß bei Nicht-Existenz eines solchen Kompensationseintrages die Migration nicht notwendig ist, kann bedeuten, daß beim Vorhan- densein mehrerer gemischter Kompensationseinträge Typ II mit Vor- und Nachoperationen durch die dadurch notwendige mehrfache Kommunikation ein Vielfaches an Netzwerkband- breite und Zeit benötigt wird. Für eine Optimierung ist also ein anderes Kostenmaß notwendig, nach dem optimiert werden kann. Gängige Kostenmaße sind Netzwerklast, die für das Rückset- zen notwendigen Zeit bzw. eine Kombination von Netzwerklast und Ausführungszeit. Hierfür werden Leistungsmodelle ähnlich dem in STRASSER UND SCHWEHM (1997) vorgestellten Mo- dell benötigt. Im folgenden wird darauf eingegangen, welche Möglichkeiten zur Optimierung sich durch die im letzten Abschnitt eingeführten Operationseinträge ergeben. Sofern für das Rücksetzen eines Schrittes S, welcher auf Knoten K ausgeführt wurde, kein ge- mischter Kompensationseintrag Typ I im Rücksetz-Log enthalten ist, besteht grundsätzlich die Möglichkeit, daß der Agent zum Rücksetzen von S nicht nach K migriert wird, sondern nur die Ressourcenkompensationseinträge und die gemischten Kompensationseinträge Typ II auf den Knoten K verschickt werden und der Datenzustand des Agenten auf jenem Knoten rückgesetzt wird, auf dem sich der Agent momentan befindet. Eine einfache Implementierung, welche die die rollbackOneStep(..)-Funktion aus Algorithmus 5-2 ersetzt, zeigt Algorithmus 5-3. Falls der Agent sich auf dem Knoten befindet, auf dem der zu kompensierende Schritt ausge- führt wurde, dann können alle Kompensationsoperationen lokal ausgeführt werden (1)1. Ist dies nicht der Fall, muß für jeden Log-Eintrag anhand des Eintragstyps entschieden werden, wie mit dem Eintrag zu verfahren ist (8). Agentenkompensationseinträge werden lokal ausgeführt (9). Bei Ressourcenkompensationseinträgen wird der Eintrag mitsamt dem Bezeichner der aktuel- len Rücksetztransaktion auf den Knoten geschickt, auf dem der zu kompensierende Schritt aus- geführt wurde (10). Dieser Knoten, im folgenden Ressourcenknoten genannt, wurde dem end- of-step-Eintrag des zu kompensierenden Schrittes entnommen (3). Es wird gewartet, bis die Vollendung der Ausführung des Ressourcenkompensationseintrages bestätigt wird. Empfängt ein Knoten einen Ressourcenkompensationseintrag, dann wird die darin enthaltene Kompensa- tionsoperation im Kontext der Transaktion, deren Bezeichner mit übertragen wurde, ausgeführt und danach eine Bestätigung zurückgeschickt (14). 1. Die Zahlen in Klammern beziehen sich auf die Fall-Numerierungen in Algorithmus 5-3 200 Kapitel 5 Partielles RücksetzenAlgorithmus 5-3. Ausführung unterschiedlicher Operationseintragstypen rollbackOneStep(Agent a, Log log, SpID spID, ResumeObject r_post){ entry = log.pop() // end-of-step if (entry.stepExecutionNode()==nodeId){ (1) entry=log.pop() while (entry≠begin-of-step){ entry.compensate() entry=log.pop() } }else{ (2) remoteCompensation(log, entry.stepExecutionNode()) (3) } if (last entry in log is savepoint){ (4) restore strongly reversible objects if (savepoint spID not reached){ log.pop() // sp not needed anymore } } if (savepoint spID reached){ (5) target=localNodeInputQueue }else{ entry = last end-of-step entry in log if ( entry.stepHasMixedCompensationObjectI()){ target = entry.stepExecutionNode() (6) }else{ target = localNodeInputQueue (7) } } Write(a,log,spID,r_post) To target } remoteCompensation(Log log, Node n){ (8) entry=log.pop() while (entry≠begin-of-step){ if (entry is AgentCompensationObject){ (9) entry.compensate() }elsif(entry is ResourceCompensationObject){ (10) Send (entry, transactionId, nodeId) To n Receive(acknowledgement) From n }else{ // MixedCompensationObjectII (11) if (entry.hasPre()){entry.pre()} (12) Send(entry, transactionId) To n if (entry.hasPost()){ (13) Receive(entry) From n entry.post() }else{ Receive(acknowledgement) From n } } entry=log.pop() } // while } a. Ausführung von Einträgen auf dem aktuellen Aufenthaltsknoten des Agenten Receive(ResourceCompensationObject r, TransactionId tId, fromNode n){ (14) register with transaction manager for tId r.compensate() Send (acknowledgement) To n } Receive(MixedCompensationObjectII r, TransactionId tId, fromNode n){ register with transaction manager for tId r.compensate() if (r.hasPost()){ Send(r) To n (15) }else{ Send(acknowledgement) To n (16) } } b. Ausführung von Einträgen auf Ressourcenknoten 5.5 Optimierungen 201Die Ausführung gemischter Kompensationseinträge Typ II geschieht analog (11), jedoch wird vor dem Versenden des Eintrages noch die pre()-Methode ausgeführt (12). Besitzt der Kompen- sationseintrag eine post()-Methode, schickt der Ressourcenknoten nach der Ausführung der compensate()-Methode den Kompensationseintrag zurück (15), damit die post()-Methode auf dem den Kompensationsschritt ausführenden Knoten lokal ausgeführt werden kann (13). Be- sitzt der Kompensationseintrag keine post()-Methode, schickt der ResourceNode eine Ausfüh- rungsbestätigung (16). Nach der Ausführung der Kompensationsoperationen werden wie in Algorithmus 5-2 eventuell noch die stark reversiblen Objekte zurückgesetzt (4). Danach muß entschieden werden, ob ein Transport des Agenten notwendig ist oder ob er in die lokale Eingangswarteschlange geschrie- ben werden kann. Ist das Ziel des Rücksetzens erreicht, so wird der Agent in die lokale Ein- gangswarteschlange geschrieben (5). Müssen weitere Schritte zurückgesetzt werden, dann wird geprüft, ob der nächste zurückzusetzende Schritt einen gemischten Ressourcenkompensations- eintrag Typ I enthält. Damit dies einfach geprüft werden kann, wird diese Information schon bei der Ausführung des Schrittes im end-of-step-Eintrag vermerkt. Enthält der nächste Schritt einen gemischten Kompensationseintrag Typ I, so ist ein Transport notwendig (6), ansonsten nicht (7). Das Verschicken einzelner Einträge führt zusätzliche Fehlerquellen ein. Nach dem in Abschnitt 4.1.3 beschriebenen Fehlermodell kann der Knoten, zu dem die Einträge verschickt werden, ausfallen und es können Netzwerkpartitionierungen (mit unbemerktem Verlust von Nachrich- ten) auftreten, sodaß sich der Agent und Ressourcen in unterschiedlichen Partition befinden. Treten diese Fehler auf, erhält der Knoten, auf dem sich der Agent aufhält, keine Bestätigung über die Ausführung der verschickten Einträge (bzw. das Resultat der Ausführung von gemisch- ten Kompensationseinträgen Typ II). Eine einfache Lösung, die sicherstellt, daß die Kompensa- tionsoperationen genau einmal ausgeführt werden, besteht darin, daß während des Wartens auf eine Ausführungsbestätigung bzw. auf ein Resultat periodisch eine Anfrage verschickt wird, ob die Einträge gerade noch ausgeführt werden. Im Falle einer negativen Antwort auf diese Anfra- ge bzw. des Ausbleibens einer Antwort wird einfach die Transaktion, innerhalb der die Kom- pensationsoperationen ausgeführt werden, abgebrochen und das Rücksetzen des gerade bear- beiteten Schrittes erneut gestartet. Die in Algorithmus 5-3 vorgestellte Art der Ausführung nutzt nur einen kleinen Teil des durch die verschiedenen Eintragstypen vorhandenen Potentials – nämlich die örtliche Trennung der Kompensation des Agenten und der Ressourcen – und ist deshalb nur in Ausnahmefällen effi- zient. Nicht ausgenutzt wird die Tatsache, daß die in den verschiedenen Eintragstypen enthalte- nen Operationen teilweise auf disjunkten Datenräumen arbeiten und daher unabhängig vonein- ander ausgeführt werden können. Deshalb ist beispielsweise die Ausführungsreihenfolge von einem Agentenkompensationseintrag und einem Ressourcenkompensationseintrag unabhängig von der Reihenfolge, in der diese beiden Einträge im Log erscheinen. Für den Fall, daß das Rücksetz-Log für einen Schritt nur Agenten- und Ressourcenkompensationseinträge enthält, bedeutet dies, daß beim Rücksetzen des Schrittes nur darauf geachtet werden muß, daß die 202 Kapitel 5 Partielles RücksetzenAgentenkompensationseinträge in der durch das Rücksetz-Log definierten Reihenfolge ausge- führt werden und ebenso die Ressourcenkompensationseinträge. Dadurch wird es möglich, alle Ressourcenkompensationseinträge gesammelt auf den Knoten zu schicken, auf dem der zu kompensierende Schritt ausgeführt wurde. Aus Sicht der Kompensationsoperationen ist es so- gar möglich, zuerst alle Ressourcenkompensationseinträge zu verschicken und dann die Agen- tenkompensationseinträge parallel zu den Ressourcenkompensationseinträgen abzuarbeiten. Etwas komplexer stellt sich die Situation dar, wenn das Rücksetz-Log für einen Schritt zusätz- lich gemischte Kompensationseinträge Typ II enthält. Abbildung 5-8 zeigt ein Beispiel für ein solches Rücksetz-Log. Die Abbildung zeigt die zu einem Schritt gehörenden Operationseinträ- ge des Rücksetz-Logs in der Reihenfolge, in der die Einträge beim Rücksetzen abzuarbeiten sind, d.h. E1 muß zuerst abgearbeitet werden. Durch die enthaltenen Kompensationseinträge Typ II werden zwischen der Kompensation des Agentenzustandes und der Kompensation der Ressourcen Abhängigkeiten eingeführt. Durch diese Abhängigkeiten ergeben sich für die Ab- arbeitung der Rücksetz-Log-Einträge eines Schrittes die folgenden Randbedingungen: • Ein Agentenkompensationseintrag kann dann abgearbeitet werden, wenn alle Operationen, die den Zustand des Agenten ändern und die laut Rücksetz-Log vor diesem Kompensations- eintrag ausgeführt werden müssen, bereits ausgeführt sind. Damit ein Agentenkompensati- onseintrag ausgeführt werden kann, müssen daher die folgenden drei Bedingungen erfüllt sein: - Die laut Rücksetz-Log vorher auszuführenden Agentenkompensationseinträge müssen bereits abgearbeitet worden sein. In Abbildung 5-8 muß beispielsweise der Eintrag E1 ab- gearbeitet worden sein bevor E2 abgearbeitet wird. - Die laut Rücksetz-Log vorher auszuführenden gemischten Kompensationseinträge Typ II, welche eine Nachoperation besitzen müssen bereits abgearbeitet worden sein. Um den Agentenkompensationseintrag E6 aus Abbildung 5-8 ausführen zu können muß also zu- vor die Nachoperation von Eintrag E5 und damit der gesamte Eintrag E5 ausgeführt wor- den sein. Abbildung 5-8. Beispiel-Log mit verschiedenen Operationseintragstypen A R GN A VGN GNR AVGN AVG AA A E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E14E13E12 R A Agentenkompensationseintrag R Ressourcenkompensationseintrag VGN Gemischter Kompensationseintrag Typ II mit Voroperation (V) und Nachoperation(N) abarbeiten 5.5 Optimierungen 203- Von den laut Rücksetz-Log vorher auszuführenden gemischten Kompensationseinträgen Typ II, welche eine Voroperation besitzen, muß zumindest die Voroperation bereits aus- geführt worden sein. Für das Beispiel in Abbildung 5-8 bedeutet dies, daß der Agenten- kompensationseintrag E4 erst ausgeführt werden kann, wenn die Voroperation von E3 be- reits ausgeführt wurde. Die Hauptoperation von E3 hingegen muß zur Ausführungszeit von E4 noch nicht ausgeführt worden sein, da diese per Definition den Datenzustand des Agenten nicht ändert. • Ein Ressourcenkompensationseintrag kann erst dann auf den Knoten der Ressourcen ge- schickt werden, wenn die laut Rücksetz-Log vor ihm abzuarbeitenden Ressourcenkompen- sationseinträge bzw. gemischten Kompensationseinträge Typ II schon verschickt wurden oder mit ihm zusammen verschickt werden, da auf dem Knoten der Ressourcen diese beiden Eintragstypen in der durch das Rücksetz-Log definierten Reihenfolge abgearbeitet werden müssen. Um beispielsweise den Ressourcenkompensationseintrag E10 aus Abbildung 5-8 verschicken zu können, müssen die Einträge E3, E5 und E7 schon verschickt worden sein bzw. mit ihm verschickt werden, da diese Einträge schon abgearbeitet sein müssen, bevor E10 abgearbeitet werden kann. • Ein gemischter Kompensationseintrag Typ II kann erst dann auf den Knoten der Ressourcen geschickt werden, wenn die laut Rücksetz-Log vor ihm abzuarbeitenden Ressourcenkom- pensationseinträge bzw. gemischten Kompensationseinträge Typ II schon verschickt wurden oder mit ihm zusammen verschickt werden. Für den Eintrag E11 aus Abbildung 5-8 bedeutet dies, daß E3, E5, E7 und E10 vor oder mit ihm zusammen verschickt werden müssen. Hat ein gemischter Kompensationseintrag Typ II eine Voroperation, so müssen vor der Ausführung der Voroperation (und daher vor dem Verschicken des Eintrages) alle laut Rücksetz-Log vor ihm abzuarbeitenden Agentenkompensationseinträge (z.B. E1 und E2 vor E3) und gemisch- ten Kompensationseinträge Typ II, welche eine Nachoperation besitzen, abgearbeitet sein. Außerdem müssen die Voroperationen aller vor ihm abzuarbeitenden gemischten Kompen- sationseinträge Typ II bereits abgearbeitet sein (Voroperation von E3 vor Voroperation von E5). Dies stellt sicher, daß die Voroperation bei der Ausführung den korrekten Zustand des Agenten vorfindet. • Auf dem Knoten der Ressourcen müssen Ressourcenkompensationseinträge und gemischte Kompensationseinträge Typ II in der durch das Rücksetz-Log definierten Reihenfolge abge- arbeitet werden. Diese Randbedingungen spannen den Raum der potentiellen Ausführungsmöglichkeiten auf, innerhalb dem optimiert werden kann. Beim Einsatz dieser Optimierung ändert sich die Seman- Abbildung 5-8. (Wdh.) Beispiel-Log mit verschiedenen Operationseintragstypen A R GN A VGN GNR AVGN AVG AA A E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E14E13E12 R 204 Kapitel 5 Partielles Rücksetzentik des Rücksetzens geringfügig. Während beim ursprünglichen Mechanismus die Funktion rpost immer auf dem Knoten ausgeführt wird, auf dem der zuletzt kompensierte Schritt ur- sprünglich ausgeführt wurde, wird sie nun auf dem Knoten ausgeführt, auf dem die letzten Kompensationsoperationen ausgeführt wurden. Dies entspricht jedoch immer noch dem Mo- dell, welches aussagt, daß rpost auf einem beliebigen Knoten ausgeführt werden kann. Unter Berücksichtigung dieser Randbedingungen gibt es viele Möglichkeiten, die Operations- einträge des Rücksetz-Logs aus Abbildung 5-8 abzuarbeiten. Eine Möglichkeit der Abarbeitung besteht darin, zuerst die Agentenkompensationseinträge E1 und E2, die Voroperation von E3, den Agentenkompensationseintrag E4 und die Voroperation von E5 auszuführen. Danach kön- nen alle Ressourcenkompensationseinträge und gemischten Kompensationseinträge Typ II auf einmal zum Knoten mit den Ressourcen verschickt und dort in der Reihenfolge E3, E5, E7, E10, E11, E13, E14 ausgeführt werden. Hierbei werden von den gemischten Kompensationseinträgen nur die Hauptoperationen ausgeführt. Als Ergebnis werden die gemischten Kompensationsein- träge E5, E11 und E14 zurückgeschickt. Nachdem das Ergebnis angekommen ist, werden die Nachoperation von E5, die Agentenkompensationseinträge E6, E8 und E9, die Nachoperation von E11, der Eintrag E12 und die Nachoperation von E14 ausgeführt. In diesem Fall werden also nur einmal Operationseinträge zum Knoten mit den Ressourcen verschickt und auch nur eine Antwort bestehend aus mehreren Operationseinträgen zurückgeschickt. Im Vergleich zur Aus- führung mit dem einfachen Algorithmus 5-3, bei der jeder Ressourcenkompensationseintrag und jeder gemischte Kompensationseintrag einzeln verschickt worden wäre, wird hier also mehrfach die Kommunikationsverzögerung (engl.: delay) zwischen den Knoten eingespart. Weitere Ausführungsmöglichkeiten ergeben sich, wenn man die Möglichkeit ausnutzt, Kom- pensationsoperationen auf Ressourcen und Agent parallel auszuführen. Dies ist vor allem dann sinnvoll, wenn die Agentenkompensationseinträge sehr rechen- und daher zeitintensiv sind. Ab- bildung 5-9 zeigt eines der möglichen Szenarien der parallelen Abarbeitung des Rücksetz-Logs aus Abbildung 5-8. Nach der Ausführung der Einträge E1 und E2 und der Ausführung der Vor- operation von Eintrag E3 wird der Eintrag E3 bereits zum Knoten mit den Ressourcen geschickt. Dort kann E3 dann schon ausgeführt werden, während lokal der Eintrag E4 und die Voroperation von E5 ausgeführt werden. Danach können die Einträge E5, E7, E10, E11, E13, E14 zum Knoten mit den Ressourcen verschickt werden. Diese werden dort abgearbeitet während lokal die rest- lichen Agentenkompensationseinträge bzw. die Nachoperationen der gemischten Kompensati- onseinträge ausgeführt werden. Da die Nachoperationen immer erst dann lokal abgearbeitet werden können, sobald das Ergebnis der jeweiligen Hauptoperation vorliegt, werden die Ergeb- nisse immer sofort nach Abschluß der Hauptoperation verschickt. Für den Eintrag E5 heißt dies Abbildung 5-8. (Wdh.) Beispiel-Log mit verschiedenen Operationseintragstypen A R GN A VGN GNR AVGN AVG AA A E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E14E13E12 R 5.5 Optimierungen 205beispielsweise, das nach der Ausführung der Hauptoperation auf dem Knoten mit den Ressour- cen der Operationseintrag sofort wieder zum den Kompensationsschritt ausführenden Knoten verschickt wird, damit dort die lokale Verarbeitung mit der Ausführung der Nachoperation von E5 fortgesetzt werden kann. Um die optimale Ausführungsstrategie zu ermitteln, müssen anhand der Randbedingungen prinzipiell sämtliche möglichen Ausführungsmöglichkeiten bestimmt werden, mittels des Ko- stenmaßes die Kosten für die verschiedenen Möglichkeiten berechnet werden, die gemäß Ko- stenmaß optimale Möglichkeit ausgewählt und mit der Lösung “Migration zum Knoten, auf dem die Ressourcen kompensiert werden müssen” verglichen werden. Als Ergebnis erhält man dann die Entscheidung, ob der Agent migriert werden soll und, wenn diese mit “nein” ausfällt, auch die Strategie, wie die Operationseinträge auszuführen sind. Diese Optimierung kann sepa- rat für jeden zu kompensierenden Schritt geschehen, d.h. für jeden Schritt wird separat entschie- den, ob der Agent für die Kompensation dieses Schrittes migrieren muß. Hierdurch wird ein lo- kales Optimum erreicht wird. Alternativ kann über alle rückzusetzenden Schritte gemeinsam optimiert werden, wodurch ein globales Optimum erreicht werden kann. 5.5.1.3 Algorithmus Die Ermittlung der optimalen Ausführungsstrategie für den allgemeinen Fall ist sehr komplex. Daher wird in diesem Abschnitt ein optimierter Algorithmus entwickelt dem die Annahme zu- grunde liegt, daß der Aufwand für die Durchführung der Kompensationsoperationen auf den Agentenzustand im Vergleich zum Aufwand für globale Kommunikation im allgemeinen ver- nachlässigt werden kann. Diese Annahme wird durch die sich aus der Definition der schwach reversiblen Objekte ergebende Vermutung gestützt, daß ein großer Teil der möglichen Anwen- dungen keine oder nur wenige schwach reversiblen Objekte verwendet und daher wenig Re- chenaufwand für die lokal beim Agenten durchzuführenden Kompensationsoperationen ent- steht. Abbildung 5-9. Parallele Ausführung von Agenten- und Ressourcenkompensation E1 E2 V(E3) E4 V(E5) N(E5) E6 E8 E9 N(E11) E12 N(E14) E5, E7, E10E3 E11, E13, E14 E5 E3 E5 E7 E10 E11 E13 E14 E11 E14 t t K1 K2 K1: Knoten, der Kompensationsschritt ausführt K2: Knoten mit den zu kompensierenden Ressourcen Ex: Ausführung der (Haupt-)Operation von Eintrag Ex V(x): Ausführung der Voroperation von Eintrag x N(x): Ausführung der Nachoperation von Eintrag x bzw. Transport von Ex auf anderen Knoten 206 Kapitel 5 Partielles RücksetzenAlgorithmus 5-4 zeigt eine auf dieser Annahme basierende optimierte Implementierung der remoteCompensation(..)-Methode aus Algorithmus 5-3. Diese Methode ist für die Ausführung der Operationseinträge zuständig, wenn sich Agent und zu kompensierende Ressourcen nicht auf dem selben Knoten befinden. Ziel der Optimierung ist, möglichst selten mit dem Ressour- cenknoten zu kommunizieren. Dies wird erreicht, indem immer möglichst viele Ressourcenein- träge und gemischte Kompensationseinträge Typ II gemeinsam zum Ressourcenknoten ver- schickt werden. Die Funktionsweise wird anhand des Logs aus Abbildung 5-10 erläutert. Der dort abgebildete Ausschnitt des Logs stellt die Operationseinträge eines einzelnen Schrittes in der Reihenfolge dar, in der sie zur Kompensation des Schrittes ausgeführt werden müssen. Der Algorithmus besteht aus drei Phasen, die zyklisch durchlaufen werden. In einer ersten Pha- se des Algorithmus wird versucht, möglichst viel Einträge lokal abzuarbeiten. Dazu wird für je- den einzelnen Eintrag entschieden, wie mit diesem zu Verfahren ist. Agentenkompensationsein- träge können sofort lokal abgearbeitet werden (1)1. Eintrag E1 aus Abbildung 5-10 wird also sofort lokal abgearbeitet. Eintrag E2, der ein Ressourcenkompensationseintrag ist, wird zum Verschicken auf den Ressourcenknoten vorgemerkt (2) – unter der Voraussetzung, daß er dort nicht schon ausgeführt worden ist (siehe weiter unten). Die Behandlung von gemischten Kompensationseinträgen Typ II hängt davon ab, ob deren Hauptoperation schon auf dem Ressourcenknoten ausgeführt wurde. Wurde die Hauptoperation schon ausgeführt (7), dann wird, falls vorhanden, noch die Nachoperation des Eintrages ausge- führt (8). Wurde die Hauptoperation noch nicht ausgeführt (3), dann wird der Eintrag zum Verschicken auf den Ressourcenknoten vorgemerkt (5). Zuvor wird jedoch noch, falls vorhanden, die Voro- peration des Eintrages ausgeführt. Da dies auf Eintrag E3 zutrifft, wird also dessen Voroperation ausgeführt und der Eintrag zum Verschicken vorgemerkt. Besitzt ein solcher Eintrag noch eine Nachoperation, dann beendet dies die Phase der lokalen Ausführung (6), da zur Ausführung der 1. Die Zahlen in Klammern beziehen sich auf die Fall-Numerierungen in Algorithmus 5-4 Abbildung 5-10. Beispiel-Log mit verschiedenen Operationseintragstypen GN A VGN A VGN GNR AA VGNVG AA R E1 E2 E3 E4 E5 E6 E7 E8 E9 E10 E11 E14E13E12 R A Agentenkompensationseintrag R Ressourcenkompensationseintrag VGN Gemischter Kompensationseintrag Typ II mit Voroperation (V) und Nachoperation(N) abarbeiten 5.5 Optimierungen 207Algorithmus 5-4. Optimierte Ausführung unterschiedlicher Operationseintragstypen remoteCompensation(Log log, Node n){ entries = array of operation entries for this step in execution order nrEntries = number of elements in entries i = 0 do{ toSend = ∅ stop = false do{ if (entries[i] is AgentCompensationObject){ (1) entries[i].compensate() i++ }else if (entries[i] is ResourceCompensationObject){ if (entries[i] not already executed){ toSend = toSend + entries[i] (2) } i++ }else{ // MixedCompensationObjectII if (main operation of entries[i] not yet executed){ (3) if (entries[i].hasPre()){ (4) entries[i].pre() } toSend = toSend + entries[i] (5) if (not entries[i].hasPost()){ i++ }else{ stop=true (6) } }else{// main operation executed (7) if (entries[i].hasPost()){ (8) entries[i].post() } i++ } } }while( (i≠nrEntries) and not stop) (9) j=i+1 stop = false while ((j