الخلاصة

  • وحّد RFC 2371 اتفاقاً ضيقاً على مرحلتين بين مديري المعاملات، لا نقل طلبات العمل أو تفويضها أو إيصال نتيجتها إلى المستخدم.
  • كان PREPARED وCOMMITTED دليلين تشغيليين قويين لكن محدودين؛ فلا يثبتان أن كل الأعمال المقصودة انضمت إلى المعاملة ولا أن الطرف المستدعي عرف النتيجة النهائية.

قناتان بدلاً من نظام يعرف كل شيء

صدر RFC 2371 في يوليو 1998 وعرّف Transaction Internet Protocol، أو TIP، بوصفه بروتوكولاً بسيطاً للتثبيت على مرحلتين. كان مضمون المعاملة، مثل طلب شراء أو حجز أو تحويل، ينتقل عبر بروتوكول التطبيق. وفي قناة أخرى يتفق مديرو المعاملات على التثبيت أو الإلغاء. سمّت الوثيقة هذا الفصل نموذج «القناتين».

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

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

التطبيق هو من رسم حدود المعاملة

في مثال التسوق، ينضم مدير محلي ومديرون بعيدون إلى معاملة واحدة حتى تثبت عدة طلبات معاً. يضمن TIP القرار الذري للمشاركين المسجلين فعلاً. أما تحديد الأعمال الداخلة في المجموعة وتوقيت طلب COMMIT فمسؤولية التطبيق.

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

لذلك لا تعني ذرية المجموعة المسجلة أن كل النية التجارية قد وُضعت داخل المجموعة.

كان عنوان TIP نقطة التقاء لا إيصالاً

انتقل سياق المعاملة بطريقتي PUSH وPULL. في PUSH يطلب المدير الأعلى من المدير الأدنى ربط المعاملة. وفي PULL يمرر التطبيق عنوان TIP، ثم يستخدم الطرف الأدنى العنوان ومرجع المعاملة للانضمام.

اشترطت الوثيقة أن يكون العنوان فريداً عالمياً إلى الأبد، لكنها تركت طريقة الإنشاء للتنفيذ. ذُكر UUID كخيار ممكن، ولا يصح إسقاط RFC 4122 اللاحق على عام 1998 باعتباره صيغة إلزامية. كما أن TIP نفسه لم يكن ينفذ العنوان؛ التطبيق هو الذي نقله.

امتلاك المرجع لم يثبت نجاح PULL أو تفويض العملية أو تثبيت المورد. كان إحداثية للقاء، لا شهادة على النتيجة.

أنشأ PREPARED التزاماً دائماً

عمل TIP عادة فوق TCP، واستطاع التفاوض على TLS وتعدد المعاملات في اتصال واحد. نظمت حالات Initial وIdle وBegun وEnlisted وPrepared وMultiplexing وTLS وError ما يجوز للمديرين قوله لاحقاً، ولم تصف رحلة العمل كاملة.

كان PREPARED يعني أن الطرف الأدنى حفظ معلومات استرداد دائمة تكفي لتنفيذ قرار المدير الأعلى لاحقاً. ولم يكن فشل التحضير مساوياً تلقائياً لـ ABORT. فالمعاملة المحضرة تستهلك موارد وتحمل مسؤولية استرداد حقيقية حتى يُعرف مصيرها.

وكان معنى COMMIT ضيقاً أيضاً: قرار المنسق بشأن المجموعة المسجلة. أما COMMITTED فهو تقرير الطرف المشارك عن نتيجة البروتوكول. وبينهما وبين إيصال العميل تقع كتابة المورد محلياً، وتسليم الرد، وعرض التطبيق، والحالة التي تُرى بعد ذلك.

قد تنجح المعاملة ويضيع الرد الأخير

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

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

لم تعبر الحماية من قناة إلى أخرى تلقائياً

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

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

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

تجعل عدسة Lu Heng حول «الحد الأدنى للمواصفة الأولية» هذا الضيق فضيلة: يوحّد البروتوكول القدر اللازم من الاتفاق من دون الاستيلاء على دلالات التطبيقات. وتطالب أولوية الشيفرة العاملة بملاحظة السجلات الدائمة والانتقالات والاسترداد، لا الاكتفاء باسم في مخطط. أما طبقات الواقع فتمنع مساواة COMMIT وCOMMITTED ورسالة الشاشة والرصيد اللاحق.

قدّم RFC 2371 إيصالاً مهماً من نظام التنسيق. لكنه لم يجعله إيصال اكتمال العمل كله.