Modul 321 Alle Aufgaben

Aufgabe 4: Vom Monolithen zu Microservices: TrackZilla & Spring Data REST

Zielsetzung

In dieser Aufgabe vollziehen Sie den Schritt von einer monolithischen Anwendung zu einer verteilten Microservice-Architektur. Am Beispiel des Bugtrackers TrackZilla untersuchen Sie, wie bestehende Fachdomänen geschnitten werden, wie Spring Data REST (@RepositoryRestResource) Standard-Endpunkte bereitstellt und welche Hürden entstehen, wenn Entitäten über Servicegrenzen hinweg verknüpft sind.

• Zeitbedarf: 2 Lektionen
• Hilfsmittel: IntelliJ IDEA, Postman, Java 17+, Maven
• Sozialform: Einzel- oder Partnerarbeit

Material & Vorlagen

Alle benötigten Dateien finden Sie im Aufgabenordner:

• Monolith (Ausgangslage): bugtracker25-vorgabe.zip
• Microservices-Starter: bugtracker25-Ticket.zip
• Musterlösung: bugtracker25-loesung.zip
• Postman Collection: 11.1_MicroServices-SpringDataRest.postman_collection.json

Die Fachdomänen von TrackZilla

TrackZilla verwaltet Fehlerberichte und Aufgaben für Softwareanwendungen. Das System gliedert sich in drei Kernbereiche:

1. Applications: Welche Software-Applikationen werden betreut? Wer ist zuständig (Owner)?
2. Users: Welche Benutzer und Rollen existieren im System?
3. Tickets: Welche Bugs oder Aufgaben gehören zu welcher Applikation und wem sind sie zugewiesen?

Im Monolithen liegen alle Tabellen in einer einzigen relationalen Datenbank und sind über Fremdschlüssel verknüpft. In der Microservice-Variante erhält jede Domäne einen eigenen Service und eine eigene Datenhaltung.

Vorgehen

Teil 1: Projektstruktur einrichten

1. Entpacken Sie bugtracker25-Ticket.zip und öffnen Sie den Ordner in IntelliJ IDEA als Maven-Projekt.
2. Kontrollieren Sie im Maven-Toolfenster, ob alle Module erkannt wurden (bei Bedarf «Reload All Maven Projects» ausführen).
3. Öffnen Sie im Modul TicketManagement das Interface TicketRepository. Beachten Sie die Annotation @RepositoryRestResource. Für normale CRUD-Operationen existiert kein eigener @RestController.

Teil 2: Spring Data REST untersuchen

Spring Data REST nimmt ein normales Repository und stellt automatisch eine Hypermedia-API (HATEOAS / HAL) bereit.

• Beantworten Sie in Ihren Notizen: Welche HTTP-Endpunkte (GET, POST, PUT, DELETE) erzeugt @RepositoryRestResource(path = "tickets") automatisch?
• Klären Sie den Unterschied zwischen @RepositoryRestResource und einem herkömmlichen @RestController.

Teil 3: Services starten

Im Monolithen startet eine einzige main()-Methode das gesamte System. Bei Microservices besitzt jeder Service eine eigene Starterklasse.

• Ergänzen Sie im Starter-Projekt analog zu TicketManagement die beiden Module ApplicationCatalog und UserManagement (übernehmen Sie Entity und Repository aus der Monolithen-Vorlage bugtracker25-vorgabe).
• Überprüfen Sie die Ports in den jeweiligen application.properties:
  • ApplicationCatalog: Port 8081
  • TicketManagement: Port 8082
  • UserManagement: Port 8083
• Starten Sie alle drei Services in IntelliJ (über das Run-Dashboard oder das Services-Fenster).
• Prüfen Sie im Browser, ob die Endpunkte erreichbar sind:
  • http://localhost:8081/applications
  • http://localhost:8082/tickets
  • http://localhost:8083/users

Teil 4: Testen mit Postman

1. Importieren Sie die Datei 11.1_MicroServices-SpringDataRest.postman_collection.json in Postman.
2. Führen Sie die vorbereiteten Abfragen aus:
   • Paging: Was bewirkt der Parameter ?page=0&size=5?
   • Sorting: Testen Sie die Sortierung mit ?sort=name,asc.
   • HAL-Links: Untersuchen Sie den Block _links in den JSON-Antworten. Welchen Zweck erfüllen Hypermedia-Links für API-Clients?

Teil 5: Beziehungen zwischen Services (Complex Relations)

Im Monolithen lässt sich in Java direkt ticket.getApplication().getOwner().getName() aufrufen, da die relationale Datenbank die Tabellen über JOINs verbindet.

Bei getrennten Services funktioniert dieser direkte Zugriff nicht mehr:

• ApplicationCatalog speichert lediglich eine owner_id, hat aber keinen Zugriff auf die Tabellen von UserManagement.

• Öffnen Sie ApplicationController.java im Modul ApplicationCatalog3.
• Analysieren Sie, wie der Controller die zusätzlichen Benutzerdaten (ownerName, ownerRole) auflöst.
• Experiment: Stoppen Sie das Modul UserManagement und rufen Sie erneut eine Applikation über ApplicationCatalog auf. Notieren Sie das beobachtete Verhalten und die Fehlerantwort.

Hinweise zur Fehlerbehebung

• Port belegt: Lässt sich ein Service wegen eines belegten Ports nicht starten, prüfen Sie im Terminal mit lsof -i :8081 und beenden Sie verbleibende Java-Prozesse.
• 404 auf Endpunkten: Spring Data REST pluralisiert Entitätsnamen nach englischen Sprachregeln (oder gemäss dem path-Attribut in @RepositoryRestResource). Kontrollieren Sie die Pfadangabe auf dem Interface.
• Lokale H2-Datenbank: Jeder Service verwendet standardmässig eine eigene In-Memory H2-Datenbank. Daten werden bei jedem Neustart neu geladen.