اصول پياده سازي نرم افزارهاي مبتني بر وب

بمنظور بررسي مقوله پياده سازي نرم افزار بر روي بستر وب بحث خود را بر روي دو موضوع عمده متمركز مي كنيم: شناخت مدل هاي رايج جهت پياده سازي نرم افزار از ابتدا تا كنون و شناخت وب بعنوان بستر مربوطه بهمراه تكنولوژي هائي كه در اين زمينه مورد استفاده قرار مي گيرند.
هدف ما رسيدن به نقطه اي است كه مشخص نمائيم، براي طراحي و پياده سازي نرم افزار بر روي بستر وب، اولا از چه نوع مدلي براي پياده سازي استفاده مي گردد و ثانيا روند توسعه و تكامل وب را با تاكيد بر نيازهاي نرم افراري از بعد ابزارشناسي دنبال كرده و از اين رهگذر جايگاه هر ابزار (تكنولوژي) تبين شده تا بدين وسيله بتوانيم از هر چيز در جايگاه خود و در زمان مربوطه استفاده كنيم. بهرحال وب يك واقعيت انكار ناپذير بوده و سايه حضور آن را در همه جا مي توان احساس كرد. نرم افزار نيز مجري خواسته هاي انساني در سرزمين سخت افزار است، اين بار با يك چالش جدي مواجه شده است : پاسخگوئي به خيل نيازهاي جديد مطرح شده متكي بر بستر وب.
در بخش اول اين مقاله موضوع اول يعني شناخت مدل هاي پياده سازي نرم افزار تشريح خواهد شد. به اين اميد كه از اين رهگذر به نقطه اي برسيم كه يك مدل مناسب جهت پياده سازي برنامه هاي تحت وب را معرفي و آن را بعنوان پايه و اسا س كار خود قرار دهيم. در ابتدا لازم است به اين اصل بديهي اشاره شود كه يك برنامه كامپيوتري حاصل تركيب داده ها و منطق است. منطق يك برنامه از طريق كدهاي مربوطه كه به يكي از زبانهاي برنامه نويسي نوشته خواهند شد، مسئول تحقق خواسته هاي تعريف شده براي يك نرم افزار از طريق انجام عمليات مورد نياز بر روي داده ها است. داده ها خود مي توانند به اشكال و روش هاي متنوعي سازماندهي و در اختيار يك نرم افزار قرار گيرند.
Program = Logic(Code) + Data
مدل هاي پياده سازي يك نرم افزار از ابتدا تاكنون متاثر از عوامل متفاوتي بوده است كه جايگاه سخت افزارها بعنوان پتانسيل هائي كه مي بايست توان خود را در جهت بالفعل نمودن نرم افزارها قرار دهند، نقش برجسته اي دارد. مدل هاي پياده سازي نرم افزار را مي توان در پنج گروه عمده بشرح زير تقسيم نمود:

MainFrame Architecture

در اين مدل دو عنصر فيزيكي مورد اهتمام جدي بودند: كامپيوتر اصلي كه با نام Host شناخته مي شد و سخت افزارهاي استفاده كننده از كامپيوتر اصلي كه با نام ترمينال شناخته مي شدند. تمامي منطق يك برنامه (Logic) بهمراه داده هاي مربوطه (Data) بر روي Host نصب مي شد و كاربران با استفاده از ترمينال ها كه بمنزله پايانه هائي جهت ورود و خروج ( نمايش ) اطلاعات بودند، قادر به ارتباط با سيستم و اجراي يك برنامه بودند. تمركز منطق برنامه در يك محل (Host) از مهمترين ويژگي هاي اين مدل است.

File Server Architecture

از اين مرحله دو واژه معروف Server و Client پا به عرصه وجود گذاشتند. حيات و معني اين واژه ها محدود به سخت افرار بود و به مرزهاي نرم افزار نرسيده بود. در اين راستا كامپيوتري كه براي ديگران سرويس هائي را ارائه مي كرد با نام Server يا در اين حالت خاص (File Server) و كامپيوترهائي كه از اين خدمات بهره مند مي شدند را Client مي گفتند. مدل فوق پاسخي اوليه به نيازهاي كاربران يك شبكه كامپيوتري بود. در مدل فوق منطق يك برنامه بر روي يك Client نصب و داده ها بر روي Server قرار مي گرفتند. دراين مدل داده ها در يك فايل ( با يك ساختار خاص) قرار گرفته و يك بانك اطلاعاتي را بوجود مي آوردند و سرويس دهنده مسئول ارائه تسهيلاتي براي جابجائي و ارسال اطلاعات موجود در فايل ها بود. تمركز منطق برنامه در يك محل ( Client ) از مهمترين ويژگي هاي اين مدل است.

Client Server Architecture

مدل فوق در پاسخ به اشكالات بوجود آمده در مدل قبل ارائه گرديد. در مدل فوق كامپيوتر ارائه كننده خدمات را همچنان Server و كامپيوترهاي استفاده كننده را Client مي ناميدند. داده هاي يك برنامه (بانك هاي اطلاعاتي) همچنان بر روي سرويس دهنده قرار داشت ولي در رابطه با منطق برنامه اصل توزيع پردازش مورد توجه جدي قرار گرفت. بنابر اصل فوق بخشي از منطق يك برنامه را در حد امكان بر روي سرويس گيرنده اجرا و بخش ديگر از منطق برنامه بر روي سرويس دهنده اجرا مي گرديد. در مدل فوق براي اجراي يك برنامه دو پردازش جداگانه يكي بر روي سرويس دهنده و ديگري بر روي سرويس گيرنده فعال و هر يك نقشي در اجراي يك برنامه را برعهده مي گرفت. مهمترين ويژگي مدل فوق مطرح كردن اصل پردازش توزيع شده است.

Two Tire Architecture

در مدل فوق اصل تقسيم وظيفه بصورت يك واقعيت انكار ناپذير مورد توجه جدي قرار گرفت در اين مدل همچنان كامپيوترهاي سرويس دهنده و سرويس گيرنده جايگاه قبلي خود را داشتند با اين تفاوت بسيار مهم كه حوزه انجام هر عمليات ( منطق ) تا اندازه اي شفاف تر گرديد. مثلا جهت دستيابي به بانك هاي اطلاعاتي تمامي DataBase Engine بر روي سرويس گيرنده قرار مي گرفت و سرويس گيرندگان جهت استفاده از داده هاي موجود در بانك اطلاعاتي نيازمند نصب امكانات نرم افزاري و آگاهي از ساختار بانك اطلاعاتي نبودند. از اين مرحله واژه هاي سرويس گيرنده و سرويس دهنده پا به عرصه نرم افزار نيز گذاشتند و مفاهيمي نظير سرويس دهنده بانك اطلاعاتي و رايج شد. مهمترين ويژگي مدل فوق تاكيد بر اصل تقسيم فعاليت در چهارچوب ارائه طبقات (Tires) بود.

Three Tire Architecture

در مدل فوق اصل تفكيك مجموعه قوانين (سياست هاي) مربوط به عملكرد يك نرم افزار مورد توجه جدي قرار گرفت. بديهي است با حجيم شدن يك نرم افزار از يكطرف و افزايش تعداد كاربران از طرف ديگر و تغييرات متوالي در سياست هاي راهبردي و عملياتي يك نرم افزار در يك سازمان، مسائل مربوط به پشتيباني و ارتقاء يك نرم افزار از مسائل بسيار مهم و حياتي در موفقيت افزايش طول عمر يك نرم افزار محسوب مي گردد.
در مدل فوق همچنان واژه هاي سرويس دهنده و سرويس گيرنده حضور مستمر خود را ادامه دادند با اين تفاوت بسيار مهم كه حوزه عملكرد اين واژه ها در رابطه با نرم افزار بسيار برجسته گرديد. در اين مدل از سه لايه استفاده مي گردد: لايه اول مسئول تماس و ارتباط با كاربر و ارائه دهنده محيط رابط كاربر، لايه دوم ( مياني ) مسئول نگهداري و اجراي سياست ها و قوانين كليدي و راهبردي حاكم بر نرم افزار و لايه سوم مسئوليت نگهداري بانك اطلاعاتي و ارائه سرويس و خدمات به لايه متقاضي ( لايه دوم ) است. عملكرد لايه دوم ( مياني ) بسيار گسترده بوده و مي توان با همگرا نمودن اين عملكردها به چند بخش، لايه هاي ديگري را نيز در اين بخش داشته باشيم، در چنين حالتي اين مدل اصطلاحا N-Tire ناميده مي شود.
مدل فوق بهترين انتخاب براي پياده سازي نرم افزار بر روي بستر وب است. كليد طلائي طراحي اين نوع نرم افزارها توانائي نوشتن عناصر (اجزا) بگونه اي است كه از يكطرف امكان بكارگيري آنها بسادگي در لايه ها و حتي چندين برنامه فراهم شده و از طرف ديگر امكان ارتباط اين عناصر با يكديگر صرفنظر از زبان برنامه نويسي استفاده شده و ساير موارد مرتبط فراهم گردد. ما مي بايست جعبه هاي سياهي را طراحي كنيم كه صرفنظر از ماهيت درون هريك، قادر به استفاده از توان آنها در بخش يا بخش هائي از يك و يا چندين نرم افزار باشيم. مطلب فوق شايد مهمترين دليل رويكرد شركت هاي عظيم نرم افزاري جهت ارائه يك ساختار استاندارد براي توليد اين عناصر باشد. تكنولوژي Component Object Model يا COM پاسخ شركت مايكروسافت به اين نياز حياتي بود.

تكنولوژي COM

مهمترين ويژگي تكنولوژي فوق قابليت استفاده مجدد و ارتباط متقابل براي عناصر( اشياء) توزيع شده است. بدين ترتيب پياده كنندگان نرم افزار اين امكان را پيدا خواهند كرد تا با در كنار هم قرار دادن اين عناصر و استفاده چندباره از آنان (حتي اگر توليدكنندگان آنها متفاوت باشند) قادر به خلق آثار ماندگار خود در سريعترين زمان ممكن و متكي بر اصول مهندسي نرم افزار باشند.

ريشه COM

تكنولوژي COM بصورت ناگهاني مطرح نگرديد و ريشه در تلاش هائي دارد كه از مدت ها قبل بعنوان يك نياز مطرح شده بود. معرفي تكنولوژي Object Linking & Embedding يا OLE در سال 1991 اولين تلاش در اين زمينه بود كه توسط شركت مايكروسافت براي ارتباط و پيوستگي بين مستندات در چهارچوب مجموعه برنامه هاي آفيس مطرح گرديد. حوزه عملكرد تكنولوژي فوق بر روي مستندات (Documents) متمركز بود. در ادامه شركت مايكروسافت به اين نكته پي برد كه تكنولوژي فوق نبايد صرفا متمركز بر روي مستندات باشد و مي تواند عملكردي جامع تر را تحت پوشش خود قرار دهد. بدين منظور نسخه شماره 2، OLE در سال 1995 مطرح گرديد و اين نسخه در ادامه تمامي عناصر و اجزاي موجود در محيط ويندوز را شامل گرديد و بدين ترتيب COM مطرح شد.
در اوايل، تكنولوژي فوق در رابطه با عناصر و اجزاي توزيع شده امكانات قابل توجه اي ارائه نكرده بود. شايد يكي از مهمترين دلايل آن عدم عرضه يك سيستم عامل شبكه اي از طرف مايكروسافت تا آن زمان بود. همزمان با عرضه ويندوز 95 و ويندوز NT در سال 1996 و مطرح شدن امكانات شبكه اي و ضرورت توزيع، اجرا و ارتباط بين عناصر توزيع شده تكنولوژي Distributed COM يا DCOM مطرح گرديد. سرانجام در سال 1997 نسخه توسعه يافته اين تكنولوژي با نام +COM توسط شركت مايكروسافت ارائه گرديد.
همزمان با گرايش بسمت طراحي و پياده سازي نرم افزارهاي متكي بر مدل Three Tire از يكطرف و نياز شديد به پياده سازي نرم افزار هاي متكي بر وب، ضرورت توجه و بازنگري در نحوه طراحي و پياده سازي عناصر توزيع شده مورد اهتمام جدي شركت هاي عظيم نرم افزاري قرار گرفت. شركت مايكروسافت در اين زمينه منادي تكنولوژي هاي COM/DCOM/COM+، Internet Explorer و ActiveX گرديد. در مقابل شركت هاي نرم افزاري ديگر، NetScape، Java/J2EE ( شركت سان ) و CORBA را مطرح كردند.
اولين نسخه CORBA در سال 1992 توسط Object Management Group يا OMG كه بالغ بر ششصد عضو دارد ارائه گرديد. آخرين نسخه آن (نسخه شماره 2) در سال 1996 عرضه شده است. عملكرد كلي تكنولوژي فوق نظير COM است. بهرحال هدف اكثر تكنولوژي هاي فوق در اين است كه امكانات و استانداردهائي را براي توليد عناصر بگونه اي ارائه نمايند كه با پياده سازي آنها، قادر به اخذ سرويس و خدمات بصورت محلي و يا از را دور باشيم.
در اين راستا شايد مناسب باشد كه به عملكرد هر Tire در نرم افزارها از بعد سرويس دهي متمركز شده و هر Tire را بعنوان مجموعه اي از سرويس ها در نظر بگيريم كه مسئول ارائه سرويس به عناصر موجود در Tire خود و يا ساير Tire هاي مرتبط باشد. با اين نگرش مي توان گفت تمامي نرم افزارها خدمات و سرويس هاي خود را در سه بخش ارائه مي نمايند:
•User Sevices
•Business Services
•Data Services
در مدل Three Tire مسئوليت ارائه هر يك از سرويس هاي فوق به يك Tire واگذار مي گردد. عناصر موجود و مسئول ارائه سرويس و خدمات در هر Tire قادر به ارتباط و درخواست سرويس از عناصر موجود در Tire خود و ساير Tire هاي موجود در بالا و يا پايين خود خواهند بود. نكته بسيار مهم در رابطه با وضعيت فوق اين است كه يك درخواست جهت اخذ سرويس نمي تواند يك Tire را حذف و خود مستقيما با Tire ثانويه ( بعدي) مرتبط و اصطلاحا يك Tire را دور بزند. مثلا عناصر موجود در لايه User Services نمي توانند مستقيما درخواست خود را براي لايه Data Services ارسال دارند. البته لايه فوق نيز چنين امكاني را نخواهد داشت. هر يك از سه بخش فوق مسئوليت هاي خاصي را برعهده گرفته و در زمانيكه يك بخش به خدمات يك بخش ديگر نياز داشته باشد، درخواست خود را براي اخذ سرويس در اختيار بخش مورد نظر قرارداده و بخش مربوطه سرويس درخواستي را در قالب اجراي يك يا چندين عنصر انجام و ماحصل را در اختيار بخش مربوطه قرار خواهد داد.
مدل فوق كه بر اساس همگرائي نوع سرويس ها و خدمات در يك نرم افزار ارائه شده است، صرفا يك مدل منطقي است و نشاندهنده يك مدل فيزيكي نيست. دراين راستا چهار مدل فيزيكي براي پياده سازي نرم افزارهاي Three Tire ارائه شده است:
•SingleServer
•Business Server
•Transaction Server
•Web Server

Single Server

در اين مدل محل استقرار تمامي عناصر بين سرويس گيرنده و سرويس دهنده شبكه تقسيم مي گردد. در مدل فوق تمامي عناصر مربوط به بانك هاي اطلاعاتي (Data Services) بر روي سرويس دهنده قرار مي گيرد. عناصر مربوط به User Service در صورتيكه بگونه اي طراحي شده اند كه ممكن است مورد استفاده چندين نرم افزار ديگر قرار بگيرند، مي بايست آنها را بر روي سرويس دهنده شبكه نصب نمود. عناصر مربوط به Business Services كه مسئوليت پياده سازي سياست ها و قوانين در يك نرم افزار را برعهده دارند، عمدتا بر روي سرويس دهنده شبكه نصب مي گردنند مگر اينكه در رابطه با يك نرم افزار، اعمال يك سياست بخصوص را مي بايست در سطح لايه User Services پياده سازي نمود ( بررسي صحت داده هاي ورودي، انجام برخي محاسبات خودكار با توجه به رفتار داده ها و ). در اين حالت عنصر مجري سياست فوق مي بايست در لايه User Services و بصورت محلي و مختص به آن نصب و فعال گردد.

Bussines Server (Application)

در مدل فوق يك سرويس دهنده اضافي با نام Application Server، استفاده مي گردد. سرويس دهنده فوق مسئوليت استقرار تمامي عناصري را كه مي بايست به اشتراك گذاشته شوند، بر عهده خواهد گرفت. در اين راستا در صورتيكه برخي از عناصر مربوط به لايه User Service باشند ولي بصورت مشترك مورد استفاده چندين نرم افزار قرار مي گيرند نيز از اين قاعده مستثني نبوده و بهترين محل براي استقرار آنان، سرويس دهنده Application است. در مدل فوق تمامي عناصر مربوط به Data service بر روي سرويس دهنده Data قرار خواهند گرفت. ارتباط تمامي سرويس گيرندگان در ابتدا با Application Server آغاز خواهد گشت. سرويس گيرندگان خواسته خود را به لايه Application ارسال و لايه فوق مسئوليت ارتباط با لايه Data را بر عهده خواهد گرفت.

Transaction Server

Transaction واحد انجام يك فعاليت بوده كه خود مي تواند شامل چندين عمليات ديگر باشد. سلسله عمليات فوق مي بايست تماما با موفقيت اجرا گردند. در مدل فوق سرويس دهنده Transaction مسئوليت مديريت و ذخيره سازي عناصر لازم براي يك فعاليت Transaction را برعهده خواهد گرفت. در اين مدل مي توان از چندين سرويس دهنده ديگر بمنظور استقرار عناصر مربوطه استفاده كرد. استقرار عناصر بر روي سرويس دهنده ها مي بايست پويا بوده و در صورت افزايش ترافيك، امكان جابجائي آنها بر روي ساير سرويس دهنده ها وجود داشته باشد. سرويس دهنده Transaction مسئوليت هاي نگهداري عناصر ActiveX، ارسال درخواست يك برنامه به يكي از سرويس دهنده ها، اتمام اجراي يك برنامه، بررسي صحت عملكرد يك عنصر را بر عهده خواهد گرفت.

Web Server

در مدل فوق يك سرويس دهنده در شبكه اضافه و مسئوليت سرويس هاي وب را بر عهده خواهد گرفت. سرويس گيرنده ها مجهز به نرم افزارهاي ارتباطي نظير مرورگرها بوده تا بدين طريق قادر به درخواست صفحات ايستا و پويا از سرويس دهنده وب باشند. برنامه هاي مبتني بر وب تمامي تاكيد خود را بر استاندارد نمودن نرم افزارهاي مرورگري معطوف مي دارند. چراكه با استاندارد شدن اين نوع از نرم افزارها تمامي سرويس گيرنده ها با يك ابزار واحد استاندارد شده از سرويس دهنده هاي وب خواسته هاي خود را مطرح خواهند نمود. بديهي است در چنين حالتي پاسخگوئي به اين درخواست ها از طرف سرويس دهنده هاي وب بمراتب ساده تر و با اطمينان خاطر بيشتري صورت مي پذيرد.
در سه مدل گفته شده قبلي، بر اين نكته تاكيد وجود داشت كه تمامي سياست هاي راهبردي نرم افزار متمركز شده تا بدين طريق اعمال تغييرات بسادگي صورت پذيرد. در مدل فوق چون سرويس دهنده وب اين پتانسيل را دارا است كه بصورت اتوماتيك عناصري را بر روي كامپيوتر سرويس گيرنده مستقر نمايد، ضرورت تمركز سياست هاي راهبردي نرم افزار بر روي سرويس دهنده چندان مهم بنظر نمي آيد. در اين مدل بيشتر سرعت اجراي اين عناصر مورد توجه است. در چنين حالتي اگر يك برنامه مبتني بر وب بر روي بستر اينترنت اجرا مي گردد، مي توان برخي از عناصر را براي سرويس گيرنده ارسال تا بصورت محلي بر روي كامپيوتر وي اجرا شوند. در چنين حالتي سعي مي شود كه زمان ارتباط و درخواست از سرويس دهنده به حداقل زمان ممكن كاهش پيدا كند چراكه پهناي باند و ارتباط با سرويس گيرنده ها را نمي توان همواره بدون نگراني تضمين نمود. در صورتيكه برنامه مبتني بر وب بر روي بستر اينترانت اجرا مي گردد، مي توان بر اساس توان كامپيوترهاي سرويس گيرنده و سرويس دهنده و پهناي باند موجود، برخي از عناصر را بر روي سرويس دهنده و برخي ديگر از عناصر را بر روي سرويس گيرنده اجرا نمود.
بهرحال مدل فوق يك ايده جديد براي اجراي يك برنامه را مطرح كرده است. سرويس دهنده وب بسادگي و بصورت اتوماتيك قادر به نصب اجزاي مورد نياز يك سرويس گيرنده خواهد بود. بدين ترتيب از يكطرف ضرورت استقرار تمامي عناصر بر روي سرويس گيرنده از بين رفته و از طرف ديگر به سرويس گيرنده ها استقلال لازم داده شده و در صورت ضرورت مي توان آنها را نيز در اجراي برخي از عناصر سهيم كر

بررسي CLR

بررسي و آشنائي با محيط زمان اجراي دات نت يعني CLR و ويژگيهاي آن از جهت انتقال برنامه ها، بحث نسخه و مديريت حافظه
CLR يا Common Language Runtime در مرکز NET platform. واقع شده است. در حقيقت CLR عملي را که runtime ها در زبان هاي پيشين انجام مي داند انجام مي دهد. براي مثال ويژوال بيسيک 6 داراي يک Runtime مخصوص به خود بود که کارهاي مديريت حافظه، فراخواني فايلها و از اين دست اعمال را براي برنامه هاي بيسيک انجام مي داد، همچنين ويژوال سي نيز داراي چنين ابزاري بود. CLR يک runtime مشترک است براي تمامي زبانهايي که بر مبناي NET. طراحي شده اند.

نسخه

در ويژوال بيسيک 6 و کلا ً سيستم هاي قبلي که بر COM استوارند نسخه يک COM مساله بزرگي براي انتشار آن است. در حالي که شما مي توانستيد نسخه هاي مختلفي از يک COM داشته باشيد ولي در استفاده از ProgID ها داراي محدوديت بوديد. براي مثال در ويژوال بيسيک هنگام استفاده از Word.Application نمي توانستيد نسخه آن را انتخاب کنيد، يعني براي مثال Word.Application.9. در CLR تمام اجزا در GAC يا GlobalAssemblies Cache بار مي شوند. بعبارت ديگر اطلاعات اسمبلي ها در GAC قرار مي گيرند. در CLR دو ويژگي براي اسمبلي هايي که در GAC قرار مي گيرند وجود دارد:
Side-by-side versioning: بدين معني که نسخه هاي مختلف يک اسمبلي در کنار هم بدون تداخل وجود دارند.
Automatic QFE: اگر نسخه جديدي از يک اسمبلي که با نسخه قبلي سازگاري دارد در GAC قرار گيرد، CLR اين مساله را تشخيص مي دهد و از آن لحظه به بعد از نسخه جديد استفاده مي کند.
نسخه ها در CLR از چهار قسمت Major.Minor.Revision.Build تشکيل شده اند. اگر در Major و Minor تغييري داده شود، اين بدين معناست که اين نسخه از اسمبلي ديگر با نسخه هاي قبلي سازگاري ندارد.

انتقال

برنامه هايي که به زبان ويژوال بيسيک قديمي نوشته مي شوند در هنگام انتقال به کامپيوترهاي ديگر دچار مشکلات فراوان مي شوند. تمامي اجزا بايد در رجيستري ثبت شوند. اگر نسخه جديدي ايجاد شود امکان دارد برنامه هايي که از نسخه قديمي استفاده مي کردند را از کار بيندازد. ولي درNET. هم مساله نسخه ها تقريبا ً حل شده است و هم نحوه انتقال. کافي است در کامپيوتر مقصد NET Framework. نصب شده باشد. در اين صورت به راحتي با استفاده از دستور xcopy داس مي توانيد برنامه خود را انتقال بدهيد!
شايان ذکر است که اين نوشته صرفا ً توضيح مختصري درباره هر کدام از قسمت هاي NET. مي دهد و براي هر کدام از اين اجزا مي توان يک مقاله مفصل نوشت.
ادامه دارد ......
* ارسال مقاله توسط عضو محترم سايت با نام کاربري : mirkazemi
/خ