پروتکل‌های وب‌سرویس

پروتکل‌های وب‌سرویس-موسسه چشم انداز هزاره سوم ملل-آموزش کاربردی GIS و RS

ممکن است از سرویسی که نوشته‌اید، اعلانی دریافت کنید که نتیجه را به چه صورتی نمایش دهد؟ اگر هر توسعه‌دهنده از شکل موردنظر خودش استفاده کند، برای مصرف‌کنندگان سرویس که پارامترهای آن را هم نمی‌دانند، مشکل‌ساز است؛ بنابراین مجموعه‌ای از پروتکل‌ها تألیف و توسعه داده‌شده‌اند. در مورد اهمیت استفاده از یک‌شکل استاندارد بحث خواهیم کرد.

اهمیت یک‌شکل استاندارد

با توجه به انعطاف بالای عصر اطلاعات، کارهای گوناگونی انجام دادیم. اسحاق نیوتن، حساب انتگرال و دیفرانسیل را ایجاد کرد که یک‌زبان واحد برای کل جهان است. ریاضیدانان رویکرد نیوتن را پذیرفتند زیرا ساده و مؤثر بود. حساب دیفرانسیل یک استاندارد و یک پروتکل موفق است. اگر دیفرانسیل نیوتن نبود، انیشتین نمی‌توانست تئوری نسبیت را بسازد. شرکت‌های بزرگی استانداردها را تعریف و ایجاد می‌کنند. همچنین سازمان‌هایی هستند که استانداردهای باز را تعریف و ایجاد می‌کنند. دیگران با استفاده از استانداردهای باز موارد جدیدی را اختراع و ایجاد می‌کنند، درست مانند نظریه‌ی نسبیت؛ بنابراین به‌جای استفاده و تبعیت از استانداردهای موجود، شرکت‌ها سعی کردند که استانداردهای جدیدی تعریف و تدوین کنند تا قوانین و راه‌های انجام کارهای تکراری را تبیین کنند. این نتایج را که به‌عنوان “فراوانی استاندارد” نام‌گذاری کرده‌ایم، موجب شده است که اپلیکیشن iOS برای اجرا و کارکردن در اندروید، Blackberry و Windows Mobile دوباره‌نویسی شود. اگر 4 تولیدکننده‌ی گوشی‌های هوشمند مذکور از یک استاندارد استفاده و تبعیت کنند، می‌توانیم اپلیکیشن‌های مشابه (مانند تلگرام، واتساپ و …) را از هر موبایلی دانلود کنیم و در همه‌ی موبایل‌ها، به‌روزرسانی هر اپلیکیشن قرار خواهد گرفت. اگرچه مرورگرها محتویات استاندارد بزرگ و موفق و پیشرفته‌ی HTML را متفاوت از هم نمایش می‌دهند ولی همه‌ی مرورگرها محتویات هر صفحه را تقریباً مشابه نمایش می‌دهند. اگر هر مرورگر از استاندارد خودش پیروی کند، هر وب‌سایت برای هر مرورگر باید به‌صورت مجزا نوشته شود. مثلاً IE 6 ممکن است یک وب‌سایت را به‌خوبی نمایش ندهد، زیرا از بعضی استانداردهای جدید HTML پشتیبانی نمی‌کند. یک مشکل دیگر، اعمال استانداردهای HTML به پلاگین‌های وب Adobe Flash و MicrosoftSilverlight است. 10 سال پیش HTML یک پلتفرم چندرسانه‌ای نبود. چند رسانه به معنی محتویات تصویری و متحرک مانند انیمیشن، فیلم و … است. در حقیقت، چند رسانه برای دنیای وب طراحی نشده بود. جامعه‌‌ی وب، استانداردهای متن باز با زبان‌های برنامه‌نویسی ایجاد کردند. درنتیجه پلاگین یک مرورگر کارهای بیشتری روی وب انجام می‌دهد. Flash به بازار وب عرضه شد و توسعه‌دهندگان با استفاده از Flash به‌راحتی اپلیکیشن‌های چندرسانه‌ای ایجاد کردند. شرکت‌ها در وب‌سایتشان از Flash استفاده کردند. توسعه‌دهندگان وارد عمل شدند و زبان برنامه‌نویسی اسکریپتی رشد کرد ددرنتیجه Adobe Flash برای بسیاری از وب‌سایت‌ها ارائه شد. برای Adobe، همه چیز خوب پیش می‌رفت تا اینکه HTML5 عناصر چندرسانه‌ای پایه را عرضه کرد. در این میان هکرها خطاهایی در Flash پیدا کردند که سیستم‌ها را آسیب‌پذیر می‌کرد و درنتیجه استفاده از flash کاهش یافت. استیو جابز با معرفی iPad از flash پشتیبانی نکرد. توسعه‌دهندگان JavaScript، CSS3 و HTML5 کتابخانه‌های jQuery و Dojo را اضافه کردند. با استفاده از این کتابخانه‌ها، توسعه‌دهندگان با تعداد خطوط کد نویسی کمتری، کارهای زیادی انجام می‌دهند. HTML5 هر روز و هر روز بهتر می‌شود و در سال 2014 استاندارد کاملی منتشر شد.

SOAP

SOAP اولین استاندارد توسعه‌یافته برای وب‌سرویس‌ها است. این استاندارد از XML استفاده می‌کند و در قالب پیام، درخواست و پاسخ به درخواست را به وب‌سرویس‌ منتقل می‌کند. مثلاً وب‌سرویس تولید اعداد تصادفی را در نظر بگیرید. می‌توانیم یک تغییر کوچک با استاندارد SOAP ایجاد کنیم.

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

دقت کنید که تنها در صورت ایجاد عدد 71، آن پیام را خواهید دید. به‌هرحال این تمرین خوبی برای استفاده‌های بعدی است. حال می‌خواهیم به عدد تصادفی یک برچسب زمانی نیز اضافه کنیم. با استفاده از SOAP می‌توانیم عنصر XML دیگری اضافه کنیم که عبارتی شبیه <m:TimeStamp>31 May-2013 12:00AM</m:TimeStamp> برمی‌گرداند. یا ممکن است به‌جای برگشت یک عدد تصادفی، بخواهید پنج عدد تصادفی برگردانید. به‌سادگی می‌توانید پنج عنصر <m:GetRandomNumber> دیگر به کد اضافه کنید.

ArcGIS for desktop با استفاده از SOAP که روی پروتکل‌ (Transmission Control Protocol (TCP قرار دارد، با سرور ارتباط برقرار می‌کند. SOAP می‌تواند روی پروتکل‌هایHTTP و SMTP نیز کار کند. در این مثال SOAP را روی پروتکل HTTP پیاده کردیم. برای امنیت بیشتر می‌توانید SOAP را روی پروتکل (Hyper Text Transfer Protocol Secure (HTTPS و برای کنترل بیشتر روی TCP پیاده کنید.

REST

اگرچه در بعضی کتاب‌ها و اسناد SOAP و REST به یک معنی استفاده می‌شوند، درحالی‌که این دو کاملاً باهم متفاوت‌اند. مقایسه‌ی SOAP با REST مانند مقایسه‌ی موتور HEMI با یک مبارز است. HEMI یک موتور استاندارد است که در هر ماشین ورزشی می‌تواند استفاده شود. مبارز، خانواده‌ای از اتومبیل‌ها است که شامل قسمت‌های استانداردی مانند موتور، فرمان و… است. ضروری نیست که حتماً یک موتور HEMI باشد. می‌توانیم (REST) را به‌عنوان یک معماری با سبک کامل در نظر بگیریم (مبارز) که همه‌ی پلتفرم ارتباطی بین سرور و مشتری را به چالش می‌کشد. REST شامل یک پیام به شکل استاندارد (موتور ) است. این پیام می‌تواند هر چیزی و نه الزاماً XML باشد.

معمار، 5 عنصری که می‌توانند معماری RESTful را صدا بزنند را می‌پذیرد. مشتری، وب‌سرویس‌های پیاده‌سازی شده در یک محیط RESTful را استفاده می‌کند. سرور می‌تواند به‌راحتی ارتقاء داده شود بدون اینکه مشتری با مسائل بهبود و ارتقاء سروکار داشته باشد. مثلاً در سال 2009 یک اپلیکیشن با Twitter REST API ایجاد کردم. آن موقع Twitter، API هایش را ایجاد کرده بود. اپلیکیشن‌های زیادی با استفاده از Twitter API ایجاد کردم. این اپلیکیشن‌ها کمی چاشنی جغرافیایی به Twitter می‌داد. یکی از این اپلیکیشن‌ها EarthTwit بود. کاربر از درون نرم‌افزار Google Earth به Twitter وارد می‌شد و همه‌ی دوستان و دنبال کننده‌های کاربر را بازیابی می‌کرد و موقعیت جغرافیایی آن‌ها را با استفاده از Google Geocoder تعیین می‌کرد. سپس موقعیت آن‌ها را در Google Earth نشان می‌داد. هم‌چنین می‌توانست موقعیت کاربر را در صورت مجوز وی، در محیط Google Earth به اشتراک بگذارد. یک روز بعضی از کاربران به من گفتند که اپلیکیشن کار نمی‌کند و موقعیت دوستان و دنبال کننده‌ها را در Google Earth نمی‌بینند. بعد از مدتی متوجه شدم که Twitter، API‌ها را به نسخه‌های بالاتر ارتقاء داده است و همه‌ی اپلیکیشن‌های من از جمله EarthTwit دچار خطا شده‌اند. بالااجبار همه‌ی کد اپلیکیشن‌ها را تغییر دادم تا با نسخه‌ی جدید API کار کنند. اگر Twitter از یک نمونه RESTful استفاده می‌کرد، اپلیکیشن‌های من‌بعد از ارتقاء نسخه‌ی API نیز کار می‌کردند.

ArcGIS for Server یک معماری RESTful است هم‌چنین استاندارد SOAP را پشتیبانی می‌کند.

برگرفته از کتاب نصب، اجرا و مدیریت Arc GIS for server

نویسنده: دکتر محمد بافقی زاده

نشر: انتشارات اکادمیک