دانلود مقاله سرویس های وب

سرویس های وب ، نقطه عطفی در معماری برنامه های توزیع شده بر روی اینترنت می باشند .

بدون شک، یکی از مهمترین تحولات در زمینه برنامه های توزیع شده ، مطرح شدن سرویس های وب است که تاثیرات فراوانی را در رابطه با وضعیت نرم افرار خصوصا بر روی اینترنت بدنبال خواهد داشت .

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

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

مقدمه
قبل از ابداع کامپیوترهای شخصی، عملا برنامه های توزیع شده ای وجود نداشته است .

در آن دوران ، استفاده از کامپیوتر، شامل نشستن پشت یک ترمینال و برقراری ارتباط با یک سیتستم بزرگ (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 ، باعث محدودیت در ارائه نوع برنامه های محاوره ای بر روی بستر وب می گردد.

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

در بخش چهارم این مقاله ، به معرفی اولیه سرویس های وب خواهیم پرداخت .

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

مقدمه مسائل موجود در رابطه با مدل های متفاوت اشیاء در برنامه های توزیع شده ، باعث گردید تا پیاده کنندگان بدنبال راهکارهای مناسب و جایگزینی در این زمینه باشند .

با توجه به سرعت در تطبیق استانداردهای وب ، بدیهی است که راه حل های ارائه شده می بایست مبتنی بر استانداردهای وب باشد .

همین امر باعث ظهور و عرضه سرویس های وب گردید.

سرویس وب چیست ؟

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

یکی از نمونه های اولیه در این زمینه ، برنامه Microsoft passport است .

برنامه فوق ، سرویس های تائید اعتبار را ارائه می نماید .

تمامی سرویس های فوق ، از طریق درخواست های مبتنی بر HTTP ، قابل دسترس و استفاده خواهند بود .

عناصر اساسی سرویس های وب عناصر اساسی در سرویس های وب، شامل : HTTP ,XML و SOAP) Simple Object Access Protocol) است .

SOAP ، یک پروتکل HTTP کم حجم و مبتنی بر XML بمنظور مبادله اطلاعات است .

پیاده سازی تکنولوژی های فوق ، توسط کنسرسیوم وب کنترل و هدایت می گردد .

بلاک های ساخت (Building - Blocks) سرویس های وب مشابه جعبه های سیاهی بوده ( نظیر عناصر) که صرفنظر از نحوه پیاده سازی، می توان آنها را بسادگی بخدمت گرفت .

سرویس های وب ، باعث کپسوله نمودن پیاده سازی و ارائه یک رابط مناسب برای ارتباطات توسط سرویس وب می گردند .

بنابراین می توان از سرویس های وب ، بعنوان بلاک های اولیه در ایجاد برنامه های متعدد استفاده کرد .

عدم وجود محدودیت در رابطه با اندازه یک سرویس وب سرویس های وب ، محدودیتی در رابطه با حجم و اندازه مورد نظر ندارند.

یک سرویس وب ، می تواند از عناصر ساده ای نظیر عناصر مورد نیاز برای ثبت یک سفارش تا برنامه های بسیار بزرگ نظیر برنامه های مالی را شامل شود .

در این راستا می توان از سرویس های وب در سطوح متفاوت متعدد و بمنظور ارائه یک راه حل مناسب استفاده کرد .

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

سرویس های وب ، قادر به ارائه مجموعه ای از اطلاعات ایستا می باشند .

مثلا" یک سرویس وب ، می تواند با توجه به درخواست کاربر ، اطلاعات جمعیت شناسی مربوط به یک شهر خاص را ارائه نماید.

در موارد دیگر ، پیاده کنندگان ممکن است از سرویس های وب بمنظور تولید برنامه هائی با قابلیت محاوره ای بالا ، استفاده نمایند.

مثلا" یک وب سایت مسافرتی ، می تواند مجموعه سرویس های لازم در خصوص یک مسافرت را بصورت Online در اختیار متقاضیان قرار دهد.

در چنین مواردی ، کاربران می توانند با استفاده از سرویس های وب ، تمامی خدمات مربوط به یک مسافرت را دریافت نمایند ( گرفتن هتل ، برنامه ریزی پرواز ، ثبت و اخذ بلیط و ...

) ارتباط و همبستگی سرویس های وب یک سرویس وب ، قادر به ارتباط با سایر سرویس های وب بمنظور ارائه یک مجموعه مناسب از سرویس ها است .

مثلا" یک سرویس وب برای یک آژانس مستغلات ، ممکن است از سرویس وب دیگر برای تائید و صحت کارت اعتباری ، بمنظور موافقت در ارائه تسهیلاتی نظیر وام بانکی بصورت Online استفاده نماید .در آینده برنامه های توزیع شده فراوانی با استفاده از سرویس های وب ، ایجاد می گردد .

در این نوع برنامه ها ، سرویس های وب بر اساس شاخص های متعددی ، انتخاب خواهند شد.

در دسترس بودن ، قیمت ، کارآئی و کیفیت، نمونه هائی از معیارهای لازم در خصوص انتخاب یک سرویس وب ، بشمار می آید .

آینده سرویس های وب چرا می باسیت نسبت به موفقیت سرویس های وب ابراز امیدواری کرد ، در حالیکه تمام تکنولوژی های دیگر تاکنون با مشکل مواجه شده اند ؟

بمنظور پاسخ به سوال فوق ، لازم است به برخی از عوامل موفقیت سرویس های وب ، اشاره گردد .

سرویس های وب با استفاده از SOAP فراخوانده می شوند .

چون SOAP دارای ماهیتی مستقل از محیط مربوطه است ، پیاده کنندگان ضرورتی به مشخص نمودن نحوه ارتباط بین عناصر DCOM ، CORBA و سایر پروتکل های دیگر ، نخواهد داشت .

بدین ترتیب هر سرویس وب ، قادر به ارتباط با هر سرویس وب دیگر خواهد بود .

با توجه به اینکه سرویس های وب ، قادر به ارتباط از طریق HTTP و XML می باشند ، هر گره موجود در شبکه که قادر به حمایت از تکنولوژی های فوق باشد ، توان میزبان بودن و یا دستیابی به سرویس های وب را دارا خواهد بود .