Verbrauchergetriebene Verträge als Möglichkeit zur Entwicklung eines Dienstes

- Das Erfolgsgeheimnis des Lieferanten besteht darin, den Verbrauchern Qualitätsprodukte anzubieten ... oh, das heißt Service. Nun, und es ist auch wichtig, sich nicht allen ernsthaften Verstößen gegen die Abwärtskompatibilität hinzugeben.
Walter White

Vom Übersetzer

Was ist das

Dies ist eine Übersetzung eines Artikels, der die CDC-Vorlage (Consumer-Driven Contracts) beschreibt.
Das Original wird von Ian Robinson auf der Website von Martin Fowler veröffentlicht.

Warum ist das so?

In einer Microservice-Architektur sind Abhängigkeiten zwischen Diensten eine Quelle von Problemen. Die CDC-Vorlage hilft bei der Lösung dieser Probleme auf eine Weise, die sowohl den Entwicklern des Dienstes als auch seinen Verbrauchern entspricht. Fowler zitiert Consumer-Driven Contracts in seinem Schlüsselartikel zur Microservice-Architektur: Microservices .

Für wen ist es?

Dieser Artikel ist besonders nützlich für Teams, die Dienste für mehrere Verbraucher innerhalb derselben Organisation entwickeln, und für Teams, die solche Dienste nutzen.

Über Begriffe

• Ich habe keine verbraucherorientierten Verträge ins Russische übersetzt - wir übersetzen keine testgetriebene Entwicklung in einem Gespräch. Bei Bedarf können Sie die Option Kundenorientierte Verträge verwenden .
• Anbietervertrag und Verbrauchervertrag werden als Lieferantenvertrag und Verbrauchervertrag übersetzt - sie werden auf Russisch nachhaltig verwendet.
• Entwicklung oder Weiterentwicklung eines Dienstes (Service Evolution) - Verfeinerung, Erweiterung der Servicefunktionalität.
• Die Community of Service (Service Community) - der Anbieter sowie alle Verbraucher dieses Dienstes.

Präambel

In diesem Artikel werden die Probleme erläutert, die zwischen Entwicklern und Verbrauchern von Diensten auftreten, beispielsweise wenn Lieferanten einen Teil ihres Vertrags ändern, insbesondere Dokumentlayouts. Es werden zwei Strategien beschrieben, um mit ihnen umzugehen:

1. Erweiterungspunkte hinzufügen.
2. "Ausreichende" Validierung der empfangenen Nachrichten.

Beide Strategien schützen die Verbraucher vor Vertragsänderungen, geben dem Dienstleister jedoch keinen Einblick:

• wie man diese Strategien am besten einsetzt;
• Was muss getan werden, wenn sich der Service entwickelt?

Der Artikel beschreibt die Vorlage für verbraucherorientierte Verträge , mit der Lieferanten ihre Kunden besser verstehen können, und konzentriert die Entwicklung des Dienstes auf die Bedürfnisse der Verbraucher.

Beispiel für die Serviceentwicklung

Betrachten Sie eine einfache Produktsuche, mit der Sie in unserem Produktkatalog suchen können, um einige der Probleme zu veranschaulichen, die bei der Entwicklung von Services auftreten. Das Suchergebnis hat folgende Struktur:

Abbildung 1: Suchergebnisdiagramm

Ein Beispieldokument mit Suchergebnissen lautet wie folgt:

<?xml version="1.0" encoding="utf-8"?> <Products xmlns="urn:example.com:productsearch:products"> <Product> <CatalogueID>101</CatalogueID> <Name>Widget</Name> <Price>10.99</Price> <Manufacturer>Company A</Manufacturer> <InStock>Yes</InStock> </Product> <Product> <CatalogueID>300</CatalogueID> <Name>Fooble</Name> <Price>2.00</Price> <Manufacturer>Company B</Manufacturer> <InStock>No</InStock> </Product> </Products> 

ProductSearch wird derzeit von zwei Anwendungen verwendet: einer internen Marketinganwendung und einer externen Reseller-Webanwendung. Beide Clients verwenden XSD, um empfangene Dokumente vor der Verarbeitung zu überprüfen. Die interne Anwendung verwendet die Felder CatalogIDID, Name, Preis und Hersteller. externe Anwendung - Felder CatalogIDID, Name und Preis. Keiner von ihnen verwendet das InStock-Feld: Obwohl es für eine Marketinganwendung in Betracht gezogen wurde, wurde es in einem frühen Entwicklungsstadium verworfen.

Eine der häufigsten Möglichkeiten zur Entwicklung eines Dienstes besteht darin, einem Dokument ein Feld für einen oder mehrere Verbraucher hinzuzufügen. Abhängig davon, wie die Client- und Serverteile implementiert wurden, können selbst einfache Änderungen wie diese kostspielige Konsequenzen für das Unternehmen und seine Partner haben.

In unserem Beispiel möchte ein zweiter Reseller, nachdem der ProductSearch-Service einige Zeit ausgeführt wurde, ihn verwenden, fordert jedoch dazu auf, jedem Produkt das Feld Beschreibung hinzuzufügen. Aufgrund der Art und Weise, wie Kunden arrangiert werden, hat diese Änderung erhebliche und kostspielige Konsequenzen sowohl für den Lieferanten als auch für bestehende Kunden. Die Kosten für jeden von ihnen hängen davon ab, wie wir die Änderung umsetzen. Es gibt mindestens zwei Möglichkeiten, wie wir die Kosten für Änderungen zwischen Mitgliedern der „Service-Community“ teilen können. Erstens könnten wir unser ursprüngliches Schema ändern und von jedem Verbraucher verlangen, seine Kopie des Schemas zu aktualisieren, um die Suchergebnisse korrekt zu überprüfen. Die Kosten für die Änderung des Systems werden hier auf den Lieferanten verteilt, der angesichts einer solchen Änderungsanforderung noch einige Änderungen vornehmen wird. und Verbraucher, die nicht an aktualisierten Funktionen interessiert sind. Auf der anderen Seite könnten wir eine zweite Operation und ein zweites Schema für einen neuen Kunden hinzufügen und die ursprüngliche Operation und das ursprüngliche Schema für bestehende Kunden beibehalten. Alle Verbesserungen liegen nun auf der Seite des Lieferanten, aber die Komplexität des Service und die Kosten für dessen Support steigen.

Zwischenspiel: Verbrannte SOA

Die Hauptvorteile der Nutzung von Diensten sind:

1. Erhöhte organisatorische Flexibilität.
2. Niedrigere Gesamtkosten für die Implementierung von Änderungen.

SOA erhöht die Flexibilität, indem Geschäftsfunktionen in dedizierten, wiederverwendbaren Diensten platziert werden. Anschließend werden diese Services verwendet und koordiniert, um die wichtigsten Geschäftsprozesse auszuführen. Dies reduziert die Kosten für Änderungen, indem die Abhängigkeiten zwischen Diensten verringert werden, sodass diese schnell neu erstellt und als Reaktion auf Änderungen oder ungeplante Ereignisse optimiert werden können.

Ein Unternehmen kann diese Vorteile jedoch nur dann vollständig nutzen, wenn die Implementierung von SOA die unabhängige Entwicklung von Diensten ermöglicht. Um die Unabhängigkeit zu erhöhen, erstellen wir Serviceverträge. Trotzdem sind wir gezwungen, die Verbraucher so oft wie den Lieferanten zu ändern, hauptsächlich weil die Verbraucher von der spezifischen Version des Lieferantenvertrags abhängen. Am Ende beginnen die Lieferanten äußerst vorsichtig mit der Änderung von Vertragsbestandteilen. insbesondere, weil sie keine Ahnung haben, wie Verbraucher diesen Vertrag umsetzen. Im schlimmsten Fall sind die Verbraucher an den Lieferanten gebunden und beschreiben den gesamten Umriss des Dokuments als Teil ihrer internen Logik.

Verträge gewährleisten die Unabhängigkeit des Dienstes; Paradoxerweise können sie auch Lieferanten und Verbraucher auf unerwünschte Weise binden. Ohne über die Funktion und Rolle der Verträge nachzudenken, die wir in unserer SOA implementieren, setzen wir unsere Dienstleistungen einer „verdeckten“ Kommunikation aus. Das Fehlen jeglicher Informationen darüber, wie Verbraucher des Dienstes den Vertrag im Kodex umsetzen, sowie das Fehlen von Umsetzungsbeschränkungen (sowohl für den Lieferanten als auch für den Verbraucher) untergraben zusammen die wahrgenommenen Vorteile von SOA. Kurz gesagt, ein Unternehmen wird müde von Dienstleistungen.

Schema-Versionierung

Durch die Versionierung des Schemas können wir mit der Untersuchung von Vertragsproblemen und Abhängigkeiten beginnen, die unseren ProductSearch-Service beeinträchtigen. Die WC3 Technical Architecture Group (TAG) hat eine Reihe von Versionsstrategien beschrieben, mit denen wir Schemata für unsere Dienste so entwerfen können, dass Abhängigkeitsprobleme reduziert werden. Diese Strategien reichen von einer übermäßig liberalen Strategie, bei der Dienste nicht zwischen verschiedenen Versionen des Schemas unterscheiden und alle Änderungen akzeptieren müssen, bis zu einem äußerst konservativen Urknall , bei dem der Dienst einen Fehler auslösen muss, wenn er eine unerwartete Version der Nachricht empfängt.

Beide Extreme verursachen Probleme, die keinen Mehrwert für das Unternehmen bieten und die Gesamtbetriebskosten des Systems erhöhen. Explizite und implizite Strategien ohne Versionen führen zu Systemen, die in ihren Interaktionen unvorhersehbar sind, schlecht entwickelt sind und hohe Kosten für Verbesserungen verursachen. Big Bang-Strategien hingegen schaffen stark miteinander verbundene Servicelandschaften, in denen Schaltkreisänderungen alle Lieferanten und Verbraucher betreffen, die Verfügbarkeit beeinträchtigen, die Entwicklung verlangsamen und die Gewinnchancen verringern.

Die Service Community aus unserem Beispiel setzt die Urknallstrategie effektiv um. Angesichts der Kosten für die Steigerung des Werts des Systems für Unternehmen ist klar, dass Lieferanten und Verbraucher von einer flexibleren Versionskontrollstrategie profitieren werden - was die TAG als Kompatibilitätsstrategie bezeichnet . Es bietet direkte und Abwärtskompatibilität von Schaltkreisen. Mit der Entwicklung von Diensten ermöglichen abwärtskompatible Schaltungen Verbrauchern neuer Schaltungen, Instanzen der alten Schaltung zu akzeptieren: Ein Anbieter, der für die Verarbeitung abwärtskompatibler neuer Versionen erstellt wurde, kann die Anforderung jedoch im alten Schaltungsformat annehmen. Die direkte Kompatibilität ermöglicht es Verbrauchern älterer Schemas hingegen, eine Instanz eines neuen Schemas zu verarbeiten. Dies ist ein wichtiger Punkt für bestehende ProductSearch-Benutzer: Wenn die Suchergebnisse ursprünglich unter Berücksichtigung der direkten Kompatibilität erstellt wurden, können Verbraucher die Antworten der neuen Version verarbeiten, ohne dass sie weiterentwickelt werden müssen.

Erweiterungspunkte

Die Schemazuordnung mit Abwärts- und Vorwärtskompatibilität ist eine gut verstandene Entwurfsaufgabe, die am besten durch das Erweiterbarkeitsmuster Must Ignore ausgedrückt wird (siehe Artikel von David Orchard und Deira Obasanjo ). In der Vorlage " Ignorieren" wird empfohlen, dass Schemata Erweiterungspunkte enthalten, mit denen Sie Typen Elemente und zusätzliche Attribute für jedes Element hinzufügen können. In der Vorlage wird außerdem empfohlen, dass XML ein Verarbeitungsmodell beschreibt, das definiert, was Verbraucher mit Erweiterungen tun. Das einfachste Modell erfordert, dass Verbraucher Elemente ignorieren, die sie nicht erkennen - daher der Name der Vorlage. Das Modell kann auch erfordern, dass Verbraucher Elemente mit dem Flag "Must Understanding" verarbeiten oder einen Fehler ausgeben, wenn sie diese nicht verstehen können.

Hier ist unsere ursprüngliche Gliederung des Suchergebnisdokuments:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> 

Lassen Sie uns nun in der Zeit zurückrollen und von Anfang an ein kompatibles, erweiterbares Schema für unseren Service angeben:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> <xs:element minOccurs="0" maxOccurs="1" name="Extension" type="Extension" /> </xs:sequence> </xs:complexType> <xs:complexType name="Extension"> <xs:sequence> <xs:any minOccurs="1" maxOccurs="unbounded" namespace="##targetNamespace" processContents="lax" /> </xs:sequence> </xs:complexType> </xs:schema> 

Dieses Design enthält ein optionales Erweiterungselement für jedes Produkt. Das Erweiterungselement selbst kann ein oder mehrere Elemente aus dem Zielnamespace enthalten:

Abbildung 2: Erweiterbares Suchergebnisschema

Nachdem wir aufgefordert werden, eine Produktbeschreibung hinzuzufügen, können wir ein neues Schema mit einem zusätzlichen Beschreibungselement veröffentlichen , das der Anbieter in den Erweiterungspunkt einfügt. Auf diese Weise kann ProductSearch Ergebnisse mit Produktbeschreibungen zurückgeben, und Verbraucher verwenden das neue Schema, um das gesamte Dokument zu validieren. Verbraucher, die das alte Schema verwenden, werden nicht unterbrochen, obwohl sie das Feld Beschreibung nicht verarbeiten. Ein neues Suchergebnisdokument sieht folgendermaßen aus:

 <?xml version="1.0" encoding="utf-8"?> <Products xmlns="urn:example.com:productsearch:products"> <Product> <CatalogueID>101</CatalogueID> <Name>Widget</Name> <Price>10.99</Price> <Manufacturer>Company A</Manufacturer> <InStock>Yes</InStock> <Extension> <Description>Our top of the range widget</Description> </Extension> </Product> <Product> <CatalogueID>300</CatalogueID> <Name>Fooble</Name> <Price>2.00</Price> <Manufacturer>Company B</Manufacturer> <InStock>No</InStock> <Extension> <Description>Our bargain fooble</Description> </Extension> </Product> </Products> 

Das überarbeitete Schema sieht folgendermaßen aus:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="InStock" type="xs:string" /> <xs:element minOccurs="0" maxOccurs="1" name="Extension" type="Extension" /> </xs:sequence> </xs:complexType> <xs:complexType name="Extension"> <xs:sequence> <xs:any minOccurs="1" maxOccurs="unbounded" namespace="##targetNamespace" processContents="lax" /> </xs:sequence> </xs:complexType> <xs:element name="Description" type="xs:string" /> </xs:schema> 

Beachten Sie, dass die erste Version des erweiterbaren Schemas mit der zweiten und die zweite mit der ersten abwärtskompatibel ist. Diese Flexibilität geht jedoch zu Lasten einer erhöhten Komplexität. Erweiterbare Schemata ermöglichen es uns, unvorhergesehene Änderungen vorzunehmen, bieten jedoch Funktionen, die möglicherweise nie benötigt werden. während wir verlieren:

• Ausdruckskraft durch einfaches Design
• Klare Darstellung der Daten durch Einführung von Metainformationselementen des Containers.

Weiter werden wir nicht auf erweiterbare Schemata eingehen. Es genügt zu sagen, dass die Erweiterungspunkte es uns ermöglichen, direkte und abwärtskompatible Änderungen an den Diagrammen und Dokumenten vorzunehmen, ohne die Lieferanten und Verbraucher des Dienstes zu beeinträchtigen. Die Erweiterung des Systems hilft uns jedoch nicht, die Entwicklung des Systems zu kontrollieren, wenn wir eine Änderung vornehmen müssen, die gegen den Vertrag verstößt.

Kompatibilität brechen

- Ja, unser Team hat in der neuesten Version die Abwärtskompatibilität verletzt! Sie konnten der leichten Optimierung des Protokolls einfach nicht widerstehen ... Nun, sei nicht beleidigt, Süße!
Carla Borin

Unser ProductSearch-Service enthält in den Suchergebnissen ein Feld, das die Verfügbarkeit dieses Produkts angibt. Der Service füllt dieses Feld mit einem teuren Aufruf eines alten Inventarsystems - eine Abhängigkeit, deren Wartung teuer ist. Der Lieferant möchte diese Abhängigkeit beseitigen, das Design bereinigen und die Gesamtsystemleistung verbessern. Und vorzugsweise ohne die Verbraucher zu beeinträchtigen. Bei der Kommunikation mit Verbrauchern stellt das Lieferantenteam fest, dass keine der Verbraucheranwendungen tatsächlich etwas mit diesem Bereich zu tun hat. Das heißt, es ist teuer und überflüssig.

Wenn wir in der aktuellen Situation das InStock-Feld aus unserem erweiterbaren Schema entfernen, werden wir leider bestehende Konsumenten brechen. Um den Anbieter zu reparieren, müssen wir das gesamte System reparieren: Wenn wir die Funktionalität vom Lieferanten entfernen und einen neuen Vertrag veröffentlichen, muss jede Verbraucheranwendung mit einem neuen Schema neu installiert werden, und die Interaktion zwischen den Diensten wird gründlich getestet. Der diesbezügliche ProductSearch-Service kann nicht unabhängig von den Verbrauchern entwickelt werden: Der Lieferant und die Verbraucher müssen "gleichzeitig springen".

Unsere Service-Community ist von ihrer Entwicklung enttäuscht, da jeder Verbraucher eine „versteckte“ Abhängigkeit hat, die den gesamten Vertrag des Lieferanten in der internen Logik des Verbrauchers widerspiegelt. Verbraucher, die die XSD-Validierung und in geringerem Maße die statische Bindung an das Dokumentschema im Code verwenden, akzeptieren implizit den gesamten Lieferantenvertrag, unabhängig von ihrer Absicht, nur einen Teil davon zu verwenden.

David Orchard gibt einige Hinweise, wie wir dieses Problem vermeiden können, und verweist dabei auf das Prinzip der Zuverlässigkeit : "Die Implementierung sollte konservativ in ihrem Verhalten und liberal in dem sein, was sie von anderen akzeptiert." Wir können dieses Prinzip im Kontext der Serviceentwicklung stärken, indem wir festlegen, dass Nachrichtenempfänger eine „ausreichende“ Überprüfung durchführen sollten: Das heißt, sie sollten nur die von ihnen verwendeten Daten verarbeiten und eine explizit eingeschränkte oder gezielte Überprüfung der empfangenen Daten durchführen - im Gegensatz zu einer implizit unbegrenzten Validierung Alles oder nichts in der XSD-Verarbeitung.

Schematron

Eine Möglichkeit, die verbraucherseitige Validierung zu konfigurieren, besteht darin, Masken oder reguläre Ausdrücke für Pfade zu Dokumentelementen zu verwenden, möglicherweise unter Verwendung einer Baumstruktur-Validierungssprache wie Schematron . Mit Schematron kann jeder ProductSearch-Benutzer angeben, was er in den Suchergebnissen erwartet:

 <?xml version="1.0" encoding="utf-8" ?> <schema xmlns="http://www.ascc.net/xml/schematron"> <title>ProductSearch</title> <ns uri="urn:example.com:productsearch:products" prefix="p"/> <pattern name="Validate search results"> <rule context="*//p:Product"> <assert test="p:CatalogueID">Must contain CatalogueID node</assert> <assert test="p:Name">Must contain Name node</assert> <assert test="p:Price">Must contain Price node</assert> </rule> </pattern> 

Schematron-Implementierungen übersetzen normalerweise ein Schematron-Schema wie dieses in eine XSLT-Transformation, die der Nachrichtenempfänger zur Validierung auf das Dokument anwenden kann.

Beachten Sie, dass dieses Diagramm keine Annahmen zu Elementen im Quelldokument enthält, die von der Verbraucheranwendung nicht benötigt werden. Daher wird die Validierung nur der erforderlichen Elemente explizit beschrieben. Änderungen am Schema des Quelldokuments werden während der Validierung nicht abgelehnt, wenn sie nicht gegen die im Schematron-Schema beschriebenen expliziten Erwartungen verstoßen, selbst wenn zuvor erforderliche Elemente entfernt werden.

Hier finden Sie eine relativ einfache Lösung für unsere Probleme mit Verträgen und Abhängigkeiten. Dazu müssen wir dem Dokument keine impliziten Metainformationselemente hinzufügen. Lassen Sie uns also rechtzeitig zurückrollen und die am Anfang des Artikels beschriebene einfache Schaltung wiederherstellen. Dieses Mal werden wir jedoch auch darauf bestehen, dass die Verbraucher in ihrem Verhalten frei sind und nur die Informationen validieren und verarbeiten, die sie benötigen (unter Verwendung von Schematron-Schemata, nicht von XSD, um empfangene Nachrichten zu überprüfen). Nachdem ein Lieferant eine Beschreibung für ein Produkt hinzugefügt hat, kann er eine überarbeitete Gliederung veröffentlichen, ohne bestehende Kunden zu beeinträchtigen. Wenn das InStock-Feld von keinem der Verbraucher überprüft oder verarbeitet wird, kann der Dienst das Suchergebnisdiagramm erneut überarbeiten, ohne die Verbraucher zu beeinträchtigen.

Am Ende dieses Prozesses sieht das ProductSearch-Antwortschema folgendermaßen aus:

 <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns="urn:example.com:productsearch:products" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="urn:example.com:productsearch:products" id="Products"> <xs:element name="Products" type="Products" /> <xs:complexType name="Products"> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" name="Product" type="Product" /> </xs:sequence> </xs:complexType> <xs:complexType name="Product"> <xs:sequence> <xs:element name="CatalogueID" type="xs:int" /> <xs:element name="Name" type="xs:string" /> <xs:element name="Price" type="xs:double" /> <xs:element name="Manufacturer" type="xs:string" /> <xs:element name="Description" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> 

Verbrauchergesteuerte Verträge

Die Verwendung von Schematron im obigen Beispiel führt zu einigen interessanten Schlussfolgerungen über Verträge zwischen Lieferanten und Verbrauchern, die über die Validierung von Dokumenten hinausgehen. In diesem Abschnitt werden einige dieser Ideen hervorgehoben, zusammengefasst und in Form der Vorlage ausgedrückt, die wir als Verbraucherverträge bezeichnen .

Das erste, was zu beachten ist, ist, dass Dokumentschemata nur ein Teil dessen sind, was ein Dienstanbieter den Verbrauchern anbieten sollte, damit sie seine Funktionalität nutzen können. Wir nennen diese ausgelagerten Informationen einen Lieferantenvertrag .

Lieferantenverträge

Der Lieferantenvertrag beschreibt die Funktionalität des Dienstes als eine Reihe exportierter Elemente, die zur Verwendung dieser Funktionalität erforderlich sind. In Bezug auf die Serviceentwicklung ist ein Vertrag ein Container für eine Reihe exportierter Elemente, die Geschäftsfunktionen beschreiben. Eine Liste dieser Elemente enthält:

• Schemata von Dokumenten . Wir haben bereits ausführlich Dokumentschemata besprochen. Dokumentschemata sind neben den Schnittstellen Bestandteil des Lieferantenvertrags, dessen Änderung höchstwahrscheinlich im Zuge der Entwicklung des Dienstes erfolgt. Vielleicht sind sie deshalb auch die Teile, mit denen wir die meiste Implementierungserfahrung mit verschiedenen Serviceentwicklungsstrategien haben, wie z. B. Erweiterungspunkten und der Verwendung von Masken für Pfade zum Dokumentieren von Elementen.
• Schnittstellen In ihrer einfachsten Form enthalten Anbieterschnittstellen eine Reihe exportierter Transaktionssignaturen, mit denen ein Verbraucher das Verhalten des Lieferanten steuern kann. Messaging-Systeme exportieren normalerweise relativ einfache Transaktionssignaturen und fügen Geschäftsinhalte in die Nachrichten ein, die sie austauschen. In solchen Systemen werden empfangene Nachrichten gemäß der im Header oder Textkörper der Nachricht codierten Semantik verarbeitet. RPC- , , - . , , , , .
• . , , "-" "fire-and-forget". , . , , . , «» , , , "" . , " ", , . , , .
• . , , , , . , . Web- WS-Policy , WS-SecurityPolicy, " ", .
• . , , , , . .

, , , , . , : , . , - , , , , . , , WS-Basic, .

, . , , , .

, ? , , (, ) , . , , , , - . .

:

• . , , , .
• . .
• . / (. "Validity of Data in Bounded Space and Time" Data on the Outside vs. Data on the Inside ). , .

, — , — . Schematron . , , . , , , , "" , . , , , - , .

, /, , ( ). , , , .

, , , , , . , , .

3:

:

• . . .
• . , . - , - . , , . , . , ; .
• . , / .

Consumer-Driven Contracts

. , , , . , , . , . , Consumer-Driven Contracts .

---, . , , . ; , , .

Consumer-Driven Contracts :

• . , . , / , / .
• . , , .
• . . , Consumer-Driven Contract , . , , .

, :

Implementierung

Consumer-Driven Contracts , Consumer-Driven Contracts. , , , / .

. , -. unit-, , , . Schematron WS-Policy, .

, , . Consumer-Driven Contracts , , , , . / , . , , - .

Die Vorteile

Consumer-Driven Contracts , . -, . , . Consumer-driven contracts , , — , , . "" , -, . — — , .

, , . Consumer-Driven Contracts . Consumer-driven contracts , , . , , , , . , , .

Consumer-Driven Contracts , , Consumer-Driven Contracts , . , , CDC.

Consumer-Driven Contracts , , : , , , . , , , . .

, , Consumer-Driven Contracts, , . , — : , . , , , . , , , , . , — , deprecated , .

Consumer-Driven Contracts . , , . , , «» , .

, Consumer-Driven Contracts . , - — - — , , , WS-Agreement WSLA, SLA. , ; . — — , " " .

, : , . , , , , .

Referenzen

1. Ian Robinson. Consumer-Driven Contracts ( )
2. Martin Fowler. Microservices , Decentralized Governance
3. . , " "
   
4. .