Context Card
Wie die vier SDK-Typen zusammenwirken
Wo treffen Developer-, Publishing-, Plattform- und Hardware-SDKs in der Praxis aufeinander?
Die kurze Antwort
Die vier SDK-Typen dienen verschiedenen Domänen, treffen sich aber an gemeinsamen Schnittstellen. Ein mit einem Hardware-SDK gebautes Gerät meldet Daten an einen Cloud-Dienst, der über ein Developer-SDK genutzt wird; eine Plattform-Erweiterung zeigt diese Daten in einer Geschäftsanwendung; eine Publishing-Pipeline übernimmt Schnittstellenbeschreibungen und Produktdaten in die Dokumentation. Das Zusammenspiel gelingt, wenn jede Grenze einen ausdrücklichen Vertrag, ein gemeinsames Datenformat, Versionierung und gemeinsame Kennungen hat.
Für: Architekten, Entwickler und Technische Redakteure an der Schnittstelle von Software, Content und Geräten
Das Wichtigste
- Hardware- zu Developer-SDK: Geräte senden Telemetrie über Gateways an Cloud-APIs.
- Developer- zu Plattform-SDK: Erweiterungen rufen externe Dienste mit eigenen Zugangsdaten und Berechtigungen auf.
- Jedes SDK zu Publishing-SDK: Referenzdokumentation wird aus Schnittstellenbeschreibungen und Code-Kommentaren generiert.
- Gemeinsame Formate (JSON, Schemas), Kennungen und Versionsnummern tragen Bedeutung über die Grenzen.
- Nachvollziehbarkeit – Tracing, Logs, eine SBOM – zeigt, welche Komponenten in einem Release zusammengewirkt haben.
Der Zusammenhang
Vier Domänen, gemeinsame Grenzen
Die SDK-Typen unterscheiden sich in Ziel und Steuerungsrichtung, aber ihre Ergebnisse speisen einander. Ein digitaler Zwilling einer Maschine kann auf Daten aus der Gerätefirmware beruhen, die über ein IoT-Gateway an einen Cloud-Dienst gehen, in einer Geschäftsanwendung angezeigt und in einem Dokumentationsportal beschrieben werden.
Was das Zusammenspiel trägt
- Ein ausdrücklicher Schnittstellenvertrag an jeder Grenze.
- Ein gemeinsames Serialisierungsformat wie JSON, mit Schemas.
- Stabile Kennungen für Geräte, Produkte und Dokumente.
- Versionierung, damit eine Änderung auf der einen Seite auf der anderen sichtbar wird.
Interoperabilität auf Formatebene reicht allein nicht; die Beteiligten müssen sich auch über die Bedeutung einig sein.
Durchgängig sichtbar
Distributed Tracing und andere Signale der Observability verfolgen eine Anfrage über Dienste hinweg. Eine Software-Stückliste hält fest, welche SDK-Versionen ein Release enthält.
Siehe den Abschnitt zum Zusammenwirken im Themenbereich Software development kits (auf Englisch).
Fragen, die sich daran anschließen
- Brauchen die vier SDK-Typen einen gemeinsamen Standard?
- Kein einzelner Standard deckt alle vier ab. Sie wirken über die Schnittstellen und Formate zusammen, die jede Grenze festlegt – APIs, Schemas, Manifeste, Gerätebeschreibungen.
- Warum sollte ein Publishing-SDK mit einem Hardware-SDK zu tun haben?
- Gerätedokumentation entsteht oft teilweise aus denselben Quellen wie die Firmware – Registerkarten, Schnittstellenbeschreibungen, Parameterlisten –, also teilen sich die Pipelines Daten.
Quellen
- OpenTelemetry documentation — OpenTelemetry
- SAP Cloud SDK — SAP
Prüfprotokoll und Änderungen
Jede Context Card wird vor der Veröffentlichung und bei jeder Änderung erneut anhand ihrer Quellen geprüft; das Datum unter der Autorenzeile ist die letzte Prüfung. Korrekturen (etwas war falsch) und Ergänzungen (etwas fehlte) stehen unten mit Datum und Uhrzeit (deutsche Zeit). Tippfehler, Formatierung und Link-Korrekturen werden nicht aufgeführt.
Geprüft
Seit der Veröffentlichung keine Korrekturen oder Ergänzungen.