Cloud-Computing Softwarearchitektur

Consumer-Driven Contracts mit Pact

Die Integration von Anwendungen verschiedener Teams ist immer noch ein Kraftakt. Integrationsprobleme zwingen dann zu einem späten Zeitpunkt in die Entwicklung zurück. Demgegenüber zeigt das Testverfahren Consumer-Driven Contracts (CDC) schon während der Entwicklung an, wenn die Teams ihre Schnittstellen verletzen. Mit dem Pact-Framework lassen sich CDC-Tests sehr gut als Unittests umsetzen. Aber was zunächst leichtgewichtig erscheint, birgt im Detail einige Fallstricke. Wer sie kennt, nimmt der Integration ihren Schrecken.

Renato Vinga-Martins

Author

27.08.2021
Lesezeit: 18 Minuten
98 Views

Integrationstests sind mit hohem Aufwand verbunden. Wenn die Automatisierung dieser Tests oder auch die manuelle Testdurchführung mit mehreren Anwendungen zu aufwendig erscheint, arbeiten die beteiligten Anwendungen unter Umständen erst im Rahmen einer Auslieferung miteinander. Schnittstellenfehler werfen dann das Projekt zu einem sehr späten Zeitpunkt im Zeitplan zurück und sind besonders teuer, wenn große Code-Teile auf diesen Schnittstellen aufbauen. Die Teams können ihre Schnittstellen zwar mittels Schemata formalisieren. Schemata bringen jedoch keine Semantik zum Ausdruck und begegnen nur bedingt der Gefahr, gegen die die Teams ihre Integrationstests einsetzen.

Consumer-Driven Contracts

Entwickelt eine Anwendung eine Schnittstelle spezifisch für eine andere Anwendung, dann lohnt es sich, wenn der Schnittstellenanbieter (Provider) die Schnittstelle am Bedarf des Nutzers (Consumer) ausrichtet. Ergänzend kann der Provider die Szenarien, in denen der Consumer die Schnittstelle nutzt, in seine eigenen Tests einfließen lassen. Es entstehen Consumer-Driven Contracts (CDC) als ein Testverfahren, das den Nutzwert und den real genutzten Umfang einer Schnittstelle in den Vordergrund rückt, versehentliche Kompatibilitätsverletzungen (Breaking Changes) vermeidet und so die Weiterentwicklung der Schnittstelle unterstützt.

CDC-Tests führen einen Perspektivwechsel herbei: Der Consumer beschreibt seine Nutzungsszenarien der gemeinsamen Schnittstelle in einem Kontrakt, gegen den Consumer und Provider testen. Der frühe und kontinuierliche Schnittstelleneinsatz anhand der Nutzungsszenarien wirkt Missverständnissen zwischen den beiden Entwicklerteams entgegen. Die Vorteile von CDC-Tests sind umso ausgeprägter, je häufiger die Teams ihre Schnittstelle weiterentwickeln.

Das Open-Source-Framework Pact

Pact [PACT] ist ein beliebtes sprachunabhängiges Open-Source-Framework zur Implementierung von CDC-Tests. Es unterstützt Schnittstellen, die JSON-basierte Kommunikation per REST oder Messaging einsetzen. Einen Vergleich mit ähnlichen oder ergänzenden Ansätzen wie Spring Cloud Contract liefert [VERGLEICH]. Pact legt einen besonderen Schwerpunkt auf Automatisierung und fördert so die enge Zusammenarbeit zwischen Consumer- und Provider-Team. Es entsteht eine gelebte Schnittstellenentwicklung und -prüfung.
Ein Blick auf die angepasste Testpyramide in Abbildung 1 zeigt, dass Pact-Tests aufwendiger als einfache, isolierte Unittests sind, auch wenn sie technisch als Unittests ablaufen. Der Grund dafür ist die engere Teamkopplung, die mit der Verwaltung der gemeinsamen Kontrakte entsteht. Aber sie sind wesentlich einfacher als Integrationstests oder fachliche Ende-zu-Ende-Tests über mehrere Anwendungen.
Die Abbildung hebt die Bedeutung der Automatisierung im Entwicklungsprozess hervor: Je häufiger Tests ablaufen, desto kürzer ist die Feedbackschleife zum Entwicklerteam, aber desto mehr Schritte der Testvorbereitung, -durchführung und -nachbereitung müssen automatisiert sein. Verarbeitungsketten (Pipelines) der Continuous Integration (CI) übernehmen die Automatisierungsaufgabe. Dies bedarf besonders sorgfältiger Vorbereitung, denn unzuverlässige Build- und Delivery-Pipelines erodieren die Qualitätskultur der Teams und senken damit die Produktqualität.
Der Beitrag zeigt im Folgenden, wie Teams die Automatisierung von CDC-Tests mit dem Pact-Framework (kurz Pact) umsetzen und wie sie ihre Schnittstellen weiterentwickeln können. Die Kontraktverwaltung nimmt dabei eine besondere Rolle ein, weil sie als Bindeglied zwischen den Teams fungiert.

Abb. 1: Pact-Tests liegen zwischen Unit- und Integrationstests

Die Funktionsweise von CDC-Tests mit Pact im Überblick

Pact-Testing ist Testing by Example. Der Consumer beschreibt beispielhaft mit einer Reihe von Interaktionen, zum Beispiel mithilfe konkreter REST-Aufrufe, wie er die Schnittstelle einsetzen will. Dadurch unterscheidet sich Pact von JSON-Schema, denn Letzteres beschreibt lediglich, was die Schnittstelle syntaktisch erlaubt. Pact erstellt den Kontrakt im JSON-Format, seinen Aufbau legt die Pact-Spezifikation fest [PACT-SPEZ].
Abbildung 2 und Tabelle 1 skizzieren die Schritte, die für den Durchlauf von Pact-Tests notwendig sind. Consumer und Provider stoßen die Schritte in speziellen Phasen ihrer CI-Pipelines (Stages) an, die sie beispielsweise mit Jenkins oder GitLab CI implementieren. Jeder dieser Schritte benötigt eine zugehörige Automatisierung seitens Pact. Ein Durchlauf besteht aus fünf Schritten und findet jedes Mal während der Stages statt, die für Build und Test zuständig sind.
Die Rolle Consumer oder Provider bezieht sich immer nur auf eine Schnittstelle. Eine Anwendung kann daher für die eine Schnittstelle der Consumer, für die andere der Provider sein. Sobald eine Anwendung in Betrieb geht, muss sie sicherstellen, dass sie mit den anderen Anwendungen zusammenarbeiten kann. Die zugehörige Prüfung nennt Pact Can I deploy?. Es bietet ein Kommandozeilenwerkzeug (CLI), um den Kontraktstatus bei der Kontraktverwaltungskomponente, dem Pact-Broker, abzufragen. Die Anwendung ist aus Pact-Sicht auslieferbar, sobald alle genutzten und angebotenen Schnittstellen positiv verifiziert sind.
In dem Ablauf verbindet die Kontraktverwaltung die beiden Schnittstellenpartner. Sie nimmt deshalb eine Schlüsselrolle ein. Sie regelt die Übergabe des Kontrakts an den Provider, damit der seine Tests ausführen kann, und die Übergabe des Verifizierungsergebnisses an den Consumer als Kompatibilitätsbestätigung. Gegenüber normalen Unittests entstehen zusätzliche Abhängigkeiten: Der Provider ist vom Kontrakt abhängig, den der Consumer in der Kontraktverwaltung registriert, und das „Can I deploy?“ des Consumers ist vom Verifizierungsergebnis abhängig, das der Provider in der Kontraktverwaltung hinterlegt.

Abb. 2: Consumer und Provider kooperieren in fünf Schritten

Tabelle 1: Schritte eines Pact-Testdurchlaufs mit Consumer und Provider

Consumer und Provider schreiben Pact-Tests als Unittests

Das Consumer- und das Provider-Team schreiben ihre Pact-Tests als leicht erweiterte Unittests. Abbildung 3 veranschaulicht hier zum besseren Verständnis den prinzipiellen Aufbau eines JUnit-Consumer-Tests mit einer Interaktion (s. [DETAIL] für weitere Information zum Pact-Test-Aufbau und -Einsatz):

Abb. 3: Beispiel für einen Consumer-Test mit den Schritten „Kontrakt erstellen“ und „Kontrakt verifizieren“

Die JUnit-Regel PactProviderRule übernimmt die Ablaufsteuerung mit der Kontraktgenerierung durch die @Pact-annotierte Methode und mit der Kontraktprüfung durch die @PactVerification-annotierte Methode.
Der generierte Kontrakt enthält als einzige Interaktion den GET-Request /users/4711, für den er eine Antwort mit einem name- und einem id-Attribut erwartet.
Der Prüfcode verwendet mit classUnderTest.getUser() den Produktivcode für den GET-Request /users/4711. Der Produktivcode führt den Aufruf auf dem Pact-Mock-Provider durch, da die Testinitialisierung den Produktivcode mit der Mock-Provider-Url versorgt.

Abbildung 4 zeigt das Kontrakt-JSON, das aus dem @Pact-Code entstanden ist. Die Matching-Rules im JSON zeigen Informationen, durch die Pact mehr als exakte String-Vergleiche durchführen kann. Die Entwicklerteams sollten bei der Pact-Test-Umsetzung auf folgende Punkte achten:

Abb. 4: Pact/Kontrakt zum Beispiel-Consumer-Test

Pact-Tests eignen sich für die technische Schnittstellenprüfung, nicht aber zum Testen fachlicher Bedingungen [ADVANCED]. Zum einen sind Fachtests an der technischen Schnittstelle falsch angesiedelt. Zum anderen würden fachliche Bedingungsänderungen unnötigerweise zu Kontraktanpassungen führen, obwohl die technische Schnittstelle unverändert bleibt.
Pact-Tests müssen für ihre Prüfungen den Produktivcode einsetzen. Allein deshalb lohnt es sich, die Schnittstellen zu kapseln, sodass der Pact-Test den Produktivcode verwendet und nicht nachbaut.
Pact-Tests liefern und testen Nutzungsszenarien, ersetzen aber keine Schnittstellendokumentation.
Pact-Tests sollten sich auf die Nutzungsszenarien konzentrieren, dabei aber nicht sämtliche Syntaxvarianten der Schnittstellendaten abarbeiten. Dafür sind normale Unittests und der Einsatz von Schemata besser geeignet. Idealerweise sollten Pact-Tests die normalen Unittests ergänzen.
Die Teams sollten Vorlagen für ihre Pact-Verwendung erstellen. Denn Pact verteilt sich über die drei Ebenen CI (z. B. Jenkins), Build (z. B. Maven) und Unittest (z. B. JUnit). Dabei kann der Überblick verloren gehen.

Die Consumer-Tests setzen somit an der tieferen Softwareschicht der technischen Schnittstelle an, sie integrieren weder GUI noch Geschäftslogik. Demgegenüber sollten die Provider-Tests möglichst viele Softwareschichten einsetzen, um realitätsnahe Ergebnisse zu produzieren [ADVANCED].

Pact unterstützt die kompatible Weiterentwicklung von Schnittstellen

Interagierende Anwendungen müssen ihre Schnittstellen weiterentwickeln können und sollen trotzdem unabhängig voneinander in Betrieb gehen können. Pact arbeitet nach dem Robustheitsgrundsatz für API-Design, auch als Postel’s Law bekannt: „sei streng bei dem, was du tust, und offen bei dem, was du von anderen akzeptierst“ [WIKI]. Das besagt hier im Kern, tolerant gegenüber Erweiterungen anderer zu sein. Auf einen REST-Aufruf bezogen, sollen Provider zusätzliche Eingabewerte und Consumer zusätzliche Ergebniswerte ignorieren. Pact unterstützt diese Schnittstellenveränderungen, indem es selbst keine Prüfung auf exakte Parametrierung und Ergebnisse durchführt.

Abb. 5: Die Provider-Version P1 erfüllt den ursprünglichen Kontrakt und die kompatible Kontraktänderung

Die beiden Beispiel-REST-Aufrufe in Abbildung 5 stehen repräsentativ für eine kompatible Kontraktänderung von (a) nach (b) des Consumers. Ein robuster Provider P1 ignoriert in (b) den zusätzlichen Parameter und der robuste Consumer C2 ignoriert das zusätzliche Adressfeld, das der Provider P1 weiterhin liefert.
Consumer und Provider können so schrittweise kompatible Kontraktänderungen wie in Abbildung 6 in Betrieb nehmen. In dem Beispiel liefert die Provider-Version P1 gemäß Kontrakt ein Gesamtadressfeld. Ersetzt der Provider übergangslos in der Version P2 das Gesamtadressfeld durch Einzelangaben (a), dann wäre das ein Breaking Change der Schnittstelle: Solch eine Änderung ist nur möglich, wenn angepasste Versionen von Consumer und Provider gleichzeitig in Betrieb gehen. Die Zwischenschritte (b) und (c) umgehen diese unerwünschte Kopplung. Zunächst erweitert der Provider in Version P1.1 seine Antwort um die Einzelangaben (b). Daraufhin nutzt der Consumer im neuen Kontrakt nur noch die Einzelangaben, und zuletzt entfernt der Provider in Version P2 das nun überflüssige Adressfeld (c). Mit ihren Pact-Tests sichern sich Consumer und Provider gegen versehentliche Änderungen ab, die Fehler an der Schnittstelle hervorrufen würden. Ein fehlschlagender Consumer-Test deckt eindeutig einen Consumer-Fehler auf. Wenn aber ein Provider-Test fehlschlägt, dann kann das an einer inkompatiblen Kontraktänderung oder an einer fehlerhaften Provider-Implementierung liegen.

Abb. 6: Beispiel für kompatible Schnittstellenänderungen

Die Kooperation von Consumer und Provider läuft automatisiert über den Pact-Broker

Der Pact-Broker dient als Bindeglied in der Consumer-Provider-Kooperation. Er ist zwar kein zwingender Bestandteil von Pact-Tests, bietet aber die für die Automatisierung notwendige Verwaltung von Consumer-Version, Provider-Version, Kontraktversion und Verifizierungsergebnis mittels einer REST-Schnittstelle. Er führt über sämtliche Verifizierungsergebnisse zu einer Kontraktversion Buch, sodass mehrere Softwarestände parallel in ihren Branchs arbeiten können. Seine Verwaltungseinträge erklären sich am besten im konkreten Zusammenspiel der CI-Pipelines. Sowohl der Pact-Broker als auch das „Can I deploy?“-Werkzeug stehen als Docker-Images [DOCKERED] für den Einsatz in der eigenen CI-Infrastruktur zur Verfügung.

Abb. 7: Der Consumer „cons-app“ installiert die neue Softwareversion C2 mit dem Provider „prov-app“

Im Ablauf in Abbildung 7 installiert die Consumer-Pipeline aus der Entwicklungsumgebung eine neue Softwareversion C2 in der Testumgebung.

Abb. 8: Pact-Broker-Einträge und „Can I deploy?“ während der Installation von C2

Abbildung 8 zeigt die Auswirkungen der Schritte im Pact-Broker und im „Can I deploy?“. Pact-Tests laufen in gesonderten Stages nach der Build-Stage, um Pact-Broker- und Schnittstellen-Probleme sichtbar von der anwendungsinternen Qualitätssicherung zu trennen:

➀ In der Ausgangssituation hat der Consumer „cons-app“ in der neuen Softwareversion C2 seinen Kontrakt mit dem Provider „prov-app“ hochgeladen. Das Tag „pre-test“ dient der Provider-Pipeline als Selektionskriterium. Der Consumer stellt so vor der Installation sicher, dass er mit der Provider-Version aus der Zielumgebung kompatibel ist.
➁ Die Änderung löst im Pact-Broker ein Ereignis aus, mit dem er die Provider-Pipeline der Testumgebung über die benötigte Verifizierung informiert.
➂ Die Consumer-Pipeline wartet anschließend im „Can I deploy?“ auf das mit „test“ getaggte Verifizierungsergebnis aus der Testumgebung.
➃ In der Testumgebung läuft die Provider-Version P1. Die Pipeline findet und verifiziert den mit „pre-test“ getaggten Kontrakt und
➄ lädt das Verifizierungsergebnis mit dem Tag „test“ auf den Pact-Broker hoch.
➆ Nach der positiven Verifizierung führt die Consumer-Pipeline die Installation von C2 in der Testumgebung durch und dokumentiert dies durch die Tag-Änderung von „pre-test“ in „test“. Das Tag „pre-test“ unterscheidet Softwareversionen, die noch installiert werden sollen, von denjenigen, die bereits installiert sind.

Es fällt auf, dass der Kontrakt selbst keine Version besitzt. Der Pact-Broker erkennt Kontraktänderungen durch Inhaltsvergleich und speichert nur veränderte Kontrakte. Die Kontraktversion ordnet er der Kombination aus Consumer, Consumer-Version und Provider zu. Auf diese Weise erkennt der Pact-Broker auch, wenn eine neue Consumer-Version einen bereits verifizierten Kontrakt verwendet und verlangt keine erneute Verifizierung.
[ADVANCED] zeigt die exakten Zusammenhänge und die Details des Pact-Broker-Datenmodells zusammen mit vielen anderen Informationen. Die Consumer-Version ist frei wählbar, muss aber eindeutig sein, um das unerwünschte Überschreiben einer Kontraktversion zu vermeiden. Der Consumer gibt deshalb üblicherweise seine Softwareversionsnummer an, bestehend aus der Semantic Version und dem Commit-Hash. Der Provider ordnet sein Verifizierungsergebnis ebenfalls einer Kontraktversion zu und versieht die Verifizierung mit seiner Provider-Version.
Im Laufe der Zeit entsteht eine Historie der Consumer- und Provider-Versionen mit ihrem zugeordneten Kontrakt und Verifizierungsergebnis. Provider-Pipeline und „Can I deploy?“ müssen die richtigen Einträge dieser Historie referenzieren und benötigen dafür stabile Kriterien. Denn standardmäßig verwendet der Pact-Broker den zuletzt erzeugten Eintrag, und das ist im Zweifelsfall der falsche, da die Pipelines von Feature-Branchs und Auslieferung parallel laufen. Die technische Softwareversion ist als Kriterium ungeeignet, weil sie sich ständig ändert. Deshalb übernehmen die Tags der Consumer und Provider diese Aufgabe. Provider und „Can I deploy?“ beziehen sich so auf den letzten Eintrag mit dem angegebenen Tag.

Abb. 9: Der Provider „prov-app“ installiert die neue Softwareversion P2 mit dem Consumer „cons-app“

Abbildung 9 zeigt den Ablauf aus Provider-Sicht, Abbildung 10 die Auswirkungen in den Werkzeugen. Die Provider-Pipeline befragt den Pact-Broker, ob seine Softwareversion P2 mit der Consumer-Version C1 der Testumgebung kompatibel ist (➀ und ➁). Bei positiver „Can I deploy?“-Antwort ➂’ taggt der Provider P2 sein Verifizierungsergebnis sofort mit „pre-test“. Bei negativer „Can I deploy?“-Antwort ➂’’ muss der Provider zunächst eine Verifizierung durchführen. Im Erfolgsfall ➃ findet die P2-Installation in der Testumgebung statt und der Provider ändert sein Tag „pre-test“ in „test“. Ab dieser Tag-Änderung führen Consumer ihr „Can I deploy?“ mit P2 durch. Schon beim ersten Einsatz der Werkzeugkette lernt man die Vorteile der kontinuierlichen gegenseitigen Prüfung und der transparenten Kommunikation mithilfe des Pact-Brokers zu schätzen. Es entstehen die gewünschte enge Zusammenarbeit von Consumer- und Provider-Team während der Schnittstellenentwicklung und die Unabhängigkeit und gegenseitige Absicherung, nachdem sie die Schnittstelle fertiggestellt haben. Allerdings müssen Consumer- und Provider-Team das Prüfverfahren gut verstanden haben und geordnet vorgehen. Denn als Kehrseite des schnellen Feedbacks erzeugen inkompatible Kontraktänderungen des Consumers Fehlerabbrüche in der fürs Consumer-Team nicht sichtbaren Provider-Pipeline.

Abb. 10: Pact-Broker-Einträge und „Can I deploy?“ während der Installation von P2

Pact-Broker und „Can I deploy?“ verhindern inkompatible Installationen

In der Anfangsphase des Pact-Einsatzes legen die Teams erfahrungsgemäß den Fokus auf die Consumer- und Provider-Tests. Die Automatisierung ihrer Kooperation zwingt sie dann, über die Weiterentwicklung ihrer Schnittstellen nachzudenken und darüber, wann der Fehlerabbruch ihrer Pipeline berechtigt ist. Die Übersicht über mögliche Konstellationen erklärt, warum das „Can I deploy?“-Verfahren inkompatible Installationen verhindert. Nach dem oben skizzierten Verfahren führen Consumer und Provider ihre Installation nur dann durch, wenn sie gegenüber der Vorgängerversion kompatibel sind. Eine neue Consumer-Version lässt sich die Kompatibilität von der bereits installierten Provider-Version durch eine positive Verifizierung bestätigen, und eine neue Provider-Version prüft den Kontrakt der bereits installierten Consumer-Version.

Abb. 11: Wann dürfen Consumer und Provider Softwareversionen in der Testumgebung installieren?

Abbildung 11 stellt schematisch die Erstentwicklung eines Consumers (C1) und eines Providers (P1) sowie deren Weiterentwicklung (C2, P2) dar. Die hier betrachteten Fälle behandeln genau eine Kontraktversion K1, die der Consumer im Pact-Broker veröffentlicht:

➀ Solange noch keine Software in Test läuft, erhält nur der Provider ein positives „Can I deploy?“ und darf P1 installieren.
➁ Anschließend erhält auch der Consumer ein positives „Can I deploy?“-Ergebnis und darf C1 installieren.
➂ Consumer und Provider dürfen dann neue Softwareversionen installieren, solange ihre Pact-Tests fehlerfrei laufen.
➃ Sollte aber der Provider-Pact-Test einen Fehler liefern, dann wird auch das „Can I deploy?“ die Installation der neuen Version verhindern.

Eine kompliziertere Sachlage entsteht, wenn das Consumer-Team eine neue Kontraktversion erzeugt. Abstimmungen zwischen den Teams sind zwar oberstes Gebot, aber das automatisierte Verfahren darf in keinem Fall inkompatible Installationen ermöglichen. Besonders wichtig sind die Fälle, in denen der Consumer mit einem neuen Kontrakt einen Breaking Change einführt.

Abb. 12: Beispiel-Szenario für Consumer und für Provider mit Breaking Changes im Kontrakt K2

Abbildung 12 zeigt beispielhaft zwei Szenarien, eins aus Consumer- (1) und eins aus Provider-Sicht (2); erwartungsgemäß bricht der Installationsvorgang in beiden Fällen ab:

➀ Wegen des Breaking Change erhält Consumer-Version C2 im „Can I deploy?“ eine negative Verifizierung von der installierten Provider-Version P1.
➁ Die Provider-Version P2 ist schon an den neuen Kontrakt K2 angepasst, weshalb der Pact-Test erfolgreich verläuft. Allerdings schlägt das „Can I deploy?“ von P2 fehl, da der Pact-Test von P2 nicht mehr die aktuelle Kontraktversion K1 verifizieren kann.

Zusammengefasst reicht es somit aus, wenn sich Consumer und Provider in ihrer „Can I deploy?“-Stage der positiven Verifizierung der bereits ausgelieferten Version versichern. Auch wenn Pact auf Microservice-Architekturen abzielt, eignet sich das dargestellte Verfahren genauso für Anwendungen mit klassischer Auslieferung. Provider und Consumer verwenden die Tags für eindeutige Kontraktversionsbezeichnungen. Bei Auslieferungen können sie das „Can I deploy?“ in derselben Weise einsetzen, um die Kompatibilität mit vorgegebenen Kontraktversionen nachzuweisen.

Fazit

Der Beitrag hat gezeigt, wie Nutzer und Anbieter von Schnittstellen mittels Kontrakten bereits während der Entwicklung ihre Kompatibilität sicherstellen. CDC-Tests helfen ihnen dabei, indem sie die Nutzungsszenarien als leichtgewichtige Unittests ablaufen lassen. Damit fördern sie die frühzeitige Stabilisierung der Schnittstellen und nehmen ein erhebliches Risiko aus den aufwendigeren Integrationstests. Pact und insbesondere der Pact-Broker unterstützen speziell die Ablaufautomatisierung von CDC-Tests und unterbinden die Installation inkompatibler Softwareversionen.
Wer CDC-Tests und Pact einsetzt, stellt schnell fest, wie wichtig die automatisierte Prüfung während der Schnittstellenweiterentwicklung ist. Die Organisation der Automatisierung ist allerdings deutlich komplizierter als die eigentlichen Pact-Tests. Dieser Aufwand lohnt sich für Schnittstellen, die häufigen Änderungen unterliegen.

items: <ListValue: [StructValue({'title': 'Hintergrundinformationen zu Pact', 'text': 'Hinter Pact steht im Kern die australische Firma DiUS (https://dius.com.au/). Pact ist ein Open-Source-Ökosystem (https://github.com/pact-foundation), im Wesentlichen bestehend aus der sprachunabhängigen Pact-Spezifikation (https://github.com/pact-foundation/pactspecification), sprachspezifischen Pact-Client-Bibliotheken und der Kontraktverwaltungskomponente Pact-Broker. Das kommerzielle DiUS-Produkt Pactflow (https://pactflow. io/) bietet eine für Unternehmenszwecke erweiterte Version des Open-Source-Pact-Brokers inklusive Cloud-Hosting. Die Open-Source-Java-Client-Bibliotheken inklusive Spring-Integration und Maven-Plug-in stammen von DiUS selbst (https://github.com/DiUS/). Das Versionierungsschema des Pact-Brokers ist von dem der Client-Bibliotheken und von dem der Spezifikation unabhängig. Die neueste Spezifikationsversion V3 unterstützt zusätzlich zu REST-Schnittstellen auch Nachrichten-orientierte Schnittstellen. Für den Start reicht auf jeden Fall der einfache, fertig gedockerte Open-Source-Pact-Broker (https://hub.\xa0docker.com/r/pactfoundation/pactbroker/) aus. Der Pactflow-Support ist sehr gut; Fragen beantwortet er innerhalb kurzer Zeit. Lizenzen der Pact-Komponenten:\r\n\r\n\r\n • Spezifikation, Docker-Pact-Broker: MIT\r\n • JVM: Apache 2.0'})]>