- Rahasia kesuksesan pemasok adalah untuk menyediakan konsumen dengan produk-produk berkualitas ... oh, yaitu, layanan. Yah dan juga penting untuk tidak menikmati semua serius dengan pelanggaran kompatibilitas.
Walter White
Dari penerjemah
Apa ini
Ini adalah terjemahan dari artikel yang menggambarkan templat Kontrak yang Didorong Konsumen (CDC).
Aslinya diterbitkan di situs web Martin Fowler oleh Ian Robinson .
Kenapa begitu
Dalam arsitektur microservice, dependensi antara layanan adalah sumber masalah. Template CDC membantu menyelesaikan masalah ini dengan cara yang sesuai dengan pengembang layanan dan konsumennya. Fowler mengutip Kontrak yang Didorong Konsumen dalam artikel utamanya tentang arsitektur microservice: Microservices .
Untuk siapa ini
Artikel ini akan sangat berguna bagi tim yang mengembangkan layanan untuk beberapa konsumen dalam organisasi yang sama, dan tim yang menggunakan layanan tersebut.
Tentang persyaratan
- Saya tidak menerjemahkan Kontrak yang Didorong oleh Konsumen ke dalam Bahasa Rusia - kami tidak menerjemahkan Pengembangan yang Didorong oleh Uji dalam suatu percakapan. Jika perlu, Anda dapat menggunakan opsi Kontrak yang berorientasi pelanggan .
- Kontrak Penyedia dan Kontrak Konsumen diterjemahkan sebagai kontrak pemasok dan kontrak konsumen - kontrak tersebut digunakan secara berkelanjutan dalam bahasa Rusia.
- Pengembangan atau evolusi layanan (evolusi layanan) - perbaikan, perluasan fungsionalitas layanan.
- Komunitas layanan (komunitas layanan) - pemasok plus semua konsumen layanan ini.
Pembukaan
Artikel ini membahas masalah yang muncul antara pengembang dan konsumen layanan, misalnya, ketika pemasok mengubah bagian dari kontrak mereka, khususnya, tata letak dokumen. Dua strategi untuk mengatasinya dijelaskan:
- Menambahkan titik ekstensi.
- "Cukup" validasi pesan yang diterima.
Kedua strategi membantu melindungi konsumen dari perubahan dalam kontrak, tetapi tidak memberikan wawasan penyedia layanan:
- cara terbaik untuk menggunakan strategi ini;
- apa yang perlu dilakukan saat layanan berkembang.
Artikel ini menjelaskan templat Kontrak yang Didorong Konsumen , yang memungkinkan pemasok untuk lebih memahami pelanggan mereka dan memfokuskan pengembangan layanan pada apa yang dibutuhkan konsumen.
Contoh evolusi layanan
Untuk mengilustrasikan beberapa masalah yang kami temui ketika mengembangkan layanan, pertimbangkan ProductSearch sederhana, yang memungkinkan Anda untuk mencari di katalog produk kami. Hasil pencarian memiliki struktur berikut:
Gambar 1: Diagram hasil pencarian
Contoh dokumen dengan hasil pencarian adalah sebagai berikut:
<?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 saat ini digunakan oleh dua aplikasi: aplikasi pemasaran internal dan aplikasi web reseller eksternal. Kedua klien menggunakan XSD untuk memverifikasi dokumen yang diterima sebelum memprosesnya. Aplikasi internal menggunakan bidang CatalogIDID, Nama, Harga, dan Pabrikan; aplikasi eksternal - bidang CatalogIDID, Nama dan Harga. Tak satu pun dari mereka menggunakan bidang InStock: meskipun dianggap sebagai aplikasi pemasaran, itu dibuang pada tahap awal pengembangan.
Salah satu cara paling umum untuk mengembangkan layanan adalah menambahkan bidang ke dokumen untuk satu atau lebih konsumen. Bergantung pada bagaimana bagian klien dan server diimplementasikan, bahkan perubahan sederhana seperti ini dapat memiliki konsekuensi yang mahal untuk bisnis dan mitranya.
Dalam contoh kami, setelah layanan ProductSearch telah berjalan selama beberapa waktu, pengecer kedua ingin menggunakannya, tetapi meminta untuk menambahkan bidang Deskripsi ke setiap produk. Karena cara pelanggan diatur, perubahan ini memiliki konsekuensi yang signifikan dan mahal bagi pemasok dan pelanggan yang ada. Biaya masing-masing tergantung pada bagaimana kami menerapkan perubahan. Setidaknya ada dua cara di mana kita dapat berbagi biaya perubahan antara anggota "komunitas layanan". Pertama, kami dapat mengubah skema asli kami dan meminta setiap konsumen memperbarui salinan skema mereka untuk memeriksa hasil pencarian dengan benar. Biaya untuk mengubah sistem di sini didistribusikan antara pemasok, yang, dihadapkan dengan permintaan untuk perubahan, masih akan membuat beberapa perubahan; dan konsumen yang tidak tertarik dengan fungsionalitas yang diperbarui. Di sisi lain, kita bisa menambahkan operasi dan skema kedua untuk pelanggan baru dan mempertahankan operasi dan skema asli untuk pelanggan yang sudah ada. Semua perbaikan sekarang berada di pihak pemasok, tetapi kompleksitas layanan dan biaya dukungannya meningkat.
Interlude: SOA Terbakar
Keuntungan utama menggunakan layanan adalah:
- Meningkatkan fleksibilitas organisasi.
- Turunkan biaya keseluruhan untuk mengimplementasikan perubahan.
SOA meningkatkan fleksibilitas dengan menempatkan fungsi bisnis dalam layanan khusus yang dapat digunakan kembali. Kemudian layanan ini digunakan dan diatur untuk melakukan proses bisnis utama. Ini mengurangi biaya perubahan dengan mengurangi ketergantungan di antara layanan, memungkinkan mereka untuk dengan cepat membangun kembali dan menyesuaikan respons terhadap perubahan atau peristiwa yang tidak direncanakan.
Namun, bisnis dapat sepenuhnya menyadari manfaat ini hanya jika penerapan SOA memungkinkan layanan berkembang secara mandiri. Untuk meningkatkan independensi, kami membuat kontrak layanan. Meskipun demikian, kami dipaksa untuk memodifikasi konsumen sesering pemasok, terutama karena konsumen bergantung pada versi spesifik kontrak pemasok. Pada akhirnya, pemasok mulai sangat berhati-hati dalam memodifikasi elemen kontrak apa pun; khususnya, karena mereka tidak tahu bagaimana konsumen menerapkan kontrak ini. Dalam kasus terburuk, konsumen terikat dengan pemasok, menggambarkan seluruh garis besar dokumen sebagai bagian dari logika internal mereka.
Kontrak memastikan independensi layanan; secara paradoks, mereka juga dapat mengikat pemasok dan konsumen dengan cara yang tidak diinginkan. Tanpa memikirkan fungsi dan peran kontrak yang kami terapkan dalam SOA kami, kami mengekspos layanan kami untuk komunikasi "rahasia". Tidak adanya informasi tentang bagaimana konsumen layanan mengimplementasikan kontrak dalam kode, serta kurangnya batasan implementasi (untuk pemasok dan konsumen), bersama-sama merusak manfaat yang dirasakan dari SOA. Singkatnya, suatu perusahaan mulai bosan dengan layanan.
Versi Skema
Kami dapat mulai meneliti masalah kontrak dan dependensi yang mengganggu layanan ProductSearch kami dengan membuat versi skema. Grup Arsitektur Teknis WC3 (TAG) telah menggambarkan sejumlah strategi versi yang dapat membantu kami merancang sirkuit untuk layanan kami dengan cara yang mengurangi masalah ketergantungan. Strategi-strategi ini berkisar dari tidak ada yang terlalu liberal, yang membutuhkan layanan untuk tidak membedakan antara versi berbeda dari skema dan menerima semua perubahan, hingga big bang yang sangat konservatif, yang mengharuskan layanan untuk membuat kesalahan jika menerima versi pesan yang tidak terduga.
Kedua ekstrem tersebut menciptakan masalah yang tidak memberikan nilai bagi bisnis dan meningkatkan total biaya kepemilikan sistem. Strategi "tanpa versi" yang eksplisit dan implisit mengarah pada sistem yang tidak dapat diprediksi dalam interaksinya, dikembangkan dengan buruk, dan memiliki biaya perbaikan yang tinggi. Strategi Big Bang, di sisi lain, menciptakan lanskap layanan yang sangat saling terkait di mana perubahan sirkuit mempengaruhi semua pemasok dan konsumen, mengganggu ketersediaan, memperlambat pengembangan, dan mengurangi peluang keuntungan.
Komunitas Layanan dari contoh kami secara efektif mengimplementasikan strategi Big Bang. Mengingat biaya untuk meningkatkan nilai sistem untuk bisnis, jelas bahwa pemasok dan konsumen akan mendapat manfaat dari strategi kontrol versi yang lebih fleksibel - yang oleh TAG disebut sebagai strategi kompatibilitas . Ini memberikan kompatibilitas langsung dan mundur dari sirkuit. Dengan pengembangan layanan, skema yang kompatibel mundur memungkinkan konsumen skema baru untuk menerima contoh skema lama: penyedia yang dibuat untuk memproses versi baru yang kompatibel mundur dapat, bagaimanapun, menerima permintaan dalam format skema lama. Kompatibilitas langsung, di sisi lain, memungkinkan konsumen skema lama untuk memproses instance skema baru. Ini adalah poin utama bagi pengguna ProductSearch yang ada: jika hasil pencarian awalnya dirancang dengan kompatibilitas langsung, konsumen dapat memproses tanggapan versi baru tanpa perlu pengembangan lebih lanjut.
Poin ekstensi
Pemetaan skema dengan kompatibilitas ke belakang dan ke depan adalah tugas desain yang dipahami dengan baik, paling baik diungkapkan oleh pola ekstensibilitas Must Ignore (lihat artikel oleh David Orchard dan Deira Obasanjo ). Templat Must Ignore merekomendasikan agar skema menyertakan titik ekstensi yang memungkinkan Anda menambahkan elemen ke tipe dan atribut tambahan untuk setiap elemen. Templat juga merekomendasikan agar XML menjelaskan model pemrosesan yang menentukan apa yang dilakukan konsumen dengan ekstensi. Model paling sederhana mengharuskan konsumen untuk mengabaikan elemen-elemen yang tidak mereka kenali - karena itulah nama templat. Model ini juga dapat meminta konsumen untuk memproses elemen-elemen yang memiliki bendera Must Understanding, atau memberikan kesalahan jika mereka tidak dapat memahaminya.
Ini adalah garis besar asli dari dokumen hasil pencarian kami:
<?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>
Sekarang mari kembali ke masa lalu, dan dari awal kami akan menunjukkan skema yang kompatibel dan dapat diperluas untuk layanan kami:
<?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>
Desain ini mencakup elemen ekstensi opsional untuk setiap produk. Elemen ekstensi itu sendiri dapat berisi satu atau lebih elemen dari namespace target:
Gambar 2: Skema Hasil Pencarian yang Dapat Diperluas
Sekarang kami diminta untuk menambahkan deskripsi produk, kami dapat menerbitkan skema baru dengan elemen Deskripsi tambahan, yang dimasukkan oleh penyedia ke titik ekstensi. Ini memungkinkan ProductSearch mengembalikan hasil yang berisi deskripsi produk, dan konsumen menggunakan skema baru untuk memvalidasi seluruh dokumen. Konsumen yang menggunakan skema lama tidak akan putus, meskipun mereka tidak akan memproses bidang Deskripsi. Dokumen hasil pencarian baru terlihat seperti ini:
<?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>
Skema yang direvisi terlihat seperti ini:
<?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>
Perhatikan bahwa versi pertama dari skema extensible kompatibel dengan yang kedua, dan yang kedua kompatibel dengan yang pertama. Namun, fleksibilitas ini datang dengan biaya peningkatan kompleksitas. Skema yang diperluas memungkinkan kita untuk membuat perubahan yang tidak terduga, tetapi mereka menyediakan fitur yang mungkin tidak pernah dibutuhkan; sementara kita kalah:
- ekspresi dari desain yang sederhana
- jelas penyajian data dengan memperkenalkan elemen informasi meta wadah.
Lebih lanjut kami tidak akan membahas skema yang diperluas. Cukuplah untuk mengatakan bahwa titik ekspansi memungkinkan kita untuk membuat perubahan yang kompatibel langsung dan mundur dalam diagram dan dokumen, tanpa mempengaruhi pemasok dan konsumen layanan. Namun, memperluas skema tidak membantu kita mengendalikan evolusi sistem ketika kita perlu melakukan perubahan yang melanggar kontrak.
Memutus kompatibilitas
- Ya, tim kami melanggar kompatibilitas ke belakang dalam rilis terbaru! Mereka tidak bisa menahan sedikit optimasi protokol ... Yah, jangan tersinggung, sayang!
Carla Borin
Layanan ProductSearch kami termasuk dalam hasil pencarian bidang yang menunjukkan ketersediaan produk ini. Layanan ini mengisi bidang ini menggunakan panggilan mahal ke sistem inventaris kuno - ketergantungan yang mahal untuk dipelihara. Pemasok ingin menghapus ketergantungan ini, membersihkan desain, dan meningkatkan kinerja sistem secara keseluruhan. Dan lebih disukai, tanpa mempengaruhi konsumen. Berkomunikasi dengan konsumen, tim pemasok menemukan bahwa tidak ada aplikasi konsumen yang benar-benar melakukan apa pun dalam bidang ini; yaitu, karena mahal, itu mubazir.
Sayangnya, dalam situasi saat ini, jika kami menghapus bidang InStock dari skema kami yang dapat diperluas, kami akan memecah konsumen yang ada. Untuk memperbaiki penyedia, kami harus memperbaiki seluruh sistem: ketika kami menghapus fungsionalitas dari pemasok dan menerbitkan kontrak baru, setiap aplikasi konsumen perlu diinstal ulang dengan skema baru, dan interaksi antara layanan harus diuji secara menyeluruh. Layanan ProductSearch dalam hal ini tidak dapat dikembangkan secara independen dari konsumen: pemasok dan konsumen harus "melompat pada saat yang sama."
Komunitas layanan kami kecewa dengan evolusinya, karena setiap konsumen memiliki ketergantungan "tersembunyi", yang mencerminkan seluruh kontrak pemasok dalam logika internal konsumen. Konsumen, menggunakan validasi XSD dan, pada tingkat lebih rendah, mengikat statis ke skema dokumen dalam kode, secara implisit menerima seluruh kontrak pemasok, terlepas dari niat mereka untuk menggunakan hanya sebagian.
David Orchard memberikan beberapa petunjuk tentang bagaimana kita dapat menghindari masalah ini, merujuk pada prinsip keandalan : "Implementasi harus konservatif dalam perilakunya dan liberal dalam hal apa yang diterimanya dari orang lain." Kami dapat memperkuat prinsip ini dalam konteks pengembangan layanan dengan menyatakan bahwa penerima pesan harus melakukan verifikasi "cukup": yaitu, mereka hanya boleh memproses data yang mereka gunakan, dan harus melakukan verifikasi data yang mereka terima secara terbatas atau bertarget - yang bertentangan dengan validasi tak terbatas secara implisit Semua atau tidak ada yang melekat dalam pemrosesan XSD.
Schematron
Salah satu cara kita dapat mengonfigurasi validasi sisi konsumen adalah dengan menggunakan topeng atau ekspresi reguler untuk jalur ke elemen dokumen, mungkin menggunakan bahasa validasi struktur pohon seperti Schematron . Menggunakan Schematron, setiap pengguna ProductSearch dapat menentukan apa yang mereka harapkan akan temukan dalam hasil pencarian:
<?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>
Implementasi Schematron biasanya menerjemahkan skema Schematron, seperti yang ini, ke dalam transformasi XSLT yang dapat diterapkan oleh penerima pesan ke dokumen untuk divalidasi.
Perhatikan bahwa diagram ini tidak mengandung asumsi tentang elemen dalam dokumen sumber yang tidak diperlukan oleh aplikasi konsumen. Dengan demikian, validasi hanya elemen yang diperlukan dijelaskan secara eksplisit. Perubahan pada skema dokumen sumber tidak akan ditolak selama validasi jika mereka tidak melanggar harapan eksplisit yang dijelaskan dalam skema Schematron, bahkan jika itu menghilangkan elemen yang diperlukan sebelumnya.
Ini adalah solusi yang relatif mudah untuk masalah kita dengan kontrak dan ketergantungan, dan ini tidak mengharuskan kita untuk menambahkan elemen meta-informasi implisit ke dalam dokumen. Jadi, mari kembali ke masa lalu dan kembalikan sirkuit sederhana yang dijelaskan di awal artikel. Namun kali ini, kami juga akan menegaskan bahwa konsumen bebas dalam perilaku mereka dan memvalidasi dan hanya memproses informasi yang mereka butuhkan (menggunakan skema Schematron, bukan XSD untuk memeriksa pesan yang diterima). Sekarang pemasok menambahkan deskripsi untuk suatu produk, ia dapat menerbitkan garis besar yang direvisi tanpa mempengaruhi pelanggan yang ada. Demikian pula, jika menemukan bahwa bidang InStock tidak dicentang atau diproses oleh salah satu konsumen, layanan dapat merevisi diagram hasil pencarian - lagi, tanpa mempengaruhi konsumen.
Pada akhir proses ini, skema respons ProductSearch terlihat seperti ini:
<?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>
Kontrak yang Didorong oleh Konsumen
Menggunakan Schematron dalam contoh di atas mengarah pada beberapa kesimpulan menarik tentang kontrak antara pemasok dan konsumen yang melampaui validasi dokumen. Di bagian ini, kami menyoroti dan merangkum beberapa gagasan ini dan mengekspresikannya dalam kerangka yang kami sebut Kontrak Konsumen .
Hal pertama yang perlu diperhatikan adalah skema dokumen hanya bagian dari apa yang harus ditawarkan penyedia layanan kepada konsumen sehingga mereka dapat menggunakan fungsinya. Kami menyebut informasi ini sebagai kontrak vendor .
Kontrak Pemasok
Kontrak vendor menjelaskan fungsionalitas layanan sebagai serangkaian elemen yang diekspor yang diperlukan untuk menggunakan fungsionalitas ini. Dalam hal pengembangan layanan, kontrak adalah wadah untuk satu set elemen yang diekspor yang menggambarkan fungsi bisnis. Daftar barang-barang ini meliputi:
- Skema dokumen . Kami sudah membahas skema dokumen detail. Seiring dengan antarmuka, skema dokumen adalah bagian dari kontrak pemasok, perubahan yang paling mungkin terjadi saat layanan berkembang; tetapi mungkin karena ini mereka juga merupakan bagian yang kami punya pengalaman implementasi paling banyak dengan berbagai strategi pengembangan layanan, seperti titik ekstensi dan menggunakan topeng untuk jalur untuk mendokumentasikan elemen.
- Antarmuka Dalam bentuknya yang paling sederhana, antarmuka penyedia menyertakan satu set tanda tangan transaksi yang diekspor yang dapat digunakan konsumen untuk mengontrol perilaku pemasok. Sistem pesan biasanya mengekspor tanda tangan transaksi yang relatif sederhana dan memasukkan konten bisnis ke dalam pesan yang mereka tukarkan. Dalam sistem seperti itu, pesan yang diterima diproses sesuai dengan semantik yang dikodekan di header atau badan pesan. RPC- , , - . , , , , .
- . , , "-" "fire-and-forget". , . , , . , «» , , , "" . , " ", , . , , .
- . , , , , . , . Web- WS-Policy , WS-SecurityPolicy, " ", .
- . , , , , . .
, , , , . , : , . , - , , , , . , , WS-Basic, .
, . , , , .
, ? , , (, ) , . , , , , - . .
:
, — , — . Schematron . , , . , , , , "" , . , , , - , .
, /, , ( ). , , , .
, , , , , . , , .
3:
:
- . . .
- . , . - , - . , , . , . , ; .
- . , / .
Consumer-Driven Contracts
. , , , . , , . , . , Consumer-Driven Contracts .
---, . , , . ; , , .
Consumer-Driven Contracts :
- . , . , / , / .
- . , , .
- . . , Consumer-Driven Contract , . , , .
, :
Implementasi
Consumer-Driven Contracts , Consumer-Driven Contracts. , , , / .
. , -. unit-, , , . Schematron WS-Policy, .
, , . Consumer-Driven Contracts , , , , . / , . , , - .
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. , ; . — — , " " .
, : , . , , , , .
Referensi
- Ian Robinson. Consumer-Driven Contracts ( )
- Martin Fowler. Microservices , Decentralized Governance
- . , " "
- .