ويژگی های امنيتی(ASP.NET (2

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

بمنظور بررسی مقوله پياده سازی نرم افزار بر روی بستر وب بحث خود را بر روی دو موضوع عمده متمركز می كنيم: شناخت مدل های رايج جهت پياده سازی نرم افزار از ابتدا تا كنون و شناخت وب بعنوان بستر مربوطه بهمراه تكنولوژی هائی كه در اين زمينه مورد استفاده قرار می گيرند.
هدف ما رسيدن به نقطه ای است كه مشخص نمائيم، برای طراحی و پياده سازی نرم افزار بر روی بستر وب، اولا از چه نوع مدلی برای پياده سازی استفاده می گردد و ثانيا روند توسعه و تكامل وب را با تاكيد بر نيازهای نرم افراری از بعد ابزارشناسی دنبال كرده و از اين رهگذر جايگاه هر ابزار (تكنولوژی) تبين شده تا بدين وسيله بتوانيم از هر چيز در جايگاه خود و در زمان مربوطه استفاده كنيم. بهرحال وب يك واقعيت انكار ناپذير بوده و سايه حضور آن را در همه جا می توان احساس كرد. نرم افزار نيز مجری خواسته های انسانی در سرزمين سخت افزار است، اين بار با يك چالش جدی مواجه شده است : پاسخگوئی به خيل نيازهای جديد مطرح شده متكی بر بستر وب.
در بخش اول اين مقاله موضوع اول يعنی شناخت مدل های پياده سازی نرم افزار تشريح خواهد شد. به اين اميد كه از اين رهگذر به نقطه ای برسيم كه يك مدل مناسب جهت پياده سازی برنامه های تحت وب را معرفی و آن را بعنوان پايه و اسا س كار خود قرار دهيم. در ابتدا لازم است به اين اصل بديهی اشاره شود كه يك برنامه كامپيوتری حاصل تركيب داده ها و منطق است. منطق يك برنامه از طريق كدهای مربوطه كه به يكی از زبانهای برنامه نويسی نوشته خواهند شد، مسئول تحقق خواسته های تعريف شده برای يك نرم افزار از طريق انجام عمليات مورد نياز بر روی داده ها است. داده ها خود می توانند به اشكال و روش های متنوعی سازماندهی و در اختيار يك نرم افزار قرار گيرند.
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) متمركز بود. در ادامه شركت مايكروسافت به اين نكته پی برد كه تكنولوژی فوق نبايد صرفا متمركز بر روی مستندات باشد و می تواند عملكردی جامع تر را تحت پوشش خود قرار دهد. بدين منظور نسخه شماره ۲، 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 كه بالغ بر ششصد عضو دارد ارائه گرديد. آخرين نسخه آن (نسخه شماره ۲) در سال 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
/خ