نمط البروتوكول المتعارف عليه

البروتوكول المعياري هو نمط تصميم يُطبق ضمن نموذج تصميم الخدمات الموجهة ، ويهدف إلى جعل الخدمات ، ضمن قائمة الخدمات، ^{قابلة للتشغيل} البيني فيما بينها من خلال توحيد ^{بروتوكولات} الاتصال المستخدمة. ^{وهذا يُغني} عن الحاجة إلى بروتوكولات اتصال وسيطة عندما تستخدم الخدمات بروتوكولات اتصال مختلفة ^.

قد تعتمد الخدمات التي تُطوّرها فرق مشاريع مختلفة على آليات اتصال متباينة. ونتيجةً لذلك، قد تحتوي قائمة الخدمات على مجموعات مختلفة من الخدمات، كلٌّ منها يتبع مجموعة مختلفة من البروتوكولات. عند إعادة استخدام خدمات ذات بروتوكولات اتصال مختلفة، يلزم وجود آلية ربط اتصالات. على سبيل المثال، الخدمات المطوّرة باستخدام بروتوكول مراسلة JMS غير متوافقة مع الخدمات التي تستخدم .NET Remoting ، لذا، للاستفادة من هذين النوعين من الخدمات، يلزم وجود تقنية وسيطة تربط بين بروتوكولات الاتصال المختلفة. إضافةً إلى التكلفة الإضافية، يُضيف استخدام هذه التقنية الوسيطة زمن استجابة وحملاً زائداً على الاتصال. وهذا يجعل الخدمات أقل قابلية لإعادة الاستخدام وأكثر صعوبة في التركيب، ^{[ 3 ]} مما يتعارض مع مبادئ تصميم قابلية تركيب الخدمات .

بهدف تصميم قائمة خدمات تضمن قابلية التشغيل البيني بين جميع الخدمات، ما يسمح بدمجها في حلول مختلفة، يفرض تطبيق نمط البروتوكول المعياري توحيد بروتوكولات الاتصال المستخدمة بين الخدمات. وعندما تستخدم جميع الخدمات بروتوكول اتصال موحد، يُلغى الحاجة إلى تقنية الربط، ويصبح الاتصال بين الخدمات أكثر سلاسة. ^{[ 4 ]}

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

يجيب نمط البروتوكول الأساسي لتوماس إيرل على السؤال التالي: "كيف يمكن تصميم الخدمات لتجنب ربط البروتوكولات؟" ^{[ 5 ]} تكمن المشكلة في أن الخدمات التي تدعم تقنيات اتصال مختلفة تُضعف قابلية التشغيل البيني، وتحد من عدد المستهلكين المحتملين، وتُنشئ الحاجة إلى تدابير ربط بروتوكولات غير مرغوب فيها. يكمن الحل في أن تُحدد بنية النظام تقنية اتصال واحدة كوسيلة وحيدة أو أساسية لتفاعل الخدمات. ولذلك، يتم توحيد بروتوكولات الاتصال (بما في ذلك إصدارات البروتوكولات) المستخدمة ضمن حدود مخزون الخدمات لجميع الخدمات (انظر الرسم التوضيحي).

تُعدّ بنية خدمات الويب إحدى أكثر آليات الاتصال نضجًا وانتشارًا. وبالإضافة إلى اختيار بنية الاتصال، لا بدّ من توحيد بروتوكولات الرسائل المستخدمة. على سبيل المثال، هل تُبنى خدمات الويب باستخدام بروتوكول SOAP عبر HTTP أم باستخدام خدمات RESTful ؟ وبالمثل، عند توحيد خدمات الويب القائمة على SOAP، يجب الاتفاق على الإصدار المحدد من بروتوكول SOAP، أي SOAP v1.1 أو SOAP v1.2.

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

في بعض الحالات، وبحسب التقنية المستخدمة في بناء الخدمة، قد يكون من الممكن دعم مجموعتين مختلفتين من البروتوكولات لجعل الخدمة متاحة لأنواع مختلفة من مستخدمي الخدمة (نمط تصميم البروتوكولات المزدوجة ^{[ 6 ]} ). على سبيل المثال، باستخدام WCF ، يمكن تهيئة الخدمة نفسها لاستخدام بروتوكولي HTTP و TCP/IP في الوقت نفسه.

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

ملحوظات

مصادر

• توماس إيرل وآخرون، (2009). أنماط تصميم بنية الخدمات الموجهة (SOA) . برنتيس هول. ISBN 978-0-13-613516-6.

• مفاهيم هندسة الخدمات الموجهة
• مسرد مصطلحات هندسة الخدمات الموجهة
• أنماط تصميم SOA