العقود المدفوعة بالمستهلك كوسيلة لتطوير الخدمة

- سر نجاح المورد هو تزويد المستهلكين بمنتجات عالية الجودة ... أي الخدمة. حسنًا ، ومن المهم أيضًا عدم الانغماس في كل ما هو خطير مع انتهاك التوافق العكسي.
والتر وايت

من المترجم

ما هذا

هذه ترجمة لمقال يصف قالب العقود الموجهة للمستهلكين (CDC).
تم نشر النسخة الأصلية على موقع Martin Fowler بواسطة Ian Robinson .

لماذا هذا

في بنية الخدمات الصغيرة ، تعتبر التبعيات بين الخدمات مصدرًا للمشكلات. يساعد قالب CDC على حل هذه المشاكل بطريقة تناسب كلاً من مطوري الخدمة والمستهلكين. يستشهد فاولر بالعقود التي يوجهها المستهلك في مقاله الرئيسي حول بنية الخدمات الصغيرة : الخدمات الصغيرة .

لمن هو

ستكون هذه المقالة مفيدة بشكل خاص لفرق تطوير الخدمات للعديد من المستهلكين داخل نفس المؤسسة ، والفرق التي تستهلك مثل هذه الخدمات.

حول الشروط

• لم أترجم العقود الموجهة نحو المستهلك إلى اللغة الروسية - نحن لا نترجم التطوير القائم على الاختبار في محادثة. إذا لزم الأمر ، يمكنك استخدام خيار العقود الموجهة للعملاء .
• تتم ترجمة عقد الموفر وعقد المستهلك على أنه عقد مورد وعقد استهلاكي - ولهما استخدام مستدام في روسيا.
• تطوير أو تطور خدمة (تطور الخدمة) - صقل وتوسيع وظائف الخدمة.
• مجتمع الخدمة (مجتمع الخدمة) - المورد بالإضافة إلى جميع مستهلكي هذه الخدمة.

الديباجة

تتناول هذه المقالة المشكلات التي تنشأ بين مطوري الخدمات ومستهلكي الخدمات ، على سبيل المثال ، عندما يغير الموردون جزءًا من عقدهم ، على وجه الخصوص ، تخطيطات المستندات. يتم وصف استراتيجيتين للتعامل معها:

1. إضافة نقاط الامتداد.
2. التحقق "الكافي" من الرسائل المستلمة.

تساعد كلتا الإستراتيجيتين في حماية المستهلكين من التغييرات في العقد ، ولكن لا تعطي مقدم الخدمة نظرة ثاقبة:

• أفضل طريقة لاستخدام هذه الاستراتيجيات ؛
• ما يجب القيام به مع تطور الخدمة.

تصف المقالة نموذج العقود الموجهة للمستهلكين ، والذي يسمح للموردين بفهم عملائهم بشكل أفضل ويركز تطوير الخدمة على ما يحتاجه المستهلكون.

مثال على تطور الخدمة

لتوضيح بعض المشكلات التي نواجهها عند تطوير الخدمات ، ضع في اعتبارك إجراء بحث بسيط عن المنتج ، والذي يسمح لك بالبحث في كتالوج منتجاتنا. نتيجة البحث لها الهيكل التالي:

الشكل 1: مخطط نتيجة البحث

مستند مثال مع نتائج البحث هو كما يلي:

<?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 قيد الاستخدام حاليًا من خلال تطبيقين: تطبيق تسويق داخلي وتطبيق ويب خارجي للموزع. يستخدم كلا العملاء XSD للتحقق من المستندات المستلمة قبل معالجتها. يستخدم التطبيق الداخلي حقول CatalogIDID والاسم والسعر والشركة المصنعة ؛ تطبيق خارجي - حقول CatalogIDID والاسم والسعر. لا يستخدم أي منهم حقل InStock: على الرغم من أنه تم اعتباره لتطبيق تسويق ، فقد تم طرحه في مرحلة مبكرة من التطوير.

تتمثل إحدى الطرق الأكثر شيوعًا لتطوير خدمة في إضافة حقل إلى مستند لعميل واحد أو أكثر. اعتمادًا على كيفية تنفيذ أجزاء العميل والخادم ، حتى التغييرات البسيطة مثل هذه يمكن أن يكون لها عواقب باهظة التكلفة على الأعمال وشركائها.

في مثالنا ، بعد تشغيل خدمة ProductSearch لبعض الوقت ، يرغب مورد ثان في استخدامها ، ولكنه يطلب إضافة حقل الوصف إلى كل منتج. نظرًا للطريقة التي يتم بها ترتيب العملاء ، فإن هذا التغيير له عواقب كبيرة ومكلفة لكل من المورد والعملاء الحاليين. تعتمد تكلفة كل منها على كيفية تنفيذ التغيير. هناك طريقتان على الأقل يمكننا من خلالهما مشاركة تكلفة التغييرات بين أعضاء "مجتمع الخدمة". أولاً ، يمكننا تغيير مخططنا الأصلي ونطلب من كل مستهلك تحديث نسخته من المخطط للتحقق من نتائج البحث بشكل صحيح. يتم توزيع تكلفة تغيير النظام هنا بين المورد ، الذي سيواجه بعض التغييرات في مواجهة طلب التغيير هذا ؛ والمستهلكين غير المهتمين بالوظائف المحدثة. من ناحية أخرى ، يمكننا إضافة عملية ومخطط ثانٍ لعميل جديد والحفاظ على العملية والمخطط الأصلي للعملاء الحاليين. جميع التحسينات الآن في جانب المورد ، ولكن تعقيد الخدمة وتكلفة دعمها في تزايد.

استراحة: أحرق الخدمية

المزايا الرئيسية لاستخدام الخدمات هي:

1. زيادة المرونة التنظيمية.
2. انخفاض التكاليف الإجمالية لتنفيذ التغييرات.

يعزز SOA المرونة من خلال وضع وظائف الأعمال في خدمات مخصصة وقابلة لإعادة الاستخدام. ثم يتم استخدام هذه الخدمات وتنسيقها لتنفيذ العمليات التجارية الرئيسية. هذا يقلل من تكلفة التغييرات عن طريق تقليل التبعيات بين الخدمات ، مما يسمح لها بإعادة البناء بسرعة وضبط استجابة للتغيرات أو الأحداث غير المخطط لها.

ومع ذلك ، لا يمكن للأعمال تحقيق هذه الفوائد بالكامل إلا إذا كان تنفيذ الخدمية يسمح بتطور الخدمات بشكل مستقل. لزيادة الاستقلال ، نقوم بإنشاء عقود الخدمة. على الرغم من ذلك ، نحن مضطرون إلى تعديل المستهلكين في كثير من الأحيان مثل المورد ، ويرجع ذلك أساسًا إلى أن المستهلكين يعتمدون على النسخة المحددة من عقد المورد. في النهاية ، يبدأ الموردون في توخي الحذر الشديد في تعديل أي عنصر من عناصر العقد ؛ على وجه الخصوص ، لأنه ليس لديهم فكرة عن كيفية تنفيذ المستهلكين لهذا العقد. في أسوأ الحالات ، يرتبط المستهلكون بالمورد ، ويصف المخطط الكامل للمستند كجزء من منطقهم الداخلي.

العقود تضمن استقلالية الخدمة ؛ ومن المفارقات ، أنه يمكنهم أيضًا ربط الموردين والمستهلكين بطرق غير مرغوب فيها. دون التفكير في وظيفة ودور العقود التي ننفذها في خدمتنا ، فإننا نعرض خدماتنا للاتصالات "السرية". إن عدم وجود أي معلومات حول كيفية تنفيذ مستهلكي الخدمة للعقد في المدونة ، بالإضافة إلى عدم وجود قيود على التنفيذ (لكل من المورد والمستهلك) ، يقوضان معًا الفوائد المتصورة لـ SOA. باختصار ، تبدأ المؤسسة في إرهاق الخدمات.

تعيين إصدار المخطط

يمكننا البدء في البحث عن مشكلات العقد والتبعيات التي تتداخل مع خدمة ProductSearch من خلال إصدار المخطط. وصفت مجموعة WC3 Technical Architecture Group (TAG) عددًا من استراتيجيات الإصدار التي يمكن أن تساعدنا في تصميم الدوائر لخدماتنا بطرق تقلل من مشكلات التبعية. تتراوح هذه الإستراتيجيات من لا شيء مفرط الليبرالية ، والذي يتطلب من الخدمات عدم التمييز بين الإصدارات المختلفة من النظام وقبول جميع التغييرات ، إلى انفجار كبير متحفظ للغاية ، والذي يتطلب من الخدمة إلقاء خطأ إذا تلقت نسخة غير متوقعة من الرسالة.

كلا التطرفين يخلقان مشاكل لا توفر قيمة للأعمال وتزيد من التكلفة الإجمالية لملكية النظام. تؤدي استراتيجيات "عدم وجود إصدارات" الصريحة والضمنية إلى أنظمة لا يمكن التنبؤ بها في تفاعلاتها ، وضعف تطويرها ، ولها تكلفة عالية من التحسينات. من ناحية أخرى ، تعمل استراتيجيات Big Bang على إنشاء مناظر طبيعية للخدمة مترابطة للغاية تؤثر فيها تغييرات الدائرة على جميع الموردين والمستهلكين ، مما يعوق التوافر ، وتباطؤ التطوير ، ويقلل فرص الربح.

يقوم مجتمع الخدمة من مثالنا بتنفيذ استراتيجية Big Bang بشكل فعال. نظرًا لتكاليف زيادة قيمة النظام للأعمال ، من الواضح أن الموردين والمستهلكين سيستفيدون من استراتيجية أكثر مرونة للتحكم في الإصدارات - ما تسميه TAG استراتيجية التوافق . يوفر التوافق المباشر والخلفي للدوائر. مع تطوير الخدمات ، تسمح المخططات المتوافقة مع الإصدارات السابقة للمستهلكين للمخططات الجديدة بقبول مثيلات المخطط القديم: ومع ذلك ، يمكن لمزود تم إنشاؤه لمعالجة الإصدارات الجديدة المتوافقة مع السابقة قبول الطلب بتنسيق المخطط القديم. من ناحية أخرى ، يسمح التوافق المباشر للمستهلكين من المخططات القديمة بمعالجة مثيل مخطط جديد. هذه نقطة رئيسية لمستخدمي ProductSearch الحاليين: إذا كانت نتائج البحث مصممة أصلاً مع وضع التوافق المباشر في الاعتبار ، فيمكن للمستهلكين معالجة استجابات الإصدار الجديد دون الحاجة إلى مزيد من التطوير.

نقاط التمديد

يعد تخطيط المخطط بالتوافق مع الإصدارات السابقة والأمامية مهمة تصميم مفهومة جيدًا ، يتم التعبير عنها بشكل أفضل من خلال نمط التمدد الذي يجب تجاهله (راجع مقالات ديفيد أورتشارد وديرة أوباسانجو ). يوصي قالب Must Ignore بأن تتضمن المخططات نقاط امتداد تسمح لك بإضافة عناصر إلى الأنواع وسمات إضافية لكل عنصر. يوصي القالب أيضًا بأن يصف XML نموذج معالجة يحدد ما يفعله المستهلكون بالامتدادات. يتطلب أبسط نموذج من المستهلكين تجاهل العناصر التي لا يتعرفون عليها - ومن ثم اسم القالب. قد يتطلب النموذج أيضًا من المستهلكين معالجة العناصر التي تحمل علامة Must Understanding ، أو إعطاء خطأ إذا لم يتمكنوا من فهمها.

فيما يلي مخططنا الأصلي لوثيقة نتائج البحث:

 <?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> 

دعونا الآن نعود بالزمن إلى الوراء ، ومن البداية سنشير إلى مخطط متوافق وقابل للتوسيع لخدمتنا:

 <?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> 

يتضمن هذا التصميم عنصر امتداد اختياري لكل منتج. قد يحتوي عنصر الامتداد نفسه على عنصر واحد أو أكثر من مساحة الاسم الهدف:

الشكل 2: مخطط نتيجة البحث القابل للتوسيع

الآن بعد أن طُلب منا إضافة وصف المنتج ، يمكننا نشر مخطط جديد بعنصر وصف إضافي ، والذي يدرجه الموفر في نقطة الامتداد. يسمح ذلك لـ ProductSearch بإرجاع النتائج التي تحتوي على أوصاف المنتج ، ويستخدم العملاء المخطط الجديد للتحقق من صحة المستند بأكمله. لن ينكسر المستهلكون الذين يستخدمون المخطط القديم ، على الرغم من أنهم لن يعالجوا حقل الوصف. يبدو مستند نتيجة بحث جديد كما يلي:

 <?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> 

يبدو المخطط المعدل كما يلي:

 <?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> 

لاحظ أن الإصدار الأول من المخطط القابل للتوسيع متوافق مع الإصدار الثاني ، والثاني متوافق مع الإصدار الأول. ومع ذلك ، تأتي هذه المرونة على حساب التعقيد المتزايد. تسمح لنا المخططات القابلة للتوسيع بإجراء تغييرات غير متوقعة ، ولكنها توفر ميزات قد لا تكون مطلوبة أبدًا ؛ بينما نفقد:

• التعبيرية من تصميم بسيط
• عرض واضح للبيانات عن طريق إدخال عناصر المعلومات الوصفية للحاوية.

علاوة على ذلك ، لن نناقش مخططات قابلة للتوسيع. يكفي أن نقول أن نقاط التوسع تسمح لنا بإجراء تغييرات متوافقة مباشرة وخلفية في الرسوم البيانية والمستندات ، دون التأثير على موردي الخدمة ومستهلكيها. ومع ذلك ، فإن توسيع المخطط لا يساعدنا في التحكم في تطور النظام عندما نحتاج إلى إجراء تغيير ينتهك العقد.

كسر التوافق

- نعم ، انتهك فريقنا التوافق العكسي في الإصدار الأخير! إنهم لا يستطيعون مقاومة التحسين الطفيف للبروتوكول ... حسنًا ، لا تشعر بالإهانة ، عزيزتي!
كارلا بورين

تتضمن خدمة ProductSearch الخاصة بنا في نتائج البحث حقل يشير إلى توفر هذا المنتج. تملأ الخدمة هذا المجال باستخدام مكالمة باهظة الثمن لنظام جرد قديم - تبعية مكلفة للحفاظ عليها. يرغب المورد في إزالة هذه التبعية وتنظيف التصميم وتحسين الأداء العام للنظام. ويفضل دون التأثير على المستهلكين. بالتواصل مع المستهلكين ، يكتشف فريق المورِّد أنه لا يوجد أي من تطبيقات المستهلكين يفعل شيئًا في هذا المجال ؛ أي أنها باهظة الثمن ، فهي زائدة عن الحاجة.

لسوء الحظ ، في الوضع الحالي ، إذا أزلنا حقل InStock من مخططنا القابل للتوسيع ، فسوف نكسر المستهلكين الحاليين. لإصلاح الموفر ، يجب علينا إصلاح النظام بأكمله: عندما نزيل الوظيفة من المورد وننشر عقدًا جديدًا ، يجب إعادة تثبيت كل تطبيق للمستهلك بمخطط جديد ، وسيتم اختبار التفاعل بين الخدمات بدقة. لا يمكن تطوير خدمة ProductSearch في هذا الصدد بشكل مستقل عن المستهلكين: يجب على المورد والمستهلكين "القفز في نفس الوقت".

يشعر مجتمع خدمتنا بخيبة أمل في تطوره ، لأن كل مستهلك لديه اعتماد "مخفي" ، والذي يعكس العقد الكامل للمورد في المنطق الداخلي للمستهلك. المستهلكون ، باستخدام التحقق من صحة XSD ، وبدرجة أقل ، الربط الثابت لنظام الوثيقة في الكود ، يقبلون ضمنيًا عقد المورد بأكمله ، بغض النظر عن نيتهم ​​في استخدام جزء فقط.

يقدم ديفيد أوركارد بعض الدلائل حول كيفية تجنب هذه المشكلة ، في إشارة إلى مبدأ الموثوقية : "يجب أن يكون التنفيذ محافظًا في سلوكه وليبراليًا في ما يقبله من الآخرين". يمكننا تعزيز هذا المبدأ في سياق تطوير الخدمة من خلال الإشارة إلى أن مستلمي الرسالة يجب أن يقوموا بالتحقق "الكافي": بمعنى أنه يجب عليهم فقط معالجة البيانات التي يستخدمونها ، ويجب عليهم إجراء تحقق محدود أو صريح من البيانات التي يتلقونها - على عكس التحقق غير المحدود ضمنيًا كل شيء أو لا شيء متأصل في معالجة XSD.

مخطط

إحدى الطرق التي يمكننا من خلالها تكوين التحقق من جانب المستهلك هي استخدام الأقنعة أو التعبيرات العادية لمسارات عناصر الوثيقة ، ربما باستخدام لغة التحقق من بنية شجرة مثل Schematron . باستخدام Schematron ، يمكن لكل مستخدم ProductSearch تحديد ما يتوقعه في نتائج البحث:

 <?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 مخطط Schematron ، مثل هذا ، إلى تحويل XSLT يمكن لمستلم الرسالة تطبيقه على المستند للتحقق من صحته.

لاحظ أن هذا الرسم التخطيطي لا يحتوي على افتراضات حول العناصر الموجودة في المستند المصدر والتي لا يحتاجها تطبيق المستهلك. وبالتالي ، يتم وصف التحقق من صحة العناصر المطلوبة فقط بشكل صريح. لن يتم رفض التغييرات التي تم إجراؤها على مخطط المستند المصدر أثناء التحقق إذا لم تنتهك التوقعات الصريحة الموضحة في مخطط Schematron ، حتى إذا كانت تزيل العناصر المطلوبة مسبقًا.

فيما يلي حل سهل نسبيًا لمشاكلنا المتعلقة بالعقد والتبعية ، وهذا لا يتطلب منا إضافة عناصر معلومات تعريف ضمنية إلى المستند. لذا ، دعونا نتراجع مرة أخرى في الوقت المناسب ونستعيد الدائرة البسيطة الموضحة في بداية المقالة. ولكن هذه المرة ، سنصر أيضًا على أن المستهلكين أحرار في سلوكهم ويتحققون من المعلومات التي يحتاجونها ويعالجونها فقط (باستخدام مخططات Schematron ، وليس XSD للتحقق من الرسائل المستلمة). الآن بعد أن أضاف المورد وصفًا لمنتج ، يمكنه نشر مخطط منقح دون التأثير على العملاء الحاليين. وبالمثل ، إذا اكتشفت أن حقل InStock لم يتم فحصه أو معالجته من قبل أي من المستهلكين ، فيمكن للخدمة مراجعة مخطط نتائج البحث - مرة أخرى ، دون التأثير على المستهلكين.

في نهاية هذه العملية ، يبدو مخطط استجابة ProductSearch كما يلي:

 <?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> 

العقود الموجهة للمستهلك

يؤدي استخدام Schematron في المثال أعلاه إلى بعض الاستنتاجات المثيرة للاهتمام حول العقود بين الموردين والمستهلكين التي تتجاوز التحقق من صحة المستندات. في هذا القسم ، نسلط الضوء على بعض هذه الأفكار ونلخصها ونعبر عنها من حيث النموذج الذي نسميه عقود المستهلكين .

أول شيء يجب ملاحظته هو أن مخططات المستندات ليست سوى جزء مما يجب أن يقدمه مقدم الخدمة للمستهلكين حتى يتمكنوا من استخدام وظائفه. نسمي هذه المعلومات الاستعانة بمصادر خارجية عقد بائع .

عقود الموردين

يصف عقد المورد وظيفة الخدمة كمجموعة من العناصر المصدرة اللازمة لاستخدام هذه الوظيفة. فيما يتعلق بتطوير الخدمة ، يعتبر العقد حاوية لمجموعة من العناصر المصدرة التي تصف وظائف الأعمال. تتضمن قائمة هذه العناصر:

• مخططات الوثائق . لقد ناقشنا بالفعل بالتفصيل مخططات الوثيقة. إلى جانب الواجهات ، تعد مخططات المستندات أجزاء من عقد المورد ، ومن المرجح تغييرها مع تطور الخدمة ؛ ولكن ربما لهذا السبب فهي أيضًا الأجزاء التي لدينا بها أكبر تجربة تنفيذ مع استراتيجيات تطوير الخدمة المختلفة ، مثل نقاط الامتداد واستخدام الأقنعة لمسارات عناصر الوثيقة.
• واجهات في أبسط أشكالها ، تتضمن واجهات المزود مجموعة من توقيعات المعاملات المصدرة التي يمكن للمستهلك استخدامها للتحكم في سلوك المورد. تقوم أنظمة المراسلة عادة بتصدير توقيعات المعاملات البسيطة نسبيًا ووضع محتوى الأعمال داخل الرسائل التي تتبادلها. في مثل هذه الأنظمة ، تتم معالجة الرسائل المستلمة وفقًا للدلالات المشفرة في رأس الرسالة أو نصها. 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 , . , , .

, :

التنفيذ

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. , ; . — — , " " .

, : , . , , , , .

المراجع

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