۲-۳-۱ چارچوب Boumhamdi و Jarir [29]
معماری منعطفی توسط Boumhamdi و Jarir برای ترکیب پویای وب سرویسها در زمان اجرا که بر اساس نیازمندیهای کاربر و سرویسهای در دسترس میباشد ارائه شده است. در این معماری کاربران میتوانند بر فرایند ترکیب سرویسها نظارت و تعامل داشته باشند و اگر در زمان ترکیب سرویسها خطایی رخ دهد میتواند برای حل مشکل ایجاد شده، طرح جدیدی را برای ترکیب سرویسها ارائه دهد.
شکل ۲-۹ : فرایند کلی چارچوب Boumhamdi و Jarir
این معماری از ۵ مؤلفه مجزا تشکیل شده است:
Query Analyser: برای آنالیز و شناخت نیازهای درخواست کننده سرویس، که نیازهای درخواست کننده را دریافت کرده و وب سرویسهایی را برای برآورده سازی نیازها پیشنهاد میدهد.
Discovery Component: که به منظور کشف سرویسهای انتشار یافته در UDDI مورد استفاده قرار میگیرد.
Constraints Manager Component: نیز مسئول نظارت بر وجود منابع در زمان اجرا و تشخیص بروز خطا در ترکیب سرویسها میباشد.
Selection Manager: هدف از این مؤلفه تولید طرحهای اجرایی در ترکیب سرویسها از بین سرویسهای جستجو شده در UDDI میباشد.
Orchestrator: برای دستیابی به یک طرح اجرایی به زبان BPEL در فرایند ترکیب سرویسها
۲-۳-۲ چارچوب DynamiCoS [30]
چارچوب DynamiCoS[35] یک مکانیزم خودکار برای ترکیب سرویسها در زمان اجرا میباشد. این مکانیزم تمامی مراحل چرخه حیات ترکیب سرویسها از کشف خودکار سرویسها، انتخاب و ترکیب آنها را پشتیبانی میکند. DynamiCoS شامل ماژولهای زیر میباشد:
ایجاد سرویس: یک سرویس جدید در ابتدا توسط فراهم آورنده آن در خارج از چارچوب DynamiCoS ایجاد میشود هرچند سرویس ایجاد شده برای انطباق با چارچوب DynamiCoS باید ورودیها، خروجیها، پیش شرطها، اثرات، هدف و معیارهای غیرعملیاتی را در توصیف خود شامل باشد.
انتشار سرویس: DynamiCoS برای پشتیبانی از انتشار توصیفات سرویسها که ممکن است به زبانهای مختلفی باشند از دو مکانیزم استفاده میکند. اولی استفاده از یک مترجم برای پشتیبانی از تمامی زبانهای توصیف سرویس است و دومی استخراج اطلاعات سرویس که در رجیستری سرویسها به ثبت رسیده است.
درخواست سرویس: واسط کاربری تعریف شده است که درخواست کننده سرویس میتواند در آن نیازهایی را که انتظار دارد وب سرویس انتخابی برای او فراهم آورد شامل هدف، خروجی، نیازهای غیرعملیاتی و غیره، را درخواست دهد. همچنین تعداد پارامترهای ورودی در درخواست سرویس بسته به تجربیات کاربر دارد ممکن است که کاربری از تمامی پارامترها استفاده نماید و کاربری دیگر تنها یک درخواست ساده ایجاد نماید.
کشف سرویس: در ابتدا تعدادی از سرویسهای نامزد قبل از ترکیب سرویس توسط این ماژول کشف میشوند. کشف سرویس بر مبنای درخواست و نیازهای کاربر صورت میگیرد. کشف سرویس شامل پرس جویی از تمامی سرویسهای موجود در رجیستری که با نیازهای کاربر هم خوانی دارد میباشد.
ترکیب سرویس: برای انجام ترکیب سرویس DynamiCoS در ابتدا مجموعه ای از سرویسها کشف شده را پردازش کرده و آنها را در ماتریس ارتباط علتی[۳۶] قرار میدهد CLM تمامی حالات ممکن از ارتباطات بین سرویسهای کشف شده را در خود ذخیره میکند.
شکل ۲-۱۰ : فرایند کلی چارچوب DynamiCoS [30]
یا کمک ماتریس CLM الگوریتم ترکیب میتواند سرویسها را به گونه ای با یکدیگر ترکیب نماید که تمامی نیازهای درخواست کننده سرویس تأمین شود.
۲-۳-۳ دیدگاه Chan و Lyu [31]
در این دیدگاه الگوریتمی برای ترکیب پویای سرویسها ارائه شده است و صحت عملکرد الگوریتم نیز توسط پتری نت اثبات میشود. مدل ترکیب سرویسهای ارائه شده در این مقاله بر مبنای دو استاندارد زبانهای وب سرویس WSDL[37] و WSCI[38] ارائه شده است. (WSDL زبان و استانداردی برای تشریح یک سرویس است و تعامل و ارتباط وب سرویسها با سرویسهای دیگر توسط WSCI بیان میشوند) رویه ترکیب سرویسها به شرح زیر میباشد:
در ابتدا الگوریتم ویژگیها و توصیفات سرویس را از UDDI دریافت و سپس توسط WSCI پیامها را در بین وب سرویسها رد و بدل میکند در ادامه از طریق WSDL تمامی ورودیها و خروجیهای هر یک از توابع و اجزای وب سرویس را بررسی میکند و از طریق WSCI تصمیم میگیرد که اجزای مختلف سرویسها چگونه با یکدیگر تعامل برقرار کنند و در نهایت با اطلاعتی که از رویه ترکیب وب سرویسها به دست آمد، عمل ترکیب صورت میگیرد.
در این الگوریتم سعی شده است درختی برای ترکیب سرویسها ایجاد نماید که از یک رویکرد پایین به بالا برای ترکیب استفاده میکند این روش تنها برای سرویسهای مبتنی بر SOAP ارائه شده است و ترکیب انواع مختلف از سرویسهای وب را پشتیبانی نمیکند.
۲-۳-۴ دیدگاه Yang و Chun-Hung [32]
رویکرد منعطفی توسط Yang و Chun-Hung برای ترکیب سرویسها مبتنی بر الگوریتم ژنتیک ارائه شده است که میتواند ترکیب وب سرویسها را بر مبنای نیازهای کیفی و عملیاتی کاربران انجام دهد. در رویکرد ارائه شده برای ترکیب جریانهای کاری چندین ساختار ترکیب نظیر ترتیبی، شرطی و موازی را در نظر میگیرد. روال کار در رویکرد ارائه شده بدین صورت میباشد که کاربران در ابتدا نیازهای خود را در قالب پارامترهایی به الگوریتم ارسال کرده و در ادامه الگوریتم مناسبترین ترکیب برای برآورده سازی نیازهای کاربران را در میان سرویسهای موجود در UDDI مییابد.
۲-۳-۵ چارچوب METEOR [33]
پروژه [۳۹]METEOR در آزمایشگاه LSDIS[40] در دانشگاه Georgia به انجام رسیده است و بیشتر تمرکز آن بر تکنیکهای مدیریت جریانهای کاری در مقیاس وسیع میباشد. پروژه فوق برای یکپارچه سازی و مدیریت جریانهای کاری در وب سرویسهای معنایی METEOR_S نامیده میشود. این رویکرد مفاهیم معنایی را به استانداردهای موجود نظیر WSDL افزوده است و یافتن سرویسها برای ترکیب با یکدیگر توسط یک موتور جستجو در مخزن سرویسها(UDDI) صورت میگیرد. الگوریتم ارائه شده برای انتخاب سرویسها در این رویکرد در ۳ گام توسعه داده شده است که در آن کاربران نیازمندیهای خود را با استفاده از مفاهیم هستی شناسی وارد میکنند.
در گام اول الگوریتم نیازهای عملیاتی کاربران را با سرویسهای ثبت شده در WSDL تطبیق میدهد.
در گام دوم مجموعه نتایجی که از گام اول بدست آمده است با توجه به شباهت معنایی بین ورودی و خروجی سرویسهای مورد انتظار کاربر با سرویسهای یافته شده در گام ۱ رتبه بندی میشوند.
در گام ۳ مجدداً سرویسها بر اساس پیش شرطها و تأثیراتی که بر یک دیگر میگزارند رتبه بندی میشوند.
METEOR_S دو نوع از ترکیب سرویسها شامل ترکیب استاتیک (ترکیب سرویس در زمان طراحی) و ترکیب پویا (ترکیب سرویس در زمان اجرا) را پشتیبانی میکند.
۲-۳-۶ چارچوب SODIUM [34]
[۴۱]SODIUM پروژه بینالمللی است برای مقابله با چالشهای پیش روی یکپارچه سازی فرایندهای کسب و کار که اکثر سازمانها درگیر آن هستند. در این پروژه یک مدل سرویس عام توسعه داده شده است که شامل مفاهیم رایج سرویسهای ناهمگون از نقطه نظرات گوناگون میباشد. SODIUM یک رویکرد تدریجی و مدل رانه برای ترکیب سرویسها ارائه داده است که شامل ۴ گام زیر است:
گام ۱: کاربران در ابتدا جزئیات فعالیتها را در سطح انتزاعی تعریف میکنند.
گام ۲: کاربران از توصیفات انتزاعی برای تولید پرس جوها در کشف سرویسها استفاده میکنند.
گام ۳: سرویسهای کشف شده، در تمامی فعالیتهایی که در فرایندهای انتزاعی وجود دارند مورد استفاده قرار میگیرند و بدین گونه آن را به یک توصیف از فرایند واقعی تبدیل میکند و در ادامه هم توصیف انتزاعی و هم توصیف واقعی در ترکیب سرویس ذخیره میشوند.
گام ۴: در نهایت توصیف از فرایند واقعی به یک توصیف قابل اجرا و مستنداتی در مورد سرویس مرکب ایجاد شده، تبدیل میشود.
SODIUM به تنهایی قادر به برآورده سازی نیازهای کیفی کاربران (QoS) نمیباشد اما میتواند از معیارهای کیفیت سرویس OMG برای برآورده سازی نیازهای کیفی کاربران استفاده نماید.
۲-۳-۷ دیدگاه Yau و Yin [35]
دانلود کامل پایان نامه در سایت pifo.ir موجود است. |