گام ۱: کاربران در ابتدا جزئیات فعالیت‌ها را در سطح انتزاعی تعریف می‌کنند.
گام ۲: کاربران از توصیفات انتزاعی برای تولید پرس جوها در کشف سرویس‌ها استفاده می‌کنند.

گام ۳: سرویس‌های کشف شده، در تمامی فعالیت‌هایی که در فرایندهای انتزاعی وجود دارند مورد استفاده قرار می‌گیرند و بدین گونه آن را به یک توصیف از فرایند واقعی تبدیل می‌کند و در ادامه هم توصیف انتزاعی و هم توصیف واقعی در ترکیب سرویس ذخیره می‌شوند.
گام ۴: در نهایت توصیف از فرایند واقعی به یک توصیف قابل اجرا و مستنداتی در مورد سرویس مرکب ایجاد شده، تبدیل می‌شود.
SODIUM به تنهایی قادر به برآورده سازی نیازهای کیفی کاربران (QoS) نمی‌باشد اما می‌تواند از معیارهای کیفیت سرویس OMG برای برآورده سازی نیازهای کیفی کاربران استفاده نماید.
۲-۳-۷ دیدگاه Yau و Yin [35]
توسط Yau و Yin رویکردی برای انتخاب و رتبه‌بندی وب سرویس‌ها بر مبنای معیار‌های کیفی ارائه شده است. در این الگوریتم برای تسهیل در رتبه‌بندی و انتخاب سرویس‌ها دایرکتوری سرویسSD^[42] وجود دارد که تمامی اطلاعات مربوط به کیفیت سرویس در آن قرار می‌گیرد و کاربر برای انتخاب سرویس، معیار‌های کیفی مد نظر خود را به SD ارسال می‌کند که این اطلاعات توسط یک رتبه دهنده سرویس SR^[43] رتبه‌بندی می‌شوند.
رویکرد انتخاب و رتبه‌بندی سرویس در شکل ۲-۱۱ نشان داده شده است و گام‌های الگوریتم ارائه شده به صورت زیر می‌باشند :
در ابتدا کاربر یک کران پایین و بالا را برای مجموعه‌ای از معیا‌ر‌های کیفی نظیر قابلیت اطمینان، تأخیر، امنیت، قیمت، شهرت تعیین می‌کند و این معیار‌ها به SD فرستاده می‌شوند.
گام ۲ : در این گام نیاز‌های عملیاتی کاربر با سرویس‌هایی که در SD ثبت شده‌اند تطبیق داده می‌شوند و یک مجموعه سرویس انتخاب و به SR ارسال می‌شود.
گام ۳ : در این گام SR در ابتدا با توجه به نیاز‌های کیفی کاربر برای هر سرویس نمره رضایت‌بخشی را محاسبه می‌کند و با توجه به آن، سرویس‌های مجموعه S را رتبه بندی می‌کند و در صورتی که چند نمره رضایت بخشی یکسان باشند از بین آن‌ها به طور تصادفی یکی را انتخاب می‌کند.
شکل ۲-۱۱ : فرایند کلی رویکرد انتخاب و رتبه بندی سرویس بر مبنای معیارهای کیفی [۳۵]
در رویکرد ارائه داده شده انتخاب وب سرویس‌ها مستقل از دیگر سرویس‌ها در نظر گرفته شده است. بنابراین زمانی که وب سرویس کاندید برای انتخاب با سرویس‌های دیگر وابسته و در ارتباط باشند نمی‌توان انتخاب مناسبی انجام داد.
۲-۳-۹ چارچوب WSSR_Q [36]
در این چارچوب مکانیزم انتخاب و رتبه‌بندی سرویس ارائه شده که مدلی برای توصیف سرویس‌های وب با در نظر داشتن اطلاعات کیفیت سرویس هر یک از وب سرویس‌ها می‌باشد. در ابتدا یک چارچوب کلی برای رتبه‌بندی و انتخاب سرویس‌ها به همراه ویژگی‌های کیفیت سرویس WSSR_Q^[44] ارائه شده است که بر مبنای مدل توصیف سرویس می‌باشد.
سپس الگوریتمی برای انتخاب سرویس که به واسطه آن نیاز های کیفی کاربران برآورده شود و همچنین الگوریتمی برای رتبه بندی سرویس برای محاسبه و نرمال سازی مقادیر کیفی سرویس برای تمامی وب سرویس‌ها ارائه می‌دهد.
سپس مکانیزمی برای بروز رسانی کیفیت ارائه می‌شود که بر اساس بازخورد کاربران مقادیر معیار های کیفی را بروز رسانی می‌کند.
در شکل ۲-۱۲ چارچوب عمومی برای انتخاب و رتبه بندی وب سرویس‌ها با در نظر گرفتن کیفیت سرویس که WSSR-Q نامیده می‌شود نشان داده شده است.
شکل ۲-۱۲ : چارچوبی برای انتخاب و رتبه بندی وب سرویس‌ها با در نظر گرفتن کیفیت سرویس [۳۶]
از معایب این روش این است که از ماتریس کیفیت سرویس برای محاسبه و نرمال سازی ویژگی‌های کیفی استفاده می‌شود همچنین در آن محدودیتی برای ترکیب سرویس‌ها در نظر گرفته نشده است.
۲-۳-۱۰ رویکرد WSMX [37]
در این رویکرد یک مکانیزم انتخاب برای محیط‌های اجرایی وب‌سرویس WSMX^[45] برای برآورده سازی نیاز‌های کاربران ارائه شده است که بهترین وب سرویس برای برآورده سازی نیاز‌های کاربر را بر اساس یک هدف انتزاعی که این هدف بیانگر آن چیزی است که کاربر می‌خواهد) برای مثال خرید یک کتاب( و فیلتر کردن نیاز های کاربر انتخاب می‌کند. از جمله معایب مکانیزم ارائه شده در این مقاله این است که تنها یک معیار کیفی کاربر را در نظر می‌گیرد و از معیار‌های کیفی چندگانه پشتیبانی نمی‌کند.
۲-۳-۱۱ دیدگاه Chaari و Badr و Biennier [38]
در این دیدگاه انتخاب سرویس‌های وب بر مبنای معیار‌های کیفی با بهره گرفتن از یک آرایه ۲ بعدی که به آن ماتریس انتخاب گفته می‌شود صورت می‌پذیرد. سطر‌های ماتریس نمایانگر وب سرویس‌ها و ستون‌ها نشان ‌دهنده معیار‌های کیفیت سرویس می‌باشد. زمانی که
مقدار خانه‌های ماتریس برابر ۱ باشد به این معنی می‌باشد که نیاز‌های کیفیت سرویس کاربر با مقدار انتشار داده شده برای سرویس مطابقت دارد و در غیر این صورت مقدار آن برابر ۰ قرار می‌گیرد.
در ادامه زمانی که سطر‌های ماتریس بیشترین تعداد ۱ را داشته باشد می‌توان نتیجه گرفت که آن سرویس بهترین وب‌ سرویس برای برآورده سازی نیاز‌های کیفیت سرویس کاربر می‌باشد.
از جمله معایب روش ارائه شده در بالا این است که از ماتریس کیفیت سرویس برای محاسبه ویژگی‌های کیفی استفاده می‌کند، در نتیجه زمانی که تعداد معیار های کیفیت سرویس و یا تعداد وب سرویس‌ها افزایش یابد، ماتریس بسیار بزرگ و تعداد محاسبات نیز بیشتر و پیچیده می‌شود بنابراین این روش نمی‌تواند همواره مناسب باشند. همچنین در این روش کاربر نمی‌تواند با وزن گزاری برای هر یک از معیار‌های کیفت سرویس در نظر گرفته شده اولویتی قائل شود.
۲-۳-۱۲ دیدگاه MOGA [39]
الگوریتم ژنتیک چندهدفه MOGA^[46] برای انتخاب بهینه وب سرویس‌ها بر مبنای معیارهای کیفیت سرویس ارائه شده است. در این الگوریتم ابتدا مکانیزمی برای دستیابی به ترکیب‌های شدنی و امکان پذیر وب سرویس‌ها با توجه به محدودیت‌های ترکیب سرویس‌ها (مانند محدودیت وابستگی و تضاد بین سرویس‌های وب) طراحی شده و در ادامه عملگرهای ژنتیک(عملگر انتخاب، تقاطع و جهش) و استراتژی‌هایی برای پراکندگی جمعیت‌های متنوع که این جمعیت‌ها همان ترکیب‌های مختلف از وب سرویس‌ها می‌باشد معرفی شده است. همچنین در آن مکانیزمی برای جلوگیری از قرار گرفتن الگوریتم در بهینگی محلی در نظر گرفته شده است. از جمله معایب روش فوق این است که کاربر نمی‌تواند با وزن گزاری برای هر یک از معیار‌های کیفت سرویس در نظر گرفته شده اولویتی قائل شود.
از جمله معایب روش فوق این است که کاربر نمی‌تواند با وزن گزاری برای هر یک از معیار‌های کیفت سرویس در نظر گرفته شده اولویتی قائل شود.
۲-۳-۱۳ جمع بندی از کارهای مرتبط
انتخاب سرویس مناسب با توجه به نیازهای عملکردی و کیفی کاربران از مهم‌ترین اهداف انتخاب و ترکیب وب سرویس‌ها می‌باشد. در بالا چندین رویکرد و روش موجود، که انتخاب سرویس‌های وب بر مبنای کیفیت سرویس را پیشنهاد داده‌اند مورد بررسی قرار گرفته است. در ادامه تعدادی از معایب و کاستی‌های الگوریتم‌های موجود را مورد بررسی قرار می‌دهیم.
بیشتر الگوریتم‌های ارائه شده کیفیت سرویس‌های وب را در زمان ترکیب محدودیتی ایستا فرض کرده‌اند درحالی‌که ممکن است در حین فرایند ترکیب، وب سرویسی جدیدی اضافه و با وب سرویسی از کار بی افتد و مقادیر معیار های کیفی آن وب سرویس در هر لحظه تغییر کند و این مسئله پویا بودن وب سرویس‌ها و تصادفی بودن کیفیت سرویس را نشان می‌دهد.
در برخی از روش‌های ارائه داده شده انتخاب بهینه سرویس‌ها مستقل از دیگر سرویس‌ها در نظر گرفته شده و در آن محدودیتی برای ترکیب سرویس‌ها در نظر نگرفته‌اند، بنابراین در این‌گونه روش‌ها زمانی که معیار های کیفی سرویس کاندید برای انتخاب با معیار های کیفی سرویس‌های دیگر وابسته و در ارتباط باشند نمی‌توان انتخاب مناسبی انجام داد.
برخی از روش‌های ارائه داده شده از ماتریس کیفیت سرویس برای محاسبه ویژگی‌های کیفی استفاده می‌کنند. پایه و اساس این گونه روش‌ها استفاده از ماتریس‌ها برای محاسبه خواص کیفیت سرویس می‌باشند و زمانی که تعداد معیار های کیفیت سرویس و یا تعداد وب سرویس‌ها افزایش یابد، ماتریس بسیار بزرگ و تعداد محاسبات نیز بیشتر و پیچیده می‌شود بنابراین این‌گونه روش‌ها نمی‌توانند همواره مناسب باشند.
برخی از روش‌های موجود معیار‌های کیفی چندگانه کاربر را پشتیبانی نمی‌کنند. در این‌گونه روش‌ها کاربر می‌تواند تنها یک معیار کیفیت سرویس را برای انتخاب وب ‌سرویس در نظر بگیرد. همچنین در برخی دیگر از روش‌های موجود با اینکه از چندین معیار‌های کیفیت سرویس پشتیبانی می‌کنند اما کاربر نمی‌تواند با وزن گزاری برای هر یک از معیار‌های کیفت سرویس در نظر گرفته شده اولویتی قائل شود.
اما در این پایان نامه رویکردی برای ترکیب پویای وب سرویس‌ها در زمان اجرا ارائه داده شده است این رویکرد از یک الگوریتم فرا ابتکاری استفاده می کند تا با افزایش مقیاس مسئله رویکرد ارائه داده شده بتواند در زمان معقولی ترکیب مناسبی از سرویس‌ها را در اختیار کاربر قرار دهد در رویکرد ارائه داده شده کاربران می‌توانند تعداد نامحدودی معیار کیفیت سرویس را برای انتخاب سرویس مناسب در نظر گیرند و همچنین می توانند با وزن گزاری برای هریک از معیارهای کیفیت سرویس در نظر گرفته شده برای آن معیار اولویت قائل شوند. جزیئات رویکرد ارائه داده شده در فصل سوم این پایان نامه آورذه شده است.
فصل سوم
روش تحقیق
۳-۱ مقدمه
در این بخش رویکردی برای مسئله ترکیب و انتخاب سرویس‌های وب به منظور کمینه نمودن زمان محاسباتی و یافتن ترکیبی بهینه برای برآورده سازی نیازهای کاربران ارائه داده می‌شود رویکرد ارائه شده پویا بوده و هر کاربر ساختار مورد نظر خود را برای سرویس مرکب با توجه به نیازهای کمی و کیفی درخواست می‌دهد. در ادامه نیاز به رویکردی برای یافتن ترک
یب بهینه خواهیم داشت تا بهترین ترکیب برای برآورده سازی نیازهای کاربران را بیابیم. در مسئله ترکیب وب سرویس‌ها اگر فرض شود n وب سرویس برای ترکیب وجود دارد و از هر یک از آن‌ها نیز m پیاده سازی متفاوت داشته باشیم، بنابراین در مسائلی با مقیاس بزرگ با میلیون‌ها حالت مختلف برای ترکیب سرویس‌ها رو به رو خواهیم بود و بررسی تمامی حالات ممکن کار پیچیده و غیرممکنی خواهد بود، حل به روش‌های دقیق برای چنین مسئله در یک زمان معقول غیر ممکن بوده و در نتیجه استفاده از روش‌های فرا مکاشفه‌ای در این موارد مناسب می‌باشند. در ادامه این فصل سه رویکرد فرا مکاشفه‌ای ارائه و با یکدیگر مقایسه می‌شوند.
۳-۲ معماری ارائه داده شده
هدف کلی از انجام این تحقیق ارائه یک رویکرد فرا مکاشفه‌ای برای انتخاب و ترکیب پویای وب سرویس‌ها بر مبنای نیازهای کاربر می‌باشد و جزئیات رویکرد ارائه داده شده به صورت گام به گام در ادامه این فصل خواهد آمد اما قبل از آن در ابتدا یک معماری عمومی برای ترکیب نمودن خودکار وب سرویس‌ها ارائه می‌دهیم. در معماری ارائه داده شده ترکیب وب سرویس‌ها بر اساس نیازهای کیفی و کمی کاربران صورت می‌گیرد بدین صورت که کاربری در ابتدا نیازهای عملیاتی و غیرعملیاتی خود را به یک واسط کاربری داده و بعد از پردازش نیاز‌ها مدل فرآیندی از آن ایجاد می‌شود توسط مکانیزم کشف سرویس، وب سرویس‌های کاندید برای هر فعالیت را مطابق با نیازهای عملیاتی کاربران از مخزن سرویس‌ها انتخاب می‌کنیم سپس توسط یک رویکرد فرا مکاشفه‌‌ای سعی در یافتن بهترین ترکیب سرویس از بین بی‌شمار حالات به وجود آمده می‌کنیم.
در ادامه کار به معرفی معماری ارائه داده شده و مؤلفه‌های آن می‌پردازیم. معماری پیشنهادی برای ترکیب پویای سرویس‌های وب مبتنی بر نیازهای کیفی کاربران در شکل ۳-۱ آمده است. در ادامه هر کدام از بخش‌ها به تفکیک توضیح داده می‌شوند.
شکل ۳-۱ : معماری پیشنهادی برای ترکیب پویای سرویس‌های وب مبتنی بر نیازهای کیفی کاربران
۳-۲-۱ درخواست سرویس
یکی از مشکلاتی که برای کاربران در انتخاب و ترکیب وب سرویس‌ها وجود دارد نحوه بیان نیازهای عملکردی و کیفی آنان می‌باشد. این نیازها شامل ورودی‌ها، خروجی‌ها، وابستگی‌ها و محدودیت‌هایی است که سرویس‌ها نسبت به یکدیگر دارند و اینکه توالی هر یک از فعالیت‌های موجود در ترکیبی از سرویس‌ها چگونه باید باشد. برای پشتیبانی معماری ارائه داده شده از ترکیب پویای سرویس‌های وب، نیازهای عملکردی کاربران به یک زبان استاندارد برای ترکیب سرویس‌ها به نام BPEL تبدیل می‌شود. زبان BPEL برای ترکیب سرویس‌ها مختلف و دستیابی به یک سرویس پیچیده تر به کار می‌رود. این زبان مبتنی بر XML می‌باشد.
در این معماری نیازهای عملکردی و کیفی درخواست کننده سرویس مرکب توسط یک واسط کاربری از آن‌ها دریافت می‌شود و توسط زبان اجرائی فرایند کسب و کار به یک مدل فرایندی در خواهد آمد. اما BPEL تنها قادر به توصیف بخش عملکردی فرایند ترکیب می‌باشد و در بیان خصوصیت‌های کیفی فرایند ترکیب ناتوان است. بنابراین برای برآورده سازی نیاز‌های غیر عملکردی درخواست کننده سرویس که همان معیارهای کیفیت سرویس می‌باشد برای هر یک از معیار‌های کیفیت سرویس توسط کاربر وزنی تعیین می‌شود که این وزن نشان دهنده ضریب اهمیت آن معیار کیفی می‌باشد. هر یک از وزن‌های اختصاص داده شده توسط کاربر در بازه صفر و یک می‌باشد و مجموع ضرایب اختصاص داده شده توسط کاربر نیز برابر یک است.
کاربران بر اساس اهمیت هر یک از معیار‌های کیفی وزن‌هایی را به صورت کیفی در واسط کاربری تعیین می‌کنند و وزن‌های تعیین شده توسط واسط کاربری به صورت کمی در آمده سپس به عنوان ورودی وارد رویکرد ترکیب سرویس‌ها می‌شود.
۳-۲-۲ انتخاب سرویس‌های کاندید
در مخزن سرویس، تعداد فراوانی وب سرویس برای برآورده سازی نیازهای متنوع کاربران وجود دارد و بعد از آنکه یک سرویس جدیدی توسط فراهم آورنده آن در UDDI ثبت شده است مخزن سرویس بروزرسانی شده و آن وب سرویس و مشخصات آن در مخزن سرویس قرار می‌گیرد. زمانی که کاربری درخواستی برای یک سرویس مرکب می‌دهد به جای آنکه رویکرد ارائه داده شده برای ترکیب، تمامی سرویس‌های موجود در مخزن سرویس را جستجو کند در ابتدا تعدادی از سرویس‌ها که مطابق با نیازهای عملکردی درخواست کننده سرویس می‌باشد را به عنوان سرویس کاندید انتخاب می‌کند تا عمل ترکیب وب سرویس‌ها در زمان کمتر و با دقت بالاتری صورت پذیرد.
در این گام مدل فرایندی از درخواست‌های کاربر که در گام قبلی ایجاد شده به عنوان ورودی به مؤلفه انتخاب سرویس‌های کاندید داده می‌شود و بر اساس هر یک از نیازهای انتزاعی کاربر مجموعه سرویس کاندید مناسب با آن نیاز انتزاعی به عنوان خروجی برگردانده می‌شود. برای مثال یک وب سرویس تور مسافرتی را در نظر بگیرید که در آن نیاز به یک سرویس انتزاعی برای رزرو بلیط هواپیما، یک سرویس برای رزرو هتل و همچنین یک سرویس انتزاعی هم برای گشت و گزار در شهر مقصد دارد. برای هرکدام از این سرویس‌های انتزاعی می‌تواند فراهم آورندگان مختلفی وجود داشته باشد که سرویس واقعی مشابه اما با معیارهای کیفی متفاوت را ارائه می‌دهند. بنابراین در فرایند ترکیب سرویس به جای آنکه ما تمامی سرویس‌های انتزاعی موجود در مخزن سرویس را جستجو کنیم می‌تو
انیم در ابتدا سرویس‌های انتزاعی کاندید را بر اساس نیازهای عملیاتی کاربر انتخاب کنیم و در بین آن‌ها مناسب‌ترین حالت برای ترکیب وب سرویس‌ها را بیابیم.
شبه کد مربوط به معماری پیشنهادی در شکل ۳-۲ نشان داده شده است و توضیحات مربوط به هر یک از نمادهای بکار رفته در آن نیز در جدول ۳-۱ آورده شده است.
جدول ۳-۱ : نمادهای بکار رفته در شبه کد و توضیحات مربوط به هر یک از آن‌ها