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

مديريت حافظه

درباره مديريت حافظه CLR بيشتر در زمينه VB بحث می کنيم.

مديريت بهتر بر Garbage Collection:

Runtime در ويژوال بيسيک دارای سيستم خود کار برای Garbage Collection ها است. در ويژوال بيسيک 6، runtime به شکل خودکار منابع را از شئ هايی که ديگر توسط برنامه استفاده نمی شوند می گيرد. برای مثال فرض کنيد می خواهيم يک فايل LOG ايجاد کنيم، برای اين کار می توان از دو شئ Scripting.Stream و Scripting.FileSystemObject استفاده کرد. اگر اين دو شئ را در تابعی به کار ببريم، بعد از اتمام عمليات، runtime منابع اختصاص داده شده به اين دو شئ را می گيرد. اما مواردی وجود دارد که runtime به آسانی امکان تشخيص شئ و زمان بلااستفاده بودن آن را ندارد.

Cyclical References:

يکی از مهمترين زمانهايی که runtime مربوط به VB نمی تواند تشخيص بدهد که آيا يک شئ به منابعی احتياج دارد يا اينکه کارش به پايان رسيده زمانی است که در متن برنامه حالتی به نام Cyclical Reference بوجود بيايد. به عنوان مثال اگر شئ A به صورت reference از شئ B استفاده کند و همچنين شئ B از A.
هر شئ COM مسئول نگهداری تعداد دفعاتی است که فعال شده است. بدين صورت که هر بار از روی آن ساخته شود با AddRef و هربار که يک برنامه آن را رها کند با Release از IUnKnown interface شمارنده ای را يکی افزايش يا کاهش می دهد. اگر آن شمارنده به صفر برسد شئ تمامی منابع خود را آزاد می کند، اما اگر هنگامی که يک شئ COM غير فعال شود ولی از Release استفاده نشود يک شئ بلا استفاده در حافظه می ماند.
runtime مربوط به VB 6 اين کار را به صورت خودکار انجام می دهد، اما هنگامی که دو شئ به هم اشاره می کنند بحث فرق می کند و runtime به شکل حالت ساده نمی تواند يک شئ را از حافظه بردارد. برای مثال به قطعه برنامه زير توجه کنيد.

'Class : CCyclicalRef Dim m_objRef as Object    Public Sub Initialize(objRef as Object)       Set m_objRef = objRef EndSub    Private Sub Class_Terminate()       Call Msgbox("Terminating.")       Setm_objRef = Nothing End Sub

در کلاس CCyclicalRef متدی با نام Initialize تعريف شده است که در پارامتر های خود يک شئ را می پذيرد و از روی آن يک شئ ديگر می سازد. حال از کلاس تعريف شده در کد زير استفاده می کنيم.

Dim objA as New CCyclicalRef Dim objB as NewCCyclicalRef    Call objA.Initialize(objB) Call objB.Initialize(objA)    Set objA = Nothing Set objB = Nothing

ابتدا دو نمونه از روی کلاس CCyclicalRef با نامهای objA و objB ساختيم، حال هر دوی اين شئ ها يک بار ساخته شده اند و شمارنده آنها يک است. با استفاده از متد Initialize هر دوی شئ ها، آدرس حافظه يکديگر را مبادله می کنند و به اين شکل از روی هر دوی آنها يک بار ديگر ساخته می شود و شمارنده هر دو، 2 می شود. شماره يک مربوط به خود برنامه است و شماره دوم مربوط به شئ هايی که به هم اشاره می کنند. سپس هر دوی آنها را برابر nothing قرار می دهيم تا آنها را از حافظه حذف کنيم. در اينجا شمارنده هر دو يکی کم و برابر يک می شود. بنابراين برنامه terminate شده است ولی هنوز شئ در حافظه وجود دارد.

Garbage Collector در CLR:

روش Garbage Collector در CLR با VB 6 Runtime تفاوت دارد. در روش جديد که خود ِ CLR و GC مسئول اجرای آن هستند، آخرين باری که از nothing استفاده می شود ولی هنوز شئ در حافظه مانده باشد، GC اين وضعيت را درک می کند و آن شئ را بعد از مدتی از حافظه خارج می کند. شئ هايی هستند که مانند COM مسئول غير فعال کردن خود نيستند، GC آنها را نيز تشخيص داده و اگر برنامه ای ديگر از آنها استفاده نکند، از حافظه حذف می شوند.

Finalize:

GC متد Object.Finilize را قبل از اينکه هر شئ را از حافظه حذف کند صدا می زند. اين متد می تواند در هر زمانی بعد از اينکه برنامه ديگر از شئ استفاده نکرد صدا زده شود، لذا در هنگام استفاده از اين متد بايد نکته را در نظر گرفت. درNET. بهتر است قبل از اينکه يک شئ بوسيله nothing از بين برود از متد Dispose يا Close استفاده شود تا سريعا ً از حافظه حذف شود.

روش سريعتر تخصيص حافظه به شئ ها

هر زمان که يک برنامه يک شئ بسازد حافظه ای به آن اختصاص می يابد، آن حافظه در virtual memory است که برای هر برنامه اختصاص می يابد و به آن heap گفته می شود. CLR مفهومی به نام Managed Heap دارد بدين معنی که شئ ها را مديريت می کند و آنها را در يک Heap ِ مديريت شده قرار می دهد و CLR مسئول حفاظت آنهاست.
از مزايای اين روش اين است که راندمان سرعت اختصاص دادن حافظه بالا می باشد. به طور کلی وقتی کُد های مديريت نشده در Heap های مديريت نشده قرار می گيرند، به دنبال جايی در حافظه می گردند که بتوانند خود را در آن قرار دهند. در CLR شئ‎ای که ساخته می شود هميشه در بالای آخرين شئ‎ای که ساخته شده در heap قرار می گيرد. تصوير مربوطه را در اين آدرس مشاهده کنيد.
ابتدا CLR حافظه ای برای شئ های A، B و C بر روی Heap در نظر می گيرد. سپس شئ B از حافظه حذف می شود، در ادامه نيز برنامه يک شئ ديگری به نام D می سازد و آن را بر روی آخرين شئ‎ای که ساخته شده بود يعنی C قرار می دهد. اين روش برای اختصاص حافظه سريع است. اما اگر CLR به انتهای heap برسد چه عملی بايد انجام دهد؟ همان طور که مشاهده کرديد اين روش به شکل افزايشی شئ ها را در حافظه قرار می دهد. وقتی CLR ديگر نتواند از حافظه استفاده کند GC را فرا می خواند. GC هم فضاهايی مانند B را کاملا ً آزاد می کند و هم شئ ها را فشرده می کند و در پايين heap قرار می دهد تا بالای heap آزاد باشد.

پردازش های مبتنی بر Client Server

در اواسط دهه ۸۰ ميلادی و زمانيكه اولين بار توليدكنندگان تجهيزات شبكه، محصولات خود را به بازار عرضه كردند، واژه Client/Server وارد عرصه كامپيوتر گرديد. در آن زمان واژه فوق صرفا در رابطه با تجهيزات سخت افزاری ( كامپيوتر ) استفاده می شد و كامپيوتری كه از آن بعنوان مركز ثقل ارائه خدمات در يك شبكه ياد می شد، را با نام Server و كامپيوتری كه از اين امكانات استفاده می كرد را بعنوان Client می شناختند ( سايه نرم افزار بر اين واژه حضور سنگينی نداشت ).
امروزه واژه فوق دارای يك معنی خاص است كه چندان مرتبط با سخت افرار نمی گردد. اغلب مردم هنوز واژه Client را به يك كامپيوتر فيزيكی نسبت داده و واژه Server را به كامپيوتر فيزيكی ديگری كه به آن متصل و سرويس هائی را ارائه می نمايد، اطلاق می نمايند. مطلب فوق با اينكه درست است ولی صرفا يك بخش اندك از تمامی واقعيت های موجود در اين زمينه است. واژه فوق امروزه در مقياس وسيعتری به خدمت گرفته می شود. بمنظور آشنائی بيشتر با اين واژه لازم است در ابتدا با ساختار و يا معماری عمومی يك نرم افزار آشنا شويم.
اغلب برنامه های كاربردی دارای سه لايه اصلی می باشند :
لايه Presentation: ( بالاترين لايه ) اين لايه مسئول ايجاد ارتباط متقابل بين انسان و كامپيوتر است ( رابط كاربر). لايه فوق مسئوليت گرفتن اطلاعات ورودی از صفحه كليد، ماوس و ساير دستگاههای ورودی و نمايش اطلاعات ذيربط بر روی دستگاههای خروجی نظير صفحه نمايشگر است.
لايه Application يا Business Logic: لايه فوق مسئول اعمال و پياده سازی سياست های مورد نظر در يك نرم افزار است، در حقيقت با عملكرد لايه فوق است كه می توان تفاوت بين يك نرم افزار از نرم افزار ديگر را مشاهده و بعنوان مثال تفاوت بين يك نرم افزار ثبت سفارش و يا انبارداری را حس كرد.
لايه Service: اين لايه مسئول ارائه سرويس های خاص و مورد نياز برای ساير لايه ها نظير سرويس های مربوط به فايل، چاپ، ارتباطی و از همه مهمتر دسترسی به بانك های اطلا عاتی است. در ادامه بحث خود را بر روی مجموعه ای از نرم افزارها ئی متمركز خواهيم كرد كه نيازمند سرويس های بانك اطلاعاتی باشند.
تعداد طبقات ( Tires )، در يك نرم افزار Client Server به نحوه ارتباط ( متراكم، معمولی ) هر يك از سه لايه گفته شده بستگی خواهد داشت. در ادامه به بررسی مدل های رايج در اين زمينه خواهيم پرداخت.

مدل One-Tire

در اين نوع نرم افزارها سه لايه گفته شده بصورت متراكم و فشرده در كنار يكديگر قرار می گيرند. در مدل فوق لايه Presentation دارای آگاهی خاص و جزئی از ساختار بانك اطلاعاتی است. لايه Application اغلب بصورت موجی با لايه های Presentation و Service مرتبط خواهد بود. تمام سه لايه گفته شده بهمراه بانك اطلاعاتی، اغلب بر روی يكدستگاه كامپيوتر قرار گرفته و اجرا خواهند شد. نرم افزارهائی با اين خصوصيت بسادگی طراحی شده و بكمك ابزارهای برنامه نويسی امروزی بسرعت نوشته خواهند شد.
در صورتيكه بخواهيم يك نرم افزار One-tire با چندين كاربر را طراحی نمائيم، می توان نرم افزار را بر روی چندين كامپيوتر اجرا و با به اشتراك گذاشتن بانك اطلاعاتی زمينه استفاده از داده های موجود در بانك را برای ساير كاربران نيز فراهم نمود. بانك اطلاعاتی را می توان بر روی يكدستگاه كامپيوتر معمولی در يك شبكه نظير به نظير ( Peer to Peer ) و يا بر روی يك سرويس دهنده فايل ( File Server ) نصب نمود. در اين حالت هر يك از كامپيوترهائی كه برنامه بر روی آنها اجرا می گردد می بايست دارای يك نسخه از Database Engine بوده تا قادر به استفاده از داده های موجود در بانك اطلاعاتی باشند. در اين مدل صرفا داده ها به اشتراك گذاشته شده و منطق بانك اطلاعاتی به اشتراك گذاشته نشده است. اين نوع از نرم افزارها ( چند كاربره One Tire ) تا زمانيكه تعداد كاربران كم باشد موفق عمل می نمايند ولی با افزايش تعداد كاربران، با مشكل مواجه می شوند.
علت عمده بروز مشكل پايبند بودن اين نوع از نرم افزارها به انجام عمليات مربوط به بانك های اطلاعاتی بر روی هر يك از سرويس گيرندگان است. مثلا اگر برنامه ای از اين نوع نياز داشته باشد كه ليست تمامی كاربرانی را كه نام آنها Reza است، را نمايش دهد، می بايست تمامی اطلاعات ( ركوردهای داده و ايندكس های مربوطه ) بمنظور پاسخگوئی به درخواست واصل شده، بر روی شبكه فرستاده شود. در برخی حالا ت خاص و با توجه به پيچيدگی درخواست های صادر شده برای اطلاعاتی خاص، ممكن است تمامی بانك اطلاعاتی برای سرويس گيرنده ارسال گردد.
اگر از يك سطح فنی به مسئله فوق نگاه كنيم، مديريت Database Engine های مستقل بر روی سرويس گيرندگان بمنظور ممانعت از بروز تعارض ( Conflict ) بين دو سرويس گيرنده جهت تلاش برای دستيابی و يا بهنگام سازی برخی ركوردها مشكل است ( مسئله RecordLocking ).

مدل Two Tire

بمنظور حل مشكل مطرح شده در مدل One-tire از بعد كارائی و مسائل فنی مربوطه، مدل فوق معرفی گرديد. نرم افزارهائی كه با اتكا بر مدل فوق طراحی و پياده سازی می گردنند در اغلب موارد دارای عملكردی مشابه مدل One Tire بوده با اين تفاوت مهم كه Database Engine بر روی سرويس گيرنده ها اجرا نخواهد شد.
در مدل فوق بانك اطلاعاتی بر روی سرويس دهنده اجرا می گردد. از روش های متعددی برای ارتباط بين لايه Application(Logic) و Database Service استفاده می گردد. SQL ( زبان ساختيافته پرس و جو ) از متداولترين روش های موجود در اين زمينه است. دستورات SQL به سرويس دهنده بانك اطلاعاتی ارسال شده و در آنجا عمليات مربوطه بصورت محلی انجام و نتيجه ( اطلاعات مربوط به درخواست ارسال شده ) برای سرويس گيرنده ها ارسال خواهد شد. در مدل فوق صرفا سرويس دهنده بانك اطلاعاتی از برنامه مجزا شده و لايه های Presentation و Busines Logic همچنان در هم تنيده هستند. دو لايه فوق همچنان دارای آگاهی اساسی ( محرمانه ) از بانك اطلاعاتی خواهند بود.
نوشتن برنامه هائی از اين قبيل تا اندازه ای پيچيده تر از مدل قبل است. امروزه ابزارهای برنامه نويسی نيز مجهز به پتانسيل هائی شده اند كه طراحی و نوشتن اين نوع از برنامه ها را سرعت می بخشد. اغلب ابزارهای برنامه نويسی دارای امكاناتی جهت استفاده از DataBase Engines بوده كه می توان از آنها در طراحی برنامه های One-Tire استفاده كرد ( نظير Jet Engine كه توسط اكسس و ويژوال بيسيك استفاده می گردد) اما نرم افزارهای Two Tire نيازمند محصولات مجزای بانك اطلاعاتی نظير Oracle , IBM DB2 , Sybase و SQL Sever می باشند.

مدل Three Tire

اين مدل همانگونه كه احتمالا حدس زده ايد تمامی سه لايه گفته شده را در بخش های مستقل قرار می دهد. در مدل فوق Business Logic يك سرويس است و می تواند بر روی كامپيوتر اختصاصی خود فعال و اجرا گردد. زمانيكه Business بصورت يك سرويس دهنده در نظر گرفته می شود با نام Application Server ناميده می شود. يك Application Server اغلب ممكن است بر روی همان كامپيوتری كه DataBase Engine قرار دارد، نصب گردد. شايد يكی از دلايل مهم جهت انجام اين كار افزايش كارآئی سيستم باشد.
يكی از مزايای مهم و كليدی، داشتن يك Application Server اين است كه بتوان آن را در محلی قرار داد كه به بهترين نوع ممكن خدمات خود را ارائه نمايد. در اين مدل مسئله حائز اهميت در اين است كه تمامی Application Serverها بتوانند و می بايست سرويس بانك اطلاعاتی خود را از يك كامپيوتر مركزی دريافت دارند. ( ممكن است در برخی حالات تعدادی از كاربران نرم افزار از يك Application Server كه بر روی يك كامپيوتر مجزا قرار گرفته است استفاده نمايند و يك كاربر از راه دور ممكن است ApplicationServer را بر روی يكدستگاه كامپيوتر اختصاصی اجرا نمايد.) بهرحال محل ApplicationServer و Database Server ارتباطی با كاربر نداشته و تمامی آنها با يك روش يكسان از نرم افزار و توانائی آن استفاده می نمايند.
در مدل فوق لايه Presentation دارای آگاهی خصوصی از بانك اطلاعاتی نبوده و لايه فوق از طريق لايه Application Server و بكمك يك استراتژی خاص با بانك اطلاعاتی مرتبط خواهد بود. مرورگرها در حالت خاص دارای هيچگونه شناختی از ساختار بانك اطلاعاتی در سايت Amazon.comنمی باشند ولی با اين حال قادر به ارتباط با بانك اطلاعاتی و خريد يك كتاب هستند. در مدل فوق با نگرش وب، سرويس گيرنده از طريق يك پروتكل خاص با يك Application Server مرتبط می گردد. برنامه هائی از اين نوع ( مدل Three Tire ) پيچيده تر از مدل های قبلی بوده و هنوز ابزارهای برنامه نويسی خاصی در اين زمينه وجود ندارد و برنامه نويسان مجبور به نوشتن حجم بالائی از كدها خواهند بود.

مدل N Tire

اين مدل امروزه بسرعت رايج و مطرح شده است. در حقيقت مدل ThreeTire در حالت خاص به سمت N-Tire ميل خواهد كرد. در اين حالت يك Application Server می تواند درخواست خود را از چندين سرويس ديگر داشته باشد. هر يك از سرويس های صدا زده شده نيز خود می توانند سرويس های ديگری را جهت پاسخگوئی به درخواست واصل شده، فعال نمايند. واژه MiddleWare اغلب جهت تشريح ارتباط يك برنامه يا Business Logic بر روی يك Application Server استفاده می گردد.

چه ميزان از Bussines Logic می بايست بر روی Application Server قرار گيرد؟

بدون شك يكی از بخش های مهم هر نرم افزار كه دائما می تواند دستخوش تغييرات گردد، مجموعه قوانينی است كه با اعمال آنها سياست عملكردی يك نرم افزار تعيين می گردد. مثلا در يك سيستم بازرگانی می توان قانونی را داشته باشيم كه برای خريدهای بالای يكصد هزار تومان مجوز مدير مربوطه فرض است. در اين حالت می توان قانون فوق را بصورت يك روتين ( سرويس ) و بصورت جامع طراحی و در لايه Application قرار داد، سرويس فوق می تواند توسط ساير سرويس های موجود در اين لايه و يا ساير لايه ها مورد استفاده قرار گيرد. بديهی است در صورتيكه اين سياست به نوعی تغيير نمايد و قرار شود از اين پس خريدهای بالای يكصد و پنجاه هزار تومان مكلف به تاييد مديريت مربوطه باشند، بسادگی با اعمال تغيير در روتين فوق و تزريق سياست جديد، زمينه استفاده اتوماتيك از آن برای ساير سرويس های استفاده كننده فراهم می گردد.
نحوه و زمان تغيير سياست فوق از ديدگاه استفاده كننده و لايه Presentation مهم نبوده و تغييرات بصورت خودكار در تمامی سرويس های موجود در ساير لايه ها حس خواهد شد. بنابراين مجموعه قوانين و سياست هائی كه در روند عملياتی يك نرم افزار نقش تعيين كننده ای را دارند، می بايست در لايه Application قرار گرفته تا بدينوسيله امكان درج تغييرات و اعمال سياست های جديد مركزيت يافته و مسائل مربوط به پشتيبانی و ارتقا يك نرم افزار با اطمينان خاطر و صرف كمترين زمان و هزينه صورت پذيرد.
در برخی از موارد می توان اين سياست ها را در قالب مجموعه ای از سرويس ها در لايه Presentation قرار داد. بررسی صحت داده های ورودی يك نمونه مناسب در اين زمينه است. در اين مورد اغلب قوانين جهت بررسی اعتبار و صحت داده های ورودی بر روی لايه Presentation قرار خواهد گرفت. بديهی است در چنين حالتی بجای ارسال اطلاعات بررسی نشده به لايه Application و بكارگيری يك روتين جهت بررسی صحت داده ها، می توان اين عمليات را در لايه Presentation قرار داد تا بدينوسيله از يكطرف ترافيك محيط انتقال داده ها افزايش نيابد و از طرف ديگر كاربران رودرو با لايه Presentation بازخوردهای سريعی را از سيستم داشته باشند. بهرحال در چنين حالاتی بخشی از منطق عملكرد يك نرم افزار را در لايه Presentation قرار داده ايم. در صورتيكه حجم Logic اضافه شده در لايه Presentation كم و ناچيز باشد، در اينصورت لايه فوق بصورت انحصاری مسئوليت های پيش فرض خود را دنبال خواهد كرد. در چنين وضعيتی سرويس گيرنده را Thin Client می گويند. در حالتيكه بر روی سرويس گيرنده، Logic بالائی قرار گرفته باشد، به آن FatClient می گويند.بهترين نمونه از يك Thin Client، مرورگرهای وب بوده كه قادر به ارتباط با انواع نرم افزهائی است كه بر روی وب سايت قرار دارند.

جمع بندی

واژه Client Server دارای معانی بمراتب بيشتری نسبت به جداسازی يك كامپيوتر سرويس گيرنده و سرويس دهنده از يكديگر است واژه فوق بسرعت در دنيای نرم افزار نيز مطرح و دارای جايگاه ويژه ای در اين زمينه شده است. از ديدگاه فوق يك روتين ( سرويس ) می تواند ارائه دهنده خدمات خاصی به ساير سرويس ها باشد. در چنين وضعيتی سرويس ارائه دهنده خدمات را Server و سرويس استفاده كننده از يك خدمات را Client می گويند. با تعميم سياست های طراحی نرم افزار از مدل های One Tire به Two-Tire و Three Tire و نهايتا N-Tire و تاكيد بر نگرش ساختيافته و اصولی به عملكرد هر يک از لايه ها، مفهوم روتين های سرويس دهنده ( Server ) و روتين های سرويس گيرنده (Client) جايگاه ممتازی را پيدا نمودند.
يك سرويس می تواند در عين خدمات دهی به ساير سرويس های متقاضی، خود نيز از خدمات ساير سرويس ها استفاده نمايد. بنابراين يك سرويس دهنده در چنين حالتی بصورت اختصاصی صرفا رسالت سرويس دهی و يا سرويس گيری را انجام نخواهد داد. اگر از ديگاه هر لايه به عملكرد سرويس ها نظری داشته باشيم، قطعا تمامی آنها مسئوليت ارائه يك سرويس خاص را در لايه مربوطه برعهده خواهند داشته و قدرمطلق تمامی آنها ارائه خدمات است. مهمترين مزيت نگرش فوق حركت بi سمت توليد سرويس هائی خواهد بود كه اولا امكان استفاده از آنان در چندين نرم افزار فراهم شده و ثانيا زمينه تحقق اصل بسيار مهم استفاده مجدد از كدهای نوشته شده (Reusable Code) نيز فراهم می گردد. امروزه با توجه به نياز روزافزون به طراحی و پياده سازی نرم افزارهای متكی بر وب، مدل های Three Tire و N-Tire بشدت مورد توجه طراحان و پياده كنندگان نرم افزارهای متكی بر بستر وب قرار گرفته است.
* ارسال مقاله توسط عضو محترم سایت با نام کاربری : mirkazemi
/خ