محبوبترینها
با چاپ روی وسایل یک کسب و کار پرسود بسازید
قیمت دیگ بخار و تولیدکننده اصلی دیگ بخار
معروف‌ترین هدیه و سوغاتی یزد مشخص شد!
آشنایی با انواع دوربین مداربسته ضد آب
پرداخت اینترنتی قبوض ساختمان (پرداخت قبض گاز، برق و آب)
بهترین دوره آموزش سئو محتوا در سال 1403 با نام طوفان ۱۴۰۳ در فروردین ماه شروع می شود
یک صرافی ارز دیجیتال چه امکاناتی باید داشته باشد؟
تعمیرگاه مجاز تعمیر ماشین لباسشویی در شرق تهران
تعمیرگاه مجاز تعمیر ماشین لباسشویی در شرق تهران
جراحی و درمان ریشه دندان عفونی با خانم دکتر صفوراامامی
چه مواردی بر قیمت کابین دوش حمام تاثیر دارند؟
صفحه اول
آرشیو مطالب
ورود/عضویت
هواشناسی
قیمت طلا سکه و ارز
قیمت خودرو
مطالب در سایت شما
تبادل لینک
ارتباط با ما
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
مطالب سایت سرگرمی سبک زندگی سینما و تلویزیون فرهنگ و هنر پزشکی و سلامت اجتماع و خانواده تصویری دین و اندیشه ورزش اقتصادی سیاسی حوادث علم و فناوری سایتهای دانلود گوناگون
آمار وبسایت
تعداد کل بازدیدها :
1798460622
مفاهيم اوليه سرويس های وب
واضح آرشیو وب فارسی:راسخون:
مفاهيم اوليه سرويس های وب سرويس های وب ، نقطه عطفی در معماری برنامه های توزيع شده بر روی اينترنت می باشند . بدون شک، يکی از مهمترين تحولات در زمينه برنامه های توزيع شده ، مطرح شدن سرويس های وب است که تاثيرات فراوانی را در رابطه با وضعيت نرم افرار خصوصا" بر روی اينترنت بدنبال خواهد داشت . ما شاهد نقطه عطفی در ظهور نسل جديدی از برنامه های کامپيوترهای با قابليت استفاده بر روی بستر وب ، خواهيم بود که گفتمان برنامه ها در عرصه جهانی را محقق خواهد کرد ( تحقق آرزوئی بزرگ برای صنعت نرم افزار) .در مجموعه مقالاتی که بدين منظور نوشته خواهد شد به بررسی اصولی سرويس های وب و جايگاه آنان در فرآيند طراحی و پياده سازی برنامه های توزيع شده پرداخته می گردد . در اين راستا لازم است در ابتدا به مقاهيم اوليه برنامه های توزيع شده ، تکامل تدريجی برنامه های توزيع شده ، محدوديت های موجود در رابطه با معماری برنامه های توزيع شده ، رويکردهای متفاوت بمنظور طراحی و پياده سازی برنامه های توزيع شده ، پرداخته گردد تا زمينه علمی مناسب، برای پرداختن به مفاهيم اوليه سرويس های وب فراهم گردد . مقدمه قبل از ابداع کامپيوترهای شخصی، عملا" برنامه های توزيع شده ای وجود نداشته است . در آن دوران ، استفاده از کامپيوتر، شامل نشستن پشت يک ترمينال و برقراری ارتباط با يک سيتستم بزرگ (Mainframe) بود. با اينکه ترمينال ها در چندين ساختمان و يا حتی محل فيزيکی قرار می گرفتند ، ولی عملا" يک کامپيوتر مرکزی وجود داشت که مسئوليت انجام تمامی پردازش ها و ذخيره سازی داده ها را برعهده می گرفت . تعريف برنامه توزيع شده با ابداع مينی کامپيوترها و کامپيوترهای شخصی، فعاليت های غيرمتمرکز، در دو زمينه پردازش و ذخيره سازی ، آرزوئی دست يافتنی گرديد. با طراحی برنامه های توزيع شده ، امکان پردازش و ذخيره سازی داده ها از حالت متمرکز خارج گرديد.يک برنامه توزيع شده، برنامه ای است که پتانسيل های پردازشی آن ممکن است توسط چندين کامپيوتر فيزيکی تامين و داده های آن در چندين محل فيزيکی، مستقر شده باشد .چرا به برنامه های توزيع شده نياز داريم ؟ در اين رابطه دلايل متعددی عنوان می شود که مهمترين آنان عبارتند از : • هزينه سيستم های Mainfarme . يکی از اولين دلايل مهم ، هزينه های بالای سيستم های Mainframe است . اين مسئله از دو زاويه متفاوت قابل بررسی است : هزينه بالای سرمايه گذاری اوليه که بسياری از سازمان ها و موسسات توان مالی آن را ندارند و دوم اينکه در اين مدل ، دارای صرفا" يک نقطه آسيب پذير با ريسک بالا می باشيم . • مالکيت اختصاصی داده ها. يکی از فاکتورهای مهم ديگر، سياست های مربوط به مالکيت داده ها است . سازمان ها و موسسات که دارای داده های اختصاصی خود می باشند، علاقه مند به واگذاری مسئوليت مديريت داده های مربوطه ، به ساير مکان های فيزيکی نمی باشند . • امنيت . يکی ديگر از فاکتورهای مهم در اين زمينه موضوع امنيت است . برای يک سازمان ، اولا" دستيابی به اغلب داده های آن می بايست بسادگی محقق گردد و ثانيا" داده ها ی حساس موجود در سازمان می بايست از بعد امنيتی، ايمن نگهداری گردند . تامين دو خواسته فوق ( رويکردهای رقابتی و رويکردهای امنيتی ) با جدا سازی فيزيکی داده ا از يکديگر محقق خواهد شد ( انباشت داده ها، با نگرش های متفاوت در رابطه با سرعت در دستيابی و ايمن در ذخيره سازی ، ضرورت وجود برنامه های توزيع شده را بخوبی نمايان می سازد ) مسائل فوق، ضرورت حرکت بسمت ايجاد يک الگوی جديد بمنظور طراحی برنامه های کامپيوتری را مطرح و بر همين اساس نسل جديدی از برنامه های کامپيوتری با عنوان " برنامه های توزيع شده" در عرصه نرم افزار بوجود آمد .برنامه های توزيع شده و ارائه دهندگان سرويس با توجه به ضرورت و تعجيل در طراحی يک الگوی جديد برای برنامه های توزيع شده و عدم وجود استانداردهای صنعتی لازم در اين خصوص ، شرکت های عظيم نرم افزاری هر يک با توجه به ديدگاه های خود ، اقدام به عرضه راهکارهائی در اين زمينه نمودند.شرکت های فوق، در رابطه با اينکه می بايست برنامه های توزيع شده بصورت عناصر توزيع شده ، توليد گردند ، اتحاد نظر داشتند . بدين ترتيب عناصر متفاوت و توزيع شده در يک برنامه، بعنوان ارائه دهندگان سرويس به يک برنامه منطقی ايفای وظيفه می نمايند. با توزيع قابليت ها و پتانسيل ها ، امکانات اساسی( بلاک های اوليه ) بمنظور ايجاد برنامه های بزرگ، بسادگی فراهم می گردد . رويکرد فوق ، مسائل و تبعات خاص خود را بدنبال داشت که در ادامه به بررسی برخی از آنان خواهيم پرداخت . برنامه های توزيع شده و وب با اينکه اينترنت بيش از بيست سال است بوجود آمده است ولی صرفا" در اواسط دهه 1990 به اين موضوع توجه گرديد، که اينترنت زير ساخت مناسب و مهمی برای ايجاد برنامه های توزيع شده است . پروتکل های ساده مبتنی بر متن در ابتدا بمنظور مبادله سرويس های درخواستی و ارسال اطلاعات بر روی اينترنت پياده سازی گرديد . گسترش و پذيرش چنين پروتکل هائی، باعث شد که اينترنت بعنوان يک محيط موفق برای برنامه های توزيع شده، مطرح گردد. بدين ترتيب در مقابل سروکار داشتن با تکنولوژی های رقابتی و اغلب انحصاری، وجود استانداردهای وب ، دليلی موجه برای توجه جدی به وب بعنوان بستری مناسب برای طراحی و پياده سازی برنامه های توزيع شده، گرديد.مسائل مربوط به برنامه های توزيع شده سنتی پياده سازی برنامه های توزيع شده مستلزم استفاده از تکنيک ها و مدل های جديد است . راهکارهای انتخابی و استفاده شده ، خود باعث بروز مسائل جديد نيز خواهند شد. در اين بخش به بررسی مسائل مرتبط با طراحی برنامه های توزيع شده پرداخته و دو معماری خاص در اين زمينه را بررسی خواهيم کرد : • معماری RPC)Remote Procedure Call-based) • معماری مبتنی بر پيام (Message-based) ملاحظات مربوط به طراحی برنامه های توزيع شده در زمان طراحی برنامه های توزيع شده مسائل متعددی وجود دارد که می بايست به آنها توجه کرد :• نوع داده های متفاوت . سيستم های عامل متفاوت، انواع مختلفی از نوع داده ها را حمايت می نمايند. در برخی موارد ، نوع داده ها در سيستم های عامل متفاوت کاملا" با يکديگر سازگار، نمی باشند . بنابراين می بايست از راهکارهای مناسب بمنظور برخورد منطقی با نوع داده های متفاوت موجود در سيستم های مختلف ، استفاده گردد.• بروز اشکال در سرويس دهنده . با توجه به اينکه عناصر يک سيستم توزيعی، عموما" بصورت از راه دور اجراء می گردند، ما دارای چندين نقطه ( مکان) برای بروز اشکال خواهيم بود. بروز اشکال در يکی از نقاط ، می تواند باعث بروز مسائل عمده ای در رابطه با عملکرد تمام برنامه توزيع شده گردد. بنابراين می بايست راهکارهای مناسب در خصوص مواجه شدن با چنين مواردی، اتخاذ گردد .• بروز اشکال در سرويس گيرنده . در صورتيکه سرويس دهنده ای وضعيت خاصی را ازطرف سرويس گيرنده ، اخذ و ذخيره می نمايد و سرويس گيرنده با اشکال مواجه گردد، می بايست از روشی بمنظور اعلام بروز اشکال به سرويس دهنده استفاده کرد. تصميم گيری و نحوه برخورد با منابع در اختيار سرويس گيرنده نيز از جمله مواردی است که می بايست راهکارهای آن بدرستی مشخص گردد.• تلاش برای فراخوانی مجدد . در صورتيکه يک متد از راه دور فراخوانده شود و از طرف سرويس دهنده واکنش لازم داده نشود، نبايد تلاش مجددی برای فراخوانی متد صورت پذيرد. مثلا" در صورتيکه متدی برای محاسبه هزينه يک سفارش فراخوانده شده و سرويس دهنده درخواستی را دريافت تا سفارش را انجام ولی پاسخ گم گردد منطقی نخواهد بود سفارش مربوطه مجددا" ارسال گردد . • امنيت . در برنامه های توزيع شده فرصت های زيادی برای تهديد های امنيتی وجود دارد . در اين راستا لازم است از يکطرف به مسائل تائيد اعتبار و صلاحيت قانونی و از طرف ديگر به ايمن سازی ارتباطات بين يک سرويس گيرنده و يک سرويس دهنده ، توجه جدی صورت پذيرد . حفاظت در مقابل انواع حملات اطلاعاتی از چالش های مهم در زمينه ايمن سازی برنامه های توزيع شده است .• يکسان سازی زمان (Clock) . عمليات و فرآيندهای متعددی در برنامه های توزيع شده به پارامتر زمان ارتباط خواهد داشت .. مثلا" در يک سيستم سفارشات تا تکليف وضعيت نحوه پرداخت، مشخص نگردد نمی توان اقدام به پردازش و ثبت سفارش مربوطه نمود. بنابراين می بايست در رابطه با نحوه همسان سازی کلاک(Clock) کامپيوترهای متفاوت که در يک برنامه توزيع شده با يکديگر ارتباط دارند، تصميم لازم اتخاذ گردد . معماری مبتنی بر 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 ، باعث محدوديت در ارائه نوع برنامه های محاوره ای بر روی بستر وب می گردد.مسائل مربوط به کارآئی و امنيت بهمراه مسائل موجود واقعی نظير قطع جريان برق سرويس دهنده و از کار افتادن برخی سرويس ها ( حتی بزرگترين وب سايت ها نمی توانند تضمين نمايند که همواره به ارائه خدمات مشغول هستند) باعث شده است که طراحی برنامه ها با رويکرد اجراء در يک شبکه اختصاصی بيشتر مورد توجه قرار گيرد و عملا" برنامه در يک ميدان محدودتر ولی ايمن و کارآ ، توزيع و استفاده گردد.مقدمه مسائل موجود در رابطه با مدل های متفاوت اشياء در برنامه های توزيع شده ، باعث گرديد تا پياده کنندگان بدنبال راهکارهای مناسب و جايگزينی در اين زمينه باشند . با توجه به سرعت در تطبيق استانداردهای وب ، بديهی است که راه حل های ارائه شده می بايست مبتنی بر استانداردهای وب باشد . همين امر باعث ظهور و عرضه سرويس های وب گرديد. سرويس وب چيست ؟ سرويس وب، يک URL ، بمنظور آدرس دهی مجموعه ای از قابليت ها ئی است که می توان آنان را از طريق شبکه و بمنظور ايجاد بلاک های اوليه در توليد يک برنامه های توزيع شده ، بخدمت گرفت. يکی از نمونه های اوليه در اين زمينه ، برنامه Microsoft passport است . برنامه فوق ، سرويس های تائيد اعتبار را ارائه می نمايد . تمامی سرويس های فوق ، از طريق درخواست های مبتنی بر HTTP ، قابل دسترس و استفاده خواهند بود . عناصر اساسی سرويس های وب عناصر اساسی در سرويس های وب، شامل : HTTP ,XML و SOAP) Simple Object Access Protocol) است . SOAP ، يک پروتکل HTTP کم حجم و مبتنی بر XML بمنظور مبادله اطلاعات است . پياده سازی تکنولوژی های فوق ، توسط کنسرسيوم وب کنترل و هدايت می گردد . بلاک های ساخت (Building - Blocks) سرويس های وب مشابه جعبه های سياهی بوده ( نظير عناصر) که صرفنظر از نحوه پياده سازی، می توان آنها را بسادگی بخدمت گرفت . سرويس های وب ، باعث کپسوله نمودن پياده سازی و ارائه يک رابط مناسب برای ارتباطات توسط سرويس وب می گردند . بنابراين می توان از سرويس های وب ، بعنوان بلاک های اوليه در ايجاد برنامه های متعدد استفاده کرد . عدم وجود محدوديت در رابطه با اندازه يک سرويس وب سرويس های وب ، محدوديتی در رابطه با حجم و اندازه مورد نظر ندارند. يک سرويس وب ، می تواند از عناصر ساده ای نظير عناصر مورد نياز برای ثبت يک سفارش تا برنامه های بسيار بزرگ نظير برنامه های مالی را شامل شود . در اين راستا می توان از سرويس های وب در سطوح متفاوت متعدد و بمنظور ارائه يک راه حل مناسب استفاده کردمنابع ايستا يا برنامه های محاوره ای دامنه استفاده از سرويس های وب بسيار گسترده بوده و در اين راستا می توان از آنان بمنظور ارائه اطلاعات ايستا و يا سرويس های پويا و بر اساس نقطه نظرات کاربران ، استفاده کرد . سرويس های وب ، قادر به ارائه مجموعه ای از اطلاعات ايستا می باشند . مثلا" يک سرويس وب ، می تواند با توجه به درخواست کاربر ، اطلاعات جمعيت شناسی مربوط به يک شهر خاص را ارائه نمايد. در موارد ديگر ، پياده کنندگان ممکن است از سرويس های وب بمنظور توليد برنامه هائی با قابليت محاوره ای بالا ، استفاده نمايند. مثلا" يک وب سايت مسافرتی ، می تواند مجموعه سرويس های لازم در خصوص يک مسافرت را بصورت Online در اختيار متقاضيان قرار دهد. در چنين مواردی ، کاربران می توانند با استفاده از سرويس های وب ، تمامی خدمات مربوط به يک مسافرت را دريافت نمايند ( گرفتن هتل ، برنامه ريزی پرواز ، ثبت و اخذ بليط و ... )ارتباط و همبستگی سرويس های وب يک سرويس وب ، قادر به ارتباط با ساير سرويس های وب بمنظور ارائه يک مجموعه مناسب از سرويس ها است . مثلا" يک سرويس وب برای يک آژانس مستغلات ، ممکن است از سرويس وب ديگر برای تائيد و صحت کارت اعتباری ، بمنظور موافقت در ارائه تسهيلاتی نظير وام بانکی بصورت Online استفاده نمايد .در آينده برنامه های توزيع شده فراوانی با استفاده از سرويس های وب ، ايجاد می گردد . در اين نوع برنامه ها ، سرويس های وب بر اساس شاخص های متعددی ، انتخاب خواهند شد. در دسترس بودن ، قيمت ، کارآئی و کيفيت، نمونه هائی از معيارهای لازم در خصوص انتخاب يک سرويس وب ، بشمار می آيد . آينده سرويس های وب چرا می باسيت نسبت به موفقيت سرويس های وب ابراز اميدواری کرد ، در حاليکه تمام تکنولوژی های ديگر تاکنون با مشکل مواجه شده اند ؟ بمنظور پاسخ به سوال فوق ، لازم است به برخی از عوامل موفقيت سرويس های وب ، اشاره گردد . • Interoperability . سرويس های وب با استفاده از SOAP فراخوانده می شوند . چون SOAP دارای ماهيتی مستقل از محيط مربوطه است ، پياده کنندگان ضرورتی به مشخص نمودن نحوه ارتباط بين عناصر DCOM ، CORBA و ساير پروتکل های ديگر ، نخواهد داشت . بدين ترتيب هر سرويس وب ، قادر به ارتباط با هر سرويس وب ديگر خواهد بود . با توجه به اينکه سرويس های وب ، قادر به ارتباط از طريق HTTP و XML می باشند ، هر گره موجود در شبکه که قادر به حمايت از تکنولوژی های فوق باشد ، توان ميزبان بودن و يا دستيابی به سرويس های وب را دارا خواهد بود .• حمايت از زبان های متعدد . پياده کنندگان قادر به نوشتن سرويس های وب با استفاده از زبان ها ی متعددی خواهند بود . بدين ترتيب ، ضرورتی به فراگيری يک زبان جديد و استانداردسازی يک زبان خاص، بمنظور ايجاد و يا استفاده از سرويس های وب نخواهد بود . • استفاده مجدد از برنامه ها . استفاده از عناصر و کتابخانه های موجود بهمراه سرويس های وب بسادگی انجام خواهد شد . توليدکنندگانی نظير شرکت ماکروسافت ، ابزار لازم برای بکارگيری عناصر و کتابخانه ها را فراهم نموده اند . اغلب شرکت ها دارای تعداد زيادی منابع نرم افزاری نظير : عناصر، توابع کتابخانه ای و برنامه ها ، می باشند. استفاده از امکانات موجود ( منابع نرم افزاری ) ، همواره مقرون بصرفه تر از پياده سازی مجدد آنان است .• استفاده از استانداردهای حمايت شده صنعتی . تمامی توليد کنندگان، از مشخصات تکنولوژی های مرتبط با سرويس های وب ، حمايت می نمايد( خصوصا" HTTP,XML,SOAP ). بدين ترتيب امکان ارتباط سيستم های نامتجانس بسادگی فراهم خواهد شد . مثلا" عنصری که با #C نوشته شده و بعنوان يک سرويس وب استفاده می گردد ، بسادگی قادر به استفاده توسط هر نوع برنامه مبتنی بر CGI خواهد بود که با ++C نوشته شده و پتانسيل ايجاد يک درخواست مبتنی بر SOAP و پردازش نتايج مربوطه را دارا باشد.پشته تکنولوژی وب و دات نت پشته تکنولوژی وب و دات نت SOAP System.Web.Services XML or Binary Formats System.Runtime.Remoting HTTP System.Net Sockets System.Net.Sockets TCP/IP System.Net.Sockets بمنظور طراحی و پياده سازی برنامه های توزيع شده ، از گزينه های متعددی استفاده می گردد . انتخاب هر گزينه مبتنی بر مجموعه ای از پارامترهای متفاوت است . تمامی تکنولوژی های موجود در اين زمينه را می توان بر اساس خصوصيات مربوطه در يک پشته (Stack) سازماندهی کرد. در بالاترين سطح اين پشته، تکنولوژی SOAP و در پايين ترين سطح ، پروتکل TCP/IP قرار می گيرد. انتخاب تکنولوژی موجود در سطوح پايين تر در پشته فوق ، افزايش کارآئی را بدنبال خواهد داشت . در چنين مواردی پياده کنندگان می بايست اطلاعات لازم و مناسبی از تکنولوژی انتخابی مربوطه را داشته باشند . بموازات حرکت در سطوح پائين تر ، سطح اطلاعات و دانش مربوطه ، افزايش و پياده کنندگان می بايست در اين زمينه مهارت های خاصی را داشته باشند . بدين ترتيب استفاده از SOAP نسبت به TCP/IP ، به دانش و مهارت های بمراتب کمتری نياز خواهد داشت ( نظير انتخاب زبان ماشين و يا يک زبان برنامه نويسی سطح بالا برای برنامه نويسی ). • TCP/IP . پائين ترين سطح در پشته تکنولوژی است . در اين سطح ، عناصر توزيع شده از يک برنامه برای ارتباط با يکديگر از TCP/IP ، استفاده می نمايند. فريمورک دات نت، بمنظور حمايت از اين نوع ارتباط، از کلاس های متعدد موجود در Namespace با نام System.Net.Sockets استفاده می نمايد.• Sockets . در صورتيکه قصد حمايت از session در برنامه ای وجود داشته باشد، می توان از Socket استفاده کرد. فريمورک دات نت، بمنظور حمايت از اين نوع ارتباط، از کلاس های متعدد موجود در Namespace با نام System.Net.Sockets استفاده می نمايد. • HTTP . در صورتيکه قصد برقراری ارتباط با سرويس دهندگان وب و يا امکان ارتباط از طريق فايروال ، وجود داشته باشد ، می توان از HTTP استفاده کرد. فريمورک دات نت، بمنظور حمايت از اين نوع ارتباط ، از کلاس های متعدد موجود در Namespace با نام System.Net استفاده می نمايد.• XML يا فرمت های باينری . با استفاده از تکنولوژی های فوق ، امکان پياده سازی يک برنامه توزيع شده براساس دستيابی از راه دور اشياء، وجود دارد. در چنين مواری مسائل متعددی نظير يکسان بودن اشياء و فرمت مبادله اطلاعات بين اشياء از راه دور، وجود خواهد داشت. فرمت مبادله اطلاعات می تواند بصورت باينری و يا سريال سازی XML برای شی مربوطه باشد.فريمورک دات نت ، بمنظور حمايت از اين نوع ارتباط ، از کلاس های متعدد موجود در Namespace با نام System.Run time.Remoting استفاده می نمايد. • SOAP . در صورتيکه قصد پياده سازی سرويس های از راه دوری وجود دارد که ارتباطی بسيار نزديک ( آزاد ) با ساير سرويس ها ی مصرف کننده را داشته و تماما" مبتنی بر استانداردهای وب می باشند ، می توان يک سرويس وب را پياده سازی کرد. پروتکل انتخابی برای اين نوع برنامه ها SOAP است . فريمورک دات نت ، بمنظور حمايت از اين نوع ارتباط، از کلاس های متعدد موجود در Namespace با نام System.Web.Services استفاده می نمايد.
این صفحه را در گوگل محبوب کنید
[ارسال شده از: راسخون]
[مشاهده در: www.rasekhoon.net]
[تعداد بازديد از اين مطلب: 880]
-
گوناگون
پربازدیدترینها