Vom Ergebnis zum Prozess
Der erste Teil dieser Reihe hat die Hauptansicht behandelt — die Gegenüberstellung
zweier Antworten als didaktische Bühne. Sie beantwortet eine Ja-oder-Nein-Frage,
und sie beantwortet sie überzeugend: Der angebundene Server bewirkt einen
sichtbaren Unterschied. Doch sie schweigt darüber, wie dieser Unterschied zustande
kommt. Welche Werkzeuge das Modell in welcher Reihenfolge wählt, mit welchen
Argumenten es sie aufruft, wie deren Ergebnisse in den weiteren Dialog
zurückfließen und an welcher Stelle aus mehreren Durchläufen schließlich eine
zusammenhängende Empfehlung wird — all dies läuft im automatischen Betrieb
verborgen ab. Die mitlaufende Zeitleiste der Hauptansicht deutet den Verkehr an,
hält ihn aber nicht an.
Eben hier setzt der vorliegende zweite Teil an. Er behandelt die
Schritt-für-Schritt-Ansicht, eine eigenständige Ansicht unter der Routemcp-walkthrough mit dem Titel „MCP Server — Step by Step“. Wo die Hauptansicht
das Ergebnis zweier Anfragen nebeneinanderstellt und den Mechanismus dabei
verbirgt, kehrt die Schritt-für-Schritt-Ansicht das Verhältnis um. Sie hält die
Pipeline an, macht jede Phase einzeln auslösbar und verwandelt den ansonsten
flüchtigen Ablauf in einen lesbaren, zeitlich gegliederten Gegenstand. Der
didaktische Gewinn liegt im Verlangsamen: Was die Hauptansicht in einem Zug
abspult, zerlegt die Vorführansicht in nachvollziehbare Schritte, die der
Betrachter in seinem eigenen Tempo durchschreiten kann.
Der Quelltext befindet sich auf GitHub unter:
Der Rundgang dieses Teils folgt deshalb nicht mehr den Bestandteilen einer
Oberfläche, sondern den Hürden, die das Anhalten und Sichtbarmachen eines an sich
automatischen Vorgangs mit sich bringt. Das erste und tragende Kapitel behandelt
die architektonische Voraussetzung: die Zerlegung der automatischen Werkzeugschleife
in einzelne, fortsetzbare Phasen, die beide Ansichten gemeinsam nutzen. Darauf
folgen die Verarbeitungsspur als Zeitachse, das einzelne Auslösen der Phasen, das
Datenpanel neben der Spur, die Darstellung paralleler Werkzeugaufrufe sowie das
Streaming und Rendern innerhalb einer einzelnen Phasenkarte. Ein Schlusskapitel
führt beide Teile der Reihe zusammen.
Wie schon im ersten Teil wird allgemeine Vertrautheit mit Vaadin vorausgesetzt;
besondere Elemente werden in ihrer Wirkung ausführlich dargestellt. Die technische
Grundlage entspricht der des ersten Teils: JDK 26, Vaadin Flow 25.1.6 mit
eingebettetem Jetty 12.1.10 und Jackson zur JSON-Verarbeitung, ohne Spring und ohne
Jakarta EE. Beide Ansichten beruhen auf derselben Protokolllogik und unterscheiden
sich allein in ihrem Antrieb und in ihrer Darstellung — eine Tatsache, die das
folgende Kapitel zum Ausgangspunkt nimmt.
Vom automatischen Loop zur angehaltenen Pipeline
Die Schritt-für-Schritt-Ansicht und die Hauptansicht zeigen denselben Vorgang.
Das ist keine Behauptung, sondern eine architektonische Tatsache, und sie ist die
Voraussetzung für alles, was dieser Teil noch behandelt. Die Hauptansicht treibt
die Werkzeugschleife automatisch: Sie ruft das Modell auf, führt die angeforderten
Werkzeuge aus, fügt deren Ergebnisse dem Dialog hinzu und ruft das Modell erneut
auf, bis keine weiteren Werkzeuge mehr verlangt werden. Die Vorführansicht muss
genau diese Schleife anhalten und in einzeln auslösbare Schritte zerlegen — ohne
dass die Protokolllogik dabei verdoppelt wird. Würde sie verdoppelt, so zeigten die
beiden Ansichten womöglich zwei verschiedene Abläufe; der didaktische Wert der
Vorführung beruht aber darauf, dass sie denselben Ablauf zeigt, nur verlangsamt.
Die Lösung liegt in einem eigenen Träger der Protokolllogik, demWalkthroughEngine. Jede seiner Methoden führt genau eine Phase aus, verändert den
übergebenen Zustand und gibt das Ergebnis als Phasendatensatz zurück, den die
Oberfläche darstellen kann.
/** Phase 1. Build a fresh state seeded with the system + user message. */
public WalkthroughState startRun(String systemPrompt, String userMessage) {
return new WalkthroughState(systemPrompt, userMessage);
}
/** Phase 2. Fetch the MCP tool catalogue and attach it to the state. */
public WalkthroughPhase.ToolCatalog fetchToolCatalogue(WalkthroughState state) {
ArrayNode tools = toolBridge.toolsForOllama();
state.setToolsArray(tools);
List<String> names = new ArrayList<>(tools.size());
for (JsonNode tool : tools) {
String name = tool.path("function").path("name").asText(null);
if (name != null) names.add(name);
}
WalkthroughPhase.ToolCatalog phase = new WalkthroughPhase.ToolCatalog(names, tools);
state.setCurrentPhase(phase);
return phase;
}
Der entscheidende Gedanke steht im Klassenkommentar des Motors: Die Protokolllogik
liegt an einer einzigen Stelle, und lediglich der Antrieb unterscheidet sich. Der
Klassenkommentar formuliert es so: „The engine is shared by the comparison view
(driving the phases in an auto loop) and the walkthrough view (driving them one
user click at a time); the protocol logic therefore lives in a single place.“ Die
fünf Phasen sind als Methoden ausgeführt — startRun, fetchToolCatalogue,runModelQuery, executeTools und finalise —, und jede ist für sich aufrufbar.
Eben weil jede Phase eine Methode ist, kann die Vorführansicht sie einzeln auf
einen Tastendruck hin aufrufen, während die Hauptansicht sie in einer einzigen
Schleife auf einem Virtual Thread abspult.
Damit die Oberfläche jede Phase einheitlich darstellen kann, sind die
Phasenergebnisse als versiegelte Schnittstelle modelliert. Jeder Datensatz trägt
das Teilergebnis, das die Vorführansicht zeigen soll, und benennt zugleich die
Handlung, die zur folgenden Phase fortschreitet.
public sealed interface WalkthroughPhase
permits WalkthroughPhase.Initial,
WalkthroughPhase.ToolCatalog,
WalkthroughPhase.ModelQuery,
WalkthroughPhase.ToolExecution,
WalkthroughPhase.FinalAnswer {
/** Short title of the phase, shown as the card heading. */
String title();
/** Plain-English description of what just happened. */
String description();
/** Label of the button that advances to the next phase. */
String nextActionLabel();
/** True when this phase is the last one; the run is complete. */
default boolean terminal() {
return false;
}
Die versiegelte Schnittstelle benennt abschließend ihre fünf zulässigen
Ausprägungen. Jede ist als record ausgeführt und kennt drei Auskünfte: einen
Titel für die Kartenüberschrift, eine Beschreibung dessen, was gerade geschehen
ist, und die Beschriftung der Schaltfläche, die zur nächsten Phase führt. So trägt
jede Phase ihre eigene Darstellungsanweisung bei sich; die Oberfläche muss nicht
wissen, in welcher Phase sie sich befindet, sondern fragt den Datensatz nach Titel,
Beschreibung und nächster Handlung. Die letzte Phase meldet über terminal, dass
der Lauf abgeschlossen ist.
Der Ablauf der Phasen lässt sich als Zustandsautomat lesen. Die ersten beiden
Phasen treten je einmal auf; zwischen Modellanfrage und Werkzeugausführung verläuft
eine Schleife, die so lange wiederholt wird, bis das Modell keine Werkzeuge mehr
verlangt; sodann mündet der Lauf in die abschließende Antwort.
Auf eben diesem Zustandsautomaten ruhen beide Ansichten. Die Hauptansicht
durchläuft ihn selbsttätig, ohne Pause; die Vorführansicht hält an jedem Übergang
inne und überlässt dem Betrachter den nächsten Schritt. Welcher Antrieb gerade
wirkt, ist eine Eigenschaft der Ansicht, nicht des Motors.
Die Zerlegung in fortsetzbare Phasen ist damit weit mehr als eine bauliche
Bequemlichkeit. Sie ist die Gewähr dafür, dass die verlangsamte Darstellung der
Vorführansicht nicht eine nachgebaute Nachahmung des Ablaufs zeigt, sondern den
Ablauf selbst — denselben, den die Hauptansicht in einem Zug abspult. Auf dieser
Grundlage kann das folgende Kapitel zeigen, wie die einzelnen Phasen zu einer
wachsenden Spur werden.
3. Die Verarbeitungsspur als Zeitachse
Wo die Hauptansicht nur das Endergebnis zeigt, bewahrt die Vorführansicht den
gesamten Weg dorthin. Das zentrale visuelle Element, in dem dieser Weg sichtbar
wird, ist die Verarbeitungsspur: eine senkrechte Folge von Karten, die mit jeder
abgeschlossenen Phase um eine Karte wächst. Die Spur ist damit nicht nur ein
Anzeigeelement, sondern das eigentliche Protokoll des Vorgangs — ein Protokoll, das
der Betrachter im Nachhinein lesen kann, weil es bestehen bleibt, statt wie der
Strom der Hauptansicht zu verfließen.
Der Träger der Spur ist ein schlichter Container, der bei jeder Phase eine Karte
aufnimmt. Er entsteht beim Aufbau der Ansicht neben dem Datenpanel.
public WalkthroughView() {
addClassName("recipe-shell");
addClassName("recipe-walkthrough");
setSizeFull();
Div body = new Div(buildTrack(), dataPanel);
body.addClassName("recipe-body");
body.setSizeFull();
add(body);
configureControls();
}
Die linke Hälfte des Körpers bildet die Spur, die rechte das Datenpanel, dem ein
eigenes Kapitel gewidmet ist. Innerhalb der Spur sammelt ein trackContainer die
Karten. Jede Phase besitzt eine eigene Aufbaumethode, die eine Karte erzeugt und
sie an den Container anhängt. Die erste Phase, die Ausgangslage, zeigt das Muster in
seiner reinsten Form.
private void renderInitialCard(WalkthroughPhase.Initial phase, Runnable onNext) {
Div card = newCard(null, "recipe-card--initial");
Span chip = makeChip("recipe-chip--initial", VaadinIcon.FLAG_O, phase.title());
Div header = headerRow(chip);
Span subtitle = makeSubtitle(
"Conversation context, ready to be sent. Nothing has hit the model yet.");
Div result = new Div();
result.addClassName("recipe-card__result");
result.add(makeSection("System prompt", phase.systemPrompt()));
result.add(makeSection("User message", phase.userMessage()));
Div description = makeDescriptionBlock(phase.description());
card.add(header, subtitle, result, description);
trackContainer.add(card);
addNextButton(card, phase.nextActionLabel(), onNext);
}
Jede Karte folgt demselben Aufbau: eine Kopfzeile mit einem zur Phase gehörenden
Symbol und dem Titel, eine Unterzeile, ein Ergebnisbereich mit dem jeweiligen
Inhalt der Phase und eine Beschreibung dessen, was geschehen ist. Titel,
Beschreibung und die Beschriftung der nächsten Handlung stammen dabei unmittelbar
aus dem Phasendatensatz — eben jene Auskünfte, die das vorige Kapitel an der
versiegelten Schnittstelle gezeigt hat. Die Karte muss daher nicht wissen, welche
Phase sie darstellt; sie fragt den Datensatz. Am Ende fügt trackContainer.add die
Karte an die Spur an, und addNextButton versieht sie mit einer Schaltfläche, die
zur nächsten Phase führt.
Die Reihenfolge der Karten ist nicht beliebig, sondern trägt eine Bedeutung.
Untereinander gestapelte Karten bezeichnen eine sequenzielle Abhängigkeit: Die eine
Phase folgt aus der vorigen. Zwischen aufeinanderfolgenden Karten wird daher ein
rein über CSS gezogener Verbinder dargestellt — eine Linie mit einer Pfeilspitze,
die den Fluss auf einen Blick sichtbar macht. Diese Verbinder sind kein Bestandteil
des Java-Quelltexts, sondern werden im Stylesheet über die Pseudoelemente::before und ::after gezeichnet; die Karten selbst bleiben dadurch schlicht.
Die Nummerierung der Phasen spiegelt diese zeitliche Ordnung wider. Die
Ausgangslage trägt die Eins, der Werkzeugkatalog die Zwei; die Modellanfragen
tragen die Drei mit einer Unternummer je Durchlauf (3.1, 3.2 …), die
Werkzeugausführungen die Vier mit derselben Unternummer (4.1, 4.2 …), und die
abschließende Zusammenfassung die Fünf. So lässt sich an der Beschriftung jeder
Karte ablesen, an welcher Stelle des Laufs sie steht und wie oft die Schleife
zwischen Modell und Werkzeugen bereits durchlaufen wurde.
Die letzte Karte fällt aus dem Muster, denn sie zeigt keine weitere Phase des
Protokolls, sondern eine Zusammenfassung des Laufs: einige Kennzahlen — die
Gesamtdauer, die Zahl der Modelldurchläufe, die Zahl der Werkzeugaufrufe und eine
geschätzte Zahl ausgegebener Token — sowie ein kleines Balkendiagramm, das die
Dauer der einzelnen Phasen ins Verhältnis setzt. Die eigentliche Antwort wiederholt
diese Karte nicht, denn sie wurde bereits in der letzten Modellanfrage-Karte
gerendert — ein Umstand, dem das siebte Kapitel nachgeht. Mit der Verarbeitungsspur
ist damit die Bühne bereitet; das folgende Kapitel zeigt, wie der Betrachter die
einzelnen Karten zum Erscheinen bringt.
Phasen einzeln auslösen
Die Verarbeitungsspur wächst nicht von selbst. Der Betrachter bestimmt das Tempo,
indem er jede Phase einzeln auslöst — und eben dieses Interaktionsmodell ist der
Kern der Vorführansicht. Das vorige Kapitel zeigte, dass jede Karte am Ende eine
Schaltfläche erhält, deren Beschriftung die nächste Phase benennt: „Fetch tool
catalogue from MCP“, „Send initial model query“, „Execute the tool“, „Send
follow-up model query“. Ein Druck auf diese Schaltfläche ruft die zugehörige
Methode des Motors auf, deren Ergebnis als neue Karte erscheint, die ihrerseits die
Schaltfläche zur übernächsten Phase trägt. So schreitet der Lauf Schritt für
Schritt voran, jeder Schritt eine bewusste Handlung.
Die Frage, was „fortsetzbar“ in einer serverseitigen Oberfläche bedeutet, lässt
sich an dieser Stelle genau beantworten. Der Zustand des Laufs ruht zwischen zwei
Schritten in einem Feld der Ansicht — dem WalkthroughState, den der Motor bei
jedem Aufruf verändert und zurückgibt. Ein Schritt nimmt diesen Zustand auf, führt
seine Phase aus und legt das Ergebnis wieder im Zustand ab. Zwischen den Schritten
geschieht nichts; die Ansicht verharrt in einem klar erkennbaren, ruhenden Zustand
und wartet auf die nächste Handlung des Betrachters.
Da die einzelnen Phasen blockierende Aufrufe an das Modell und an die Werkzeuge
enthalten, greift auch hier das aus dem ersten Teil bekannte Aktualisierungsmodell:
Die Ausführung erfolgt auf einem Hintergrund-Thread, und das Ergebnis wird über@Push und UI.access in den Komponentenbaum eingeschleust. Zwei Marken sichern
dabei den geordneten Ablauf: phaseInFlight zeigt an, dass eine Phase gerade läuft,
und autoRunning, ob der Betrachter den automatischen Durchlauf gewählt hat.
Neben dem schrittweisen Fortschreiten bietet die Ansicht nämlich einen zweiten Weg:
die Schaltfläche „Run to End“, die die verbleibenden Phasen selbsttätig durchläuft.
Während eines solchen automatischen Laufs werden die Schaltflächen der einzelnen
Karten unterdrückt; die Karten erscheinen weiterhin, sobald ihre Phase aufgelöst
ist, doch zwischen den Phasen wird eine kurze Pause eingefügt, damit der Fortschritt
lesbar bleibt. Diese Pause beträgt 350 Millisekunden und wird über einen eigenen
Virtual Thread eingelegt.
private void scheduleAutoContinue() {
UI ui = UI.getCurrent();
Thread.startVirtualThread(() -> {
try {
Thread.sleep(AUTO_RUN_PAUSE_MS);
} catch (InterruptedException ie) {
Thread.currentThread().interrupt();
return;
}
try {
ui.access(this::continueAuto);
} catch (UIDetachedException ignored) {
}
});
}
Der Hintergrund-Thread schläft die festgelegte Pause und löst sodann überUI.access den nächsten Schritt aus. Der try-Block um ui.access fängt dieUIDetachedException ab — der Fall, dass der Betrachter die Ansicht inzwischen
verlassen hat; dann verläuft der automatische Lauf still ins Leere, statt einen
Fehler zu werfen. An welcher Stelle der automatische und der schrittweise Antrieb
auseinandertreten, zeigt der Abschluss einer Phase. Nach der Werkzeugausführung
etwa entscheidet eine einzige Verzweigung, ob es automatisch weitergeht oder ob dem
Betrachter die nächste Schaltfläche angeboten wird.
phaseInFlight = false;
if (autoRunning) {
scheduleAutoContinue();
} else {
addNextButton(card, exec.nextActionLabel(), this::advanceToModelQuery);
updateRunToEndAvailability();
}
Ist der automatische Lauf gewählt, so plant die Phase ihre Fortsetzung selbst;
andernfalls erhält die Karte eine Schaltfläche, deren Beschriftung wiederum dem
Phasendatensatz entstammt und deren Betätigung zur nächsten Phase führt. Der
Unterschied zur automatischen Schleife der Hauptansicht ist damit genau benannt:
Nicht die Mechanik der Übertragung ändert sich — sie ist in beiden Ansichten
dieselbe —, sondern allein der Auslöser. An die Stelle der selbsttätigen
Fortsetzung tritt die bewusste Handlung des Betrachters.
Eine „Reset“-Schaltfläche neben dem Eingabefeld räumt die Spur und die erfassten
Kennzahlen wieder ab, sodass ein neuer Prompt eingegeben werden kann. Damit verfügt
der Betrachter über drei Bedienhandlungen: einen Lauf beginnen, ihn schrittweise
oder selbsttätig zu Ende führen und ihn zurücksetzen. Welcher Weg gewählt wird,
ändert nichts am gezeigten Ablauf, sondern allein an seinem Tempo — und genau darin
liegt der didaktische Wert: Der Betrachter kann denselben Vorgang einmal in Ruhe
studieren und einmal im Zusammenhang ablaufen lassen. Das folgende Kapitel wendet
sich dem zweiten großen Bestandteil der Ansicht zu, dem Datenpanel.
Das Datenpanel
Neben der Verarbeitungsspur steht ein zweiter Bereich, dem dieses Kapitel gilt: das
Datenpanel. Während die Spur das zeitliche Nacheinander der Phasen festhält, zeigt
das Datenpanel den jeweils aktuellen Stand der Daten, auf die das Modell zugreift —
den Vorrat und das Ernährungsprofil. Das Verhältnis der beiden Bereiche ist das von
Verlauf und Zustand: Die Spur beantwortet die Frage, wie es zum gegenwärtigen Stand
gekommen ist; das Datenpanel beantwortet die Frage, wie dieser Stand in diesem
Augenblick aussieht.
Bemerkenswert ist, womit das Datenpanel gebaut ist. Es ist keine eigene
Komponente, sondern dieselbe Seitenleiste, die bereits die Hauptansicht verwendet —
hier lediglich unter einem anderen Namen geführt.
private final Sidebar dataPanel = new Sidebar(services.pantry(), services.profile());
Die Wiederverwendung ist kein Zufall, sondern Ausdruck desselben Grundsatzes, der
schon den ersten Teil durchzog: Der fachliche Zustand wird an genau einer Stelle
gepflegt, und beide Ansichten greifen über dieselben REST-Clients darauf zu. Was im
Seitenleiste das Werkzeug des Vorführenden; in der Vorführansicht tritt sie zusätzlich
als Anschauungsobjekt auf, das zeigt, was das Modell lesen kann.
Im Aufbau der Ansicht erscheint das Datenpanel als rechte Hälfte des Körpers, der
Spur gegenübergestellt.
Div body = new Div(buildTrack(), dataPanel);
body.addClassName("recipe-body");
body.setSizeFull();
add(body);
Die Untertitelzeile der Ansicht benennt die Aufgabe des Panels ausdrücklich: „The
data panel on the right reflects what the model can read; the track below grows one
card per step.“ Damit ist das Zusammenspiel der beiden Bereiche auf den Punkt
gebracht. Links wächst die Spur Karte um Karte und zeigt den Vorgang; rechts steht
das Datenpanel und zeigt den Gegenstand, auf den der Vorgang sich bezieht.
Das Datenpanel ist nicht starr, sondern wird im Verlauf des Laufs aufgefrischt — und
zwar an der Stelle, an der das Modell den Zustand tatsächlich verändert haben kann.
Nach der Werkzeugausführung, wenn ein zustandsänderndes Werkzeug wie das Verbrauchen
einer Zutat oder das Anpassen des Profils gelaufen ist, lädt die Ansicht das Panel
neu.
dataPanel.refreshGrid();
dataPanel.refreshProfileForm();
Eben hier zeigt sich der didaktische Gewinn der Gegenüberstellung von Verlauf und
Zustand. Der Betrachter sieht in der Spur, dass ein Werkzeug aufgerufen wurde, das
den Vorrat verändert; und er sieht im selben Augenblick im Datenpanel, wie sich der
Vorrat dadurch geändert hat. Das eine erklärt das andere: Die Werkzeugausführung in
der Spur ist die Ursache, die veränderte Anzeige im Datenpanel die Wirkung. Wo die
Hauptansicht die Auffrischung erst am Ende eines ganzen Laufs vornimmt, geschieht
sie hier nach jeder einzelnen Werkzeugausführung — passend zum verlangsamten Tempo
der Vorführung, das jede Wirkung einzeln sichtbar machen will.
So fügen sich Spur und Datenpanel zu zwei Blickwinkeln auf denselben Vorgang. Der
eine zeigt die Abfolge der Handlungen, der andere ihren Niederschlag im Zustand.
Das folgende Kapitel kehrt zur Spur zurück und betrachtet einen Fall, der eine
eigene Darstellung verlangt: die gleichzeitige Ausführung mehrerer Werkzeuge.
Parallele Werkzeugaufrufe darstellen
Verlangt das Modell in einer Antwort mehrere Werkzeuge zugleich, so stellt sich
eine doppelte Aufgabe: Die Aufrufe sind nebenläufig auszuführen, und ihre
Gleichzeitigkeit ist zugleich als solche darzustellen. Beide Seiten dieser Aufgabe
löst die Vorführansicht in einer Weise, die die technische Wirklichkeit des Motors
unmittelbar abbildet.
Die Ausführung übernimmt der Motor in seiner vierten Phase. Er öffnet einen
Ausführer mit je einem Virtual Thread pro Aufgabe, reicht für jeden Werkzeugaufruf
ein CompletableFuture ein, wartet mit allOf auf deren Abschluss und sammelt die
Ergebnisse in der ursprünglichen Reihenfolge der Anforderung ein.
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
List<CompletableFuture<WalkthroughPhase.ToolOutcome>> futures =
new ArrayList<>(calls.size());
for (WalkthroughPhase.PendingToolCall call : calls) {
futures.add(CompletableFuture.supplyAsync(
() -> invokeSafely(call), executor));
}
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
List<WalkthroughPhase.ToolOutcome> outcomes = new ArrayList<>(calls.size());
for (CompletableFuture<WalkthroughPhase.ToolOutcome> f : futures) {
outcomes.add(f.join());
}
Drei Eigenschaften dieser Ausführung verdienen Beachtung. Erstens werden die
Aufrufe wirklich gleichzeitig geführt, jeder auf einem eigenen Virtual Thread.
Zweitens werden die Ergebnisse in der Reihenfolge der Anforderung eingesammelt,
nicht in der Reihenfolge ihres Eintreffens; die Darstellung bleibt dadurch stabil,
gleich welcher Aufruf zuerst antwortet. Drittens wirft ein fehlgeschlagener Aufruf
keine Ausnahme, sondern wird über invokeSafely als Fehlerergebnis zurückgegeben,
sodass das Modell im nächsten Durchlauf darauf reagieren kann.
Der Darstellung dieser Gleichzeitigkeit liegt eine bewusste Entscheidung zugrunde:
Mehrere zugleich angeforderte Aufrufe werden nicht als getrennte, untereinander
gestapelte Karten gezeigt, sondern als nebeneinanderliegende Spuren innerhalb einer
einzigen Werkzeugausführungs-Karte, versehen mit einer Parallelmarkierung, die
nennt, wie viele nebenläufige Virtual Threads laufen. Untereinander gestapelte
Karten bezeichnen, wie das dritte Kapitel zeigte, eine sequenzielle Abhängigkeit;
nebeneinanderliegende Spuren bezeichnen die Gleichzeitigkeit. Die Form der
Darstellung trägt damit selbst eine Aussage über die Nebenläufigkeit.
Während ein Aufruf noch läuft, zeigt seine Spur den Namen des Werkzeugs, die
Argumente und einen Hinweis auf das ausstehende Ergebnis.
private Div buildLaneRunning(WalkthroughPhase.PendingToolCall c) {
Div lane = new Div();
lane.addClassName("recipe-walkthrough__lane");
lane.addClassName("recipe-walkthrough__lane--running");
Span name = new Span(c.name() + "(...)");
name.addClassName("recipe-walkthrough__tool-name");
Pre args = new Pre(prettyJson(c.argumentsJson()));
args.addClassName("recipe-walkthrough__json");
Span pending = new Span("Awaiting MCP response...");
pending.addClassName("recipe-walkthrough__pending");
lane.add(name, args, pending);
return lane;
}
Ist die Ausführung abgeschlossen, so ersetzt die Karte die laufenden Spuren durch
die aufgelösten und frischt zugleich das Datenpanel auf.
private void finishToolExecutionCard(Div card, Div description,
Div result, Div lanes,
Div progressWrap,
WalkthroughPhase.ToolExecution exec) {
result.remove(progressWrap);
card.removeClassName("running");
lanes.removeAll();
for (WalkthroughPhase.ToolOutcome oc : exec.outcomes()) {
lanes.add(buildLaneResolved(oc));
}
description.removeAll();
description.add(makeDescriptionLabel("Description"));
description.add(new Div(new Span(exec.description())));
dataPanel.refreshGrid();
dataPanel.refreshProfileForm();
Jede aufgelöste Spur zeigt den Namen des Werkzeugs, die Argumente und das
sauber formatierte Ergebnis-JSON; ein fehlerhafter Aufruf färbt seine Spur rot.
Bemerkenswert ist, dass die Auffrischung des Datenpanels genau hier geschieht — nach
der Ausführung, wenn die Werkzeuge den Zustand verändert haben könnten —, womit sich
der Bogen zum vorigen Kapitel schließt.
Die Aussage der Darstellung — sequenziell untereinander, parallel nebeneinander —
entspricht der Wirklichkeit des Motors. Die Beschreibung des Phasendatensatzes
bringt dies auf den Punkt: „The MCP server executed all N tools concurrently
(parallel virtual threads). Each lane shows arguments and result independently.“
So macht die Vorführansicht die Nebenläufigkeit zugleich wirksam und sichtbar. Sie
führt die Aufrufe wirklich gleichzeitig, und sie zeigt sie in einer Form, die diese
Gleichzeitigkeit nicht verschleiert, sondern ausstellt — ohne dabei die zeitliche
Einordnung der Aufrufe in den Gesamtablauf zu verlieren, denn alle Spuren wohnen in
ein und derselben Karte an ihrer Stelle in der Spur.
Das folgende Kapitel kehrt zu einem Detail zurück, das in der Modellanfrage-Karte
wohnt und den Bogen zum ersten Teil schließt: dem Streaming des Textes und seiner
abschließenden Darstellung als Markdown innerhalb einer einzelnen Karte.
Streaming und Markdown in der Phasenkarte
Das fünfte Kapitel des ersten Teils endete mit einem Vorausverweis. Dort wurde
gezeigt, dass die Hauptansicht den Strom unmittelbar als Markdown rendert, und
zugleich angekündigt, dass die Schritt-für-Schritt-Ansicht den umgekehrten Weg
geht: erst Rohtext, dann gerendert. Diesen Gegenentwurf löst das vorliegende Kapitel
ein. Er wohnt in der Modellanfrage-Karte, jener Karte, die einen einzelnen Aufruf an
das Modell darstellt.
Während der Strom läuft, wächst der Text in einem schlichten Bereich an. Die Karte
wird beim Aufbau mit einem solchen streamDiv, einer unbestimmten Fortschrittsleiste
und — als Besonderheit der Vorführansicht — einer Darstellung der gesendeten
Anfrage versehen. Sodann läuft auf einem Virtual Thread der Aufruf des Motors, dessen
Rückruf jedes Fragment an den Rohtextbereich anhängt.
StringBuilder buffer = new StringBuilder();
Div header = headerRow(chip);
Div description = makeDescription();
Div result = new Div(requestSection, replyLabel, progressWrap, streamDiv);
result.addClassName("recipe-card__result");
card.add(header, subtitle, result, description);
trackContainer.add(card);
java.time.Instant t0 = java.time.Instant.now();
int iterationLabel = nextIter;
Thread.startVirtualThread(() -> {
try {
WalkthroughPhase.ModelQuery query = engine.runModelQuery(state,
chunk -> ui.access(() -> {
buffer.append(chunk);
streamDiv.setText(buffer.toString());
}));
Der Rückruf hängt jedes Fragment an den Puffer an und setzt dessen Inhalt als
reinen Text auf den streamDiv. Es ist setText, nicht das Setzen von
Markdown-Inhalt: Während des Stroms erscheint die Antwort bewusst als Rohtext. Damit
ist die im ersten Teil angekündigte Zweistufigkeit in ihrer ersten Stufe sichtbar.
Bemerkenswert ist zudem die Darstellung der Anfrage, die der Karte vorausgeht: Sie
zeigt genau die Botschaften, die an das Modell gesandt wurden — System- und
Benutzernachricht sowie, in späteren Durchläufen, die vorangegangenen Antworten und
Werkzeugergebnisse —, sodass der Betrachter genau erkennt, was das Modell empfangen
hat.
Die zweite Stufe tritt ein, sobald der Strom abgeschlossen ist. Dann entscheidet
die Karte anhand der angeforderten Werkzeuge, wie sie sich abschließend darstellt.
if (query.toolCalls().isEmpty()) {
result.remove(streamDiv);
Markdown rendered = new Markdown(streamedText.isBlank() ? "_(no text)_" : streamedText);
rendered.addClassName("recipe-walkthrough__rendered");
result.add(rendered);
phaseInFlight = false;
// The streamed text is already rendered as Markdown here, so the
// dedicated "final answer" card would be redundant. Skip straight
// into the run-summary card with timing + token stats.
if (autoRunning) {
scheduleAutoContinue();
} else {
scheduleAutoSummaryAdvance();
}
} else {
if (streamedText.isBlank()) {
streamDiv.setText("(no text emitted; the model went straight to tool calls)");
streamDiv.addClassName("recipe-walkthrough__stream--empty");
}
Verlangt das Modell keine Werkzeuge, so handelt es sich um die endgültige Antwort.
Die Karte entfernt den Rohtextbereich und ersetzt ihn durch eine frisch erzeugteMarkdown-Komponente — die zweite Stufe der angekündigten Zweistufigkeit. Eben
weil die endgültige Antwort hier bereits gerendert ist, wäre eine eigene Karte für
die „endgültige Antwort“ überflüssig; der Kommentar im Quelltext sagt es
ausdrücklich. Die Ansicht schreitet daher unmittelbar zur Zusammenfassungs-Karte
fort, die das dritte Kapitel als letzte Karte der Spur beschrieben hat. Verlangt das
Modell hingegen Werkzeuge, so bleibt der Rohtext stehen — gegebenenfalls mit einem
Hinweis, falls das Modell unmittelbar zu den Werkzeugaufrufen übergegangen ist —, und
darunter erscheint eine Aufstellung der angeforderten Aufrufe.
Der Grund für diese andere Wahl gegenüber der Hauptansicht liegt, wie schon im
ersten Teil dargelegt, im anderen Zweck. Die lehrende Ansicht bevorzugt ein ruhiges,
stabiles Bild jeder Phase. Während des Stroms zeigt sie den Rohtext, der ruhig
anwächst, ohne dass sich unvollständige Auszeichnungen unter dem Blick des
Betrachters umordnen; erst nach Abschluss tritt an seine Stelle das gerenderte
Dokument. Die Phasenbeschreibung bestätigt es: „Streaming is complete and the text
is rendered as Markdown.“
flowchart TD
A["card created: requestSection + streamDiv + progress bar"] --> B["stream runs:buffer.append(chunk)streamDiv.setText(buffer) — raw text"]
B --> C{"stream complete:tool calls requested?"}
C -->|"no"| D["remove streamDivadd Markdown(streamedText) — rendered"]
C -->|"yes"| E["keep raw textappend 'Requested N tool calls' panel"]
D --> F["advance to run summary"]
E --> G["advance to tool execution"]
Damit schließt sich der Bogen, den der erste Teil gespannt hat. Die beiden Ansichten
beantworten dieselbe Gestaltungsfrage auf zwei begründete Weisen: Die Hauptansicht
rendert fortlaufend, um die Lebendigkeit des Entstehens zu zeigen; die
Vorführansicht zeigt erst Rohtext und rendert nach Abschluss, um die Ruhe des
Studierens zu wahren. Beide Wege folgen demselben Grundsatz, dass eine Oberfläche
den Zustand ihres Inhalts ehrlich abbilden sollte. Das folgende Kapitel kehrt zu
einer Karte zurück, die der Lauf früh durchschritten hat und die einer näheren
Betrachtung lohnt: der Werkzeugkatalog-Karte.
Die Werkzeugkatalog-Karte
Der Lauf durchschreitet zu Beginn eine Karte, die das vorangegangene Erzählen rasch
hinter sich gelassen hat: die Werkzeugkatalog-Karte, die zweite Phase. Sie verdient
eine nähere Betrachtung, denn sie ist mehr als eine bloße Liste. Sie macht sichtbar,
welche Werkzeuge der angebundene Server dem Modell überhaupt anbietet, und sie tut
dies in einer Form, die das bloße Aufzählen übersteigt: mit anklickbaren Abzeichen
und vollständigen JSON-Deskriptoren, zwischen denen ein sanftes Scrollen vermittelt.
Die Karte führt zwei Bereiche: eine Reihe von Abzeichen und eine Folge von
Einträgen. Jeder Eintrag stellt ein Werkzeug ausführlich dar — mit Namen,
Beschreibung und dem vollständigen JSON-Deskriptor —, während die Abzeichen als
knappe, anklickbare Sprungmarken dienen. Der Aufbau der Einträge geht aus dem
Werkzeug-Array hervor, das der Motor in der zweiten Phase beschafft hat.
Map<String, Div> entryByName = new java.util.LinkedHashMap<>();
for (JsonNode tool : phase.toolsArray()) {
String toolName = tool.path("function").path("name").asText();
if (toolName == null || toolName.isBlank()) continue;
Div entry = new Div();
entry.addClassName("recipe-walkthrough__tool-entry");
entry.getElement().setAttribute("data-tool-name", toolName);
Span entryTitle = new Span(new Icon(VaadinIcon.CODE), new Span(toolName));
entryTitle.addClassName("recipe-walkthrough__tool-entry-title");
String description = tool.path("function").path("description").asText("");
if (!description.isBlank()) {
Span entryDesc = new Span(description);
entryDesc.addClassName("recipe-walkthrough__tool-entry-desc");
entry.add(entryTitle, entryDesc);
} else {
entry.add(entryTitle);
}
Pre json = new Pre(prettyJson(tool.toString()));
json.addClassName("recipe-walkthrough__json");
entry.add(json);
entries.add(entry);
entryByName.put(toolName, entry);
}
Zweierlei verdient Beachtung. Erstens werden Name und Beschreibung unmittelbar aus
dem JSON-Knoten des Werkzeugs gelesen — über path und asText —, sodass die Karte
genau das zeigt, was der Server tatsächlich anbietet, nicht eine gepflegte
Zweitfassung. Zweitens hält eine LinkedHashMap die Zuordnung von Werkzeugnamen zu
Eintrags-Div fest und bewahrt dabei die Reihenfolge; eben diese Zuordnung
ermöglicht es den Abzeichen, gezielt zu ihrem Eintrag zu springen. Der vollständige
Deskriptor wird als nichtproportional gesetzter Pre-Block beigefügt.
Die Abzeichen entstehen in einem zweiten Durchlauf, diesmal über die Namensliste der
Phase. Findet sich zu einem Namen ein Eintrag, so wird das Abzeichen anklickbar
gemacht und mit den nötigen Merkmalen für Bedienbarkeit und Barrierefreiheit
versehen.
for (String name : phase.toolNames()) {
Span tag = new Span(name);
tag.addClassName("recipe-walkthrough__tool-tag");
Div target = entryByName.get(name);
if (target != null) {
tag.addClassName("recipe-walkthrough__tool-tag--clickable");
tag.getElement().setAttribute("title",
"Jump to " + name + " descriptor");
tag.getElement().setAttribute("role", "button");
tag.getElement().setAttribute("tabindex", "0");
tag.getElement().addEventListener("click",
ev -> scrollToToolEntry(target));
tag.getElement().addEventListener("keydown",
ev -> scrollToToolEntry(target))
.setFilter("event.key === 'Enter' || event.key === ' '");
}
tags.add(tag);
}
Hier zeigt sich, wie viel sich mit den Bordmitteln von Vaadin Flow am Element selbst
regeln lässt. Das Abzeichen erhält über setAttribute die Rolle einer Schaltfläche,
einen Tooltip und einen Tabulatorindex, sodass es nicht nur mit der Maus, sondern
auch mit der Tastatur erreichbar ist. An das Element werden zwei Lauscher gehängt —
einer für den Mausklick, einer für die Tastatur —, wobei der Tastaturlauscher übersetFilter auf die Eingabe- und die Leertaste eingeschränkt wird. Dieser Filter ist
bemerkenswert: Er ist ein clientseitiger Ausdruck, der schon im Browser entscheidet,
ob das Ereignis überhaupt an den Server gemeldet wird; unnötige Serverrunden
unterbleiben so.
Das eigentliche Springen besorgt eine kleine Methode, die clientseitiges Verhalten
über executeJs anstößt.
private void scrollToToolEntry(Div target) {
target.getElement().executeJs(
"this.scrollIntoView({behavior:'smooth', block:'start'});"
+ "this.classList.add('recipe-walkthrough__tool-entry--flash');"
+ "setTimeout(() => "
+ "this.classList.remove('recipe-walkthrough__tool-entry--flash'),"
+ " 1500);");
}
Der übergebene JavaScript-Ausdruck lässt den Zieleintrag sanft in den sichtbaren
Bereich rollen und fügt ihm sodann für anderthalb Sekunden eine Stilklasse hinzu,
die ihn kurz aufleuchten lässt, bevor sie wieder entfernt wird. So findet der
Betrachter nach einem Klick auf ein Abzeichen den zugehörigen Deskriptor nicht nur
wieder, sondern sein Blick wird durch das Aufleuchten unmittelbar dorthin geführt.
Dass this innerhalb des Ausdrucks auf das Zielelement verweist, ist die Brücke
zwischen der serverseitigen Komponente und ihrer clientseitigen Entsprechung.
So fügt sich die Katalogkarte aus drei einfachen Mitteln: dem Lesen des realen
Werkzeug-Arrays, der Verknüpfung von Abzeichen und Eintrag über eine geordnete
Zuordnung und einem schmalen Stück clientseitigen Verhaltens für das Springen und
Aufleuchten. Eine Diagrammbibliothek oder ein zusätzliches Rahmenwerk ist dafür
nicht nötig; das Element und seine Methoden genügen.
Das folgende Kapitel wendet sich der letzten Karte des Laufs zu, die ebenfalls von
Hand gefügt ist und kein zugekauftes Diagramm verwendet: der Zusammenfassungskarte.
Die Zusammenfassungskarte
Die letzte Karte des Laufs zeigt keine weitere Phase des Protokolls, sondern eine
Bilanz: einige Kennzahlen und ein Balkendiagramm, das die Dauer der einzelnen Phasen
ins Verhältnis setzt. Das dritte Kapitel hat sie bereits als Abschluss der Spur
erwähnt; hier sei sie ausführlich betrachtet, denn sie ist reine, von Hand gefügte
Vaadin-Komposition — ohne Diagrammbibliothek, allein aus elementaren Komponenten und
proportional gesetzten Breiten.
Die Karte selbst ist schlicht aufgebaut. Sie reiht eine Reihe von Kennzahlenkacheln
und ein Balkendiagramm aneinander; die eigentliche Antwort wiederholt sie nicht, da
diese bereits in der letzten Modellanfrage-Karte gerendert wurde.
private void renderFinalAnswerCard(WalkthroughPhase.FinalAnswer phase) {
Div card = newCard(null, "recipe-card--final");
Span chip = makeChip("recipe-chip--final", VaadinIcon.CHART_LINE,
"5. Run summary");
Div header = headerRow(chip);
Span subtitle = makeSubtitle(
"Timing and approximate token usage per phase. Token counts are "
+ "estimated as streamed-chars / 4.");
Div result = new Div();
result.addClassName("recipe-card__result");
result.add(buildSummaryTiles(phase));
result.add(buildPhaseChart());
Div description = makeDescriptionBlock(phase.description());
card.add(header, subtitle, result, description);
trackContainer.add(card);
}
Die Kennzahlen entstehen aus den Statistikwerten, die während des Laufs Phase für
Phase erfasst wurden. Jede abgeschlossene Phase hat einen PhaseStat-Datensatz
hinterlassen — mit Bezeichnung, Farbklasse, Dauer und einer Größenangabe samt
Einheit, etwa der Zahl der Werkzeuge oder der Zeichenzahl des Stroms. Aus diesen
Werten summiert die Karte die Gesamtdauer, die Zahl der Werkzeugaufrufe und die
Gesamtzahl der gestreamten Zeichen.
private Div buildSummaryTiles(WalkthroughPhase.FinalAnswer phase) {
long totalChars = 0;
long totalDurationMs = 0;
int toolCalls = 0;
for (PhaseStat s : phaseStats) {
totalDurationMs += s.duration().toMillis();
if ("chars".equals(s.sizeLabel())) totalChars += s.sizeValue();
if ("tool".equals(s.sizeLabel()) || "tools".equals(s.sizeLabel())) {
toolCalls += (int) s.sizeValue();
}
}
long wallClockMs = runStartedAt == null ? totalDurationMs
: java.time.Duration.between(runStartedAt, java.time.Instant.now()).toMillis();
long approxTokens = totalChars / 4;
Div tiles = new Div();
tiles.addClassName("recipe-walkthrough__summary-tiles");
tiles.add(buildTile(VaadinIcon.CLOCK,
formatMillis(wallClockMs), "Total time"));
tiles.add(buildTile(VaadinIcon.REFRESH,
Integer.toString(phase.iterations()), "Model iterations"));
tiles.add(buildTile(VaadinIcon.COGS,
Integer.toString(toolCalls), "Tool calls"));
tiles.add(buildTile(VaadinIcon.FILE_TEXT_O,
"≈ " + approxTokens, "Output tokens (~chars/4)"));
return tiles;
}
Zwei Feinheiten verdienen Beachtung. Die Gesamtdauer wird, wenn der Startzeitpunkt
bekannt ist, als tatsächlich verstrichene Wanduhrzeit zwischen Beginn und Gegenwart
gemessen, nicht als bloße Summe der Phasendauern; Pausen zwischen den Schritten
gehen so in die ausgewiesene Gesamtzeit ein. Und die Zahl der ausgegebenen Token
wird nicht gemessen, sondern aus der Zeichenzahl geschätzt — als Zeichenzahl geteilt
durch vier —, weshalb die Kachel das Ungefähr-Zeichen trägt. Es ist eine bewusst
grobe Näherung, die dem Betrachter eine Größenordnung gibt, ohne mehr zu
versprechen, als sie halten kann.
Jede einzelne Kachel ist ein kleiner, immer gleicher Baustein aus Symbol, Wert und
Beschriftung.
private Div buildTile(VaadinIcon icon, String value, String label) {
Div tile = new Div();
tile.addClassName("recipe-walkthrough__tile");
Icon i = new Icon(icon);
i.addClassName("recipe-walkthrough__tile-icon");
Span valueSpan = new Span(value);
valueSpan.addClassName("recipe-walkthrough__tile-value");
Span labelSpan = new Span(label);
labelSpan.addClassName("recipe-walkthrough__tile-label");
tile.add(i, valueSpan, labelSpan);
return tile;
}
Das Balkendiagramm ist der lehrreichste Teil der Karte, denn es zeigt, wie sich ein
brauchbares Diagramm ohne jede Diagrammbibliothek allein mit den Mitteln der
Plattform zeichnen lässt. Zunächst wird der größte Dauerwert ermittelt, der als
Bezugsgröße für die Skalierung dient; sodann erhält jede Phase eine Zeile.
private Div buildPhaseChart() {
Div chart = new Div();
chart.addClassName("recipe-walkthrough__chart");
Span chartTitle = makeSectionLabel(VaadinIcon.BAR_CHART_H,
"Per-phase duration");
chart.add(chartTitle);
long maxMs = 1;
for (PhaseStat s : phaseStats) {
maxMs = Math.max(maxMs, s.duration().toMillis());
}
for (PhaseStat s : phaseStats) {
chart.add(buildChartRow(s, maxMs));
}
return chart;
}
Der Kern liegt in der einzelnen Zeile. Aus der Dauer der Phase und dem zuvor
ermittelten Größtwert wird ein Prozentwert berechnet, der unmittelbar als Breite des
Balkens gesetzt wird. Eine Untergrenze von zwei Prozent sorgt dafür, dass auch sehr
kurze Phasen als sichtbarer Balken erscheinen und nicht ganz verschwinden.
private Div buildChartRow(PhaseStat s, long maxMs) {
Div row = new Div();
row.addClassName("recipe-walkthrough__chart-row");
Span label = new Span(s.label());
label.addClassName("recipe-walkthrough__chart-label");
long ms = s.duration().toMillis();
double pct = Math.max(2.0, (ms * 100.0) / maxMs);
Div barTrack = new Div();
barTrack.addClassName("recipe-walkthrough__chart-track");
Div bar = new Div();
bar.addClassName("recipe-walkthrough__chart-bar");
bar.addClassName("recipe-walkthrough__chart-bar--" + s.colorClass());
bar.getStyle().set("width", String.format(java.util.Locale.ROOT,
"%.1f%%", pct));
barTrack.add(bar);
Span duration = new Span(formatMillis(ms));
duration.addClassName("recipe-walkthrough__chart-duration");
Span size = new Span(s.sizeValue() + " " + s.sizeLabel());
size.addClassName("recipe-walkthrough__chart-size");
row.add(label, barTrack, duration, size);
return row;
}
Die Breite des Balkens wird über getStyle().set("width", …) als Prozentangabe
unmittelbar am Element gesetzt; die Farbe entstammt einer Stilklasse, deren Name aus
der Farbklasse der Phase gebildet wird, sodass die Balken farblich zu den Abzeichen
der Phasen passen. Neben dem Balken zeigt die Zeile die Dauer und die Größenangabe.
Die Dauer wird dabei lesbar formatiert: unterhalb einer Sekunde in Millisekunden,
darüber in Sekunden mit zwei Nachkommastellen.
private static String formatMillis(long ms) {
if (ms < 1000) return ms + " ms";
return String.format(java.util.Locale.ROOT, "%.2f s", ms / 1000.0);
}
So entsteht aus wenigen Bausteinen ein vollständiges kleines Diagramm: eine
Bezugsgröße, je Phase eine Zeile, ein in der Breite proportional gesetzter Balken
und eine ablesbare Beschriftung. Bemerkenswert ist, was hier alles nicht nötig war —
keine Diagrammbibliothek, kein Zeichnen auf einer Leinwand, kein zusätzliches
Rahmenwerk. Ein Div, dem man eine prozentuale Breite gibt, ist bereits ein Balken;
mehr braucht es nicht.
Damit sind auch die beiden Karten betrachtet, die der Lauf rasch durchschritten oder
zuletzt erreicht hat. Das folgende und letzte Kapitel zieht die Summe und führt
beide Teile der Reihe zusammen.
Schluss
Der erste Teil dieser Reihe zeigte, dass der angebundene Server einen Unterschied
bewirkt; der zweite hat gezeigt, wie dieser Unterschied zustande kommt. Damit ist
der Bogen geschlossen, den die Einleitung des ersten Teils gespannt hat — der
Übergang vom Was zum Wie. Die Schritt-für-Schritt-Ansicht hält an, was die
Hauptansicht in einem Zug abspult, und macht aus dem flüchtigen Ablauf einen
lesbaren Gegenstand.
Die tragende Einsicht dieses Teils war architektonischer Natur: Beide Ansichten
ruhen auf demselben Motor. Die Protokolllogik lebt an einer einzigen Stelle, imWalkthroughEngine, dessen fünf Phasen als einzeln aufrufbare Methoden ausgeführt
sind. Eben diese Zerlegung in fortsetzbare Phasen ist die Gewähr dafür, dass die
verlangsamte Vorführung nicht eine Nachahmung, sondern denselben Ablauf zeigt, den
die Hauptansicht selbsttätig durchläuft. Auf dieser Grundlage standen die übrigen
Kapitel: die Verarbeitungsspur, die den Vorgang Karte um Karte als Zeitachse
bewahrt; das einzelne Auslösen der Phasen, das dem Betrachter das Tempo überlässt;
das Datenpanel, das den Zustand neben den Verlauf stellt; die Darstellung paralleler
Werkzeugaufrufe, deren Form selbst die Nebenläufigkeit ausstellt; das Streaming
mit abschließendem Markdown-Rendern in der Phasenkarte, das den im ersten Teil
angekündigten Gegenentwurf einlöste; die Werkzeugkatalog-Karte, die den dem Modell
angebotenen Werkzeugen anklickbare Abzeichen und vollständige JSON-Deskriptoren
zuordnet; und schließlich die Zusammenfassungskarte, die den Lauf in Kennzahlen und
einem von Hand gezeichneten Balkendiagramm beschließt.
So verschieden die beiden Ansichten in ihrer Wirkung sind, verbindet sie derselbe
Grundsatz, der bereits den ersten Teil durchzog. Eine Oberfläche für
modellgesteuerte Werkzeugnutzung hat nicht nur Ergebnisse anzuzeigen, sondern den
Vorgang ihrer Entstehung nachvollziehbar zu halten. Die Hauptansicht erfüllt diesen
Grundsatz durch Gegenüberstellung und Gleichzeitigkeit; die Vorführansicht erfüllt
ihn durch Anhalten und Zergliederung. Beide sind unterschiedliche Antworten auf
dieselbe Forderung, und gerade ihre Verschiedenheit zeigt, dass die Forderung mehr
als eine Umsetzung zulässt.
Es bleibt der Rückblick auf die Reihe als Ganzes. Sie begann mit einem MCP-Server,
der mit den Bordmitteln des JDK gebaut war, ohne Spring und ohne Jakarta EE. Sie
setzte sich fort mit einer Oberfläche, die denselben Verzicht auf schwergewichtige
Rahmenwerke wahrt und sich auf Vaadin Flow mit eingebettetem Jetty beschränkt. Und
sie schloss mit zwei Ansichten auf denselben Vorgang, die zeigen, dass sich der
Nutzen eines angebundenen Servers nicht behaupten, sondern vorführen lässt — einmal
als Ergebnis, einmal als Prozess. Wer die Reihe von Anfang bis Ende verfolgt hat,
verfügt damit nicht nur über einen lauffähigen Demonstrator, sondern über ein
Verständnis dafür, weshalb eine sorgfältig geführte Oberfläche für die Vermittlung
modellgesteuerter Werkzeugnutzung unentbehrlich ist.
