CONTRACT: Schnittstelle festlegen (5C Design, Teil 4)

By 5. Juli 2019 September 4th, 2019 Allgemein, Inhaltliches

Entwerfe Schnittstellen so, dass eine möglichst reibungslose Interaktion zwischen dem Baustein und seinen Consumern möglich ist.

  1. Software-Entwurf: Ein Blick zurück und nach vorn
  2. CUT: Richtig schneiden
  3. CONCEAL: Verbergen
  4. CONTRACT: Schnittstelle festlegen
  5. CONNECT: Verbinden
  6. CONSTRUCT: Aufbauen
  7. Its a Wrap: Zusammenfassung

Wie legt man eine Schnittstelle fest, die eine möglichst reibungslose Interaktion ermöglicht? Tatsächlich ist das Thema bereits in den SOLID Prinzipien sehr prominent vertreten. So steht das L darin für das Liskovsche Substitutionsprinzip von Barbara Liskov (nähere Infos hier). Noch interessanter finde ich aber das I aus SOLID, das für das Interface-Segregation Prinzip steht. Dies ist die erste von 3 Techniken für sauberes Schnittstellendesign, die ich ihnen hier vorstelle. Es besagt, dass die Schnittstelle eines Moduls immer nach ihren einzelnen Verantwortlichkeiten aufgeteilt sein sollte. Es darf demnach nicht eine einzige generische Schnittstelle geben, sondern für jeden Anwendungsfall der Benutzung einer Komponente jeweils eine eigene. Ich möchte das anhand eines Beispiels erläutern.

Interface Segregation und REST-APIs

Die Web Service Description Language (oder kurz WSDL) ist eine Beschreibungssprache für Schnittstellen und ein offizieller Standard des W3C Konsortiums. Sie wird meist in Kombination mit dem Simple Object Access Protocol (oder kurz SOAP) verwendet. Bei meinem Grundlagen-Seminaren zum Thema Software-Architektur geht es u.a. immer auch um das Interface-Segregation Prinzip. Ich frage die Teilnehmer dann gerne, ob jemand unter ihnen schon mal eine WSDL-Datei bekommen hat, die mehrere Megabyte groß war, und von der er (oder sie) sich zunächst einmal wie erschlagen fühlte. Eigentlich ist immer jemand dabei, der so eine Situation schon mal erlebt hatte. Solch komplexe Schnittstellen haben 2 potentielle Probleme:

  • Der Einarbeitungsaufwand für den Entwickler, der diese Schnittstelle verwenden möchte, ist ausgesprochen hoch. In der WSDL Spezifikation ist nicht vorgesehen, die Schnittstelle zu strukturieren.
  • Es besteht die Gefahr, dass der Code, der die Schnittstelle konsumiert, Abhängigkeiten zu Teilen der Schnittstelle entwickelt, die von diesem gar nicht benötigt werden. Sobald das Modell zur Schnittstelle vom Client generiert wurde ist es möglich, auch zu nicht relevanten Teilen einer nur teilweise verwendeten Schnittstelle Abhängigkeiten zu entwickeln.

Als Standard für Schnittstellen im Web hat sich inzwischen der Representational State Transfer als Alternative etabliert. Dabei wird eine komplexe Schnittstelle in ihre einzelnen „Subjekte“ bzw. Ressourcen aufgeteilt. Dieser Schritt entspricht einer Umsetzung des Interface-Segregation-Prinzips. REST hat also das I aus SOLID quasi „mit eingebaut“.

Die Kommunikation mit diesen einzelnen Ressourcen erfolgt mit den „Verben“ des HTTP-Protokolls, also beispielsweise mittels GET, PUT, POST und DELETE. Dabei gibt es auch Weiterleitungen von einer Ressource zur nächsten, die damit in Verbindung steht. Diese Weiterleitung (genannt Hypermedia As the Engine of Application State oder kurz: HATEOAS) bietet eine gewisse Flexibilität was die Änderung der einzelnen Endpoints angeht. Außerdem ist sie noch eine Form der Selbstdokumentation für Nutzer der Schnittstelle. Das Gefühl der Frustration, weil man so etwas wie eine monströse WSDL erhalten hat, sollte es bei REST-APIs also gar nicht erst geben.

Das Schnittstellen-Problem des Mars-Climate Orbiter

Neben der Schnittstellentrennung gibt es weitere Techniken für eine reibungslose Interaktion. Im konkreten Beispiel hätte ihre Anwendung einen Millionenschaden vermieden. Vielleicht hatten Sie es 1999 in den Nachrichten mitbekommen: Die NASA Sonde Mars-Climate Orbiter war abgestürzt. Sie hätte in einen Orbit um den Planeten Mars eintreten sollen, ist aber stattdessen auf dessen Oberfläche zerschellt (für nähere Infos dazu klicken Sie bitte hier). Passiert war Folgendes: Die Software wurde in Teilen von der NASA und teilweise von Lockheed-Martin entwickelt. An einer Stelle gab es eine Schnittstelle zur Weitergabe des gemessenen Impulses an die Steuerungseinheit. Während das eine Team davon ausging, dass dieser auf dem metrischen System basiert ging das andere Team von einer Abbildung basierend auf dem imperialen System aus. Das Ergebnis war der oben erwähnte Verlust der Raumsonde und ein entsprechender Millionenschaden. Ich könnte mir vorstellen, dass diese Schnittstelle nicht viel spezifischer definiert war als in folgendem Listing:


public double getSpeed ();

Eine solche Definition lässt einfach zu vieles offen. Um welche Einheit handelt es sich bei der Geschwindigkeit? Außerdem ist nicht klar ob auch negative Werte möglich sind, oder nur positive Werte als Rückgabewerte in Frage kommen. Diese Art von Problem kann durch eine spezifischere Definition des Schnittstellenkontraktes behoben werden. Viel besser ist die folgende Definition, wo wir uns des JSR305 bedienen und mit der entsprechenden Annotation beschreiben, dass diese Methode keine negativen Werte zurückliefert. Außerdem wird durch die Methodensignatur klar, dass es sich um die SI Einheit für Geschwindigkeit handelt:


public @Nonnegative double getSpeedInMetersPerSecond();

Achtung, Gefahr!

Besonders problematisch sind Schnittstellen, die einem jeden Consumer die Möglichkeit bieten, den Provider selbst in Probleme zu bringen. Dies zu vermeiden wäre mein 3. Tipp zum Thema. Wo man dies häufig antrifft ist, wenn sich mehrere Services oder Subsysteme den Zugriff auf ein und dieselbe Datenbank mit demselben Datenmodell teilen. So wie dies in der folgenden Grafik dargestellt ist:

Die Schnittstelle, die eine solche geteilte Datenbank ihren Consumern bereitstellt ist nämlich das Datenmodell selbst, und im Falle einer relationalen Datenbank die Abfragesprache SQL. Das beinhaltet die Möglichkeit einzelne Tabelleneinträge zu sperren, oder auch die Datenbank mit umfangreichen Query-Abfragen inkl. Joins über viele Tabellen zu lähmen. Eine dermaßen missbräuchliche Verwendung wird die anderen Consumer der Datenbank ebenfalls in Probleme bringen. Genau das sollte aber über eine Schnittstelle gar nicht erst möglich sein. Ich rede dabei wohlgemerkt nicht von Denial-of-Service Attacken, sondern von Dingen, welche früher oder später im Zuge der üblichen Wartungstätigkeit passieren.

Wird eine Schnittstelle zwar angeboten, aber von niemandem benutzt, ist natürlich noch keine Interaktion passiert. Im nächsten Beitrag (“CONNECT: Verbinden”) betrachten wir die Folgen, welche es zwangsläufig haben wird, wenn Bausteine über Schnittstellen miteinander interagieren.

Leave a Reply