Stub (Softwareentwicklung)
Einführung
Ein Stub (deutsch sinngemäß „Platzhalter“ oder „Stummel“) ist ein Softwaremodul, das in der Softwareentwicklung oder in verteilten Systemen als Stellvertreter für eine andere Komponente fungiert. Stubs werden verwendet, um eine Funktionalität nachzubilden, die (noch) nicht vorhanden ist, oder um entfernte Aufrufe zu kapseln.
Stubs sind in mehreren Bereichen verbreitet:
- In der Test- und Entwicklungsphase als Platzhalter für Module.
- In verteilten Systemen zur Kapselung entfernter Funktionsaufrufe (Remote Procedure Calls, RPC).
- In der Schnittstellenentwicklung zur Isolierung einzelner Komponenten.
Grundprinzip
Ein Stub übernimmt Aufgaben für ein nicht vorhandenes oder entferntes Modul:
- Er nimmt Funktionsaufrufe entgegen.
- Er bereitet Daten ggf. auf (Marshalling).
- Er leitet sie an ein Zielmodul oder einen Server weiter oder simuliert eine Antwort.
Auf diese Weise können Entwickler unabhängig voneinander Komponenten entwickeln und testen.
Einsatz in verteilten Systemen
In verteilten Systemen wird zwischen Client-Stubs und Server-Stubs (oft auch Skeletons genannt) unterschieden:
- Client-Stub – nimmt lokale Funktionsaufrufe entgegen, serialisiert Parameter (Marshalling) und sendet sie an den Server.
- Server-Stub (oder Skeleton) – empfängt die Daten, deserialisiert sie (Unmarshalling) und ruft die entsprechende Serverfunktion auf.
Dieses Muster abstrahiert die Netzwerkdetails und lässt entfernte Aufrufe wie lokale Funktionsaufrufe erscheinen.
Beispiel mit RPC
- Die Schnittstelle wird in einer IDL (Interface Definition Language) beschrieben.
- Ein Compiler (z. B. `rpcgen` bei ONC RPC) generiert automatisch Stubs.
- Entwickler schreiben dann nur noch die Geschäftslogik; Netzwerkdetails übernimmt der Stub.
Stubs vs. Mocks vs. Skeletons
| Begriff | Beschreibung | Typischer Einsatz |
|---|---|---|
| Stub | Einfacher Platzhalter oder Vermittler für eine Funktion/Methode | Frühe Entwicklung, RPC |
| Mock | Simuliert Verhalten mit vorgegebenen Antworten und Überprüfung von Aufrufen | Unit Tests |
| Skeleton | Gegenstück zum Client-Stub auf der Serverseite | RPC-Server |
Vorteile
- Ermöglicht parallele Entwicklung: Ein Team kann Stubs nutzen, während ein anderes Team das echte Modul entwickelt.
- Abstrahiert Netzwerk- und Implementierungsdetails.
- Vereinfachung von Tests und Integration.
Nachteile
- Stubs müssen konsistent mit der endgültigen Implementierung gehalten werden.
- Zusätzlicher Code-Generierungs- und Pflegeaufwand.
- Gefahr falscher Annahmen über Laufzeit- oder Fehlerverhalten.
Schnittstellendefinition
Stubs basieren oft auf klar definierten Schnittstellen:
- Interface Definition Language (IDL) – definiert Funktionen, Parameter und Datentypen.
- Automatische Stub-Generierung durch Compiler/Tools.
- Plattform- und sprachübergreifende Nutzung möglich.
Beispiel in RPCL für ONC RPC:
program MATH_PROG {
version MATH_VERS {
int ADD(int a, int b) = 1;
} = 1;
} = 0x20000001;
Sicherheitsaspekte
Stubs selbst führen keine Sicherheitsprüfungen durch, sie können jedoch:
- Authentifizierungs- oder Autorisierungsinformationen weiterleiten.
- Eingaben validieren, bevor sie an entfernte Systeme gesendet werden.
- Transportverschlüsselung (z. B. TLS) nutzen, um Daten abzusichern.
Literatur
- Andrew S. Tanenbaum: Verteilte Systeme – Prinzipien und Paradigmen
- W. Richard Stevens: UNIX Network Programming
- RFC 5531 – RPC: Remote Procedure Call Protocol Specification Version 2