Kolumne

Knigge für Softwarearchitekten: Die API-tektin

Gernot Starke, Peter Hruschka

Unserer Einschätzung nach werden Schnittstellen oft als Dinge dritter Klasse behandelt. Technologie auswählen, Features bauen und Bugs fixen gehen vor. Sogar Dokumentation schreiben scheint uns in manchen Projekten wichtiger als effektive Schnittstellen zu entwerfen. Wir wünschen Ihnen und uns die API-tektin, die gemeinsam mit Softwarearchitekten den Schnittstellen auf die Sprünge hilft.

Aber was ist eine Schnittstelle? Der einfachste Fall: Sie haben einen Consumer und einen Provider. Consumer benötigt irgendetwas vom Provider, seien es Rechen- oder Abfrageergebnisse, Daten oder Dateien, Messwerte von Sensoren oder Statusinformationen; also eine digitale Antwort auf eine ebenso digitale Frage. Sie können diesen einfachen Fall durch Fragen von Zeitverhalten (sync, async) oder Antwortverhalten (request-response, fire-and-forget, single-consumer, multiple-consumer etc.) noch verkomplizieren.

Aber schauen wir mal auf den einfachsten Fall: Ein Consumer muss die Anfrage irgendwie an den Provider übermitteln. Oft geschieht das über einen Funktions- oder Methodenaufruf mit Parametern und Rückgabewert. Viele der üblichen Interaktionen zwischen Consumern und Providern können wir auf solch einfache Aufrufe zurückführen. Diese Art der Zusammenarbeit zwischen Bausteinen ist die Grundlage von Modularisierung und Komponentenbildung und kommt in Systemen aller Art an beliebig vielen Stellen vor. Damit ist Schnittstellenentwurf ein alltägliches Allerweltsproblem. Und wir sollten überlegen, welche der jeweiligen Personen (Stakeholder) eigentlich an solchen Entscheidungen beteiligt ist.

 

 

Wer entscheidet über Schnittstellen?

Abbildung 1 zeigt diese Situation – völlig verallgemeinert – mit möglichen Beteiligten: Das Consumer-Team C, Providerteam P, eine Architektin A, Management M sowie sonstige Stakeholder S. In einer solchen Situation müssen für die Schnittstellen jede Menge Detailentscheidungen getroffen werden. Und dabei können sich die Stakeholder A, C, P sowie M und S wie folgt einbringen:

Abb. 1: Wer entscheidet über Schnittstellen?

Tabelle 1: Bei Detailentscheidungen ist nicht immer das Wissen aller nötig

Entscheidet nur eine Partei, minimiert das den Abstimmungsaufwand. Entscheiden viele Parteien, steigert das den Aufwand, führt aber möglicherweise zu einer höheren Qualität der Entscheidungen, weil mehrere unterschiedliche Gesichtspunkte berücksichtigt werden können. Bedenken Sie: In jedem System gibt es Dutzende von Schnittstellenentscheidungen zu treffen, und jede davon lässt sich auf eine der genannten Arten entscheiden.

Unser dringender Rat: Als API-tektin suchen Sie zuerst die besonders kritischen oder wichtigen Schnittstellen, die auf wesentliche Qualitätsmerkmale des Systems Einfluss nehmen könnten. Dann überlegen Sie für diese Prio-1-Schnittstellen, welche Personen an den jeweiligen Entscheidungen mitwirken sollten. Sie müssen dabei neben den rein architektonischen Anforderungen und Gegebenheiten noch Faktoren wie Zeit, Aufwand, Homogenität der Architektur, Umsetzungsgeschwindigkeit oder andere Qualitätsmerkmale berücksichtigen. Das ist eine schwere Aufgabe. Für diese Metaentscheidung benötigen Sie neben Detailwissen über die jeweiligen Consumer und Provider noch einen guten Überblick über das Gesamtsystem. Daher sind Sie als Architektin – respektive API-tektin – für dieses Thema prädestiniert.

Warum ist das kompliziert?

Neben den in der Realität gar nicht so banalen Fragen nach den Namen von Schnittstellen und Parametern taucht in der Praxis sofort die Frage der Fehler- und Ausnahmebehandlung auf. In der Praxis benötigt die Behandlung von Fehler- und Sonderfällen oft 80 Prozent des gesamten Aufwands. In Remotesituationen muss der Consumer einen passenden Provider erst einmal finden – da helfen beispielsweise Registries oder Broker – und sie müssen sich ausweisen (authenticate) sowie Berechtigung nachweisen (authorize). Dann wäre da noch die Frage nach dem technischen Kommunikations- oder Übertragungsprotokoll (Plain Sockets, FTP, HTTP etc.) oder möglichen Handshake-Schritten vor der eigentlichen Kommunikation. Bis hierhin ist es meist noch überschaubar. Aber dann kommen in schlimmen Fällen noch eines oder mehrere der folgenden Themen ins Spiel. Und dann es wird es richtig schwierig:

  • Vertraulichkeit: Wenn an der Schnittstelle übertragene Daten oder sogar die Benutzung der Schnittstelle an sich vertraulich sind, müssen Sie gegebenenfalls in die Werkzeugkiste der Kryptografie greifen und dazu noch organisatorische Sicherheitsaspekte berücksichtigen. Schwierigkeitsgrad: extrem hoch
  • Verfügbarkeit: Wenn die Schnittstelle niemals ausfallen darf, könnten Sie Redundanz in Software und Hardware einführen, einen Cluster und Load Balancer einsetzen oder weitere teure Maßnahmen starten. Schwierigkeitsgrad: hoch, Kosten: hoch bis sehr hoch
  • Durchsatz, Antwortzeit: Die Implementierung des Providers optimieren, Redundanz (z. B. Caching) einführen, extrem schnelle Hardware oder Netze kaufen. Schwierigkeitsgrad: mittel, Kosten: beliebig
  • Flexibilität: Sie möchten Datenformate flexibel halten, die Provider oder Zugriffskanäle austauschbar gestalten. Theoretisch ist alles möglich, praktisch für Entwurf und Implementierung beliebig aufwendig. Testen wird aber zum Albtraum. Schwierigkeitsgrad: Umsetzung mittel, Test: extrem
  • Versionierung: Abwärtskompatibel? Source- oder binärkompatibel? Jede Änderung eine neue Version vom Provider? Versionskennung in den Namen der Schnittstelle oder als Metainformation in die Parameter? Wie OSGi? Schwierigkeitsgrad: hoch, Aufwand: klein bis beliebig.

APIs in der Praxis

Einige Themen liegen uns nach langjähriger Beschäftigung mit Schnittstellen noch am Herzen. Diese möchten wir Ihnen ungeordnet mitgeben:

  • Externe Schnittstellen sind viel schlimmer als interne Schnittstellen, weil wir auf die Außenwelt normalerweise kaum Einfluss haben, auf unsere inneren Komponenten aber schon.
  • Consumer von Schnittstellen könnten ausführbare Tests (Consumer-driven Contracts) schreiben, die entsprechende Provider auf Einhaltung der jeweiligen Schnittstellenvereinbarungen überprüfen. Für solche Art Tests gibt es mit Pact einen schicken Open-Source-Ansatz (eine Einführung findet sich hier).
  • Das Thema API-Management ist zum Managementhype geworden, bei dem viele namhafte Softwarehersteller mitspielen. Wir geben erst gar keine Links an: IBM, SAP, Microsoft, CA, Software AG, HP, Intel und so weiter.

Mehr über API-Design lernen?

Bis vor kurzer Zeit gab es praktisch keine Literatur zum Thema systematischer Entwurf von Schnittstellen. Vom uralten „Practical API Design“ von Jaroslav Tulach [1] einmal abgesehen, das völlig unbrauchbar für Normalbürger war, weil unverständlich und konfus. Obwohl Jaroslav als einer der zentralen NetBeans-Entwickler nachweislich Ahnung von Schnittstellen hat. Es gab also keine Möglichkeit, dieses wichtige Thema zu vertiefen.

Lesen Sie auch: RESTful APIs dokumentieren – so geht’s!

Anfang 2017 hat Kai Spichale endlich für Abhilfe gesorgt [2] und den lang erhofften Durchbruch geschafft: Sein Buch „API-Design“ möchten wir Ihnen wärmstens empfehlen. Sie finden darin Infos zu Grundlagen, zu Java-APIs, wie Sie Ihre eigenen Fluent-APIs entwickeln können, zum schwierigen Thema Kompatibilität, zu REST und Web-APIs, SOAP, Web Services und Messaging. Schließlich bietet Kai Ihnen noch Infos zu diversen übergreifenden Themen an, beispielsweise Dokumentation, Caching oder Skalierbarkeit von Schnittstellen. Also, liebe API-tektinnen und API-tekten, jetzt gibt es keine Ausrede mehr.

Fazit

Schnittstellen Ihres Systems, interne wie auch externe, können über Erfolg und Misserfolg kräftig mitentscheiden. Widmen Sie ihnen angemessene Aufmerksamkeit und erheben Sie API-Design zu einem der wesentlichen Themen in Architektur- und Entwicklungsdiskussionen. Wie so oft müssen Sie priorisieren: Kümmern Sie sich als API-tektin um die wesentlichen Schnittstellen. Manche können Sie durchaus an die Consumer- oder Providerteams delegieren. Aber bei einigen werden Sie selbst mitbestimmen müssen. API-tektin mag wie ein schwieriger Job klingen, aber Sie können damit für viel bessere Systeme sorgen.

In diesem Sinne: Möge die Macht der Schnittstellen mit Ihnen sein!

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.