قبل يومين كنت أتحدث مع أحد الأصدقاء على المسنجر MSN Messenger عن موضوع الهيكل العام للتطبيقات Application Architecuture و عن رأيه في مقال كتبته في نفس الموضوع (ما زال تحت التحرير)، كان النقاش حول نموذج الـ n-Tiers تحديداً، و ما يشوب هذا النموذج من غموض و فهم خاطيء عند أغلب المبرمجين، كما كان موجود عند صديقي المسنجري، عموما، أستغل الفرصة لكتابة بلوق جديد قبل ان انتهي من المقال الذي أتعبني بصراحة، و أضع هنا ما كتبته هناك، بعد زيادة و إعادة ترتيب، و بالتأكيد لطش كم مخطط جاهز لل n-tiers (الله يخليك البحث عن الصور في قووقل، لول).

 نموذج الـ n-Tier عبارة نموذج تصميمي للتطبيقات،  حيث يقسم فيه التطبيق فيزيائياً إلى ثلاث أجزء يسمى كل جزء بطبقة Layer، كل جزء يعمل في خادم منفصل Separate Server، الجزء الأول يسمى طبقة الوصول إلى البيانات Data Access Layer و هو الجزء الذي توجد فيه قاعدة البيانات Database و جزء يسمى بطبقة عناصر العمل Bussiness Object Layer يعمل في خادم يسمى خادم التطبيقات Application Server، و جزء يسمى طبقة العرض Presentation Layer و يعمل في جهاز المستخدم Client PC.

و بشكل أدق، هو نموذج تشغيلي و ليس بالنموذج التصميمي (منطقي) للتطبيقات الأعمال Bussiness Application، و هنا أقول تشغيلي لأن كود البرامج التي تصمم على شكل n-Tier ستعمل على أكثر من جهاز بشكل تسلسلي، بمعنى، أن جزء من الكود سيعمل في البداية على جهاز المستخدم في طبقة العرض، و من ثم سينتقل تنفيذ الكود إلى طبقة عناصر العمل التي ستتخاطب مع طبقة الوصول إلى البيانات لسحب البيانات و إعادتها للمستخدم. الخلط الحاصل عند اغلب المطورين هو تسميت تطبيقات مصممة منطقياً كـ n-Tier، و لكنها تشغل كما يسميها David Hayden بـ n-Layer، و هو يقصد النموذج الذي تكون فيه طبقة العرض و طبقة عناصر العمل يعملان في نفس جهاز المستخدم Client PC الشيء الذي يفقد نموذج الـ n-Tier كفائته التشغيلية، الشكل (1) التالي يعرض تطبيق n-Tier، و الشكل (2) لتطبيق n-Layer.

الشكل (1): تطبيق n-Tier.

الشكل (2): تطبيق n-Layer.

لماذا لا نفصل في الموضوع حسب تسلسله التاريخي؟ و هو كذلك...

 يرجع تاريخ هيكلية التطبيقات إلى أيام المين فريم Mainframe، ففي ذلك الوقت كانت تصمم تطبيقات الأعمال Bussiness Application على شكل نموذج يسمى Monolithic بإستخدام لغة برمجة تسمى الكوبول COBOL، و فيها يتم الجمع بين البيانات و عناصر العمل، و شاشات الإستخدام في مكان واحد (برنامج واحد)، و يتم تشغيله في مكان واحد وهو المين فريم Mainframe، و يقوم المستخدمين بالإتصال على النظام عن طريقة نهاية طرفية Termianl مربوطة بشكل مباشر مع المين فريم، و من هناك يتم تنشيط النظام و تشغيله، الشكل 1 يوضح الألية، بعد ذلك دخلنا عصر الحاسبات الشخصية PC، و أصبحت البرامج تكتب بلغات برمجة حديثة، و يقسم البرنامج إلى جزئين، جزء العميل Client، و جزء الخادم Server الذي يمثله المين فريم Mainframe، و يتم الاتصال باقاعدة البيانات الموجودة في المين فريم بطرق مختلفة لا يسعنى التحدث عنها هنا، كذلك ظهرت برامج تقوم بتخزين البيانات في نفس جهاز المستخدم كالفوكس برو FoxPro، و هذا النموذج يعتبر Monolithic، لأن البيانات و عناصر العمل و الشاشات كلها في جهاز المستخدم.

الشكل 1: تطبيق Monolithic يعمل في مين فريم Mainframe.

 بعد ذلك دخلنا عصر الإنترنت، و عصر الخادمات الصغيرة Servers، التي تقدم أداء ممتاز بتكلفة قليلة، و لكن بالطبع بأداء أقل من المين فريم Mainframe، هذا التغير صاحبه تغيير في طريقة بناء البرامج و أدخلنا في عصر جديد اسمه عصر التطبيقات الموزعة Distrubted System، حيث تجد مكونات البرنامج موزعة على أكثر من خادم و جهاز، فيوجد خادم يسمى قاعدة البيانات Database Server، و يوجد خادم التطبيقات Applicatin Server، هذا التقسم الفيزيائي، أجبر المبرمجين على تقسيم برامجهم منطقيا (وفيزيائيا بتقسيم البرنامج إلى DLLS) بحيث يتم تصميم فئات Classes للإتصال بقاعدة البيانات (غالبا ما يستخدم مكتبات جاهزة كالـ ADO او ADO.NET)، او حتى يتم تصميمها على شكل Stored Procedures تعمل في محرك قاعدة البيانات نفسه، كالشيء الحاصل في قواعد بيانات اوراكل و SQL Server.

الجدير بالذكر أن في تطبيقات Web Application يلعب خادم الويب Web Server دور خادم التطبيقات Application Server، و أضع الشكل التالي للتوضيح.

إنشاء الله سيكون المقال أشمل في الشرح و سأفصل في كل طبقة.

بإختصار...
يوجد ثلاث نماذج لهياكل التطبيقات، وهي:
* Monlithic
* Client/Server
* 2-Tier
* n-Tier

لمن أراد الإستزادة، فما عليه إلا البحث في قووقل، و سيظهر له العديد من المقالات التي تتحدث في نفس الموضوع.

و تقبلوا تحياتي،،