Modul 29 · Migration Deep Dive · Stufe 5 Enterprise Runtime

Service Registry und ServiceLoader

dynamische Service Registry wird nachvollziehbar in Java SPI mit ServiceLoader überführt. Die Akte zeigt nicht nur das Ziel, sondern die tatsächlichen Dateien, APIs, Dependencies, Codebelege, Tests, Risiken und Cutover-Schritte.

Service RegistryService Provider Interface

2 → 3Produktionsdateien

25 → 23Java-Zeilen

1 → 1Testdateien

0 / 0Dependencies entfernt / neu

NIEDRIGRisiko · Score 3

Was sich konkret ändert

Dimension	Legacy	Modern	Migrationskonsequenz
Programmiermodell	imperativ / ohne Framework-Annotationen	explizite Java-Abstraktionen	Annotationen und Containerfunktionen werden nur dort eingesetzt, wo sie eine konkrete technische Verantwortung übernehmen.
Abhängigkeiten	1 direkte Dependencies	1 direkte Dependencies	0 neu, 0 entfernt; Versionen und transitive Auswirkungen im erfolgreichen Online-Build prüfen.
Öffentliche API	3 erkannte Methoden	2 erkannte Methoden	Methoden werden nach fachlicher Rolle gemappt; reine Bootstrap- und Framework-Methoden sind kein fachlicher Vertrag.
Datenmodell	class ServiceRegistry, interface PaymentService	class DefaultPaymentProvider, class PaymentProviders, interface PaymentProvider	Feldnamen, IDs, Null-Semantik, Gleichheit und Serialisierungsform werden separat regressionstestet.
Fehlerverhalten	Legacy-Exceptions und Rückgabewerte	explizitere Fach-/Framework-Fehlerabbildung	Fehler dürfen nicht nur technisch übersetzt werden; Status, Ursache, Retrybarkeit und Client-Vertrag müssen erhalten oder versioniert werden.
Tests	Bestands- und Golden-Master-Tests	Unit-, Slice-, Contract- und Integrationstests	Der Modern-Pfad wird zuerst gegen denselben fachlichen Vektor geprüft und danach um neue technische Risiken ergänzt.
Betrieb	Legacy-Start/Lifecycle	modernes Packaging, Health und externe Konfiguration	Module Path/JAR-Inhalt und Service Discovery im finalen Artefakt testen.
Rollback	Legacy-Artefakt bleibt unverändert	Modern-Artefakt getrennt deploybar	Kein Rollback über Datenverlust: Schema, Nachrichten und verschlüsselte Daten müssen rückwärtslesbar oder durch Dual-Read abgesichert sein.

Fachlicher Vertrag: unverändert zu erhalten

PaymentProvider-SPI ist klein, stabil und implementation-neutral.
Provider-Auswahl bei mehreren Implementierungen ist deterministisch.
Dynamische OSGi-Lifecycle-Semantik wird nicht fälschlich als ServiceLoader-Eigenschaft angenommen.

Hauptrisiko und Testfokus

provider discovery, ordering and duplicates

no provider, multiple provider and packaging tests

Die Modernisierung gilt erst als abgeschlossen, wenn der fachliche Vertrag automatisiert belegt ist.

Verbindliches Code- und Rollenmapping

Die Zuordnung ist semantisch: Eine Legacy-Klasse kann in mehrere moderne Rollen zerlegt werden.

Legacy-Rolle / Datei	Modern-Rolle / Datei	Bedeutung
ServiceRegistry.java + PaymentService.java	PaymentProviders.java + PaymentProvider.java	Registry wird Java-SPI-Resolver.
registrierte Implementierung	DefaultPaymentProvider.java + META-INF/services	Provider wird über ServiceLoader paketiert.

Legacy-Quellinventar

Datei	Typ	Annotationen	öffentliche API	Pattern	Zeilen
PaymentService.java	interface PaymentService	—	—	—	5
ServiceRegistry.java	class ServiceRegistry	—	void register(Class<T> type, T service) void unregister(Class<?> type) Optional<T> find(Class<T> type)	Service Registry	20

Modern-Quellinventar

Datei	Typ	Annotationen	öffentliche API	Pattern	Zeilen
DefaultPaymentProvider.java	class DefaultPaymentProvider	—	String pay(int cents)	—	7
PaymentProvider.java	interface PaymentProvider	—	—	Service Provider Interface	7
PaymentProviders.java	class PaymentProviders	—	PaymentProvider first()	—	9

Dependency- und Laufzeitmigration

Status	Dependency	Version	Scope	Prüfung
BEIBEHALTEN	org.junit.jupiter:junit-jupiter	BOM/Parent → BOM/Parent	test → test	Gemeinsame Dependency; Version und Scope im effektiven POM prüfen.

Direkte POM-Daten ersetzen keinen erfolgreichen Online-Build mit transitiver SBOM- und CVE-Prüfung.

Vorher-/Nachher-Codebelege

Die folgenden Ausschnitte stammen direkt aus den enthaltenen Projekten. Dadurch ist sichtbar, welche Verantwortung tatsächlich verschoben wurde.

Legacy
ServiceRegistry.java + PaymentService.java

→

Modern
PaymentProviders.java + PaymentProvider.java

Migrationsbedeutung: Registry wird Java-SPI-Resolver.

Legacy-Code

projects/29-osgi-service-registry/legacy/src/main/java/at/aydin/lab/osgi/legacy/ServiceRegistry.java

package at.aydin.lab.osgi.legacy;

import java.util.*;

// Design Pattern: Service Registry
// Zweck: Dienste können dynamisch registriert, ersetzt und entfernt werden.
public final class ServiceRegistry {
    private final Map<Class<?>, Object> services = new HashMap<>();
    public <T> void register(Class<T> type, T service) {
        services.put(type, service);
    }

    public void unregister(Class<?> type) {
        services.remove(type);
    }

    public <T> Optional<T> find(Class<T> type) {
        return Optional.ofNullable(type.cast(services.get(type)));
    }
}

Legacy-Code

projects/29-osgi-service-registry/legacy/src/main/java/at/aydin/lab/osgi/legacy/PaymentService.java

package at.aydin.lab.osgi.legacy;

public interface PaymentService {
    String pay(int cents);
}

Modern-Code

projects/29-osgi-service-registry/modern/src/main/java/at/aydin/lab/osgi/modern/PaymentProviders.java

package at.aydin.lab.osgi.modern;

import java.util.*;

public final class PaymentProviders {
    public PaymentProvider first() {
        return ServiceLoader.load(PaymentProvider.class).findFirst().orElseThrow();
    }
}

Modern-Code

projects/29-osgi-service-registry/modern/src/main/java/at/aydin/lab/osgi/modern/PaymentProvider.java

package at.aydin.lab.osgi.modern;

// Design Pattern: Service Provider Interface
// Zweck: Provider werden ohne zentrale Registry über Standard-Java-Metadaten entdeckt.
public interface PaymentProvider {
    String pay(int cents);
}

Legacy
registrierte Implementierung

→

Modern
DefaultPaymentProvider.java + META-INF/services

Migrationsbedeutung: Provider wird über ServiceLoader paketiert.

Legacy-Code

projects/29-osgi-service-registry/legacy/src/main/java/at/aydin/lab/osgi/legacy/ServiceRegistry.java

package at.aydin.lab.osgi.legacy;

import java.util.*;

// Design Pattern: Service Registry
// Zweck: Dienste können dynamisch registriert, ersetzt und entfernt werden.
public final class ServiceRegistry {
    private final Map<Class<?>, Object> services = new HashMap<>();
    public <T> void register(Class<T> type, T service) {
        services.put(type, service);
    }

    public void unregister(Class<?> type) {
        services.remove(type);
    }

    public <T> Optional<T> find(Class<T> type) {
        return Optional.ofNullable(type.cast(services.get(type)));
    }
}

Modern-Code

projects/29-osgi-service-registry/modern/src/main/java/at/aydin/lab/osgi/modern/DefaultPaymentProvider.java

package at.aydin.lab.osgi.modern;

public final class DefaultPaymentProvider implements PaymentProvider {
    public String pay(int cents) {
        return "PAID " + cents;
    }
}

Technischen Unified Diff öffnen

--- ServiceRegistry.java
+++ DefaultPaymentProvider.java
@@ -1,20 +1,7 @@
-package at.aydin.lab.osgi.legacy;
+package at.aydin.lab.osgi.modern;
 
-import java.util.*;
-
-// Design Pattern: Service Registry
-// Zweck: Dienste können dynamisch registriert, ersetzt und entfernt werden.
-public final class ServiceRegistry {
-    private final Map<Class<?>, Object> services = new HashMap<>();
-    public <T> void register(Class<T> type, T service) {
-        services.put(type, service);
-    }
-
-    public void unregister(Class<?> type) {
-        services.remove(type);
-    }
-
-    public <T> Optional<T> find(Class<T> type) {
-        return Optional.ofNullable(type.cast(services.get(type)));
+public final class DefaultPaymentProvider implements PaymentProvider {
+    public String pay(int cents) {
+        return "PAID " + cents;
     }
 }

Umsetzungsplan mit Qualitäts-Gates

Arbeitspaket 1
Benötigte Registry-Funktionen und echte Dynamik-Anforderungen klären. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.
Arbeitspaket 2
PaymentProvider als Java-SPI definieren. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.
Arbeitspaket 3
META-INF/services korrekt paketieren. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.
Arbeitspaket 4
PaymentProviders mit Auswahl-/Fehlerregeln implementieren. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.
Arbeitspaket 5
No-/Multi-provider- und Packaging-Tests ausführen. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.
Arbeitspaket 6
Legacy Registry nur entfernen, wenn keine dynamische Nachinstallation benötigt wird. Nachweis: Commit/PR, automatisierter Test und aktualisierte Betriebsdokumentation.

Konkreter Test- und Abnahmekatalog

ID	Ebene	Prüfung	erforderlicher Nachweis
29-OSGI-SERVICE-REGISTRY-A01	Integration/Contract	Provider wird im gebauten JAR gefunden.	Automatisierter Test und CI-Protokoll
29-OSGI-SERVICE-REGISTRY-A02	Integration/Contract	Kein Provider liefert verständlichen Fehler.	Automatisierter Test und CI-Protokoll
29-OSGI-SERVICE-REGISTRY-A03	Integration/Contract	Mehrere Provider folgen dokumentierter Priorität.	Automatisierter Test und CI-Protokoll
29-OSGI-SERVICE-REGISTRY-A04	Integration/Contract	SPI enthält keine Implementierungsdetails.	Automatisierter Test und CI-Protokoll
29-OSGI-SERVICE-REGISTRY-A05	Integration/Contract	Grenze zu echtem OSGi ist in Architektur dokumentiert.	Automatisierter Test und CI-Protokoll
29-OSGI-SERVICE-REGISTRY-T01	Unit	Fachlogik ohne Container oder externen Dienst testen.	Unit-Test
29-OSGI-SERVICE-REGISTRY-T02	Regression	Legacy- und Modern-Ergebnis für denselben Golden-Master-Vektor vergleichen.	Vergleichsreport
29-OSGI-SERVICE-REGISTRY-T03	Negative	Fehlerhafte, leere und grenzwertige Eingaben prüfen.	Negativtest
29-OSGI-SERVICE-REGISTRY-T04	Operations	Start, Health, Shutdown und Konfigurationsfehler prüfen.	Deployment-/Startprotokoll
29-OSGI-SERVICE-REGISTRY-T05	Packaging	Module Path, JAR-Inhalt und Service Discovery aus finalem Artefakt prüfen.	Packaging-Smoke-Test
29-OSGI-SERVICE-REGISTRY-F01	Fokus	no provider, multiple provider and packaging tests	Modulspezifischer Testreport

Risikoregister des Moduls

Risiko	Auswirkung	Gegenmaßnahme	Gate
provider discovery, ordering and duplicates	NIEDRIG	no provider, multiple provider and packaging tests	vor Cutover

Konfiguration und Ressourcen

Seite	Ressource	Zeilen
Modern	modern/src/main/resources/META-INF/services/at.aydin.lab.osgi.modern.PaymentProvider	1

Rollback und Koexistenz

ServiceRegistry kann als alternativer ProviderResolver hinter derselben SPI bestehen bleiben, falls dynamische Registrierung noch benötigt wird.

Abbruchkriterien

Fachlicher Golden-Master weicht ab.
Daten-, Nachrichten- oder API-Kompatibilität ist ungeklärt.
Fehlerquote, Latenz oder Ressourcenverbrauch überschreiten das vereinbarte Limit.
Monitoring oder Rückfallpfad ist nicht funktionsfähig.

Definition of Done

Provider wird im gebauten JAR gefunden.
Kein Provider liefert verständlichen Fehler.
Mehrere Provider folgen dokumentierter Priorität.
SPI enthält keine Implementierungsdetails.
Grenze zu echtem OSGi ist in Architektur dokumentiert.
Alle oben genannten Test-IDs besitzen einen automatisierten oder begründet manuellen Nachweis.
SBOM, Dependency- und CVE-Prüfung wurden mit erreichbaren Repositories ausgeführt.
Cutover und Rollback wurden in einer produktionsnahen Umgebung geprobt.
Quellcode, Konfiguration, Runbook und Architektur-/Pattern-Dokumentation sind synchron.

Direkte Arbeitslinks

CodevergleichModulauditModul-POM Matrix