در اواسط دهه ۸۰ ميلادی و زمانيكه اولين بار توليدكنندگان تجهيزات شبكه، محصولات خود را به بازار عرضه كردند، واژه 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 ) بين دو سرويس گيرنده جهت تلاش برای دستيابی و يا بهنگام سازی برخی ركوردها مشكل است ( مسئله Record Locking ).
مدل 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 كه بر روی يك كامپيوتر مجزا قرار گرفته است استفاده نمايند و يك كاربر از راه دور ممكن است Application Server را بر روی يكدستگاه كامپيوتر اختصاصی اجرا نمايد.) بهرحال محل Application Server و Database Server ارتباطی با كاربر نداشته و تمامی آنها با يك روش يكسان از نرم افزار و توانائی آن استفاده می نمايند.
در مدل فوق لايه Presentation دارای آگاهی خصوصی از بانك اطلاعاتی نبوده و لايه فوق از طريق لايه Application Server و بكمك يك استراتژی خاص با بانك اطلاعاتی مرتبط خواهد بود. مرورگرها در حالت خاص دارای هيچگونه شناختی از ساختار بانك اطلاعاتی در سايت Amazon.com نمی باشند ولی با اين حال قادر به ارتباط با بانك اطلاعاتی و خريد يك كتاب هستند. در مدل فوق با نگرش وب، سرويس گيرنده از طريق يك پروتكل خاص با يك Application Server مرتبط می گردد. برنامه هائی از اين نوع ( مدل Three Tire ) پيچيده تر از مدل های قبلی بوده و هنوز ابزارهای برنامه نويسی خاصی در اين زمينه وجود ندارد و برنامه نويسان مجبور به نوشتن حجم بالائی از كدها خواهند بود.
مدل N Tire
اين مدل امروزه بسرعت رايج و مطرح شده است. در حقيقت مدل Three Tire در حالت خاص به سمت 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 بالائی قرار گرفته باشد، به آن Fat Client می گويند.بهترين نمونه از يك Thin Client، مرورگرهای وب بوده كه قادر به ارتباط با انواع نرم افزهائی است كه بر روی وب سايت قرار دارند.
جمع بندی
واژه Client Server دارای معانی بمراتب بيشتری نسبت به جداسازی يك كامپيوتر سرويس گيرنده و سرويس دهنده از يكديگر است واژه فوق بسرعت در دنيای نرم افزار نيز مطرح و دارای جايگاه ويژه ای در اين زمينه شده است. از ديدگاه فوق يك روتين ( سرويس ) می تواند ارائه دهنده خدمات خاصی به ساير سرويس ها باشد. در چنين وضعيتی سرويس ارائه دهنده خدمات را Server و سرويس استفاده كننده از يك خدمات را Client می گويند. با تعميم سياست های طراحی نرم افزار از مدل های One Tire به Two-Tire و Three Tire و نهايتا N-Tire و تاكيد بر نگرش ساختيافته و اصولی به عملكرد هر يک از لايه ها، مفهوم روتين های سرويس دهنده ( Server ) و روتين های سرويس گيرنده (Client) جايگاه ممتازی را پيدا نمودند.
يك سرويس می تواند در عين خدمات دهی به ساير سرويس های متقاضی، خود نيز از خدمات ساير سرويس ها استفاده نمايد. بنابراين يك سرويس دهنده در چنين حالتی بصورت اختصاصی صرفا رسالت سرويس دهی و يا سرويس گيری را انجام نخواهد داد. اگر از ديگاه هر لايه به عملكرد سرويس ها نظری داشته باشيم، قطعا تمامی آنها مسئوليت ارائه يك سرويس خاص را در لايه مربوطه برعهده خواهند داشته و قدرمطلق تمامی آنها ارائه خدمات است. مهمترين مزيت نگرش فوق حركت بi سمت توليد سرويس هائی خواهد بود كه اولا امكان استفاده از آنان در چندين نرم افزار فراهم شده و ثانيا زمينه تحقق اصل بسيار مهم استفاده مجدد از كدهای نوشته شده (Reusable Code) نيز فراهم می گردد. امروزه با توجه به نياز روزافزون به طراحی و پياده سازی نرم افزارهای متكی بر وب، مدل های Three Tire و N-Tire بشدت مورد توجه طراحان و پياده كنندگان نرم افزارهای متكی بر بستر وب قرار گرفته است.
