فصل دوم: ادبیات موضوع

۲-۱ مقدمه

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

( اینجا فقط تکه ای از متن فایل پایان نامه درج شده است. برای خرید متن کامل پایان نامه با فرمت ورد می توانید به سایت feko.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. )

۲-۲ معماری سرویس گرا

امروزه سیستم‌های توزیع شده‌ی^[۱۱] زیادی وجود دارند که به صورت ذاتی ناهمگون^[۱۲] و از نظر جغرافیایی^[۱۳] جدا از هم هستند. دلیل اصلی پیدایش این نوع سیستم‌ها به دلیل تعامل بین سازمان‌های مختلف در داخل یک کشور و یا حتی بین سازمان‌های مختلف در کشورهای متفاوت است[۱۳] . سؤال اصلی که در رابطه با این سیستم‌ها وجود دارد چگونگی سازگاری این نوع سیستم‌ها با وجود ناهمگونی بین بخش‌های مختلف است. یکی از روش‌هایی که طراحان این نوع سیستم‌ها از آن برای پیاده­سازی سیستم استفاده می‌کنند، معماری سرویس­گرا است که با وجود ناهمگون بودن بخش‌های مختلف سیستم‌های توزیع شده، پیاده­سازی را آسان­تر می­ کند.
در مهندسی نرم افزار، معماری سرویس گرا مجموعه ­ای از اصول^[۱۴] و متدلوژی‌هایی است که طراحی و توسعه نرم افزار را به صورت سرویس‌های سازگار^[۱۵] امکان پذیر می‌سازد. به این صورت که با این روش ابتدا سیستم مورد مطالعه به واحدهای کوچک منطقی به نام سرویس تقسیم می‌شود و در مرحله بعدی همان طور که در شکل ۲-۱ قابل مشاهده است، با ترکیب این سرویس‌ها سیستم مورد مطالعه پیاده­سازی می‌شود[۱۴] .

شکل ۲-۱ : لایه تعامل در معماری سرویس [۱۴]

۲-۲-۱ تعاریف شرکت‌های مهم تجاری از معماری سرویس­گرایی

بعضی از شرکت‌های تجاری که راه حل‌های فنی برای پیاده­سازی این معماری تولید نموده‌اند، تعاریفی فنی برای معماری سازمانی ارائه داده‌اند :
معماری سرویس گرا از نگاه IBM : روشی برای ساخت سیستم‌های توزیع شده است که کارکردهای نرم افزاری را در قالب سرویس ارائه می‌کند. این سرویس‌ها هم توسط دیگر نرم افزارها قابل فراخوانی هستند و نیز برای ساخت سرویس‌های جدید مورد استفاده قرار می‌گیرند، این روش برای یکپارچه­سازی فناوری‌ها در محیطی که انواع مختلفی از سکوهای نرم افزاری و سخت افزاری وجود دارد ایده­آل است. ویژگی­های معماری سرویس گرا به این شرح است:
استفاده از استانداردهای مستقل از فناوری و مورد توافق برای ارائه مؤلفه­ های نرم­افزاری تحت قالب سرویس
معرفی کننده یک روش مشخص و مورد توافق برای تعریف و ارتباط بین مؤلفه­ های نرم­افزاری
مؤلفه­ های نرم­افزاری منفرد می‌توانند در ساخت دیگر نرم­افزارها استفاده شوند.
تقویت­کننده رهیافت سرهم بندی اجزاء­­ از قبل تعریف شده برای ساخت نرم افزارها به جای توسعه و پیاده­سازی آن‌ها
قادرند به نرم افزاهای خارج سازمانی مانند انواع داخلی آن متصل شوند.
­
معماری سرویس گرا از نگاه ORACLE : مجموعه ای از سرویس‌های خود شمول^[۱۶] که قادر به ارتباط با یکدیگر بوده و ویژگی­های اصلی آن‌ها به این قرار است:
اتصال سست
دانه درشتی
جهت فراخوانی بر روی گذرگاه منتشر می‌شوند.
تعریف سرویس در سطح کسب و کار و منتج شده از فرآیندها باعث انعطاف پذیری و چابکی فناوری اطلاعات در پشتیبانی از تغییرات حرفه می‌شود.
معماری سرویس گر از نگاه Forrester: سبکی از طراحی، پیاده سازی و مدیریت هر دو نرم­افزارهای کاربردی و زیرساخت‌ها که :
نرم افزارهای کاربردی به صورت واحدهای کارکردی مبتنی بر حرفه سازماندهی می‌شوند و از طریق شبکه قابل دسترس هستند.
خصیصه های کیفیت سرویس (امنیت، کارای، سبک یکپارچه­سازی و …) به روشنی برای هر سرویس تعریف و مشخص می‌شود.
زیرساخت‌های نرم افزاری مسئولیت کاری مدیریت دسترسی به سرویس‌ها و اجرای آن‌ها را بر عهده می‌گیرند.
پروتکل‌ها و زیرساخت‌های این معماری می‌بایست مورد توافق و نافذ باشد ولی به فناوری خاصی وابسته نباشد.

۲-۲-۲ اصول معماری سرویس گرا

آقای توماس ارل^[۱۷] در یک مقاله پژوهشی برای اولین بار هشت اصل در رابطه با سرویس گرایی مطرح کردند که امروزه در سکوهای معماری سرویس گرا این اصول رعایت می‌شوند [۱۵ ، ۱۶] که عبارتند از :
قراردادهای استاندارد شده سرویس‌ها^[۱۸] : سرویس‌ها اهداف و قابلیت‌های خودشان را از طریق قراردادها در معرض دید مشتریان می‌گذارند به همین دلیل یکی از اصول کلیدی‌ این معماری همین قراردادهای استاندارد شده هستند. قراردادهای استانداردی برای انتقال داده بین سرویس‌ها و توصیف سرویس‌ها وجود دارد که در بخش بعدی به صورت مختصر شرح داده خواهند شد. در شکل ۲-۲ بخش‌هایی از قرارداد توصیف سرویس آورده شده است که تحت تأثیر استانداردسازی قرار می‌گیرند.
<policy>
<ExactlyOne>
<All>
assertions ….
</All>
<All>
assertions ….
</All>
</ExactlyOne>
……
</policy>
<schema >
<element >
<complexType>
<sequence>
<element … />
<element … />
<element … />
</sequence>
</complexType>