PhilKa: Die Seite wurde neu angelegt: „{{DISPLAYTITLE:Stub (Softwareentwicklung)}} {{Infobox Software | Name = Stub | Kategorie = Softwareentwicklung / Verteilte Systeme | Verwandte Begriffe = Remote Procedure Call, Mock, Skeleton (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…“

2025-09-23T13:07:11Z

Die Seite wurde neu angelegt: „{{DISPLAYTITLE:Stub (Softwareentwicklung)}} {{Infobox Software | Name = Stub | Kategorie = Softwareentwicklung / Verteilte Systeme | Verwandte Begriffe = Remote Procedure Call, Mock, Skeleton (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…“

Neue Seite

{{DISPLAYTITLE:Stub (Softwareentwicklung)}}
{{Infobox Software
| Name = Stub
| Kategorie = Softwareentwicklung / Verteilte Systeme
| Verwandte Begriffe = [[Remote Procedure Call]], [[Mock]], [[Skeleton (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 ==
In [[Remote Procedure Calls]]:
* 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 ==
{| class="wikitable"
! 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:
<syntaxhighlight lang="c">
program MATH_PROG {
version MATH_VERS {
int ADD(int a, int b) = 1;
} = 1;
} = 0x20000001;
</syntaxhighlight>

== 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''

== Siehe auch ==
* [[Remote Procedure Call]]
* [[Mock (Softwareentwicklung)]]
* [[Skeleton (Softwareentwicklung)]]
* [[Marshalling (Informatik)]]

[[Kategorie:Softwareentwicklung]]
[[Kategorie:Verteiltes Rechnen]]
[[Kategorie:Middleware]]

Stub (Softwareentwicklung) - Versionsgeschichte