بخشی از مقاله

مفاهيم اوليه سرويس های وب


سرويس های وب ، نقطه عطفی در معماری برنامه های توزيع شده بر روی اينترنت می باشند . بدون شک، يکی از مهمترين تحولات در زمينه برنامه های توزيع شده ، مطرح شدن سرويس های وب است که تاثيرات فراوانی را در رابطه با وضعيت نرم افرار خصوصا" بر روی اينترنت بدنبال خواهد داشت . ما شاهد نقطه عطفی در ظهور نسل جديدی از برنامه های کامپيوترهای با قابليت استفاده بر روی بستر وب ، خواهيم بود که گفتمان برنامه ها در عرصه جهانی را محقق خواهد کرد ( تحقق آرزوئی بزرگ برای صنعت نرم افزار) .


در مجموعه مقالاتی که بدين منظور نوشته خواهد شد به بررسی اصولی سرويس های وب و جايگاه آنان در فرآيند طراحی و پياده سازی برنامه های توزيع شده پرداخته می گردد . در اين راستا لازم است در ابتدا به مقاهيم اوليه برنامه های توزيع شده ، تکامل تدريجی برنامه های توزيع شده ، محدوديت های موجود در رابطه با معماری برنامه های توزيع شده ، رويکردهای متفاوت بمنظور طراحی و پياده سازی برنامه های توزيع شده ، پرداخته گردد تا زمينه علمی مناسب، برای پرداختن به مفاهيم اوليه سرويس های وب فراهم گردد .


مقدمه
قبل از ابداع کامپيوترهای شخصی، عملا" برنامه های توزيع شده ای وجود نداشته است . در آن دوران ، استفاده از کامپيوتر، شامل نشستن پشت يک ترمينال و برقراری ارتباط با يک سيتستم بزرگ (Mainframe) بود. با اينکه ترمينال ها در چندين ساختمان و يا حتی محل فيزيکی قرار می گرفتند ، ولی عملا" يک کامپيوتر مرکزی وجود داشت که مسئوليت انجام تمامی پردازش ها و ذخيره سازی داده ها را برعهده می گرفت .


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


در اين رابطه دلايل متعددی عنوان می شود که مهمترين آنان عبارتند از :
• هزينه سيستم های Mainfarme . يکی از اولين دلايل مهم ، هزينه های بالای سيستم های Mainframe است . اين مسئله از دو زاويه متفاوت قابل بررسی است : هزينه بالای سرمايه گذاری اوليه که بسياری از سازمان ها و موسسات توان مالی آن را ندارند و دوم اينکه در اين مدل ، دارای صرفا" يک نقطه آسيب پذير با ريسک بالا می باشيم .


• مالکيت اختصاصی داده ها. يکی از فاکتورهای مهم ديگر، سياست های مربوط به مالکيت داده ها است . سازمان ها و موسسات که دارای داده های اختصاصی خود می باشند، علاقه مند به واگذاری مسئوليت مديريت داده های مربوطه ، به ساير مکان های فيزيکی نمی باشند .
• امنيت . يکی ديگر از فاکتورهای مهم در اين زمينه موضوع امنيت است . برای يک سازمان ، اولا" دستيابی به اغلب داده های آن می بايست بسادگی محقق گردد و ثانيا" داده ها ی حساس موجود در سازمان می بايست از بعد امنيتی، ايمن نگهداری گردند . تامين دو خواسته فوق ( رويکردهای رقابتی و رويکردهای امنيتی ) با جدا سازی فيزيکی داده ا از يکديگر محقق خواهد شد ( انباشت داده ها، با نگرش های متفاوت در رابطه با سرعت در دستيابی و ايمن در ذخيره سازی ، ضرورت وجود برنامه های توزيع شده را بخوبی نمايان می سازد )


مسائل فوق، ضرورت حرکت بسمت ايجاد يک الگوی جديد بمنظور طراحی برنامه های کامپيوتری را مطرح و بر همين اساس نسل جديدی از برنامه های کامپيوتری با عنوان " برنامه های توزيع شده" در عرصه نرم افزار بوجود آمد .


برنامه های توزيع شده و ارائه دهندگان سرويس
با توجه به ضرورت و تعجيل در طراحی يک الگوی جديد برای برنامه های توزيع شده و عدم وجود استانداردهای صنعتی لازم در اين خصوص ، شرکت های عظيم نرم افزاری هر يک با توجه به ديدگاه های خود ، اقدام به عرضه راهکارهائی در اين زمينه نمودند.شرکت های فوق، در رابطه با اينکه می بايست برنامه های توزيع شده بصورت عناصر توزيع شده ، توليد گردند ، اتحاد نظر داشتند .

بدين ترتيب عناصر متفاوت و توزيع شده در يک برنامه، بعنوان ارائه دهندگان سرويس به يک برنامه منطقی ايفای وظيفه می نمايند. با توزيع قابليت ها و پتانسيل ها ، امکانات اساسی( بلاک های اوليه ) بمنظور ايجاد برنامه های بزرگ، بسادگی فراهم می گردد . رويکرد فوق ، مسائل و تبعات خاص خود را بدنبال داشت که در ادامه به بررسی برخی از آنان خواهيم پرداخت .


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


مسائل مربوط به برنامه های توزيع شده سنتی
پياده سازی برنامه های توزيع شده مستلزم استفاده از تکنيک ها و مدل های جديد است . راهکارهای انتخابی و استفاده شده ، خود باعث بروز مسائل جديد نيز خواهند شد. در اين بخش به بررسی مسائل مرتبط با طراحی برنامه های توزيع شده پرداخته و دو معماری خاص در اين زمينه را بررسی خواهيم کرد :
• معماری RPC)Remote Procedure Call-based)
• معماری مبتنی بر پيام (Message-based)
ملاحظات مربوط به طراحی برنامه های توزيع شده


در زمان طراحی برنامه های توزيع شده مسائل متعددی وجود دارد که می بايست به آنها توجه کرد :
• نوع داده های متفاوت . سيستم های عامل متفاوت، انواع مختلفی از نوع داده ها را حمايت می نمايند. در برخی موارد ، نوع داده ها در سيستم های عامل متفاوت کاملا" با يکديگر سازگار، نمی باشند . بنابراين می بايست از راهکارهای مناسب بمنظور برخورد منطقی با نوع داده های متفاوت موجود در سيستم های مختلف ، استفاده گردد.


• بروز اشکال در سرويس دهنده . با توجه به اينکه عناصر يک سيستم توزيعی، عموما" بصورت از راه دور اجراء می گردند، ما دارای چندين نقطه ( مکان) برای بروز اشکال خواهيم بود. بروز اشکال در يکی از نقاط ، می تواند باعث بروز مسائل عمده ای در رابطه با عملکرد تمام برنامه توزيع شده گردد. بنابراين می بايست راهکارهای مناسب در خصوص مواجه شدن با چنين مواردی، اتخاذ گردد .


• بروز اشکال در سرويس گيرنده . در صورتيکه سرويس دهنده ای وضعيت خاصی را ازطرف سرويس گيرنده ، اخذ و ذخيره می نمايد و سرويس گيرنده با اشکال مواجه گردد، می بايست از روشی بمنظور اعلام بروز اشکال به سرويس دهنده استفاده کرد. تصميم گيری و نحوه برخورد با منابع در اختيار سرويس گيرنده نيز از جمله مواردی است که می بايست راهکارهای آن بدرستی مشخص گردد.


• تلاش برای فراخوانی مجدد . در صورتيکه يک متد از راه دور فراخوانده شود و از طرف سرويس دهنده واکنش لازم داده نشود، نبايد تلاش مجددی برای فراخوانی متد صورت پذيرد. مثلا" در صورتيکه متدی برای محاسبه هزينه يک سفارش فراخوانده شده و سرويس دهنده درخواستی را دريافت تا سفارش را انجام ولی پاسخ گم گردد منطقی نخواهد بود سفارش مربوطه مجددا" ارسال گردد .


• امنيت . در برنامه های توزيع شده فرصت های زيادی برای تهديد های امنيتی وجود دارد . در اين راستا لازم است از يکطرف به مسائل تائيد اعتبار و صلاحيت قانونی و از طرف ديگر به ايمن سازی ارتباطات بين يک سرويس گيرنده و يک سرويس دهنده ، توجه جدی صورت پذيرد . حفاظت در مقابل انواع حملات اطلاعاتی از چالش های مهم در زمينه ايمن سازی برنامه های توزيع شده است .


• يکسان سازی زمان (Clock) . عمليات و فرآيندهای متعددی در برنامه های توزيع شده به پارامتر زمان ارتباط خواهد داشت .. مثلا" در يک سيستم سفارشات تا تکليف وضعيت نحوه پرداخت، مشخص نگردد نمی توان اقدام به پردازش و ثبت سفارش مربوطه نمود. بنابراين می بايست در رابطه با نحوه همسان سازی کلاک(Clock) کامپيوترهای متفاوت که در يک برنامه توزيع شده با يکديگر ارتباط دارند، تصميم لازم اتخاذ گردد .


بخش های ديگر مقاله :
بخش دوم : بررسی دو نمونه معماری در رابطه با برنامه های توزيع شده
بخش سوم : تاثير استانداردهای وب در فرآيند طراحی و پياده سازی برنامه های توزيع شده
بخش چهارم : مفاهيم اوليه سرويس های وب

________________________________________
مفاهيم اوليه سرويس های وب - بخش دوم
در بخش اول اين مقاله ، به مفاهيم اوليه دررابطه با برنامه های توزيع شده و چالش های مربوطه اشاره گرديد . در اين بخش به بررسی اجمالی دو نمونه از راهکارهای ارائه شده در رابطه با برنامه های توزيع شده يعنی معماری RPC و مبتنی بر پيام، خواهيم پرداخت .


معماری مبتنی بر RPC
معماری مبتنی بر RPC ، اولين گزينه موجود بمنظور ارائه يک راه حل مناسب در ارتباط با برنامه های توزيع شده است .
RPC)Remote Procedure Call) ، يک نوع فراخوانی به تابع و يا روتپنی است که برروی يک سيستم از راه دور مستقر است .RPC ، مشابه فراخوانی يک روتين و يا يک تابع معمولی است که کدهای مربوط به فراخوانی تابع ، توسط کاربر بکار گرفته می شود . RPC ، دارای مشخصات زير است :
• مشخص بودن محل سرويس . برنامه نويس ، ضرورتی به آگاهی از محل فيزيکی ارائه دهنده سرويس نخواهد داشت .


• يک مدل آشنا برای برنامه نويسان . اغلب برنامه نويسان نسبت به استفاده از اشکال خاصی از فراخوانی توابع، آشنا بوده و بدفعات در برنامه های خود اقدام به اين کار نموده اند . زير ساخت RPC ، يک Stub ايجاد که نمايانگر کد روتين از راه دور بوده و باعث فراخوانی تابع از راه دور بهمراه پارامترهای مربوطه از طريق شبکه و ارسال اطلاعات ذيربط برای سرويس دهنده RPC ، خواهد شد.بر روی سرويس دهنده RPC ، اطلاعات ارسالی (Stub) از حالت فشرده خارج ، و اطلاعات مربوطه ( آرگومان ها ) برای پردازش در اختيتار تابع صدازده شده ، قرار خواهند گرفت . نتايج مربوطه پس از فراخوانی تابع مربوطه و انجام عمليات ، برای صدا کننده تابع ، ارسال می گردد.


فراخوانی همزمان توابع
در مدل RPC ، يک برنامه ارتباطی را با يک سرويس دهنده RPC برقرار می نمايد. فراخوانی توابع RPC ، شباهت بسياری به فراخوانی روتين های محلی دارد . سمنتيک بلاک های RPC ، مشابه آنهائی است که در فراخوانی روتين های محلی، مورد استفاده قرار می گيرد. اين حقيقت که سمنتيک بلاک ها مشابه است، بدين معنی است که فراخوانی ها بصورت همزمان می تواند صورت پذيرد.

در اين حالت در مواقع ضروری بخشی از کدهای مربوط به اجرای روتين ، بلاک تا پس از برگرداندن مقدار توسط تابع مجددا" آزاد و امکان اجرای آنها فراهم گرد .بمنظور پياده سازی قابليت پردازش همزمان لازم است که با توجه به ماهيت کدهای موجود در يک روتين ، امکان اجراء يک نمونه از آنان را در هر لحظه فراهم و پس از اطمينان از تکميل عمليات مربوطه ، بخش مربوطه آزاد تا زمينه اجرای ساير پردازه های در نوبت انتظار ، فراهم گردد. وضعيت فوق نظير تابع XOR است و شرط وجود يکی منوط به عدم وجود ديگری خواهد بود. برای اکثر پياده کنندگان نرم افزار ، مدل برنامه نويسی فوق مناسب و بکارگيری آن آسان خواهد بود گرچه استقرار يک مدل همزمان در بالای معماری توزيع شده ، می تواند باعث بروز مسائلی خاص و از نگاهی ديگر گردد .


ايجاد افزونگی
اولين مسئله در ارتباط با معماری مبتنی بر RPC ، به يافتن ( کشف ) اطلاعات بر می گردد. برنامه ها چگونه اطلاعات مورد نياز خود را برای ارتباط با يک نقطه پايانی بمنظور دريافت سرويس مورد نظر، پيدا می نمايند.ساده ترين گزينه در اين راستا که توسط اکثر برنامه نويسان استفاده می گرد ، درج مستقيم (Hard code ) کدهای مربوط به نقطه پايانی ( نقطه تماس ) است . روش فوق مکانيزمی بهينه در اين رابطه نبوده و از يکطرف افزونگی اطلاعات را بدنبال داشته و از طرف ديگر امکان اشکال زدائی يک برنامه را با موانع جدی روبرو خواهد ساخت .


تجمع دردستيابی
زمانيکه برنامه ای با چندين سرويس توزيع شده ارتباط برقرار می نمايد نسبت به برنامه ديگر که صرفا" با يک سرويس توزيع شده مرتبط می گردد ، دارای استعداد بيشتر، بمنظور پذيرش اشکالات خصوصا" در موارديکه سرويس ها در دسترس نمی باشند ، خواهد بود. تجمع و انباشت در دستيابی يک برنامه توزيع شده ، مستقيما" تاثير منفی خود را از نحوه پياده سازی برنامه ها اخذ می نمايد.

Load balancing و بروز اشکال
درج مستقيم کد نقاط پايانی در يک برنامه ، باعث بروز مسئله ديگری می گردد . در اين رابطه برنامه های مبتنی برRPC قادر به استفاده از روشی مناسب و ساده بمنظور انجام عمليات Load Balancing پويا ، نخواهند بود .در صورت بروز اشکالات پويا و عدم دستيابی به سرويس دهنده ، برنامه مربوطه قادر به ارائه پاسخ شايسته نخواهد بود.


اولويت بندی
در معماری مبتنی برRPC ، ا ولويت بندی درخواست ها تقريبا" غير ممکن بوده و تمام درخواست ها بصورت پيش فرض با توجه به الگوريتم FCFS)First Come First Serve) ، پردازش خواهند شد.در چنين مواردی اگر سرويس دهنده ای دارای حجم پردازش بالا( لود بالا ) باشد ، سرويس گيرندگان با اولويت بالا که نيازمند دريافت خدمات مربوطه از سرويس دهنده مربوطه می باشند ، گرفتار تاخير فراوان خواهند شد.


برخورد با مسائل غيرقابل پيش بينی
يکی ديگر از مسائل مرتبط با برنامه های مبتنی بر RPC ، عدم توانائی آنان بمنظور برخورد با مسائل غير قابل پيش بينی نظير موارد زير است :
• قطع موقت جريان برق سرويس دهنده بر اساس بروز اشکال در سرويس دهنده
• بروز اشکال در منابع مورد نياز برنامه نظير ارتباط با يک بانک اطلاعاتی
• ضرورت استفاده از سخت افزار اضافه بمنظور برخورد با مسائل غيرقابل پيش بينی


يکی ديگر از معماری های موجود برای ايجاد برنامه های توزيع شده ، معماری مبتنی بر پيام است . رويکرد فوق، به برنامه ها امکان ارتباط با سرويس های داخلی را بکمک تکنولوژی صف بندی پيام ها ، خواهد داد . تکنولوژی صف بندی ، مسيريابی يک پيام را دنبال و ثبت می نمايد . تکنولوژی فوق ، سطح مناسبی از اطمينان بمنظور تشخيص سريع اشکال و در صورت صلاحديد اصلاحات لازم بدون دخالت کاربر را فراهم می نمايد. معماری مبتنی بر پيام، عموما" در کنار پروتکل های صف بندی پيام ها نظير MSMQ)Microsoft Message Queuing) ايجاد می گردد.


پيام های غير همزمان
مهمترين ويژگی معماری مبتنی بر پيام ، قابليت غير همزمانی آنان و ارسال پيام در مقابل فراخوانی تابع است . مزايای هر يک از موارد فوق بشرح زير است :
• امکان مسير يابی پيام ها بر اساس لود و اولويت وجود خواهد داشت .
• امکان استفاده بهينه از زمان برای سرويس گيرندگان در موارديکه در انتظار در اختيار گرفتن زمان مربوطه برای انجام عمليات می باشند، فراهم می گردد.
ويژگی های فوق ، خود می توانند باعث بروز مسائل ديگری گردند.


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


Interoperability
اغلب سيستم های مبتنی بر پيام با استفاده از محصولات خاص صف بندی پيام ، پياده سازی می گردند . در اين رابطه لازم است برای پياده سازی سيستم هائی که می بايست با يکديگر تعامل اطلاعاتی بکمک پيام های مربوطه داشته باشند ، تدابير خاصی انديشيده گردد . مثلا" تمامی سازمان ها ی سهيم در عمليات توزيع شده، می بايست دارای امکانات زير باشند :


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


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


استانداردهای وب
معماری های RPC و مبتنی بر پيام ، توسط سازمان های متعددی پياده سازی شده و دارای مسائل خاص خود می باشند . در اين بخش به برخی از اين موارد اشاره خواهد گرديد.
وجود مشکل در ارتباط با پروتکل های باينری


مدل های اشياء توزيع شده نظير DCOM)Distributed Component Object Model) ، ( RMI)Java Remote Method Invocation) و CORBA(Common Object Request Broker Architecture ) ، دارای محدوديت عمده استفاده از پروتکل های باينری می باشند . استفاده از پروتکل های باينری ، باعث بروز مسائل متعددی می گردد :
• Firewalls . اولين مسئله در رابطه با پروتکل های باينری، Point to Point بودن آنان می باشد . هر ارتباط با يک نقطه پايانی که درون فايروال وجود دارد، مستلزم باز نمودن برخی از پورت ها برای مبادله اطلاعات توسط مديريت فايروال سيستم است . برای اکثر سازمان ها اين ريسک امنيتی ،قابل قبول نخواهد بود .
• Interoperability . يکی ديگر از مسائل، تعامل بين مدل های اشياء متمايز است . هر مدل اشياء از پروتکل های انحصاری خود استفاده می نمايد. می توان نرم افزاری را بمنظور ترجمه بسته های اطلاعاتی بين مدل های متفاوت اشياء ، ايجاد نمود. ( ممکن است نتايج نسبتا" خوبی را هم بدنبال داشته باشد ) . دستاورد رويکرد فوق ، الزام اغلب سازمان ها بمنظور استفاده از يک مدل اشياء برای پياده سازی تمام سيستم های خود در سازمان مربوطه، خواهد بود. در صورتيکه يکی از Partner های سازمان از يک مدل اشياء رقابتی ديگر استفاده نمايد ، می تواند باعث بروز مسائل متعددی گردد .
• فرمت های داده . يکی ديگر از مسائل مربوط به پروتکل های باينری، رمزگشائی داده ارسال شده با استفاده از اينچنين پروتکل هائی است . هر پروتکل با استفاده از روش خاص خود اقدام به رمزنمودن اطلاعات می نمايد. مشکل در ترجمه داده از يک فرمت به فرمت ديگر ما را بسمت سياست جداسازی سازمانی مبتنی بر فرمت داده ها که آنها را قادر به برخورد مناسب با داده ها می نمايد ، سوق خواهد داد .


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


اينترنت و وب
TCP و IP در ابتدا برای اتصال شبکه های متفاوتی که توسط طراحان مختلفی ، طراحی می گرديدند ، مورد استفاده قرار می گرفت و همين رويکرد باعث ايجاد شبکه ای از ساير شبکه ها و با نام اينترنت گرديد. در ادامه در اواخر سال 1990 " تيم برنرز- لی " در CERN ، وب را ابداع نمود. وب، يک شبکه بهم متصل سراسری از سندهای ابرمتن است . در اين راستا دو انقلاب تکنولوژی تحقق پيدا کرد : ظهور HTML و HTTP)Hypertext Transfer Protocol) .


HTML ، زبانی است که نحوه افزودن علائم نشانه گذاری ( بشکل مجموعه ای از تگ ها ) به سندهای مبتنی بر متن را بمنظور ارائه اطلاعات در يک مرورگر وب و نحوه نمايش متن موجود در سند ، مشخص می نمايد. سندهای حاوی تگ های HTML ، سندهای ابرمتنی ناميده می شوند.
مزايای HTTP
HTTP ، پروتکلی است که برای درخواست و دريافت سندهای ابرمتن در وب استفاده می گردد . يکی از نکات بسيار مهم در رابطه با پروتکل HTTP ، عدم محدوديت جهت کار با نوع خاصی از سندها است .( صرفا" شامل سندهای HTML نمی گردد ) . برای تائيد گفته فوق، می توان به سرويس های وب اشاره کرد. سرويس های وب و سرويس گيرندگان مربوطه قادر به مبادله سندهای XML با استفاده از پروتکل HTTP می باشند . همزمان با گسترش و عموميت يافتن وب، HTTP بعنوان يک پروتکل جامع و فراگير مطرح گرديد .استفاده از HTTP باعث غلبه بر يکی از موانع جدی برای ارتباط بين مدل های اشياء توزيع شده گرديد .


XML فرمتی مناسب برای داده ها
پياده کنندگان بسرعت متوجه اين حقيقت گرديدند که HTML ، صرفا" اين امکان را برای يک مولف سند، فراهم می آورد که ساختار نمايشی خود را تعريف نموده و در رابطه با تعريف ساختار داده ها و يا ارتباط بين داده ها در يک سند ، سکوت و عملا" قادر به پاسخگوئی به اين نوع از خواسته ها نيست .محدوديت فوق تا سال 1996 تحمل ولی در همين سال بود که زبان جديدی بمنظور تشريح ساختار داده های موجود در يک سند ، ايجاد گرديد. اين زبان جديد XML ناميده گرديد .اسناد XML ، می بايست اهداف زير را تامين نمايند:


• استفاده آسان بر روی اينترنت
• وضوح و شفافيت لازم
• سهولت در ايجاد
• تفسير و پردازش آسان
• توسعه پذير، مستقل ازمحيط مربوطه
رشد و گسترش XML ، دليلی قاطع بر مناسب بودن آن بعنوان يک فرمت عمومی داده است .


فايروال دوستانه
نکته نهائی در رابطه با وب، جايگاه و نفش سرويس دهنده وب است . سرويس دهندگان وب ، عموما" از طريق پروتکل HTTP برای برقراری ارتباط با سرويس گيرندگان استفاده می نمايند. يکی از مهمترين ويژگی يک سرويس دهنده وب، نقش آن بعنوان يک " دروازه" (Gateway) برای يک سازمان است. سرويس دهندگان وب ، صرفا" به ارائه محتويات HTML عمل نمی نمايند.

با توجه به امکانات توسعه پذيری HTTP ، سرويس دهندگان وب، قادر به ارسال درخواست ها ی دريافت شده ، برای يک Request handler مناسب، نيز می باشند. سرويس دهنده وب، با نحوه برخورد handler با يک درخواست HTTP ، کاری نداشته و مسئوليت پردازش درخواست ارسالی و توليد يک پاسخ HTTP بر عهده Handler ، خواهد بود. سرويس دهنده وب در ادامه پاسخ مربوطه را برای سرويس گيرنده ارسال ، خواهد کرد.


سرويس دهندگان وب قادر به Forward نمودن درخواست ها برای هر نوع سرويسی می باشند که يک درخواست HTTP را تشريح و قادر به ارائه پاسخ مبتنی بر HTTP باشند. تمامی عمليات فوق، بدون نياز به هرگونه پيکربندی مجدد و يا عدول از سياست های مربوط به فايروال، انجام می شود.
مسائل در ارتباط با وب
در مقابل مزايای گفته شده ، در اين رابطه مسائلی و مشکلاتی همچون امنيت و کارآئی وجود دارد .


• امنيت . با توجه به عمومی بودن زير ساخت اينترنت ، ارتباطات انجام شده دارای پتانسيل لازم بمنظور آسيب پذيری در مواردی نظير : ره گيری ، اصلاح ، Spoofing ( روشی که با استفاده از آن امکان دستيابی غير مجاز به يک کامپيوتر فراهم می گردد ) و ساير مسائل مربوط به دستيابی ، خواهند بود.


• کارآئی . عموم کاربران اينترنت همچنان از خطوط Dial-up برای دستيابی به اينترنت استفاده می نمايند. همين مسئله باعث بروز مسائل متعددی در رابطه با کارآئی برنامه ها و خدمات مربوطه خواهد شد. بدين ترتيب در ارتباط با بکارگيری برنامه هائی با شرايطی خاص و پيچيده بر روی بستر وب ، دچار محدوديت هائی خواهيم بود .مثلا" برخی از برنامه ها ی محاوره ای نيازمند يک ارتباط متعامل مناسب با سرويس دهنده می باشند. محدوديت های مربوط به پهنای باند ارتباطات از نوع Dial-up ، باعث محدوديت در ارائه نوع برنامه های محاوره ای بر روی بستر وب می گردد.


مسائل مربوط به کارآئی و امنيت بهمراه مسائل موجود واقعی نظير قطع جريان برق سرويس دهنده و از کار افتادن برخی سرويس ها ( حتی بزرگترين وب سايت ها نمی توانند تضمين نمايند که همواره به ارائه خدمات مشغول هستند) باعث شده است که طراحی برنامه ها با رويکرد اجراء در يک شبکه اختصاصی بيشتر مورد توجه قرار گيرد و عملا" برنامه در يک ميدان محدودتر ولی ايمن و کارآ ، توزيع و استفاده گردد.
در بخش چهارم اين مقاله ، به معرفی اوليه سرويس های وب خواهيم پرداخت .
________________________________________
مفاهيم اوليه سرويس های وب - بخش چهارم
آنچه تاکنون گفته شده است :
بخش اول : مفاهيم اوليه برنامه های توزيع شده و چالش های مربوطه
بخش دوم : بررسی دو نمونه معماری در رابطه با برنامه های توزيع شده
بخش سوم : تاثير استانداردهای وب در فرآيند طراحی و پياده سازی برنامه های توزيع شده
و اما در اين بخش ، به بررسی مفاهيم اوليه سرويس های وب خواهيم پرداخت

در متن اصلی مقاله به هم ریختگی وجود ندارد. برای مطالعه بیشتر مقاله آن را خریداری کنید