Session State
Serverseitiger Zustand, der ueber mehrere Requests lebt.
Benutzerschnittstelle · Prio 8 · Version 4
Legacy UI / JSP / JSF / Struts
Serverseitige Masken, Session State, Validierung, Berechtigungen und fachliche Workflows fuer Sachbearbeitung.
Kurzverständnis und Systemgrenze
Eine alte JSP-, JSF- oder Struts-Oberflaeche ist nicht nur HTML mit Tabellenlayout. Sie bildet fachliche Arbeitsschritte, Rollen, Plausibilitaeten, Zwischenzustaende und Ausnahmen ab.
Viele Regeln liegen direkt in der Maske: Felder werden abhängig von Status, Rolle oder Kanal angezeigt; Validierung passiert in JavaScript, Action-Klassen, Managed Beans und Datenbankconstraints gleichzeitig.
Modernisierung sollte UI nicht 1:1 nachbauen. Besser ist, den fachlichen Workflow zu extrahieren, einen Application Service zu schaffen und danach moderne UI-Komponenten gegen stabile Use-Case-APIs zu setzen.
Daten- und Verantwortungsgrenze: Legacy UIs besitzen oft implizites Prozesswissen. Maskenreihenfolge, Pflichtfelder, Buttons, Session-Objekte und Berechtigungen zeigen, wie Sachbearbeiter wirklich arbeiten. Dieses Wissen muss vor einem Frontend-Neubau gesichert werden.
Fachliche und technische Darstellung
Wichtige Begriffe und Artefakte
Action Form
Struts-Formularobjekt fuer Requestdaten und Validierung.
Backing Bean
JSF-Komponente, die UI-Zustand und Aktionen verwaltet.
Maskenworkflow
Reihenfolge fachlicher Schritte, Berechtigungen und Zwischenentscheidungen.
Typischer Ablauf Schritt für Schritt
- Benutzer oeffnet Suchmaske und waehlt Fall aus.
- Server legt Bearbeitungskontext in Session.
- Maske zeigt Felder je Rolle, Status und Prozessschritt.
- Action/Bean validiert Eingabe und ruft EJB-Service.
- Nach Erfolg wird Status aktualisiert und naechste Maske oder Druck/Archiv angestossen.
Ausführliche Praxisbeispiele mit Code und Konfiguration
Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.
Struts Action Mapping
<action path="/approveInvoice"
type="com.example.legacy.ui.ApproveInvoiceAction"
name="approveInvoiceForm"
scope="session"
validate="true"
input="/invoice/edit.jsp">
<forward name="success" path="/invoice/approved.jsp"/>
<forward name="fourEyes" path="/invoice/review.jsp"/>
<forward name="error" path="/invoice/edit.jsp"/>
</action>
JSP mit Rollen- und Statuslogik
<c:if test="${user.hasRole('APPROVER') and invoice.status == 'READY'}">
<html:submit property="action" value="Freigeben"/>
</c:if>
<c:if test="${invoice.amount > 10000}">
<div class="warning">Vier-Augen-Pruefung erforderlich</div>
</c:if>
Moderner Application Service als Ziel
public class InvoiceApprovalUseCase {
public NextScreen approve(ApproveInvoiceCommand command, UserContext user) {
permissionPolicy.require(user, "APPROVE_INVOICE");
ApprovalDecision decision = approvalPolicy.decide(command.invoiceId(), user);
if (decision.requiresFourEyes()) {
reviewRepository.createReview(command.invoiceId(), user.id());
return NextScreen.reviewRequired(command.invoiceId());
}
invoiceService.approve(command.invoiceId(), user.id());
return NextScreen.approved(command.invoiceId());
}
}
Risiken, Fehlerbilder und Diagnose
| Aspekt | Beschreibung |
|---|---|
| Fachliches Risiko | Unklare Verantwortung fuer Sachbearbeitung fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem. |
| Technisches Risiko | JSP und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen. |
| Betriebsrisiko | Fehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert. |
| Migrationsrisiko | Neue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern. |
Typische Fallen:
- Session-Objekte enthalten fachliche Wahrheit, die bei Skalierung verloren geht.
- Validierung ist auf Client, Server und DB verteilt.
- Neue UI ruft alte Services direkt und baut Maskenlogik erneut verteilt auf.
- Berechtigungen sind in JSP-Tags versteckt statt zentral dokumentiert.
Modernisierungspfad und geeignete Entwurfsmuster
| Pattern | Einsatz in diesem System |
|---|---|
| Strangler Fig Pattern | Neue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen. |
| Anti-Corruption Layer | Altbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen. |
| Facade | Komplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln. |
| Adapter | Protokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen. |
| Golden Master Test | Bestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen. |
Empfohlene Schritte:
- Extrahiere Workflow als Zustandsmodell oder Use-Case-Service.
- Erzeuge Screenshot- und Golden-Master-Tests fuer kritische Masken.
- Isoliere UI von Fachlogik: Controller duenn, Application Service stark.
- Migriere Maske fuer Maske hinter Feature Toggle oder Strangler Route.
Analysefragen für echte Projekte
- Wer besitzt fachlich die Wahrheit fuer Sachbearbeitung?
- Welche technische Komponente ist kritisch: JSP, JSF, Struts?
- Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
- Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
- Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
- Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
- Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
- Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung
Nimm eine Legacy-Maske und dokumentiere alle sichtbaren und unsichtbaren Regeln: Feldsichtbarkeit, Pflichtfelder, Buttonlogik, Sessiondaten, Rollen, Statusuebergaenge, Serviceaufrufe und Fehlermeldungen.