شکل۳٫۳ قالب ESB
این قالب متشکل از ۵ بخش است :

 

 

برنامه کاربردی : سرویس ها در معماری سرویس گرا با لایه ای از برنامه کاربردی که زیر آن قرار می گیرد نمایش داده می شود : این برنامه های کاربردی شامل برنامه های کاربردی سمت سرور نظیر IBM Web Sphere ، برنامه های کاربردی قدیمی نظیر CICS ، برنامه های کاربردی NET ، و … برنامه های کاربردی بسته بندی شده شامل SAP ، People soft ،Oracle و … است.

اتصالات

ESB قابلیت اتصال را از طریق کاربران JMS و کانال MQ پروتکل وب سرویس ها و … فراهم می آورد .

 

 

باس

جنبه ی باس ESB ، کامپوننت اصلی پیغام رسانی برای سکوی نرم افزاری این قالب است و یکپارچگی را از طریق پارادایم های پیغام دهی نظیر نقطه به نقطه ، درخواست/ پاسخ ، انتشار/ تصدیق فراهم می آورد .
این پیغام ها در مودهای مداوم و غیر مداوم صورت می گیرد . سایر فاکتورهای کلیدی در باس شامل موارد زیر است :

 

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

 

 

این باس بر روی زیرساختار Web Sphere ایجاد می شود .

ویژگی های آن ، امکان این را فراهم می آورد تا دسترسی سریع و کنترل شکست را با WAS5/6 که از کلاسترهای شبکه استفاده می کنند پشتیبانی کند .

یک پایگاه داده رابطه ای ایجاد شده است تا مکانیزم تداوم و سازگاری پیغام ها را حفظ کند .

هر سرور برنامه کاربردی می تواند به صورت دلخواهانه از یک و یا چند موتور پیغام رسانی میزبانی کند .

 

میانجی

یک چارچوب میانجی باعث ایجاد انعطاف پذیری و انتزاع برای ESB است که از یک چارچوب مبتنی بر پالیسی برای تعریف میانجی استفاده می کند .
قابلیت های لایه میانجی عبارتست از :

 

 

مجازی سازی : نقاط پایانی سرویس ها مجازی شده اند . این کار امکان این را فراهم می آورد تا سرویس ها خودشان مکانشان را بدون تاثیر گذاشتن بر مشتری ها تغییر دهند .

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

نظارت و مدیریت بر کیفیت سرویس : چارچوب میانجی امکان نظارت خودکار را فراهم می آورد .

انتخاب و مسیریابی پویا : میانجی باعث می شود که توزیع بار به نحو بهتری انجام شود و مسیریابی بر اساس محتوا انجام شود .

انتزاع پالیسی ها : چارچوب میانجی گری امکان این را فراهم می آورد تا مدیریت تعاریف و اعمال رویه ها به راحتی صورت پذیرد .

 

منطق کسب و کار

ESB منطق کسب و کار را پشتیبانی نمی کند ولی منطق کسب و کار معنوی در برنامه های کاربردی دیگر SOA گنجانده شده اند .
شکل۳٫۴ سرویس های ESB
۳٫۲٫۴ تعریف موجودیت های کلیدی با بهره گرفتن از الگوهای طراحی سیستم ها ی توزیع شده
هسته اصلی سیستم های اجرایی تولید را دو موجودیت منبع و مشتری تشکیل می دهد که در اکثر سیستم های توزیع شده موجودیت منبع با همین نام و تحت عناوین هولون منبع و یا عامل منبع شناخته شده است و موجودیت مشتری تحت عنوان هولون سفارش و یا عامل سفارش شناخته می شود ، تعاملاتی که این دو موجودیت انجام می دهند پایه و اساس الگوی طراحی سیستم های اجرایی تولید را تشکیل می دهد .
استفاده از الگوی طراحی که از تراکم استفاده می کند نیز روشی متداول است که بتوان موجودیت های تولید که در سلسله مراتبی جای دارند را سازماندهی کرد و با بهره گرفتن از آن بتوان هر چه بهتر مشکل پیچیدگی را کاهش داد .
به کارگیری میانجی نیز ابزاری قدرتمند است تا با بهره گرفتن از آن بتوان سیستم های مختلف را به هم پیوند داد ، این الگوی طراحی صرفاً مختص تولید نبوده و در طراحی های محیط های دیگر نیز متداول است .

 

۳٫۳ شناسایی سرویس ها

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

 

 

مدلسازی هدف – سرویس

GSM[32] از سه رویکرد استفاده می کند که چالش ، فرصت ها ، استراتژی ها و اهداف سازمان را مد نظر قرار داده ولی در نهایت اهداف کسب و کار را که محرکه مرتبط با محدوده پروژه مد نظر است را شناسایی می کند و این اهداف به زیر هدفهایی که مرتبط با هدف اصلی است تجزیه می شوند . این تجزیه سلسله مراتبی از اهداف کمک می کند تا زیر اهداف شناسایی شده به بهترین نحو به سرویس ها نگاشت شود . ضمناً این کار بسیار مهم است تا در حین کار فاکتور های کارایی کلیدی ([۳۳]KPI) شناسایی شوند تا تعیین سرویس ها با در نظر گرفتن آنها مشخص شود . KPI ها و معیارهای مشخص شده به کار می روند تا تعیین کنند تا چه حد راه حل سرویس گرایی که مورد استفاده قرار گرفته است موثر است .
GSM محدوده ای که کاربر را درگیر می کند به خوبی مشخص می کند و تعیین می کند که این بخش های کسب و کار نیاز به تغییر برای سرویس گرایی دارد . این مدلسازی بهترین اهداف کسب و کار را که تغییر در آنها تاثیر چشم گیری بر کسب و کار دارند شناسایی می کند . این کار ضمناً امکان محقق شدن اهداف توسط سرویس ها را نیز فراهم می آورد .

 

 

تجزیه دامنه

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

 

 

تحلیل دارایی های فعلی

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

 

 

انتخاب سرویس های کاندید

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

 

۳٫۴ تطابق رویکرد با مدل محاسباتی ابری

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

 

۳٫۴٫۱ مراحل چارچوب از دید محاسبات ابری

در سال­های اخیر فلسفه ” طراحی در همه جا، تولید در همه جا(DAMA[34]) ” ظهور کرده است. طبق این فلسفه کاربران درخواست­های مختلف تولید خود را از طریق سایت­های مختلف درخواست می­ کنند. DAMA همچنین می ­تواند لینک ارتباطی بین بخش برنامه ­ریزی منابع سازمان در سطح کلان، مدیریت ارتباط با مشتری، طراحی و مهندسی منابع فراهم آورد.
با وجود چنین رویکردی و ظهور محاسبات ابری، می­توان پتانسیل­های گسترده آن را در سیستم­های اجرایی تولید توزیع­شده به کار برد. به طور کلی در حال حاضر دو رویکرد عمده در به کارگیری محاسبات ابری در امر تولید وجود دارد. رویکرد اول، اتخاذ محاسبات ابری در بخش­های مورد نیاز تولید و رویکرد دوم، ابری کردن کل فرایند تولید است. در اینجا رویکرد اول مبنای کار قرار گرفته است.
طبق مبانی مدل محاسبات ابری نیازمندی­های مختلف، تحت عنوان سرویس قابل پوشش است. در مدل مرجع این محاسبات، سرویس­ها می­توانند از بخش محاسباتی ابر، بخش حین اجرای آن و بخش برنامه کاربردی درخواست شود. در این چارچوب، سعی شده است تا توابع اصلی سیستم­های اجرایی تولید را تحت عنوان سرویس دریافت کرد.