ارشد - دانلود نمونه پایان نامه

متن کامل پایان نامه را در سایت منبع fuka.ir می توانید ببینید

وب سرویس، ترکیب وب ‌سرویس، انتخاب وب ‌سرویس، رویکرد‌های فرا مکاشفه‌ای، کیفیت سرویس
فهرست مطالب
TOC o "1-3" h z u فصل 1 : مقدمه و کلیات تحقیق PAGEREF _Toc344935128 h 11-1 مقدمه PAGEREF _Toc344935129 h 21-2 هدف از اجرای طرح PAGEREF _Toc344935130 h 61-3 توجیه ضرورت انجام طرح و اهمیت موضوع PAGEREF _Toc344935131 h 71-4 مدل تحقیق PAGEREF _Toc344935132 h 91-5 فرضیات مسئله PAGEREF _Toc344935133 h 101-6 چارچوب تحقیق PAGEREF _Toc344935134 h 10فصل 2 : ادبیات و پیشینه تحقیق PAGEREF _Toc344935135 h 122-1 مقدمه PAGEREF _Toc344935136 h 132-2 مفاهیم پایه PAGEREF _Toc344935137 h 132-2-1 رهیافت‌های یکپارچه سازی سیستم‌های اطلاعاتی PAGEREF _Toc344935138 h 132-2-2 کاربرد معماری سرویس گرا PAGEREF _Toc344935139 h 142-2-3 تعریف معماری سرویس گرا PAGEREF _Toc344935140 h 152-2-4 مزایای استفاده از معماری سرویس گرا PAGEREF _Toc344935141 h 172-2-4-1 استفاده مجدد PAGEREF _Toc344935142 h 172-2-4-2 کاهش هزینه در یکپارچه سازی PAGEREF _Toc344935143 h 192-2-4-3 چابکی کسب و کار PAGEREF _Toc344935144 h 192-2-5 وب سرویس PAGEREF _Toc344935145 h 202-2-5-1 انتخاب و کشف وب سرویس PAGEREF _Toc344935146 h 212-2-6 ترکیب وب سرویس‌ها PAGEREF _Toc344935147 h 232-2-6-1 سرویس مرکب PAGEREF _Toc344935148 h 242-2-6-2 BPEL PAGEREF _Toc344935149 h 242-2-6-3 چرخه حیات سرویس مرکب PAGEREF _Toc344935150 h 252-2-6-4 ساختارهای ترکیب وب سرویس PAGEREF _Toc344935151 h 292-2-6-5 محدودیت‌ها در ترکیب وب سرویس‌ها PAGEREF _Toc344935152 h 322-2-7 معیارهای کیفیت سرویس PAGEREF _Toc344935153 h 332-2-7-1 انواع معیارهای کیفیت سرویس PAGEREF _Toc344935154 h 352-3 کارهای مرتبط PAGEREF _Toc344935155 h 362-3-1 چارچوب Boumhamdi و Jarir PAGEREF _Toc344935156 h 362-3-2 چارچوب DynamiCoS PAGEREF _Toc344935157 h 372-3-3 دیدگاه Chan و Lyu PAGEREF _Toc344935158 h 392-3-4 دیدگاه Yang و Chun-Hung PAGEREF _Toc344935159 h 392-3-5 چارچوب METEOR PAGEREF _Toc344935160 h 402-3-6 چارچوب SODIUM PAGEREF _Toc344935161 h 412-3-7 دیدگاه Yau و Yin PAGEREF _Toc344935162 h 422-3-9 چارچوب WSSR_Q PAGEREF _Toc344935163 h 432-3-10 رویکرد WSMX PAGEREF _Toc344935164 h 452-3-11 دیدگاه Chaari و Badr و Biennier PAGEREF _Toc344935165 h 452-3-12 دیدگاه MOGA PAGEREF _Toc344935166 h 46۲-۳-۱۳ جمع بندی از کارهای مرتبط PAGEREF _Toc344935167 h 46فصل 3 : روش تحقیق PAGEREF _Toc344935168 h 493-1 مقدمه PAGEREF _Toc344935169 h 503-2 معماری ارائه داده شده PAGEREF _Toc344935170 h 503-2-1 درخواست سرویس PAGEREF _Toc344935171 h 523-2-2 انتخاب سرویس‌های کاندید PAGEREF _Toc344935172 h 523-2-3 رویکرد ترکیب وب سرویس‌ها PAGEREF _Toc344935173 h 553-3 فرمول بندی و بی مقیاس سازی معیار‌های کیفیت سرویس PAGEREF _Toc344935174 h 563-4 محاسبه میزان برازندگی یک سرویس مرکب PAGEREF _Toc344935175 h 583-5 رویکرد‌های فرا مکاشفه‌ای PAGEREF _Toc344935176 h 673-5-1 نمایش جواب مسئله PAGEREF _Toc344935177 h 673-5-2 رویکرد ژنتیک PAGEREF _Toc344935178 h 683-5-2-1 ساختار کلی الگوریتم ژنتیک PAGEREF _Toc344935179 h 693-5-2-2 مفاهیم کلیدی الگوریتم ژنتیک PAGEREF _Toc344935180 h 713-5-2-2-1 ایجاد جمعیت اولیه PAGEREF _Toc344935181 h 713-5-2-2-2 عملگر‌های ژنتیک PAGEREF _Toc344935182 h 713-5-2-2-3 انتخاب PAGEREF _Toc344935183 h 733-5-2-2-4 تابع برازش PAGEREF _Toc344935184 h 743-5-3 رویکرد رقابت استعماری PAGEREF _Toc344935185 h 743-5-3-1 شکل دهی امپراطوری‌های اولیه PAGEREF _Toc344935186 h 753-5-3-2 حرکت مستعمره‌ها به سمت امپریالیست PAGEREF _Toc344935187 h 773-5-3-3 جابه جایی موقعیت مستعمره و امپریالیست793-5-3-4 قدرت کل یک امپراطوری PAGEREF _Toc344935188 h 803-5-3-5 رقابت استعماری PAGEREF _Toc344935189 h 803-5-4 رویکرد جریان آب PAGEREF _Toc344935190 h 823-5-4-1 عملگرهای جریان آب PAGEREF _Toc344935191 h 843-5-4-1-1 ایجاد جمعیت اولیه PAGEREF _Toc344935192 h 853-5-4-1-2 انشعاب و حرکت جریان آب PAGEREF _Toc344935193 h 853-5-4-1-3 ادغام جریان‌ها PAGEREF _Toc344935194 h 883-5-4-1-4 تبخیر و بارش PAGEREF _Toc344935195 h 893-5-4-1-5 جستجوی همسایگی PAGEREF _Toc344935196 h 89فصل 4 : محاسبات و یافته‌های تحقیق PAGEREF _Toc344935197 h 914-1 مقدمه PAGEREF _Toc344935198 h 924-2 تنظیم پارامتر رویکرد های فرا مکاشفه‌ای PAGEREF _Toc344935199 h 924-3 ارزیابی و کارایی رویکردها PAGEREF _Toc344935200 h 964-4 مشاهده نتایج PAGEREF _Toc344935201 h 984-4-1: تأثیر افزایش تعداد سرویس‌های انتزاعی بر زمان اجرای رویکردهای ارائه داده شده PAGEREF _Toc344935202 h 984-4-2 تأثیر افزایش تعداد سرویس‌های واقعی بر زمان اجرای رویکردهای ارائه داده شده PAGEREF _Toc344935203 h 1014-4-3 مقایسه کارایی رویکرد های فرا مکاشفه‌ای و روش دقیق PAGEREF _Toc344935204 h 1024-4-4 مقیاس پذیری PAGEREF _Toc344935205 h 1054-4-5 کارایی PAGEREF _Toc344935206 h 106فصل 5 : نتیجه گیری و پیشنهادات PAGEREF _Toc344935207 h 1075-1 مقدمه PAGEREF _Toc344935208 h 1085-2 مزایای رویکرد ارائه شده PAGEREF _Toc344935209 h 1095-3 عملکرد رویکرد های ارائه شده PAGEREF _Toc344935210 h 1105-4 تحقیقات آتی PAGEREF _Toc344935211 h 112منابع و مآخذ PAGEREF _Toc344935212 h 113
فهرست شکل‌ها
TOC h z t "Caption" c "شکل" شکل 1-1: سه لایه اصلی در معماری سرویس گرا PAGEREF _Toc345002823 h 3شکل 1-2 : ترکیب سرویس‌ها بر مبنای معیارهای کیفیت سرویس PAGEREF _Toc345002824 h 5شکل 1-3 : مراحل انجام تحقیق PAGEREF _Toc345002825 h 9شکل 2-1 : محیط کسب و کار سرویس گرا PAGEREF _Toc345002826 h 17شکل 2-2 : استفاده مجدد از وب سرویس‌ها در معماری سرویس گرا PAGEREF _Toc345002827 h 18شکل 2-3 : چابکی کسب و کار در معماری سرویس گرا PAGEREF _Toc345002828 h 20شکل 2-4 : ترکیب وب سرویس‌ها در جریان کاری PAGEREF _Toc345002829 h 24شکل 2-5 : چرخه حیات سرویس مرکب PAGEREF _Toc345002830 h 26شکل 2-6 : ساختارهای ترکیب وب سرویس‌ها در جریان‌های کاری PAGEREF _Toc345002831 h 30شکل 2-7 : ترکیب وب سرویس‌ها به همراه ساختارشان PAGEREF _Toc345002832 h 32شکل 2-8 : معیارهای کیفیت سرویس PAGEREF _Toc345002833 h 34شکل 2-9 : فرایند کلی چارچوب Boumhamdi و Jarir PAGEREF _Toc345002834 h 36شکل 2-10 : فرایند کلی چارچوب DynamiCoS PAGEREF _Toc345002835 h 38شکل 2-11 : فرایند کلی رویکرد انتخاب و رتبه بندی سرویس بر مبنای معیارهای کیفی PAGEREF _Toc345002836 h 43شکل 2-12 : چارچوبی برای انتخاب و رتبه بندی وب سرویس‌ها با در نظر گرفتن کیفیت سرویس PAGEREF _Toc345002837 h 44شکل 3-1 : معماری پیشنهادی برای ترکیب پویای سرویس‌های وب مبتنی بر نیازهای کیفی کاربران PAGEREF _Toc345002838 h 51شکل 3-2 : شبه کد مربوط به معماری پیشنهادی PAGEREF _Toc345002840 h 54شکل 3-3 : ارزش مجموع معیار‌های کیفی با توجه به ساختار‌های مختلف PAGEREF _Toc345002842 h 60شکل 3-4 : نمای ساده شده از ارزش مجموع معیار‌های کیفی PAGEREF _Toc345002843 h 61شکل 3-5 : نحوه نمایش جواب‌ها در رویکرد‌های فرا مکاشفه‌ای PAGEREF _Toc345002849 h 67شکل 3-6 : ساختار کلی الگوریتم ژنتیک PAGEREF _Toc345002850 h 70شکل 3-7 : مثالی از نحوه عملکرد تقاطع دو نقطه‌ای PAGEREF _Toc345002851 h 72شکل 3-8 : اجزای تشکیل دهنده یک کشور (معیار‌های کیفیت سرویس) PAGEREF _Toc345002852 h 76شکل 3-9 : عملگرهای همانند سازی و جستجوی همسایگی PAGEREF _Toc345002853 h 79شکل 3-10: تغییر جای استعمارگر و مستعمره PAGEREF _Toc345002854 h 80شکل ‏3-11: کل امپراطوری،پس از تغییر موقعیت‌ها PAGEREF _Toc345002855 h 80شکل 3-12 : شمای کلی رقابت استعماری PAGEREF _Toc345002856 h 81شکل 3-13 : شبه کد مربوط به الگوریتم فرا ابتکاری رقابت استعماری PAGEREF _Toc345002857 h 82شکل 3-14: نمای کلی رویکرد جریان آب PAGEREF _Toc345002858 h 83شکل 3-15 : عملگر تقاطع یکنواخت پارامتری در رویکرد جریان آب PAGEREF _Toc345002859 h 86شکل 3-16 : نحوه عملکرد عملگر جهش در رویکرد جریان آب PAGEREF _Toc345002860 h 87شکل 3-17 : نحوه عملکرد عملگر جستجو همسایگی PAGEREF _Toc345002861 h 90شکل4-1 : روند تغییرات زمان محاسباتی رویکردهای فرا مکاشفه‌ای با افزایش تعداد سرویس‌های انتزاعی PAGEREF _Toc345002870 h 100شکل4-2 : روند تغییرات زمان محاسباتی رویکردهای فرا مکاشفه‌ای با افزایش تعداد سرویس‌های واقعی PAGEREF _Toc345002872 h 102شکل4-3 :روند تغییرات زمان محاسباتی رویکردهای فرا مکاشفه‌ای و روش دقیق در مسائل با مقیاس کوچک PAGEREF _Toc345002874 h 104

فهرست جداول
TOC h z t "Caption" c "Table" جدول 3-1 : نمادهای بکار رفته در شبه کد و توضیحات مربوط به هر یک از آن‌ها PAGEREF _Toc344972118 h 54جدول 3-2 : توابع محاسبه ارزش مجموع هر یک از معیار‌های کیفی با ساختار‌های مختلف PAGEREF _Toc344972120 h 59جدول3-3 : مقادیر معیارهای کیفی برای وب سرویس‌های مختلف PAGEREF _Toc344972123 h 62جدول 3-4 : مجموع ارزش ماکسیمم و مینیمم معیار‌های کیفیت سرویس PAGEREF _Toc344972124 h 64جدول 3-5 : مقادیر بی مقیاس شده مجموع ارزش معیار‌های کیفیت سرویس PAGEREF _Toc344972125 h 65جدول 3-6 : وزن‌های تعیین شده توسط کاربر برای هر یک از معیار‌های کیفیت سرویس PAGEREF _Toc344972126 h 66جدول 3-7 : مجموع ارزش نهایی هر یک از معیارهای کیفیت سرویس در یک سرویس مرکب PAGEREF _Toc344972127 h 66جدول 4-1 : سطوح مختلف فاکتورهای در نظر گرفته شده برای رویکرد‌های فرا مکاشفه‌ای PAGEREF _Toc344972140 h 93جدول 4-2 : مقادیر برگزیده برای فاکتورهای در نظر گرفته شده برای رویکرد‌های فرا مکاشفه‌ای PAGEREF _Toc344972143 h 94جدول 4-3 : معیارهای کیفیت سرویس به همراه توضیحات هر یک از آن‌ها PAGEREF _Toc344972146 h 98جدول 4-4 : میزان برازندگی رویکرد های فرا مکاشفه‌ای با افزایش تعداد سرویس‌های انتزاعی PAGEREF _Toc344972147 h 99جدول 4-5 : میزان برازندگی رویکرد های فرا مکاشفه‌ای با افزایش تعداد سرویس‌های واقعی PAGEREF _Toc344972149 h 101جدول 4-6 : مقایسه میزان برازندگی رویکردهای فرا مکاشفه ای و روش دقیق در مسائل با مقیاس کوچک PAGEREF _Toc344972151 h 103

فصل اول
مقدمه و کلیات تحقیق2157095494059
1-1 مقدمهامروزه سازمان‌ها به دلیل افزایش جریان اطلاعات در محیط‌های داخل و خارج سازمان و مدیریت این جریان اطلاعات به ناچار باید از مزایای فناوری اطلاعات و سیستم‌های اطلاعاتی استفاده نمایند. این گونه سیستم‌ها باید با سایر سیستم‌های اطلاعاتی در بخش‌های مختلف سازمان در تعامل و ارتباط باشند. برای دست‌یابی به یکپارچگی در سطح وسیع، سیستم‌های اطلاعاتی باید قابلیت‌هایی نظیر : انعطاف‌پذیری، مقیاس‌پذیری و سازگاری سیستم‌های قدیمی با سیستم جدید را دارا باشند. معماری سرویس گرا (SOA) الگوی جدیدی را در پیاده سازی سیستم‌های اطلاعاتی ارائه می‌دهد و این امکان را به توسعه‌دهندگان سیستم‌ها می‌دهد تا بیشتر تمرکزشان به تحقق ویژگی‌هایی باشد که سازمان‌ به آن‌ها نیاز دارد و این امر توسط پروتکل‌های ارتباطی استاندارد، واسط‌های کاربر، جریان‌های کاری و خدمات مدیریت زیرساخت‌ها صورت می‌پذیرد ADDIN EN.CITE <EndNote><Cite><Author>Griffiths</Author><Year>2010</Year><RecNum>1</RecNum><DisplayText>[2]</DisplayText><record><rec-number>1</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">1</key></foreign-keys><ref-type name="Book">6</ref-type><contributors><authors><author>Griffiths, N.</author><author>Chao, K.M.</author></authors></contributors><titles><title>Agent-based service-oriented computing</title></titles><dates><year>2010</year></dates><publisher>Springer-Verlag New York Inc</publisher><isbn>1849960402</isbn><urls></urls><language>en</language></record></Cite></EndNote>[2].
در واقع تکامل و رشد معماری سرویس گرا به سازمان‌ها این امکان را می‌دهد تا تمام قابلیت‌های خود را در قالب سرویس ارائه دهند، در این نوع از سازمان‌ها فرآیند‌های کاری از مرز‌های سازمانی فراتر رفته و بین تولید‌کنندگان مواد اولیه، مشتریان و تمامی شرکا ارتباط برقرار می‌کنند.
بعد از رشد چشم‌گیر ارتباطات به دلیل گسترش استفاده از اینترنت معماری سرویس گرا به موضوع مهمی در کسب‌وکار و محافل علمی در دنیا تبدیل شده است. نرم افزار‌های معماری سرویس گرا در حوزه تجارت الکترونیک و یکپارچه‌سازی نرم افزار‌های سازمانی نقش مهمی را ایفا می‌کنند. برای معماری سرویس گرا لایه های متفاوتی را می‌توان در نظر گرفت شکل 1-1 لایه‌های اصلی این معماری را نشان می‌دهد که شامل لایه کسب و کار، لایه سرویس و لایه نرم افزار است ADDIN EN.CITE <EndNote><Cite><Author>Erl</Author><Year>2005</Year><RecNum>47</RecNum><DisplayText>[3]</DisplayText><record><rec-number>47</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">47</key></foreign-keys><ref-type name="Book">6</ref-type><contributors><authors><author>Erl, T.</author></authors></contributors><titles><title>Service-oriented architecture: concepts, technology, and design</title></titles><dates><year>2005</year></dates><publisher>Pearson Education</publisher><isbn>813171490X</isbn><urls></urls><language>en</language></record></Cite></EndNote>[3].

شکل 1-1: سه لایه اصلی در معماری سرویس گرا ADDIN EN.CITE <EndNote><Cite><Author>Erl</Author><Year>2005</Year><RecNum>47</RecNum><DisplayText>[3]</DisplayText><record><rec-number>47</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">47</key></foreign-keys><ref-type name="Book">6</ref-type><contributors><authors><author>Erl, T.</author></authors></contributors><titles><title>Service-oriented architecture: concepts, technology, and design</title></titles><dates><year>2005</year></dates><publisher>Pearson Education</publisher><isbn>813171490X</isbn><urls></urls><language>en</language></record></Cite></EndNote>[3]
یکی از نقاط قوت معماری سرویس گرا قابلیت آن در همگون سازی عملیات بین سیستم‌های اطلاعاتی ناهمگون می‌باشد. معماری سرویس گرا برای یکپارچه‌سازی و ارتباط بین سیستم‌های اطلاعاتی از وب سرویس‌ها استفاده می‌کند. با پیشرفت معماری سرویس گرا وب سرویس‌ها محبوبیت بسیاری یافته و بسیاری از طرح‌ها و برنامه‌ها تجاری توسط این تکنولوژی صورت می‌پذیرد.
اگرچه پتانسیل واقعی سرویس‌ها و معماری سرویس گرا زمانی مشخص می‌شود که برای پاسخگویی به نیاز جدید مشتریان، ترکیبی از سرویس‌های موجود را در کنار هم قرار دهیم. به عبارت دیگر زمانی ما به ترکیب وب سرویس‌ها نیازمند خواهیم بود که به تنهایی یک سرویس نتواند پاسخگو درخواست‌های پیچیده مشتریان باشد اما با ترکیب نمودن آن‌ها توابع و قابلیت‌های متنوع سرویس‌ها در کنار هم می‌توانند پاسخگو نیاز‌ها و درخواست‌های پیچیده مشتریان باشد ADDIN EN.CITE <EndNote><Cite><Author>Ma</Author><Year>2009</Year><RecNum>2</RecNum><DisplayText>[4]</DisplayText><record><rec-number>2</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">2</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Ma, C.</author><author>He, Y.</author></authors></contributors><titles><title>An Approach for Visualization and Formalization of Web Service Composition</title><secondary-title>International Conference on Web Information Sys--s and Mining, 2009. WISM 2009. </secondary-title></titles><pages>342-346</pages><dates><year>2009</year></dates><pub-location>Shanghai</pub-location><publisher>IEEE</publisher><isbn>0769538177</isbn><urls></urls><language>en</language></record></Cite></EndNote>[4].
روز به روز تعداد وب سرویس‌ها با عملکردها و قابلیت‌های مشابه در محیط‌های شبکه‌ای و اینترنت در حال افزایش می‌باشد حال کاربران و توسعه‌دهندگان سیستم‌های اطلاعاتی چگونه می‌توانند مناسب‌ترین سرویس از بین وب ‌سرویس‌های موجود را کشف و انتخاب کنند.
سفارش دهندگان سرویس‌های وب معمولاً نیازمندی‌های غیرعملیاتی خود را با استفاده از یکسری معیار‌های کیفی بیان می‌دارند. کیفیت سرویس قابلیت‌های یک محصول یا سرویس برای مواجه شدن با نیازمندی‌های غیرعملیاتی کاربر را توصیف می‌کند و این معیارهای کیفی می‌توانند به عنوان یک محک زن برای تفاوت و برتری دادن بین سرویس‌ها و فراهم آورندگان سرویس‌ها مورد استفاده قرار گیرند ADDIN EN.CITE <EndNote><Cite><Author>Sha</Author><Year>2009</Year><RecNum>3</RecNum><DisplayText>[5]</DisplayText><record><rec-number>3</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">3</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Sha, L.</author><author>Shaozhong, G.</author><author>Xin, C.</author><author>Mingjing, L.</author></authors></contributors><titles><title>A QoS based web service selection model</title><secondary-title>Information Technology and Applications, 2009. IFITA &apos;09. International Forum on</secondary-title></titles><pages>353-356</pages><volume>3</volume><dates><year>2009</year></dates><pub-location>Chengdu</pub-location><publisher>IEEE</publisher><isbn>076953600X</isbn><urls></urls><language>en</language></record></Cite></EndNote>[5].
در بین سرویس‌های مشابه ممکن است سرویس‌هایی وجود داشته باشند که با توجه به معیار‌های کیفیت سرویس برای کاربران مناسب‌تر می‌باشند بنابراین زمانی که برای اجرای یک عملیات چندین سرویس با عملکرد‌‌های مشابه وجود دارند آنگاه سرویس را بر مبنای نیاز‌ها و معیار‌های کیفیت سرویس کاربران انتخاب می‌کنیم.
مسئله ترکیب سرویس‌ها بر اساس معیارهای کیفت سرویس در شکل 1-2 نشان داده شده است که در آن n تعداد کل وب سرویس‌ها و Kn نیز تعداد پیاده سازی‌های هر یک از وب سرویس‌ها می‌باشد. بنابراین برای وب سرویس WSi ، Ki پیاده سازی وجود دارد که شامل Si,1,…,Si,j,…,Si, Ki می‌باشد. همچنین هر پیاده سازی از وب سرویس‌ها معیارهای کیفیت سرویس خاص خود را دارند. qi,jl نشان دهنده معیار کیفیت سرویس l ام برای وب سرویس Si,j می‌باشد. در روابط بالا (1≤i≤n) و (1≤j≤Ki)

شکل 1-2 : ترکیب سرویس‌ها بر مبنای معیارهای کیفیت سرویس
توصیف، تعریف، و یکپارچگی جهانی (UDDI) استانداردی است که فراهم آورندگان، سرویس‌های خود را در آن ثبت می‌کنند و مانند مخزنی عمل می‌کند که سرویس‌ها در داخل آن قرار می‌گیرد برنامه های کاربردی می‌توانند با جستجو در داخل این مخزن سرویس‌های گوناگون را فراخوانی و از توابع عملیاتی آن‌ها استفاده نمایند.
طبق گفته UDDI این استاندارد برای انتشار و جستجو سرویس‌ها از معیار‌های کیفیت سرویس پشتیبانی نمی‌کند اما ممکن است، نیازمندی‌های کاربران شامل یکسری از نیازهای غیرعملیاتی مانند معیار های کیفی باشد ADDIN EN.CITE <EndNote><Cite><Author>Committee</Author><Year>2004</Year><RecNum>4</RecNum><DisplayText>[6]</DisplayText><record><rec-number>4</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">4</key></foreign-keys><ref-type name="Web Page">12</ref-type><contributors><authors><author>UDDI Spec Technical Committee</author></authors></contributors><titles><title>UDDI Version 3.0. 2</title></titles><dates><year>2004</year></dates><urls><related-urls><url> http://uddi.org/pubs/uddi_v3.htm</url></related-urls></urls><language>en</language></record></Cite></EndNote>[6].
یکی از روش‌های موجود برای بهینه سازی ترکیب وب سرویس‌ها و به حداکثر رساندن رضایت کاربران برای برآورده سازی نیاز‌های عملیاتی و غیرعملیاتی استفاده از رویکرد‌های تقریبی می‌باشد که در زمان کوتاه قادر به یافتن جوابی مناسب و نزدیک به بهینه هستند. این گونه رویکرد‌ها را می‌توان به دو دسته رویکرد‌های مکاشفه‌ای و فرا مکاشفه‌ای تقسیم نمود. برای حل مشکلاتی که در رویکرد‌های مکاشفه‌ای از جمله قرار گرفتن آن‌ها در بهینگی محلی وجود داشته است رویکرد‌های فرا مکاشفه‌ای ارائه شده‌اند. این رویکرد‌ها به گونه هوشمند عمل می‌کنند و با جابه‌جا کردن جمعیت‌های متنوع که همان ترکیبی از وب سرویس‌ها می‌باشد ترکیب و انتخاب کارایی از آن‌ها را در اختیار ما قرار می‌دهند در حقیقت رویکرد‌های فرا مکاشفه‌ای در مواقعی که محدودیتی برای زمان وجود دارد و استفاده از روش‌های حل دقیق، میسر نمی‌باشد و یا پیچیدگی مسائل بهینه سازی زیاد باشند، مناسب هستند.
از آنجا که در بهینه سازی ترکیب وب سرویس‌ها حالات بی‌شماری برای ترکیب به وجود خواهد آمد و جستجوی تمامی این حالات برای دستیابی به یک حالت بهینه در بسیاری از مواقع غیرممکن می‌باشد در نتیجه در این پایان نامه روش جدیدی برای انتخاب و ترکیب کارا وب سرویس‌ها بر مبنای معیار‌های کیفیت سرویس با استفاده از رویکردهای تقریبی ارائه می‌شود تا مناسب‌ترین ترکیب از بین ترکیب‌های موجود را در سریع‌ترین زمان ممکن انتخاب نماییم. در ادامه پایان نامه رویکرد ارائه داده شده را پیاده سازی و مورد ارزیابی قرار خواهیم داد.
1-2 هدف از اجرای طرحامروزه اکثر شرکت‌ها و سازمان‌ها، تجارت و کسب و کار خود را در بستر اینترنت قرار داده‌اند و با برون سپاری بخش‌های مختلف سازمان به دنبال کوچک سازی ساختار فیزیکی سازمان می‌باشند همچنین با گذشت زمان نیازمندی‌های مشتریان در محیط‌های کسب‌و‌کار به سرعت در حال رشد می‌باشند که می‌تواند چالش جدی در توسعه سیستم‌های اطلاعاتی به حساب آیند. در بیشتر موارد یک سرویس نمی‌تواند به تنهایی پاسخگو نیاز‌های پیچیده مشتریان باشد از این‌رو برای پاسخگویی به این‌گونه نیاز‌ها باید ترکیبی از سرویس‌ها مورد استفاده قرار گیرند. بنابراین توانایی سازمان‌ها و شرکت‌ها در انتخاب و ترکیب کارای وب سرویس‌ها در توسعه نرم‌افزار‌ها و سیستم‌های اطلاعاتی سرویس گرا بسیار اهمیت می‌یابد، از طرف دیگر سرویس‌های گوناگون با عملکرد‌های مشابه که توسط فراهم آورندگان متفاوتی ارائه می‌شوند روز به روز در اینترنت افزایش می‌یابند، حال کاربران چگونه می‌توانند از بین سرویس‌های مشابه سرویس دلخواه خود را انتخاب کنند.
آیا سرویس همواره در دسترس می‌باشد؟ آیا هزینه آن مناسب است؟ آیا سرویس در زمان کمتر از 3 ثانیه می‌تواند به جواب برسد؟ آیا سرویس انتخابی سرویس معروفی می‌باشد؟ این سؤال‌ها در مورد معیار‌های کیفیت سرویس، در تجارت الکترونیک و تبادلات بین بنگاه‌ها همواره مطرح بوده است.
بنابراین هدف از انجام این تحقیق، ارائه رویکرد جدید برای انتخاب و ترکیب کارا وب سرویس‌ها در سازمان‌هایی با مقیاس بزرگ بر مبنای معیار‌های کیفیت سرویس می‌باشد تا کاربران بتوانند بر مبنای معیارهای کیفی هر یک از سرویس‌ها، مناسب‌ترین ترکیب از بین ترکیب‌های موجود را در سریع‌ترین زمان ممکن انتخاب کنند.
1-3 توجیه ضرورت انجام طرح و اهمیت موضوع
با گسترش استفاده از تکنولوژی‌های مرتبط به سرویس گرایی و وب سرویس‌ها و نیز تشدید رقابت میان ارائه‌دهندگان سرویس‌های وب، به ناچار بسیاری از فراهم ‌آورندگان، سرویس‌هایی با عملکرد‌های مشابه اما با ویژگی‌های کیفی متفاوت را ارائه دادند. این سرویس‌ها می‌توانند به ده‌ها هزار حالت متفاوت ترکیب شوند بنابراین حالت‌های بی‌شماری برای ترکیب به وجود خواهد آمد در نتیجه در فرایند ترکیب، سازمان‌ها باید پیاده‌سازی‌های متنوع از سرویس‌ها را از بین انبوهی از پیاده‌سازی‌های موجود در اینترنت که دارای عملکردهای مشابه اما ویژگی‌های کیفی متفاوت می‌باشند انتخاب نمایند ADDIN EN.CITE <EndNote><Cite><Author>Zhang</Author><Year>2011</Year><RecNum>5</RecNum><DisplayText>[7]</DisplayText><record><rec-number>5</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">5</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Zhang, C.</author></authors></contributors><titles><title>Adaptive Genetic Algorithm for QoS-aware Service Selection</title><secondary-title>Advanced Information Networking and Applications (WAINA), 2011 IEEE Workshops of International Conference on</secondary-title></titles><pages>273-278</pages><dates><year>2011</year></dates><pub-location>Biopolis</pub-location><publisher>IEEE</publisher><isbn>161284829X</isbn><urls></urls><language>en</language></record></Cite></EndNote>[7].
در زیر دو دلیل مهم که سبب می‌شود که به دنبال راه حلی برای مشکل انتخاب و ترکیب کارای سرویس‌ها بر مبنای معیار‌های کیفی باشیم آورده شده است :
1 : انواع مختلف و تعداد بسیار زیادی از سرویس‌ها توسط فراهم آورندگان آن‌ها در اینترنت قرار گرفته است که دارای کارایی، قیمت، زمان پاسخگویی و پلت فرم‌های متفاوت اما دارای عملکرد مشابه‌ای می‌باشند در نتیجه انتخاب سرویس مناسب برای کاربران کار پیچیده و سختی و تا حدی غیرممکن می‌باشد.
2 : نیازهای کیفی کاربران در زمینه های بازار گرایی و اعتماد به سرویس‌ها رشد یافته در نتیجه باید معیارهای متنوعی برای کیفیت سرویس از قبیل درجه اعتماد، موفقیت سرویس، هزینه های مالی، زمان پاسخگویی در راه حل‌های جدید گنجانده شوند ADDIN EN.CITE <EndNote><Cite><Author>Zhao</Author><Year>2011</Year><RecNum>6</RecNum><DisplayText>[8]</DisplayText><record><rec-number>6</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">6</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Zhao, L.</author><author>Ren, Y.</author><author>Li, M.</author><author>Sakurai, K.</author></authors></contributors><titles><title>Flexible service selection with user-specific QoS support in service-oriented architecture</title><secondary-title>Journal of Network and Computer Applications</secondary-title></titles><periodical><full-title>Journal of Network and Computer Applications</full-title></periodical><dates><year>2011</year></dates><isbn>1084-8045</isbn><urls></urls><language>en</language></record></Cite></EndNote>[8].
کشف و ترکیب سرویس‌ها در زمان اجرای آن همواره جزء مهم‌ترین چالش پیش‌رو در نرم‌افزار‌های سرویس گرا بوده است. اگر ما تعداد کل کار‌ها در جریان کاری را k و برای انجام هرکدام از این جریان‌های کاری n وب‌ سرویس با عملکرد مشابه داشته باشیم، در این صورت nk ترکیب مختلف از وب سرویس‌ها برای اجرای فرایندهای کاری به وجود می‌آید. بنابراین دستیابی به یک ترکیب بهینه از ترکیبات موجود بسیار پیچیده خواهد بود و جستجو تمامی حالت‌ها بسیار پرهزینه و زمان ‌بر است. از طرف دیگر تعداد ترکیبات به وجود آمده با در نظر گرفتن معیار‌های کیفیت سرویس کاربران بیشتر نیز خواهد شد ADDIN EN.CITE <EndNote><Cite><Author>Wang</Author><Year>2007</Year><RecNum>7</RecNum><DisplayText>[9]</DisplayText><record><rec-number>7</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">7</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Wang, H.</author><author>Tong, P.</author><author>Thompson, P.</author></authors></contributors><titles><title>QoS-Based Web Services Selection</title><secondary-title>e-Business Engineering, 2007. ICEBE 2007. IEEE International Conference on</secondary-title></titles><pages>631-637</pages><dates><year>2007</year></dates><pub-location>Hong Kong</pub-location><publisher>IEEE</publisher><isbn>0769530036</isbn><urls></urls><language>en</language></record></Cite></EndNote>[9].
1-4 مدل تحقیقمراحل انجام این تحقیق مطابق شکل ۱-3 خواهد بود :

شکل 1-3 : مراحل انجام تحقیق1-5 فرضیات مسئلهداده‌های کیفیت سرویس هر یک از وب سرویس‌ها توسط فراهم آورنده آن سرویس مشخص می‌شوند.
عواملی مانند کارایی و پهنای باند اینترنت در پیاده سازی رویکرد ارائه شده تأثیر گزار نمی‌باشند.
در شبکه اینترنت تعداد بسیار زیاد و انواع متنوعی از سرویس‌ها وجود دارند و هر کدام دارای معیار‌های مختلفی برای تعیین کیفیت سرویس می‌باشند.
وب سرویس‌های گوناگون می‌توانند با یکدیگر ترکیب شوند و خدمت واحدی را ارائه دهند.
معیارهای کیفیت سرویس نظیر زمان پاسخگویی، قابلیت اطمینان، دسترس پذیری، زمان تاخیر و نرخ موفقیت در ترکیب و انتخاب وب سرویس‌ها تأثیر گزار می‌باشند.
1-6 چارچوب تحقیقدر ادامه ساختار پایان نامه به صورت زیر می‌باشد:
در فصل دوم مفاهیم پایه‌ای از معماری سرویس گرا و اهمیت استفاده آن در سازمان‌ها و مروری از کارهای انجام شده در زمینه انتخاب و ترکیب وب سرویس‌ها مورد بررسی قرار خواهد گرفت. در فصل سوم در ابتدا مبانی روش پیشنهادی به همراه معرفی معماری و مدل پیشنهادی گفته می‌شود و سپس رویکردی برای انتخاب و ترکیب بهینه وب سرویس‌ها با در نظر داشتن معیار‌های کیفی کاربران با هدف خودکار سازی انتخاب و ترکیب سرویس‌های وب ارائه خواهد شد. کلیات و مکانیزم روش‌های فرا مکاشفه‌‌ای توسعه داده شده و نیز جزئیات رویکرد ارائه شده در ادامه خواهد آمد. در فصل چهارم پس از بیان نحوه تولید مسائل نمونه، نتایج پیاده سازی رویکردهای فرا مکاشفه‌‌ای توسعه داده شده در محیط آزمایشگاهی مورد تحلیل قرار می‌گیرد. و در نهایت در فصل پنجم با نتیجه گیری و جمع آوری کارهای انجام شده و کارهای آینده تحقیق را به پایان میرسانیم.

فصل دوم
ادبیات و پیشینه تحقیق21889781335720
2-1 مقدمهمسئله انتخاب و ترکیب سرویس‌های وب مبتنی بر معیارهای کیفیت سرویس، یک مسئله ترکیباتی پیچیده است که در بسیاری از مسائل دنیای واقعی کاربرد دارد. با توجه به اهمیت و پیچیدگی این مسائل تاکنون مطالعات زیادی حول این موضوع انجام شده است و رویکردها و تکنیک‌های گوناگونی برای حل مسئله ترکیب سرویس‌های وب ارائه شده است.
در این فصل در ابتدا با مفاهیم و تعاریف معماری سرویس گرا و وب سرویس‌ها آشنا می‌شویم و در ادامه توضیحاتی راجع به انتخاب و ترکیب وب سرویس‌ها و اهمیت معیارهای کیفیت سرویس در آن که به عنوان معیارهایی جهت ارزیابی سرویس نرم افزاری می‌باشند، داده خواهد شد. در انتها فصل نیز به معرفی تعدادی از کارهای مرتبطی که تاکنون در زمینه ترکیب و انتخاب سرویس‌های وب صورت گرفته است می‌پردازیم.
2-2 مفاهیم پایه2-2-1 رهیافت‌های یکپارچه سازی سیستم‌های اطلاعاتیرهیافت‌های مختلفی برای یکپارچه‌سازی سیستم‌های اطلاعاتی ارائه شده است از جمله اتصال نقطه به نقطه یا استفاده از یک مترجم مرکزی و یا پورتال‌ها، که در اتصال نقطه به نقطه برای ایجاد ارتباط بین نرم‌افزار‌های مختلف باید استاندارد‌ها و مسیر‌ ارتباطی بین دو نرم‌افزار ایجاد شود، همان‌طور که پیداست در این رهیافت با افزایش نیاز به ارتباط بین زیرسیستم‌های مختلف هزینه‌ توسعه و تولید نرم‌افزار‌های جدید که با سیستم‌های پیشین در تعامل باشند به شدت افزایش میابند. در روش مترجم مرکزی یک میان افزار که وظیفه ترجمه پیام‌ها را بر عهده دارد بین تمامی زیرسیستم‌ها قرار گرفته و زمانی که یک زیرسیستم قصد ارتباط با زیر سیستم دیگر را داشته باشد ابتدا پیام را به مترجم مرکزی ارسال می‌کند و بعد از ترجمه به پروتکل و فناوری مربوطه به زیر سیستم دوم ارسال می‌شود. اما در معماری سرویس گرا اصل بر این است که همه سیستم‌های اطلاعاتی با یک واسط استاندارد و مورد توافق جهانی تعامل داشته باشند. وب سرویس‌ها با فرستادن پیام‌های بر مبنای XML با مشتریان و یا سایر وب سرویس‌ها ارتباط برقرار می‌کنند.
2-2-2 کاربرد معماری سرویس گراامروزه تغییرات زیادی در نحوه کسب و کار سازمان‌ها در جهان به وجود آمده و بسیاری از کسب و کارها مشتری محور شده است. در این نوع از سازمان‌ها بیشتر نگاه‌ها و توجهات به مشتریان می‌باشد. بنابراین برای برآورده سازی نیازهای مشتریان، سازمان‌ها باید بتوانند خدمات خود را در سریع‌ترین زمان ممکن به مشتریان ارائه دهند. این سازمان‌ها به دنبال این هستند تا راه حل‌های بهتری را در مواجهه با تغییرات محیطی ارائه دهند تا تحویل خدمات را در سریع‌ترین زمان ممکن و با قیمت ارزان‌تر در اختیار مشتریان قرار دهند. معماری سرویس گرا این امکان را به سازمان‌ها می‌دهد و آن‌ها را قادر می‌سازد تا فرایند های کسب و کار را در میان سازمان‌‌ها یکپارچه سازند. SOA ایده جدیدی را برای سازماندهی فرآیندهای کسب و کار در جهت پاسخ گویی سریع به نیازهای در حال تغییر مشتریان ارائه می‌دهد ADDIN EN.CITE <EndNote><Cite><Author>Kanchanavipu</Author><Year>2008</Year><RecNum>8</RecNum><DisplayText>[10]</DisplayText><record><rec-number>8</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">8</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Kanchanavipu, K.</author></authors></contributors><titles><title>An Integrated Model for SOA Governance</title><secondary-title>rapport nr.: Report/IT University of Göteborg 2008: 002</secondary-title></titles><periodical><full-title>rapport nr.: Report/IT University of Göteborg 2008: 002</full-title></periodical><dates><year>2008</year></dates><urls><related-urls><url>http://hdl.handle.net/2077/10495</url></related-urls></urls><language>en</language></record></Cite></EndNote>[10].
اما با این وجود معماری سرویس گرا برای تمامی سیستم‌های اطلاعاتی که نیاز به یکپارچه سازی دارند راه حل مناسبی نمی‌باشد با توجه به محبوبیت فعلی SOA در بین کاربران بسیاری از آنان حتی زمانی که استفاده از SOA برای سازمان مناسب نباشد نیز به سراغ آن می‌روند ADDIN EN.CITE <EndNote><Cite><Author>Kontogiannis</Author><Year>2007</Year><RecNum>9</RecNum><DisplayText>[11]</DisplayText><record><rec-number>9</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">9</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Kontogiannis, K.</author><author>Lewis, G.A.</author><author>Smith, D.B.</author><author>Litoiu, M.</author><author>Muller, H.</author><author>Schuster, S.</author><author>Stroulia, E.</author></authors></contributors><titles><title>The landscape of service-oriented sys--s: A research perspective</title><secondary-title>International Workshop on Sys--s Development in SOA Environments</secondary-title></titles><pages>1-1</pages><dates><year>2007</year></dates><publisher>IEEE</publisher><isbn>0769529607</isbn><urls></urls><language>en</language></record></Cite></EndNote>[11].
بنابراین مدیران می‌بایست قبل از تصمیم گیری برای استفاده از این الگو در سازمان دید کامل و درستی از زیرساخت‌های فناوری و فرایندهای کسب و کار سازمان بدست آورند و به این نکته توجه داشته باشند که با استفاده از این معماری سازمان چه چیزی را بدست می‌آورد.
جسوتیس سه خصوصیتی را که سیستم‌های مبتنی بر SOA باید داشته باشند را آورده است که شامل: سیستم‌های پیچیده توزیع شده، سیستم‌هایی که مالکان مختلفی دارند و سیستم‌های ناهمگون می‌باشد ADDIN EN.CITE <EndNote><Cite><Author>Josuttis</Author><Year>2007</Year><RecNum>10</RecNum><DisplayText>[12]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">10</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>Josuttis, N.</author></authors></contributors><titles><title>SOA in practice-Art of Distributed Sys-- Design. 2007</title></titles><dates><year>2007</year></dates><publisher>O&apos;Reilly &amp; Assoc</publisher><urls></urls><language>en</language></record></Cite></EndNote>[12]:
در سیستم‌های پیچیده توزیع شده تمامی اجزا سیستم باید در محل‌های خود قرار گیرند و از قابلیت‌های توزیع شده که در دسترس است استفاده نمایند. SOA این امکان را با استفاده از تعامل سرویس دهندگان و سرویس گیرندگان فراهم می‌آورد.
زمانی که عملکردها و قابلیت‌های گوناگون سیستم‌های اطلاعاتی توسط مالکین مختلف کنترل می‌شوند اولویت‌های گوناگونی به وجود می‌آید و نمی‌توان انتظار داشت که تمامی مالکین بتوانند تمامی اتفاقاتی که در سیستم رخ می‌دهد را تحت نظر داشته باشند. راه حل و روش SOA برای چنین سیستم‌هایی که توسط یک نفر کنترل نمی‌شوند می‌تواند بسیار مناسب باشد.
در سیستم‌ها با مقیاس بزرگ استفاده از پلتفرم‌ها و زبان‌های برنامه نویسی مختلف بسیار رایج است و این ناهمگونی‌ها در پلتفرم‌ها و زبان‌های برنامه نویسی ممکن است در یکپارچه سازی سیستم‌های اطلاعاتی مشکل ساز باشد. اما SOA می‌تواند به راحتی مشکل ناهمگونی سیستم‌های اطلاعاتی در سازمان‌ها را برطرف سازد.
در ادامه این فصل به معرفی معماری سرویس گرا می‌پردازیم و توضیح مختصری از معماری سرویس گرا و مزایا و معایب آن می‌دهیم.
2-2-3 تعریف معماری سرویس گرابه سختی تعریف دقیق برای واژه معماری سرویس گرا یا به اختصار SOA یافت می‌شود اما این بدان معنا نیست که تعریفی وجود ندارد. در واقع تعاریف گوناگونی برای معماری سرویس گرا وجود دارد که اغلب وابسته به حوزه ای است که مورد استفاده قرار می‌گیرد در ADDIN EN.CITE <EndNote><Cite><Author>MacKenzie</Author><Year>2006(accessed 2008-02-14)</Year><RecNum>11</RecNum><DisplayText>[13]</DisplayText><record><rec-number>11</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">11</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>MacKenzie, C.M.</author></authors></contributors><titles><title>Reference model for service oriented architecture</title><secondary-title>Public Review Draft 2</secondary-title></titles><dates><year>2006(accessed 2008-02-14)</year></dates><urls><related-urls><url>http://www.oasis-open.org/committees/download.php/16587/wd-soa-rm-cd1ED.pdf.</url></related-urls></urls><language>en</language></record></Cite></EndNote>[13] تعریفی از معماری سرویس گرا توسط OASIS ارائه شده است:

متن کامل در سایت امید فایل 

معماری سرویس گرا الگویی برای سازمان‌ها و استفاده از قابلیت‌های توزیع شده آن‌ها تحت نظارت افراد گوناگونی می‌باشد.
با توجه به تعریفی که در بالا آمده است معماری سرویس گرا یک الگو می‌باشد. به عبارت دیگر SOA یک رویکرد و یا یک روش تفکری است، بنابراین نمی‌توان گفت که یک ابزار می‌باشد، که بتوان آن را خرید ADDIN EN.CITE <EndNote><Cite><Author>Josuttis</Author><Year>2007</Year><RecNum>10</RecNum><DisplayText>[12]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">10</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>Josuttis, N.</author></authors></contributors><titles><title>SOA in practice-Art of Distributed Sys-- Design. 2007</title></titles><dates><year>2007</year></dates><publisher>O&apos;Reilly &amp; Assoc</publisher><urls></urls><language>en</language></record></Cite></EndNote>[12].
معماری سرویس گرا شامل سیاست‌ها، تجارب و چارچوب‌هایی است که کارکردهای سیستم را قادر می‌سازد به صورت مجموعه ای از سرویس‌های توزیع شده در اندازه های مورد نظر سازمان تعریف شوند. این سرویس‌ها با کمک تعریف یک واسط استاندارد از پیاده سازی مجزا شده‌اند ADDIN EN.CITE <EndNote><Cite><Author>مهجوریان</Author><Year>زمستان 88</Year><RecNum>12</RecNum><DisplayText>[1]</DisplayText><record><rec-number>12</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">12</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author><style face="normal" font="default" charset="178" size="100%">امیر مهجوریان</style></author><author><style face="normal" font="default" charset="178" size="100%">فریدون شمس</style></author></authors></contributors><titles><title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></title><secondary-title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></secondary-title></titles><dates><year><style face="normal" font="default" charset="178" size="100%">زمستان 88</style></year></dates><urls></urls><language>a</language></record></Cite></EndNote>[1].
افراد مختلف با توجه به جایگاه خود دیدگاه های متفاوتی نسبت به معماری سرویس گرا دارند و در ادامه سه دیدگاه کارشناسان حرفه، معماران و طراحان از معماری سرویس گرا توضیح داده شده است:
کارشناسان حرفه: مجموعه ای از سرویس‌ها که سازمان آن‌ها را به مشتریان یا شرکا خود ارائه می‌دهد.
معماران: سبکی از معماری که شامل قوانین و الگوهایی می‌باشد که منجر به ایجاد خصایصی نظیر پیمانه ای بودن، بسته بندی، اتصال سست، استفاده مجدد و ترکیب پذیری شده و از نظر ساختار از یک ارائه دهنده و یک درخواست کننده سرویس تشکیل شده است.
طراحان و پیاده سازان: مدل برنامه نویسی که از استانداردهایی مانند WSDL، UDDI، SOAP و فناوری‌هایی نظیر وب سرویس‌ها استفاده می‌کند و امکان برقراری ارتباط بین مؤلفه های نرم افزاری را مستقل از سکو و فناوری پیاده سازی فراهم می‌آورد ADDIN EN.CITE <EndNote><Cite><Author>مهجوریان</Author><Year>زمستان 88</Year><RecNum>12</RecNum><DisplayText>[1]</DisplayText><record><rec-number>12</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">12</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author><style face="normal" font="default" charset="178" size="100%">امیر مهجوریان</style></author><author><style face="normal" font="default" charset="178" size="100%">فریدون شمس</style></author></authors></contributors><titles><title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></title><secondary-title><style face="normal" font="default" charset="178" size="100%">طراحی سازمان سرویس گرا بر اساس اصول معماری سرویس گرا</style></secondary-title></titles><dates><year><style face="normal" font="default" charset="178" size="100%">زمستان 88</style></year></dates><urls></urls><language>a</language></record></Cite></EndNote>[1].
معماری سرویس گرا را می‌توان در روابط بین مشتریان سرویس، فراهم آورندگان سرویس و دلالان سرویس تعریف کرد و این 3 حوزه در کنار یکدیگر، یک محیط کسب و کار سرویس گرا را به وجود می‌آورند ADDIN EN.CITE <EndNote><Cite><Author>Kanchanavipu</Author><Year>2008</Year><RecNum>8</RecNum><DisplayText>[10]</DisplayText><record><rec-number>8</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">8</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Kanchanavipu, K.</author></authors></contributors><titles><title>An Integrated Model for SOA Governance</title><secondary-title>rapport nr.: Report/IT University of Göteborg 2008: 002</secondary-title></titles><periodical><full-title>rapport nr.: Report/IT University of Göteborg 2008: 002</full-title></periodical><dates><year>2008</year></dates><urls><related-urls><url>http://hdl.handle.net/2077/10495</url></related-urls></urls><language>en</language></record></Cite></EndNote>[10].

شکل 2-1 : محیط کسب و کار سرویس گرا ADDIN EN.CITE <EndNote><Cite><Author>Kanchanavipu</Author><Year>2008</Year><RecNum>8</RecNum><DisplayText>[10]</DisplayText><record><rec-number>8</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">8</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Kanchanavipu, K.</author></authors></contributors><titles><title>An Integrated Model for SOA Governance</title><secondary-title>rapport nr.: Report/IT University of Göteborg 2008: 002</secondary-title></titles><periodical><full-title>rapport nr.: Report/IT University of Göteborg 2008: 002</full-title></periodical><dates><year>2008</year></dates><urls><related-urls><url>http://hdl.handle.net/2077/10495</url></related-urls></urls><language>en</language></record></Cite></EndNote>[10]
2-2-4 مزایای استفاده از معماری سرویس گرا
مزایای عمده استفاده از SOA شامل قابلیت استفاده مجدد از سرویس‌ها و خدمات، توانایی آن در کاهش هزینه‌ها، بهبود فرایند های کسب و کار و چابک سازی سازمان‌ها می‌باشد ADDIN EN.CITE <EndNote><Cite><Author>Svensson</Author><Year>2006</Year><RecNum>13</RecNum><DisplayText>[14]</DisplayText><record><rec-number>13</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">13</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Svensson, C.</author><author>Wallen, L.</author></authors></contributors><titles><title>SOA and M &amp; A-Relationships between Service Oriented Architectures (SOA) and Mergers and Acquisitions (M &amp; A)</title><secondary-title>Department of Informatics, Lund University, Lund, Sweden</secondary-title></titles><periodical><full-title>Department of Informatics, Lund University, Lund, Sweden</full-title></periodical><dates><year>2006</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[14].
2-2-4-1 استفاده مجدد
معماری سرویس گرا این امکان را برای سازمان‌ها و توسعه دهندگان سیستم‌های اطلاعاتی فراهم می‌آورد تا از یک سرویس و یا خدمت چندین بار استفاده نمایند و دیگر نیاز نمی‌باشد تا سازمان‌ها سرویس‌های مورد نیاز خود را از نو پیاده سازی نمایند بلکه سرویس‌های موجود را می‌توانند چندین بار فراخوانی و مورد استفاده قرار دهند و این امر سبب کاهش هزینه‌ها در سازمان می‌شود.

شکل 2-2 : استفاده مجدد از وب سرویس‌ها در معماری سرویس گرا
در این معماری یک مخزنی از سرویس‌ها وجود دارد که وب سرویس‌ها در آن قرار می‌گیرند و کاربران و توسعه دهندگان تنها سرویس‌های مورد نیاز خود را فراخوانی می‌کنند بدون آنکه نیاز باشد از جزئیات آن سرویس‌ها و نحوه پیاده سازی آن‌ها آگاه باشند. از دیگر مزایای استفاده مجدد سرویس‌ها، فراخوانی یک سرویس در سرویس دیگر برای برآورده سازی نیازهای کاربران می‌باشد. معماری سرویس گرا می‌تواند انواع مختلف سیستم‌های اطلاعاتی را بدون هیچ گونه دردسر و به آسانی در سطح سازمانی و فرا سازمانی یکپارچه سازد همچنین دیگر نیاز نمی‌باشد توسعه دهندگان سیستم‌های اطلاعاتی برای افزودن قابلیت‌های جدیدی به نرم افزار کار زیادی انجام دهند. آن‌ها برای این کار از پروتکل‌های استاندارد و وب سرویس‌ها استفاده می‌کنند که در ادامه توضیح داده می‌شود.
2-2-4-2 کاهش هزینه در یکپارچه سازیطراحی خوب معماری سرویس گرا، به سازمان‌ها این امکان را می‌دهد تا برخلاف معماری‌های سنتی که نیاز به سرمایه گزاری های بسیار زیادی داشته، چندین سازمان کوچک با سرمایه و منابع مالی کم یکپارچه و همراه شده و با یکدیگر همکاری نمایند. در معماری سرویس گرا به جای آن که هر سازمان برای خود یک مجموعه کامل از سیستم اطلاعاتی را ایجاد و پیاده سازی نماید می‌تواند سرویس‌های مورد نیاز را برای توسعه سیستم‌های اطلاعاتی از فراهم آورندگان مختلف جمع آوری نماید و آن‌ها را در نرم افزار خود فراخوانی کند و در بدترین حالات سازمان نیاز پیدا می‌کند تا سرویس جدیدی را ایجاد نماید. با توجه با توانایی بالا معماری سرویس گرا در استفاده مجدد از سرویس‌ها و فرایند های سازمان، معماری سرویس گرا نه تنها هزینه های مستقیم سازمان را کاهش می‌دهد تأثیر بسیار زیادی را در کاهش هزینه‌های نگهداری و پشتیبانی می‌گزارد.
2-2-4-3 چابکی کسب و کارمعماری سرویس گرا برای یکپارچه سازی سیستم‌های اطلاعاتی در سازمان‌ها بسیار مناسب می‌باشد. سازمان‌هایی که از این معماری استفاده می‌نمایند می‌توانند سرعت بیشتری را در یکپارچه سازی بخش‌های مختلف به وجود آورند. امکان اضافه و یا تغییر ماژول‌ها در معماری سرویس گرا که فرایند های کسب و کار را شکل می‌دهند و تعامل بین آن‌ها را به وجود می‌آورند به سازمان‌ها این امکان را می‌دهد تا بیشتر تلاش و تمرکزشان به سمت ارزش‌های اصلی و سرعت بخشیدن به معرفی محصولات و خدمات جدید سوق یابد.

شکل 2-3 : چابکی کسب و کار در معماری سرویس گرا2-2-5 وب سرویس
همان طور که از نام معماری سرویس گرا پیداست، SOA تا حد زیادی مبتنی بر سرویس‌ها می‌باشد. یک سرویس می‌تواند نمایش قابلیت‌های کسب و کار یک سازمان باشد و افراد و یا سرویس‌های دیگر که از آن سرویس استفاده می‌کنند نیاز ندارند که از جزئیات تکنیکی سرویس و نحوه پیاده سازی آن اطلاعی داشته باشند همچنین واسط کاربری سرویس باید به گونه ای باشد که افراد در کسب و کار های مختلف بتوانند به آسانی آن سرویس را مورد استفاده قرار دهند ADDIN EN.CITE <EndNote><Cite><Author>Josuttis</Author><Year>2007</Year><RecNum>10</RecNum><DisplayText>[12]</DisplayText><record><rec-number>10</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">10</key></foreign-keys><ref-type name="Generic">13</ref-type><contributors><authors><author>Josuttis, N.</author></authors></contributors><titles><title>SOA in practice-Art of Distributed Sys-- Design. 2007</title></titles><dates><year>2007</year></dates><publisher>O&apos;Reilly &amp; Assoc</publisher><urls></urls><language>en</language></record></Cite></EndNote>[12] و این یک مزیت بسیار مهم برای معماری سرویس گرا در تعامل با ذی‌نفعان می‌باشد.
همان طور که قبلاً اشاره شده یکی از نقاط قوت معماری سرویس گرا قابلیت آن‌ها در همگون سازی عملیات بین سیستم‌های اطلاعاتی ناهمگون و استفاده مجدد از توابع و سرویس‌ها در سیستم‌های نرم افزاری جدید می‌باشد. معماری سرویس گرا برای یکپارچه‌سازی و ارتباط بین سیستم‌های اطلاعاتی از وب سرویس‌ها استفاده می‌کند.
در هر سرویس تنها خروجی آن سرویس برای کاربران مهم است و اینکه از چه پلتفرمی استفاده می‌شود و یا چه زبان برنامه نویسی مطرح نمی‌باشد، بنابراین سیستم‌های ناهمگون به آسانی می‌توانند با یکدیگر در تعامل و ارتباط قرار گیرند.
وب سرویس‌ها با یکپارچه سازی نرم افزار های تجاری موجود در اینترنت امکان اجرای کارآمد تبادلات بین دو بنگاه (B2B) و ایجاد بستری برای تجارت الکترونیک (B2C) را تسهیل می‌بخشند. وب سرویس‌ها می‌توانند به تنهایی در یک نرم افزار یا در وب سرویس‌های دیگر برای مبادلات پیچیده تجاری مورد استفاده قرار گیرند ADDIN EN.CITE <EndNote><Cite><Author>D&apos;Mello</Author><Year>2010</Year><RecNum>14</RecNum><DisplayText>[15]</DisplayText><record><rec-number>14</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">14</key></foreign-keys><ref-type name="Conference Paper">47</ref-type><contributors><authors><author>D&apos;Mello, D. A.</author><author>Ananthanarayana, V. S.</author></authors></contributors><titles><title>Review of Quality of Service (QoS) Driven Dynamic Web Service Selection Techniques</title><secondary-title>Industrial and Information Sys--s (ICIIS)</secondary-title></titles><pages>201 - 206 </pages><dates><year>2010</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[15].
تکنولوژی وب سرویس‌ها بر مبنای استانداردهای XML نظیر SOAP، WSDL و UDDI می‌باشد. معماری سرویس گرا به دلیل پتانسیل بسیار بالای آن برای استفاده مجدد، کارایی و مقیاس پذیری بالا و قابلیت یکپارچه سازی سیستم‌های اطلاعاتی محبوبیت بالایی را نزد توسعه دهندگان سیستم‌های اطلاعاتی بدست آورده است ADDIN EN.CITE <EndNote><Cite><Author>Street</Author><Year>2008</Year><RecNum>15</RecNum><DisplayText>[16]</DisplayText><record><rec-number>15</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">15</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Street, J.</author><author>Gomaa, H.</author></authors></contributors><titles><title>Software Architectural Reuse Issues in Service-Oriented Architectures</title><secondary-title>Hawaii International Conference on Sys-- Sciences, Proceedings of the 41st Annual</secondary-title></titles><pages>316-316</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769530753</isbn><urls></urls><language>en</language></record></Cite></EndNote>[16].
2-2-5-1 انتخاب و کشف وب سرویسیکی از مهم‌ترین مسائلی که در معماری سرویس گرا وجود دارد حل مسائلی نظیر کشف، انتخاب و ترکیب سرویس‌ها می‌باشد. کشف سرویس فرایندی است که در آن کاربر سرویس‌های مورد نیاز خود را از مخزن سرویس می‌یابد و می‌تواند آن را در بین سرویس‌های موجود انتخاب نماید بنابراین بدیهی می‌باشد که کاربران قبل از هرگونه انتخاب سرویس، ابتدا باید سرویس‌های مورد نیاز خود را جستجو نمایند. در ADDIN EN.CITE <EndNote><Cite><Author>Sathya</Author><Year>2011</Year><RecNum>16</RecNum><DisplayText>[17]</DisplayText><record><rec-number>16</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">16</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Sathya, M.</author><author>Swarnamugi, M.</author><author>Dhavachelvan, P.</author><author>Sureshkumar, G.</author></authors></contributors><titles><title>Evaluation of qos based web-service selection techniques for service composition</title><secondary-title>International Journal of Software Engineering (IJSE)</secondary-title></titles><periodical><full-title>International Journal of Software Engineering (IJSE)</full-title></periodical><pages>73</pages><volume>1</volume><number>5</number><dates><year>2011</year></dates><urls></urls><language>en</language></record></Cite></EndNote>[17] نیازمندی‌های پایه برای هر کدام از رویکردهای انتخاب سرویس به صورت زیر بیان شده است:
نیازهای مورد انتظار مشتریان از سرویس‌ها، سرویس‌های ارائه شده توسط فراهم آورنده سرویس و فرایند انتخاب سرویس
نیازهای مورد انتظار مشتریان از سرویس‌ها:
نیازهای مشتریان ممکن است ساده و یا پیچیده باشد. نیازهای ساده مشتریان می‌تواند توسط یک سرویس به تنهایی پاسخ داده شود و دیگر نیازی به ترکیبی از سرویس‌ها نباشد. اما برای برآورده سازی نیازهای پیچیده کاربران که شامل نیازهای عملیاتی و غیرعملیاتی می‌باشد باید سرویس‌های مختلف را با یک دیگر ترکیب نمود. یک سرویس مرکب سرویسی می‌باشد که با اجرای چندین سرویس در دسترس یک فرایند را انجام می‌دهد. مشتریان سرویس‌ها انتظار دارند علاوه بر برآورده سازی نیازمندی‌های عملیاتی، نیازهای غیرعملیاتی آن‌ها نیز که شامل یکسری معیارهای کیفیت سرویس نظیر درجه اطمینان به سرویس، زمان پاسخگویی و... می‌باشد توسط سرویس‌های انتخاب شده برآورده شود بنابراین امروزه انتخاب سرویس‌ها مبتنی بر معیارهای کیفیت سرویس برای کاربران اهمیت بسیاری پیدا کرده است.
سرویس‌های ارائه شده توسط فراهم آورنده سرویس:
سرویس‌های ارائه شده توسط فراهم آورنده سرویس علاوه بر برآورده سازی نیازهای عملیاتی کاربران، باید پاسخگو نیازهای کیفی آن‌ها نیز باشد. نیاز‌های عملیاتی به نیاز‌هایی گفته می‌شود که بیانگر عملکرد یک سرویس است و نیازهای غیرعملیاتی بیانگر کیفیت عملکردی سرویس می‌باشد.
فرایند انتخاب سرویس:
در مرحله انتخاب سرویس باید نیازهای کاربران را با سرویس‌های ارائه شده توسط فراهم آورنده تطبیق دهیم. انتخاب پویای سرویس‌ها شامل دریافت نیازهای کاربر، انتشار و ثبت سرویس توسط فراهم آورنده آن با استفاده از زبان توصیف سرویس‌ها و در نهایت تطبیق نیازهای کاربران با سرویس‌هایی انتشار داده شده و انتخاب یک سرویس برای برآورده سازی نیاز کاربران می‌باشد.
سرویس‌هایی که کشف شده‌اند به عنوان ورودی به فرایند انتخاب سرویس داده می‌شوند تا بهترین سرویس که نیازهای عملیاتی و کیفی کاربران را برآورده می‌سازد از بین چندین سرویس کشف شده انتخاب شود. تکنیک‌ها و رویکرد‌های مختلفی برای انتخاب بهینه سرویس‌ها در دهه اخیر توسط پژوهشگران ارائه شده است.
2-2-6 ترکیب وب سرویس‌هادر ایجاد و اجرای فرایندهای کسب و کار زمانی که یک سرویس به تنهایی نتواند نیازهای کاربران را برآورده سازد می‌توانیم چندین سرویس را در کنار یک دیگر قرار دهیم و آن‌ها را با هم ترکیب نموده و این‌گونه ارزش افزوده برای وب سرویس‌ها ایجاد نماییم.
برای مثال فرض کنید کنفرانس بین‌المللی در کشور دیگر در حال برگزاری است و شرکت کنندگان قبل از حضور در کنفرانس باید اقدام به رزرو هتل، رزرو بلیط هواپیما یا دیگر وسایل نقلیه، پرداخت هزینه ثبت نام در کنفرانس و غیره کنند. مسئولین برگزار کننده کنفرانس برای راحتی شرکت کنندگان که می‌خواهند در کنفرانس حاضر شوند برنامه ریزی سفر و ثبت نام در کنفرانس را توسط ارائه سرویس‌هایی به صورت خودکار در آورده‌اند.
در این سناریو شخص شرکت کننده وارد وب سایت کنفرانسی که قرار است در آن شرکت کند می‌شود اگر بخواهد تنها در کنفرانس ثبت نام کند با پر کردن فرم و پرداخت مبلغ ثبت نام این کار را انجام می‌دهد و اگر نیز بخواهد می‌تواند هتل و وسیله نقلیه را برای شرکت در کنفرانس از طریق وب سایت کنفرانس رزرو نماید و هزینه آن را پرداخت کند در این سناریو سرویس‌های مجزا و تک کاره با یکدیگر ترکیب شده و سرویس یکپارچه ای را برای حضور نویسندگان مقالات در کنفرانس فراهم آورده و در نهایت یک سرویس ترکیبی ایجاد شده است. زمانی که سرویس دهنده‌ای ترکیبی از سرویس‌ها را ارائه می‌دهد در ابتدا باید یک جریان کاری از فعالیت‌ها را طراحی نماید که هر کدام از این فعالیت‌ها توسط یک وب سرویس قابل انجام می‌باشد. شکل 2-4 جریان‌های کاری از فعالیت‌های سازمان را نشان می‌دهد که شامل 7 وب سرویس WS1، WS2، WS3، ...، WS7 می‌باشد. هر کدام از این وب سرویس‌ها می‌توانند پیاده‌سازی‌های متفاوت اما عملکرد‌های مشابهی داشته باشند بنابراین در ادامه باید اطلاعاتی راجع به پیاده‌سازی‌های تمامی وب سرویس‌های موجود بدست آوریم که این اطلاعات شامل ویژگی‌های کیفی، آدرس اینترنتی، وابستگی‌ها و تضاد‌های سرویس‌ها نسبت به یکدیگر می‌باشند.
شکل 2-4 : ترکیب وب سرویس‌ها در جریان کاریسپس باید از ابزاری برای ترکیب کارای وب سرویس‌ها با در نظر داشتن معیار‌های کیفی کاربران استفاده کنیم که در ادامه راجع به آن صحبت خواهیم کرد.
2-2-6-1 سرویس مرکبسرویس مرکب سرویسی است که از ترکیب چندین سرویس به وجود آمده و این سرویس‌ها با یکدیگر در تعامل می‌باشند. در ترکیبی از وب سرویس‌ها هرکدام از آن‌ها ممکن است در پلتفرم‌ها و محیط‌های مختلفی پیاده سازی شده و در سیستم اطلاعاتی جداگانه ای به کار گرفته شده باشند. در یک سرویس مرکب، برای دست یابی به هدف که همان اجرای فرایند کسب و کار می‌باشد تمامی سرویس‌ها باید با یکدیگر در تعامل باشند ADDIN EN.CITE <EndNote><Cite><Author>Zeng</Author><Year>2008</Year><RecNum>17</RecNum><DisplayText>[18]</DisplayText><record><rec-number>17</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">17</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Zeng, L.</author><author>Ngu, A.H.H.</author><author>Benatallah, B.</author><author>Podorozhny, R.</author><author>Lei, H.</author></authors></contributors><titles><title>Dynamic composition and optimization of Web services</title><secondary-title>Distributed and Parallel Databases</secondary-title></titles><periodical><full-title>Distributed and Parallel Databases</full-title></periodical><pages>45-72</pages><volume>24</volume><number>1</number><dates><year>2008</year></dates><isbn>0926-8782</isbn><urls></urls><language>en</language></record></Cite></EndNote>[18].
یک سرویس مرکب خود ترکیبی از چند سرویس تک کاره و یا سرویس مرکب می‌باشد که بر اساس یک الگو از پیش تعریف شده فراخوانی می‌شوند و یک سرویس پیچیده برای اجرای فرایند کسب و کار را ایجاد می‌کنند ADDIN EN.CITE <EndNote><Cite><Author>Sivasubramanian</Author><Year>2009</Year><RecNum>18</RecNum><DisplayText>[19]</DisplayText><record><rec-number>18</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">18</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Sivasubramanian, SP</author><author>Ilavarasan, E.</author><author>Vadivelou, G.</author></authors></contributors><titles><title>Dynamic web service composition: Challenges and techniques</title><secondary-title>Intelligent Agent &amp; Multi-Agent Sys--s, IAMA 2009</secondary-title></titles><pages>1-8</pages><dates><year>2009</year></dates><publisher>IEEE</publisher><isbn>1424447100</isbn><urls></urls><language>en</language></record></Cite></EndNote>[19].
BPEL2-2-6-2
BPEL یک زبان مبتنی بر XML برای تعریف و اجرای فرایندهای کسب و کار با بهره گیری از جریان‌های کاری مبتنی بر وب سرویس می‌باشد. یک فرایند شامل مجموعه ای از متغیرها و جریان‌های کاری می‌باشد که به عنوان ترکیبی از فعالیت‌ها بیان می‌شود ADDIN EN.CITE <EndNote><Cite><Author>Baresi</Author><Year>2007</Year><RecNum>19</RecNum><DisplayText>[20]</DisplayText><record><rec-number>19</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">19</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Baresi, L.</author><author>Bianculli, D.</author><author>Ghezzi, C.</author><author>Guinea, S.</author><author>Spoletini, P.</author></authors></contributors><titles><title>Validation of web service compositions</title><secondary-title>Software, IET</secondary-title></titles><periodical><full-title>Software, IET</full-title></periodical><pages>219-232</pages><volume>1</volume><number>6</number><dates><year>2007</year></dates><isbn>1751-8806</isbn><urls></urls><language>en</language></record></Cite></EndNote>[20] به عبارت دیگر BPEL زبانی برای ترکیب وب سرویس‌ها می‌باشد که توسط شرکت‌هایی نظیر IBM، Microsoft، SAP و غیره توسعه یافته است.
BPEL دارای چندین گروه از عناصر سازنده می‌باشد که مهم‌ترین آن‌ها عبارتند از :
<Process> : شروع یک فرایند
<PartnerLink> : تعریف سرویس‌های شرکت کننده در یک ترکیب
<invoke>,<invoke>…<receivey> : فراخوانی همگام و غیر همگام
<variable>,<assign>,<copy> : دست‌کاری متغیرهای میانی و نتایج
<Scop>,<FaultHandlers> : اداره کردن خطا
<Sequence>,<flow> : اجرای موازی و ترتیبی
<Switch> :کنترل منطق ADDIN EN.CITE <EndNote><Cite><Author>Milanovic</Author><Year>2004</Year><RecNum>20</RecNum><DisplayText>[21]</DisplayText><record><rec-number>20</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">20</key></foreign-keys><ref-type name="Journal Article">17</ref-type><contributors><authors><author>Milanovic, N.</author><author>Malek, M.</author></authors></contributors><titles><title>Current solutions for web service composition</title><secondary-title>Internet Computing, IEEE</secondary-title></titles><periodical><full-title>Internet Computing, IEEE</full-title></periodical><pages>51-59</pages><volume>8</volume><number>6</number><dates><year>2004</year></dates><isbn>1089-7801</isbn><urls></urls><language>en</language></record></Cite></EndNote>[21]
2-2-6-3 چرخه حیات سرویس مرکبیک سرویس مرکب شامل ترکیبی از سرویس‌های موجود برای دستیابی به قابلیت‌هایی می‌باشد که یک سرویس به تنهایی نمی‌تواند آن را فراهم آورد. چرخه حیات سرویس مرکب یک دید و نگاه یکپارچه ای از مراحل توسعه و اجرای ترکیب سرویس‌ها با یکدیگر را فراهم می‌آورد.
با توجه به حق انتخاب کاربران در توصیف فعالیت‌های گوناگون در فرایند ترکیب سرویس‌ها، مراحل چرخه حیات می‌توانند متفاوت باشند. شکل ۲-5 مراحل چرخه حیات که در ADDIN EN.CITE <EndNote><Cite><Author>Pessoa</Author><Year>2008</Year><RecNum>21</RecNum><DisplayText>[22]</DisplayText><record><rec-number>21</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">21</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Pessoa, R.M.</author><author>Silva, E.</author><author>van Sinderen, M.</author><author>Quartel, D.A.C.</author><author>Pires, L.F.</author></authors></contributors><titles><title>Enterprise interoperability with SOA: a survey of service composition approaches</title><secondary-title>Enterprise Distributed Object Computing Conference Workshops, 2008 12th</secondary-title></titles><pages>238-251</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769537200</isbn><urls></urls><language>en</language></record></Cite></EndNote>[22] برای توسعه و اجرای ترکیب سرویس‌ها ارائه شده است را نشان می‌دهد.

شکل 2-5 : چرخه حیات سرویس مرکب ADDIN EN.CITE <EndNote><Cite><Author>Pessoa</Author><Year>2008</Year><RecNum>21</RecNum><DisplayText>[22]</DisplayText><record><rec-number>21</rec-number><foreign-keys><key app="EN" db-id="vr0v5v0v4rw50eeteflpe05i0fe2rpfs0txz">21</key></foreign-keys><ref-type name="Conference Proceedings">10</ref-type><contributors><authors><author>Pessoa, R.M.</author><author>Silva, E.</author><author>van Sinderen, M.</author><author>Quartel, D.A.C.</author><author>Pires, L.F.</author></authors></contributors><titles><title>Enterprise interoperability with SOA: a survey of service composition approaches</title><secondary-title>Enterprise Distributed Object Computing Conference Workshops, 2008 12th</secondary-title></titles><pages>238-251</pages><dates><year>2008</year></dates><publisher>IEEE</publisher><isbn>0769537200</isbn><urls></urls><language>en</language></record></Cite></EndNote>[22]
تحلیل نیازمندی : اولین مرحله از چرخه حیات سرویس‌های مرکب شناسایی و اولویت بندی کسب و کار و نیازمندی‌های مشتریان می‌باشد. در این مرحله حوزه کار مشخص شده، منابع برنامه ریزی می‌شوند و محیط‌های کسب و کار که سرویس‌های جدید در آن قرار است عمل کنند تعیین می‌شوند. امکان نیاز به سرویس جدید بر مبنای نیازهای مشتریان و تحلیل آن مشخص می‌شود و خروجی این مرحله مستندی از نیازمندی‌های عملکردی و غیر عملکردی سیستم می‌باشد.
طراحی و توصیف : در این مرحله سرویس مرکب، برای برآورده سازی نیازهای کسب و کار مشتریان، که در مرحله قبل شناسایی شدند، طراحی و در ادامه سرویس‌هایی که برای ترکیب نیاز می‌باشند انتخاب و یک مدل فرایندی برای هماهنگی و تعامل وب سرویس‌ها با یکدیگر توصیف می‌شود که شامل گام‌های زیر می‌باشد :
انتخاب سرویس : در ترکیب سرویس‌ها ابتدا باید آنان را انتخاب و رتبه بندی کرد. خروجی الگوریتم انتخاب و رتبه بندی لیستی از سرویس‌ها می‌باشد که این سرویس‌ها نیازهای عملکردی و غیر عملکردی کاربران را بر اساس معیارهای کاربر برآورده می‌سازد.
ایجاد مدل فرآیندی : در ایجاد ترکیبی از سرویس‌ها باید بتوانیم تعیین کنیم که چه سرویس‌هایی، در چه زمانی و توسط چه کسانی اجرا شوند و اجزای آن چه وابستگی با هم داشته باشند. در نتیجه خروجی این مرحله این است که چگونه بین سرویس‌هایی که برای برآورده سازی نیازهای کاربران کشف و انتخاب شده‌اند هماهنگی ایجاد کنیم و این امر می‌تواند توسط روش‌های دستی، نیمه خودکار و خودکار صورت گیرد.
تایید و ارزیابی مدل فرایندی : ممکن است که سرویس‌ها قابلیت و کارکردهای مشابه ای داشته باشند و این احتمال وجود دارد که حالت‌های مختلفی از ترکیب سرویس‌ها برای برآورده سازی نیازهای کاربر به وجود آید بنابراین سرویس مرکب باید مورد ارزیابی قرار گرفته و سرویسی انتخاب شود که هم نیازهای عملیاتی و هم نیازهای غیرعملیاتی کاربران را برآورده سازد. یکی از راه های رایج برای ارزیابی استفاده از یک تابع ارزیابی و رتبه بندی می‌باشد که در آن کاربران برای هر کدام از معیارهای کیفی وزنی را در نظر می‌گیرند و این‌گونه ترکیب‌های مختلف رتبه بندی می‌شوند. همچنین باید اعتبارسنجی از صحت عملکرد سرویس مرکب و تعامل وب سرویس‌ها با یکدیگر در یک ترکیب صورت پذیرد تا در زمان اجرای سرویس مرکب ایجاد شده بن بستی رخ ندهد.
تحقق یافتن : در این مرحله تمرکز بر جزئیات فنی پیاده سازی سرویس می‌باشد. در این مرحله سرویس‌هایی که در مراحل قبل شناسایی و طراحی شده‌اند تولید و تست می‌شوند و پیاده سازی‌های مختلف از سرویس‌ها با زبان‌های برنامه نویسی مختلفی نوشته می‌شوند.
استقرار یافتن : در این مرحله مشکلات نصب، پیکربندی و مدیریت سرویس‌ها مورد بررسی قرار گرفته و نمونه سرویس در محیط اجرای سرویس نشان داده می‌شود.
انتشار یافتن : در این مرحله اطلاعات توصیفی سرویس‌ها انتشار می‌یابد. معمولاً این اطلاعات در یک سند توصیف سرویس ارائه می‌شود و سرویس‌ها می‌توانند توسط کاربران بالقوه شناسایی شوند. مستند توصیف سرویس شامل موارد زیر می‌باشد: سرویس چه کاری را انجام می‌دهد، کجا می‌توان آن را یافت و چگونه می‌توان آن را فراخوانی کرد.
کشف کردن : در این مرحله مشتریان در مستندات توصیف سرویس که در مرحله قبل مشخص شده و در رجیستری سرویس انتشار یافته‌اند جستجو کرده و سرویس‌های مورد نیاز خود را می‌یابند.
انقیاد سرویس : یک سرویس ممکن است پیاده سازی‌های متنوعی داشته باشد و هر پیاده سازی هم استقرارهای متفاوتی داشته باشد در این مرحله نشان داده می‌شود که سرویس نهایی چگونه می‌تواند کشف و نمونه گزاری شود. مرحله انقیاد هم در زمان طراحی و هم در زمان اجرا می‌تواند انجام شود همچنین می‌تواند به صورت پویا و یا ایستا باشد.

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *