شناسایی و طبقه بندی ، تهیه و تحویل، و نظارت و ردیابی سرویس ها.
علاوه بر موارد فوق، قواعد معماری دقیقی برای طراحی و تعریف سرویس ها پیشنهاد شده است که بر رفتار طبیعی سیستم و سبک طراحی آن تاثیر می گذارند.[۲۳]اصول زیر برای طراحی معماری سرویس گرای کارآمد پیشنهاد شده است :

قرارداد سرویس استاندارد : سرویس های درون یک مخزن سرویس از استانداردهای طراحی قرارداد یکسانی پیروی می کنند. این قرارداد یک توافقنامه ارتباطی است که بر اساس یک یا چند سند توصیف سرویس تعیین می شود.
اتصال سست سرویس ها : قراردادهای سرویس اتصال ضعیفی میان نیازمندی های مصرف کننده ها اعمال می کنند و خود از محیط پیرامونشان جدا هستند .
تجرید سرویس : قرارداد های سرویس فقط اطلاعات حیاتی را شامل می شوند و اطلاعات در مورد سرویس به آنچه در قراردادهای سرویس منتشر می شود محدود است .
قابلیت استفاده مجدد سرویس : سرویس ها فقط منطق کاری را نمایش می دهند و می توانند به عنوان منابع سازمانی قابل استفاده مجدد تلقی شوند .
بسته بندی سرویس : دست یابی به کارکرد سرویس از طریق یک واسط خوش تعریف امکان پذیر است . در واقع کاربرد سرویس از دید کاربر به صورت جعبه سیاه است .
خودمختاری سرویس : سرویس ها بر محیط زمان اجرای خود سطح کنترل بالایی دارند .
قابلیت شناسایی سرویس ها : فراداده های گویایی به سرویس ها الحاق می شود که به شناسایی و تفسیر آنها کمک می کند.
قابلیت ترکیب سرویس : سرویس ها عناصر موثری برای ترکیب هستند، بدون توجه به اندازه و پیچیدگی ترکیب مورد نیاز.
معماری سرویس گرا و راه حل های مبتنی بر وب سرویس از دو نقش کلیدی پشتیبانی می کنند : یک درخواست کننده سرویس (مشتری) و یک تولید کننده سرویس که از طریق درخواست های سرویس با یکدیگر تعامل دارند. در نتیجه نقش ، نوع شرکت کننده در معماری سرویس گرا را مشخص می کند[۲۴]. میان درخواست کننده و تولید کننده یک رابطه اتصال ضعیف وجود دارد ،که به طور خاص در اینترنت ، از اهمیت بالایی برخوردار است زیرا دو طرف ممکن است در سازمان های متفاوتی باشند .
سرویس های معماری سرویس گرا برای درخواست کننده قابل رویت هستند اما ، مولفه های درونی آنها چنین نیستند. درخواست کننده سرویس تا زمانی که کارکردی مورد نیاز او برآورده می شود نیاز ندارد از جزئیات پیاده سازی سرویس مطلع باشد. در مقابل، تولید کننده سرویس به نحوه طراحی مولفه ها ، مدیریت و دسترسی آنها اهمیت می دهد .
تولیدکننده های سرویس ، سرویس ها را در در قالب استاندارد تعریف و توصیف کرده سپس آنها را در مخازن سرویس، همراه با اطلاعاتی در مورد جزئیات فنی و نحوه دسترسی به سرویس منتشر می کنند . توصیف سرویس ها معمولاً در قالب فایل های زبان توصیف سرویس های وب (WSDL^[27]) صورت می گیرد. هر فایل WSDL شامل اطلاعاتی در مورد نوع متغیر های ، عملیات ، واسط ، نقاط و زمان اتصال سرویس می شود. درخواست کننده سرویس از روی اطلاعات موجود در مخازن ، سرویس مورد نیاز خود را پیدا می کند. سپس با بهره گرفتن از اطلاعاتی که تولید کننده فراهم کرده است اتصال خود با تولید کننده را برقرار کرده و از سرویس استفاده می کنند . نمای این معماری در شکل ۲-۴ نمایش داده شده است .
شکل ۲٫۷مدل معماری وب سرویس] ۲۶[
در ادامه با توجه به موضوع این تحقیق به معرفی روش های کشف سرویس پرداخته می شود .
۲٫۶٫۱ کشف سرویس
یکی از مزایای معماری سرویس گرا فراهم کردن بستری برای استفاده از سرویس های تولید شده در خارج از سازمان است که سبب صرفه جویی در هزینه و سرعت بخشیدن به فرایند توسعه سیستم می شود[۲۵].از این رو به ساز وکارها و روش هایی نیاز است تا یک سازمان را در شناسایی سرویس های مورد نیاز خود کمک کنند. موضوع کشف سرویس در همین راستا مطرح می شود و رابطه نزدیکی با روش های انتشار سرویس و بازیابی اطلاعات دارد .
کشف سرویس عمل تطبیق نیازهای یک مشتری با اطلاعات ارائه شده در توصیف سرویس توسط ارائه دهندگان سرویس است.
درخواست کننده سرویس می تواند توصیف سرویس را در زمان طراحی یا زمان اجرا از مخازن توصیف سرویس ، مانند^[۲۸] UDDI، بدست آورد[۲۶]. کشف سرویس در اکثر مواقع در ادامه شناسایی سرویس انجام می شود . در شناسایی سرویس با تحلیل نیازمندی های سیستم ، تشخیص داده می شود که به چه سرویس هایی نیاز است . در مرحله بعد یا این سرویس ها تولید می شوند و یا با بهره گرفتن از روش های کشف سرویس، سرویس های متناظر با سرویس های شناسایی شده کشف می شوند .
گسترش معماری سرویس گرا و افزایش تعداد تولید کننده های سرویس های وب سبب شده است نیاز به روش هایی جدید برای توصیف و کشف سرویس ها احساس شود ، به خصوص در مورد همکاری های بین سازمانی. از چالش های مطرح در زمینه کشف سرویس می توان به تفاوت در نحوه توصیف سرویس ها توسط سازندگان سرویس ، مخازن نگهداری سرویس ها و زبان های توصیف سرویس متفاوت اشاره کرد[۲۸] . روش های متفاوتی برای کشف سرویس معرفی شده اند که هر کدام سعی در رفع این چالشها دارند اما در میزان اهمیتی که به هر یک از مسائل نام برده می دهند، متفاوت می باشند. در ادامه این روش ها به صورت مختصر معرفی می شوند.
۲٫۶٫۲ روش های کشف سرویس
هدف کشف سرویس تسهیل دسترسی درخواست کنندگان به توصیف سرویس ها است . برای این منظور روش های متفاوتی ارائه شده اند که تلاش می کنند دسترسی آسان با دقتی بالا به سرویس ها را برای درخواست کنندگان فراهم کنند. این روش ها عمل تطبیق بین سرویس درخواستی و سرویس های موجود را بر روی توصیفات سرویس ها که در قالب فایل های WSDL آمده است انجام می دهند . روش های کشف سرویس را می توان به دو دسته کلی روش های کارکردی و روش های غیر کارکردی تقسیم کرد. در ادامه در مورد هر دسته از این روش ها توضیح مختصری داده می شود[۲۸] .
روش های کشف سرویس مبتنی بر توصیف کارکردی
در این دسته ، روش ها توصیفات عملکردی سرویس ها را با نیاز های عملکردی درخواستی تطبیق می دهند . توصیفات عملکردی یک سرویس را مشخص می کند . این روش ها به سه دسته تطابق لغوی ، تطابق معنایی و تطابق رفتاری تقسیم می شوند[۲۸] .
روش های تطابق لغوی بر اساس کلمات کلیدی ، واسط های سرویس و طبقه بندی ها عمل تطبیق را انجام می دهند . در این روش ها یک پرس و جو شامل موارد نامبرده شده در بالا ایجاد می شود و سپس با بهره گرفتن از روش های تطابق متن نزدیک ترین سرویس شناسایی می شود . یکی از مشکلات این روش ها این است که کلمات ، واژگان و دسته بندی هایی که دو طرف تولیدکننده و درخواست کننده به کار می برند ممکن است متفاوت باشد و سبب شود که تمام سرویس ها مرتبط شناسایی نشوند. همچنین در روش هایی که تطابق بر اساس واسط های سرویس انجام می شود لازم است که تولید کننده سرویس اسامی معنا داری برای متغیرهای ورودی و خروجی تعیین کنند که این امر همیشه انجام نمی شود.
روش های تطابق رفتاری عمل تطابق را بر اساس فرایند رفتاری و عملکردی سرویس انجام می دهند و نه توصیف سرویس . در این روش ها از ماشین حالت برای مدل سازی رفتار سرویس استفاده می شود و انتشار و جستجو سرویس نیز با بهره گرفتن از ماشین های حالت صورت می گیرد . از مشکلات این روش ها می توان به دشواری مدل سازی سرویس های بزرگ و پیچیده اشاره کرد. همچنین تولید کننده و درخواست کننده سرویس باید از دانش خوبی در مورد ماشین های حالت و حوزه عمومی رفتار سرویس داشته باشند[۲۸].
در روش های تطابق معنایی ، روابط و مفاهیم معنایی توصیف سرویس ها نیز در فرایند تطبیق لحاظ می شود . این روش ها بسته به نحوه کشف روایط معنایی به چهار دسته روش های بازیابی اطلاعات ، روش های مبتنی بر هستان شناسی و روش های مبتنی بر محتوا ، تقسیم می شوند .
روش های مبتنی بر بازیابی اطلاعات از موتورهای جستجو و خزنده های وب برای پیدا کردن فایل های WSDL در اینترنت استفاده می کنند . سپس روش های بازیابی اطلاعات را برای فرایند تطبیق به کار می برند . تشابه معنایی بین توصیف و درخواست سرویس با بهره گرفتن از پایگاه های داده ای لغوی ، مانندWordNet، انجام می شود. ایراد این روش در این است که نتایج فرایند جستجو ممکن است دقت ۱۰۰ درصد نداشته باشند[۲۸] .
در روش هایی که از هستان شناسی در فرایند تطبیق بهره می برند هستان شناسی حوزه نقش عمده ای ایفا می کند . در فرایند تطبیق روابط معنایی میان توصیف و درخواست سرویس با توجه به هستان شناسی معین می شود و سپس عمل تطبیق صورت می گیرد. یکی از مشکلات این روش هزینه بسیار بالای ایجاد و نگهداری یک هستان شناسی است . علاوه بر این تعریف هستان شناسی برای تمامی حوزه ها عملاً میسر نیست . از دیدگاه درخواست کننده نیز درک مفاهیم و روابط درون هستان شناسی ممکن است دشوار باشد .
فرایند تطبیق در روش های مبتنی بر محتوا با توجه به شرایط محتوا معین شده در زبان پرس و جو محتوا و اطلاعات عملیات محتوا که در پرس و جو درخواست کننده مشخص شده اند انجام می گیرد . البته نیاز به تعریف یک زبان قراردادی برای نمایش عملیات و شرایط محتوا از معایب این روش است . همچنین برای بیان شرایط و عملیات محتوا در این زبان ، درخواست کننده باید دانش خوبی از حوزه سرویس داشته باشد .
روش های کشف سرویس مبتنی بر توصیف غیر کارکردی
این دسته از روش های کشف سرویس بر اهمیت ویژگی های غیرعملکردی از دیدگاه درخواست کننده تاکید دارد. عامل اصلی در این روش ها سطح کیفیت خدمات (QoS^[29]) ارائه شده توسط تولید کنندگان است . برای این منظور مدل توسعه داده شده UDDI نیز پیشنهاد شده است تا از QoS ها ، ویژگی­های قابلیت استفاده از پرکاربردترین ویژگی ها در زمینه پیدا کردن سرویس های مورد نیاز درخواست کنندگان را شناسایی کند . بر این مبنا روشی ارائه شده است که انتظارات و ترجیحات درخواست کنندگان را در شناسایی سرویس مناسب دخالت می دهد . در اغلب این روش ها از محاسبات فازی برای رسیدن به توازن میان ویژگی های مختلف، در حالتی که سرویسی که تطابق کامل با نیازهای درخواست کننده داشته باشد پیدا نشود ، استفاده می شود[۲۹].
۲٫۶٫۳ معماری های کشف سرویس
معماری های متفاوتی برای کشف سرویس ارائه شده اند که بیشتر به محل مخازن سرویس و نحوه دسترسی به آنها می پردازند . معماری های پیشنهاد شده را می توان به دو دسته کلی معماری های متمرکز و معماری های توزیع شده تقسیم کرد.
در معماری های متمرکز ، سرویس ها در یک مخزن مرکزی مانند UDDI یا پورتال وب نگهداری می شوند . معماری هایی که از UDDI به عنوان مخزن استفاده می کنند خود به دو دسته معماری های مرکب و معماری های مبتنی بر واسطه تقسیم می شوند . از مزایای معماری متمرکز این است که دسترسی سریع به تمام توصیفات سرویس ها را فراهم می کند . اما در مقابل این روش با چالش هایی نیز مواجه است از جمله اینکه خود مخزن مرکزی به یک گلوگاه تبدیل می شود زیرا دسترسی به سرویس ها فقط از طریق آن انجام می شود . مسئله دیگر در ارتباط با این معماری این است که ثبت سرویس ها بر عهده خود تولیدکننده ها است و در صورتی که این کار انجام نشود مخازن سرویس قدیمی شده و سرویس های تازه را شامل نمی شوند .
روش هایی که معماری توزیع شده را پیشنهاد می کنند از قابلیت انعطاف پذیری و توسعه پذیری بهره می برند . در چنین معماری هایی سرویس ها در وب سایت تولید کننده نگهداری می شوند و از ساز و کارهای متفاوتی برای پیدا کردن سرویس ها استفاده می شود. روش هایی که از معماری توزیع شده استفاده می کنند را می توان بر اساس نحوه دست یابی به سرویس ها به سه دسته معماری های مبتنی بر اینترنت ، معماری های مبتنی بر عامل ها و معماری های همتا به همتا تقسیم کرد[۳۰] .
۲٫۷٫جمع­بندی
با توجه به مطالب مطرح شده واضح است که سیستم­های اجرایی تولید توزیع­شده می­توانند مزایای فراوانی را برای سازمان­ها فراهم­آورند، اما در مراحل مقدماتی خود نیاز به تحقیقات و بررسی­های زیادی دارند. اولین گام می­توانند ارائه چارچوبی راهبردی باشد که تمامی فعالیت­های موجود در سیستم­های اجرایی تولید را شامل شود. این چارچوب بایستی به نحوی باشد که راه­حلی برای چالش­های مطرح­شده در ارتباط با سیستم­های اجرایی تولید توزیع­شده باشد.
یکی از مهمترین فعالیت­ها در سیستم­های اجرایی تولید توزیع­شده شناسایی سرویس­هایی است که بتواند به عنوان دارایی پایه در این سیستم در نظر گرفته شود. همانطور که در بخش سیستم­های اجرایی تولید توزیع­شده عنوان شد بیشتر کارهای مرتبط تمرکز بر معماری هولونی و چند­عاملی داشته­است. این تحقیق به دلیل تمرکز برروی کشف سرویس و با توجه به کمبود روش­های سرویس­گرا، سیستم­های اجرایی تولید، سعی در رفع چالش­های همروندی، یکپارچگی و قابلیت کار متقابل اجزای سیستم را دارد. دلیلی که از سرویس­ها در این روش استفاده شده است، قابلیت استفاده مجدد بالای آن­ها است. با پیدا کردن سرویس­های مورد نیاز این سیستم­ها، می­توان طراحی و شناسایی سرویس را به نیازمندی­های پوشش داده نشده، محدود و در نتیجه در هزینه و زمان صرفه­جویی کرد.

فصل سوم- مبانی راهکار پیشنهادی

۳٫۱ مقدمه

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

۳٫۲ نگاهی کلی

هدف این تحقیق ارائه چهارچوبی سرویس گرا برای سیستم های اجرایی تولید و مبتنی بر مدل محاسبات ابری است . علت استفاده از سرویس گرایی در ارائه این چهارچوب این است که بتوان با تحلیل ماژولهای مختلف این سیستم ها سرویس های مورد نیاز را استخراج نمود . البته با توجه به ماهیت این سیستم ها و سیستم های امکاناتی ، نمی توان ادعا کرد که تمامی سرویس های چهارچوب شناسایی شده اند ولی سرویس های استخراج شده قابل پاسخگویی برای مهمترین بخش های سیستم هستند. بسیاری از این سرویس ها قابلیت ترکیب با کامپوننت های فعلی سیستم را دارند و بسیاری از آنها بایستی جایگزین راه حل های فعلی شوند.
از این رودر این چارچوب ، سرویس های شناخته شده در حقیقت جزء سرویس های اصلی این سیستم ها هستند و در مراحل دیگر چرخه این سیستم ها ، به عبارتی در فاز توسعه و پیاده سازی نیز نیاز به کشف سرویس وجود دارد که زیر مجموعه این کار قرار نمی گیرد. این سرویس ها منجر به افزایش استفاده مجدد و در نتیجه کاهش هزینه ها حین اجرا خواهد شد.
تحقیقات صورت گرفته نشان می دهد که متودولوژی های متعددی برای تحلیل سرویس گرا ایجاد و به کار گرفته می شود ، رویکردی که ما برای تحلیل این سیستم ها استفاده می کنیم بایستی ویژگی آن را داشته باشد تا سیستم های توزیع شده و بسیار بزرگ را تحت پوشش قرار دهد. در بین متودولوژی های موجود، متودولوژی SOMA (Service Oriented Modelling and Architecture ( کاندید مناسبی برای این کار می باشد.
با توجه به مطالعات انجام شده بر روی دامنه موجود، تمرکز برای کشف و شناسایی سرویس ها و تعیین مشخصه سرویس های مهم این سیستم با بهره گرفتن از متودولوژی پیشنهاد شده می باشد.
- ابتدا با بررسی سیستم های اجرایی تولید موجود و شناسایی مشکلات و بسط این مشکلات با در نظر گرفتن محیط توزیع شده جدید ، به شرح مسائل مختلف که برای رفع آنها نیاز به ارائه مدل سرویس گرا داریم می پردازیم.
- با در نظر گرفتن شرح مسائل مختلف برای هر کدام بنا بر متودولوژی در نظر گرفته SOMA و الگوی راه حل پیشنهاد می دهیم.