إنترنت الأشياء (الجزء الثّاني): بِنية نظام إنترنت الأشياء

عندَ الكلامِ عن البيئاتِ الموزَّعة^* Distributed Environments فإنّ الرَّبط بين المكوّنات يصبح مُتطلَّبًا حَرِجَ التّحقيق، وإنّ إنترنت الأشياء مثالٌ واضحٌ عنْ هذهِ الحالة، وتحتاجُ بِنيةُ نظامِ إنترنت الأشياء الشّاملِ إلى ضمانِ عدمِ وجودِ عيوبٍ في مكوّناته؛ إذ تُعدُّ الوثوقيّة Reliability العاملَ الأكثرَ أهميّةً في تصميمِ أنظمة إنترنت الأشياء، بالإضافة إلى ربطِ الطّبقةِ الفيزيائيّةِ الممثَّلةِ بالأجهزة معَ الأجزاءِ الافتراضيَّة أو البرمجيَّات، وللوصولِ إلى ذلك؛ نحتاجُ دراسةً متأنّيةً لتصميمِ فشلِ الاستعادة^* Failure Recovery، وقابليّةِ التّوسّع، ومنذُ أنْ أصبحَ التّنقّلُ وتغييرُ المكانِ جزءًا مُهمًّا لأنظمةِ إنترنت الأشياء معَ الانتشارِ الكبيرِ لاستخدامِ الهواتفِ الذّكيّة؛ فإنَّ البُنى الحديثة تحتاجُ لمستوى تكيّفٍ معيّنٍ للتّعامل على نحوٍ صحيحٍ مع التّفاعلاتِ داخلَ النّظام بأكمله.

يوضّح الشّكل الآتي الخطوطَ العريضة للنّسخة الموسَّعة من بِنية إنترنت الأشياء.

تتضمّنُ طبقاتُ الخدماتِ تحليلَ ومعالجةَ الوقائع وإدارةَ المواردِ واكتشافَ الخدمات، فضلًا عن تجميعِ الرّسائلِ وخدماتِ باصِ نقلِ الخدماتِ Enterprise Services Bus (ESB) بينَ طبقةِ الاتّصالات والطّبقةِ الفيزيائيّة، وتتضمّنُ البِنية أيضًا إدارةً للـ API – التي تعدُّ رئيسيّةً لتعريفِ ومشاركةِ خدماتِ النّظامِ والمنصّاتِ المعتمدةِ على الويب (أو ما يُكافئها من تطبيقاتِ الهواتفِ الذّكيّة)- من أجلِ إدارةِ  الـ APIs الموجودة في النّظامِ والوصولِ إليها.

كُنّا قد ذكرنا آنفاً  أنَّ الباحثينَ توصّلوا إلى عدّةِ بنىً مرجعيّة لإنترنت الأشياء، وسنُصنّفها وفقَ الآتي :

البنى خدميّة التّوجّه (Service-Oriented Architectures (SOA:

تكفلُ هذهِ البِنيةُ قابليَّةَ تبادلِ المكوّنات بين الأجهزةِ غيرِ المُتجانسة، ولتوضيحِ هذهِ الفكرة؛ لنفترضْ أنَّ بِنيةَ SOA عامّةً مكوّنةً من أربعِ طبقاتٍ بوظائفَ منفصلة:

1- طبقةُ حسّاساتٍ: مكوّناتٌ عتاديّةٌ متاحةٌ لتحسّس حالةِ الأشياء.

2- طبقةُ الشّبكة:  الطّبقةُ الأساسيّةُ لدعمِ الاتّصال السّلكيّ واللّاسلكيّ عبرَ الأشياء.

3- طبقةُ الخدماتِ:  لإنشاءِ وإدارةِ الخدماتِ اللّازمةِ للمستخدمين أو للتّطبيقات.

4- طبقةُ واجهاتِ المُستخدم:  مؤلفةٌ من طرقِ التّفاعلِ مع المستخدمين أو التّطبيقات.

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

واستُخدمت البِنية SOA في شبكاتِ الحسّاساتِ اللّاسلكيّة WSN^*؛ وذلكَ بسببِ امتلاكِها مستوى التّجريدِ المناسبِ ومِيزاتٍ عائدة لتصميمِها الجزئيّ (القائم على الأجزاء)، ولذلك اعتُمدَت في مجالِ إنترنت الأشياء أيضًا، ومن ناحيةٍ أُخرى ومن وجهة نظرِ المستخدم؛ توضعُ التّطبيقاتُ في مجموعاتٍ مألوفةٍ دون تعقيداتٍ إضافيّةٍ بما يخصّ معرفةَ الطّبقات والبروتوكولات، بالإضافةِ إلى إمكانيّة بناءِ خدماتٍ معقّدةٍ ومختلفةٍ عبرَ إعدادِ وظائفٍ مختلفةٍ للنّظامِ في كلِّ مرّة، فتركَّبُ الخدمةُ التي تناسبِ الطّبيعة غيرَ المتجانسة لنظام إنترنت الأشياء؛ إذ يتطلَّب تحقيقُ كلِّ مَهمّةٍ سلسلة نداءاتٍ للخدماتِ الموجودةِ في المكوّناتِ المُختلفة الموزَّعةِ في مواقع متعدّدة.

البنى المعتمدة على واجهةِ برمجةِ التطبيقات API-Oriented Architectures

إنّ الاتّصالية Connectivity مُدهشةٌ حقًّا؛ إذْ تجعلُ العالَم كُلَّه بأيدينا سواءٌ عن طريقِ الحواسيب أو عن بواسطةِ الأجهزةِ التي تجعلُنا قادرين على الشِّراء والنَّشر والتّواصل أينمَا كنّا، ولكنْ؛ هل سألتَ نفسَك كيفَ حدثَ ذلك؟ كيف تمكَّنا من تحقيقِ الاتّصال بين أجهزةٍ وتطبيقاتٍ مختلفة؟

وإنّ الفارس المجهول في هذا كلِّه هو واجهاتُ برمجةِ التّطبيقات (Application Programming Interface (API؛ المحرُّك الخفيُّ خلفَ الكواليس.

يُعرَّف الـ API في برمجةِ الحواسيب بأنّه ساعي البريدِ الّذي يأخذُ الطّلباتُ من المستخدمين، ويخبرُ النّظامَ بما يريدون فعلُه، ثمَّ يُعيد الاستجابةَ للمستخدمين، كالنّادل في المطعم؛ يدوّنُ ما تختارُه من القائمةِ ويأخذُ طلبكَ إلى المطبخِ ثمَّ يعيدُ لكَ ما طلبته؛ فيُؤدّي النّادل هنا دورَ API والمطبخ هو النّظام، في حينِ أنَّك المستخدم في كلا المثالين.

وتَستخدم الطّرقُ التّقليديّةُ بروتوكولَ الوصولِ البسيط للأغراض (Simple Object Access Protocol (SOAP^* وبروتوكولِ مناداةِ الطّرق عن بعد (Remote Method Invocation (RMI^* كوسائلَ لوصفِ الخدماتِ واكتشافِها ومناداتها، ومن ناحيةٍ أُخرى ونظرًا للتّعقيدِ المرتبطِ بهذه التّقنيّات؛ قُدِّمت الوسائلُ المعتمدة على Web APIs وREST****** كخياراتٍ بديلة، يُفعَّلُ مجالُ المصادرِ اللّازمةِ (عرض حزمةِ الشّبكة وسعة التّخزين والمعالجة) عبرَ تحويلِ البيانات المُنتظم في أثناءِ مناداةِ النّظام وفقَ أسلوب طلب/استجابة؛ أيْ عند  طلبِ بياناتٍ مُعيّنةٍ من النّظام فإنَّه سيُظهر استجابة.

وإنّ صيغَ تبادلِ البياناتِ خفيفةِ الوزنِ مثل JSON يمكنها تقليلُ الكمّيّات الهائلةِ من البيانات المذكورة آنفًا، وخاصًّة في حالِ التّعاملِ مع الأجهزةِ الذّكيّةِ والحسّاساتِ محدودةِ المصادر عن طريقِ استبدالِ ملفَّات XML الضّخمة المُستخدمة في توصيفِ الخدمات، وهذا يُساعد في استخدامِ قناةِ الاتّصال ومعالجةِ قدرةِ الأجهزةِ بفعاليّةٍ أكبر.

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

تُقتَرح طريقةُ الاكتشاف على مرحلتين Two-Phase discovery ضمن هذا الإطار لإيجادِ الحسّاساتِ الّتي تُقدّم الخدماتِ المطلوبة، وتعملُ على إجراءِ التّطابقِ بين مِيزاتٍ معيّنةٍ  كتحديدِ موقعٍ ما، وبالمثل؛ تقترحُ بعض التّصاميم وجودَ طبقةِ وسيطِ خدمات Service-broker تُدعى FOKUS تكشفُ مجموعةً من الـ APIs لتمكينِ الوصولِ المشتركِ للنّواة OpenMTC.

ويمكنُ لطرقِ تعريفِ الخدماتِ ومشاركتها في البيئاتِ الموزّعة - كإنترنت الأشياء - تخفيضَ تعقيدِ اكتشاف الخدماتِ في دائرةِ تطويرِ التّطبيقات، والتّقليلُ من طوفانِ طلبِ الخدماتِ service-call في الزّمن الحقيقي أيضًا.

ولذلك؛ يُنصح المطوّرون ومدراءُ الأعمالِ بالتّركيز على تطويرِ ومشاركةِ APIs في المراحل المبكّرة من دورةِ حياة تطويرِ التّطبيقات، فبالنّتيجة وعنْ طريقِ نشر البيانات  على نحوٍ صحيحٍ للمطوّرين والمستخدمين النّهائيين؛ تُنشأُ بيئةُ بياناتٍ مفتوحةٍ تُسهّلُ بدورِها جمعَ المعلوماتِ ومشاركتَها وتحديثَها.

=========================================================

^*البيئات الموزّعة Distributed Environments: هي تقنيةٌ برمجيّةٌ قياسيّةٌ تُستخدمُ لإعدادِ البياناتِ وتهيئتها وإدارة معالجتها وتبادلها في أنظمةٍ مكونةٍ من مجموعةِ أجهزةٍ موزَّعة جغرافيًّا (بوجودِ تباعدٍ جغرافيّ أو بدونه).

^*فشل الاستعادة Failure Recovery: الاستعادةُ هي إجرائيّةُ إعادةِ تخزينِ قاعدةِ البياناتِ لتعودَ إلى حالتِها الوظيفيَّة الكاملة بعدَ فشلِ عقدةٍ أو أكثرَ ضمنَ النّظام؛ أيْ لا يؤثّرُ حدوثُ عطلٍ في أحدِ مكوّناتِ النّظام على عمله، وإنّ عدمَ أخذِ حدوث الأعطال في أيّ نظامٍ بعينِ النّظر يجعلُ منهُ نظامًا غيرَ موثوق.

^*WSN: يعني شبكةُ الحسّاسات اللاسلكيّة Wireless Sensors Networks، وهيَ مؤلّفةٌ من أجهزةٍ مستقلّةٍ موزّعةٍ مكانيًّا لِمراقبة الشّروطِ البيئيّةِ والفيزيائيّة، ويشمَل نظام WSN بوّابةً تُوفّرُ اتّصالاً لاسلكيًّا بالعودةِ إلى العالمِ السّلكيّ والعقدِ الموزّعة.

^*SOAP: هو بروتوكول تبادلُ المعلوماتِ البنيويّة Structured information لتحقيقِ خدمات الويب في الشّبكاتِ الحاسوبيّة، ويعدُّ قادرًا على توسيعِ HTTP لتشمل مراسلاتِ XML، ويمكنه تبادلُ وثائق كاملة أو الاتّصال بإجرائيّةٍ عن بعد.

^*RMI:  استدعاءُ الطّرق عن بعد Remote Method Invocation؛ عبارةٌ عن API يؤمّنُ آليّةً تسمحُ لغرضٍ أن يستدعي طرقَ غرضٍ آخر، ويؤمّنُ اتّصالًا عن بعد بينَ التّطبيقاتِ باستخدام غرضين.

^*REST: اختصار ٌلمصطلح Representational State Transfer أي نقلُ الحالةِ التّمثيليّة، ويظهرُ المصطلحُ أنّهُ يتعاملُ مع العلاقةِ بين الزّبون والمخدّم وكيفيّة تخزينِ حالةِ هذهِ العلاقة، وفي بدايات تطويرِ الويب؛ أصبحَ من الضروريّ للتّطبيقات من جهةِ الخادم أن تتذكّرَ بعض التّفاصيل الخاصّةِ بالمستخدم الّذي يخاطبه، ولكن إذا كانَ الخادم سيحتفظُ بحجمِ عدَّة كيلوبايتات لكلّ مستخدم؛ فإنّه - ومعَ عددٍ كبيرٍ من المستخدمين- سيصلُ لمرحلةِ نفاذٍ بالسّعةِ التخزينيّة للخادم مهما كانت كبيرة، ولذلك؛ فإنّ المستخدمَ يقدّمُ للخادمِ كلّ ما يحتاجه ليقوم بفعلٍ معيّن، ثمَّ يقومُ الخادمُ بذلك الفعلِ، فلا يحتاجُ الخادم تذكّرَ تفاصيل تتعلّقُ بأيّ مستخدمٍ ونتجنّب بذلكَ مشكلةَ نفاذِ الذّاكرة ومشاكل فشلِ الأداء المتعلّقة بها.

مصادر المقال: