اجرایی تولید، سرویس گرا، معماری سرویس گرا

ظاهر متمرکز ولی به صورت فیزیکی به صورت توزیع شده و متمرکز دیده می شود .

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

شکل3.2 ESB
ESB نه تنها پیشنهاد استفاده از وب سرویس ها را می دهد بلکه امکان این را فراهم می کند که نقش الگویی متداول برای به کارگیری برنامه های کاربردی قدیمی را ایفا کند. این برنامه های کاربردی می توانند در چارچوب SOA با استفاده از به کارگیری سرویس های اضافه تر نظیر اداپترها قابل استفاده باشند .
به طور کلی ESB ، اقدامات زیر را انجام می دهد:
• امکان این را فراهم می آورد تا اتصال مناسب بین سرویس ها ایجاد شود.
• امکان این را فراهم می آورد تا سرویس ها با یکدیگر بر اساس ملزومات QOS و طی تراکنش های خاص نظیر سنکرون ، آسنکرون ، دائمی و غیردائمی ، اتصال سست و اتصال ضعیف ارتباط برقرار کنند .
• به عنوان زیرساختاری متداول برای معماری سرویس گرا ، رخدادها و پیغام های آن باشد به نحوی که پلتفرم های ناهمگون را به صورت شفاف به هم متصل می سازد .
• نقش میانجی را بین درخواست ها و پاسخ های سرویس گرا ایجاد می کند.
– با ایجاد سرویس های متغیر ، ردیابی و سرویس های ارزش افزوده
– ایجاد اتصال شفاف بین سرویس ها
ESB پتانسیل برآورده کردن فاکتور بحرانی کسب و کار را دارد :
• کاهش هزینه در هزینه های فناوری اطلاعات و افزایش چابکی کسب و کار ، با ایجاد هابی مشترک که سیستم های ناهمگون می توانند به آن متصل شوند و به سرعت با یکدیگر مشارکت داشته باشند ، چرخه توسعه محصول سریعتری داشته باشند و مدیریت فرآیندها را در محیط هایی گسترده پشتیبانی کنند .
• ESB ، تکنولوژی مبتنی بر استانداردی را فراهم می آورد که ملزومات برای نگهداری واسط های پیغام گرا که به عنوان مثال مرتبط با هزینه های پرسنل ، نگهداری و … هستند را کاهش می دهد .
قالب مورد استفاده در ESB برای معماری سرویس گرا:
مبنای ESB بر اساس رویکرد توزیع شدگی برای یکپارچه سازی است .این قابلیت آن ، این امکان را فراهم می آورد تا واحدهای کسب و کار مختلف ، برنامه های یکپارچه سازی خودشان را به تدریج توسعه دهند و به صورت محلی کنترل را اعمال کنند . همزمان ، ESB امکان این را فراهم می آورد تا واحد های کسب و کار به صورت انتخابی و به صورت امن به محض نیاز به یکدیگر متصل شوند . ESB یک لایه پیغام رسانی مبتنی بر استاندارد ایجاد می کند که نقش پل ارتباطی است که منطق کسب و کار مختلف را به هم پیوند می دهد .
شکل3.3 قالب ESB
این قالب متشکل از 5 بخش است :
1- برنامه کاربردی : سرویس ها در معماری سرویس گرا با لایه ای از برنامه کاربردی که زیر آن قرار می گیرد نمایش داده می شود : این برنامه های کاربردی شامل برنامه های کاربردی سمت سرور نظیر IBM Web Sphere ، برنامه های کاربردی قدیمی نظیر CICS ، برنامه های کاربردی NET ، و … برنامه های کاربردی بسته بندی شده شامل SAP ، People soft ،Oracle و … است.
2- اتصالات
ESB قابلیت اتصال را از طریق کاربران JMS و کانال MQ پروتکل وب سرویس ها و … فراهم می آورد .
3- باس
جنبه ی باس ESB ، کامپوننت اصلی پیغام رسانی برای سکوی نرم افزاری این قالب است و یکپارچگی را از طریق پارادایم های پیغام دهی نظیر نقطه به نقطه ، درخواست/ پاسخ ، انتشار/ تصدیق فراهم می آورد .
این پیغام ها در مودهای مداوم و غیر مداوم صورت می گیرد . سایر فاکتورهای کلیدی در باس شامل موارد زیر است :
• این باس بر روی زیرساختار Web Sphere ایجاد می شود .
• ویژگی های آن ، امکان این را فراهم می آورد تا دسترسی سریع و کنترل شکست را با WAS5/6 که از کلاسترهای شبکه استفاده می کنند پشتیبانی کند .
• یک پایگاه داده رابطه ای ایجاد شده است تا مکانیزم تداوم و سازگاری پیغام ها را حفظ کند .
• هر سرور برنامه کاربردی می تواند به صورت دلخواهانه از یک و یا چند موتور پیغام رسانی میزبانی کند .
4- میانجی
یک چارچوب میانجی باعث ایجاد انعطاف پذیری و انتزاع برای ESB است که از یک چارچوب مبتنی بر پالیسی برای تعریف میانجی استفاده می کند .
قابلیت های لایه میانجی عبارتست از :
• مجازی سازی : نقاط پایانی سرویس ها مجازی شده اند . این کار امکان این را فراهم می آورد تا سرویس ها خودشان مکانشان را بدون تاثیر گذاشتن بر مشتری ها تغییر دهند .
• دستکاری پیغام ها : چارچوب میانجی گری ، امکان مسیریابی ، پاک کردن محتوای پیغام ها را فراهم می آورد و این منطق به صورت توزیع شده در شبکه اعمال می شود .
• نظارت و مدیریت بر کیفیت سرویس : چارچوب میانجی امکان نظارت خودکار را فراهم می آورد .
• انتخاب و مسیریابی پویا : میانجی باعث می شود که توزیع بار به نحو بهتری انجام شود و مسیریابی بر اساس محتوا انجام شود .
• انتزاع پالیسی ها : چارچوب میانجی گری امکان این را فراهم می آورد تا مدیریت تعاریف و اعمال رویه ها به راحتی صورت پذیرد .

5- منطق کسب و کار
ESB منطق کسب و کار را پشتیبانی نمی کند ولی منطق کسب و کار معنوی در برنامه های کاربردی دیگر SOA گنجانده شده اند .

شکل3.4 سرویس های ESB

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

3.3 شناسایی سرویس ها
در فاز شناسایی سرویس ها علاوه بر سرویس ها ، عناصر کلیدی دیگری نیز شناسایی می شوند نظیر کامپوننت ها و جریان های کاری که ما بیشتر بر شناسایی سرویس ها تمرکز داریم. تجربه نشان داده است که بهترین کار برای شناسایی سرویس ها به کارگیری چندین تکنیک است ، به عبارتی یک تکنیک توان پاسخگویی برای شناسایی سرویس ها را ندارد ، گام اول توسط مدلسازی هدف – سرویس صورت گیرد تا در مرحله اول تطابق بهتری بین اهداف کسب و کار و سرویس های شناخته شده داشته باشیم . سرویس ها در مرحله اول تحت عنوان سرویس مشخص شده شناسایی می شوند ولی در نهایت تنها مجموعه ای از آنها تحت عنوان سرویس کاندید برای پیاده سازی شناسایی می شوند . در ادامه به معرفی سه تکنیک اصلی برای شناسایی سرویس ها می پردازیم :
• مدلسازی هدف – سرویس
GSM32 از سه رویکرد استفاده می کند که چالش ، فرصت ها ، استراتژی ها و اهداف سازمان را مد نظر قرار داده ولی در نهایت اهداف کسب و کار را که محرکه مرتبط با محدوده پروژه مد نظر است را شناسایی می کند و این اهداف به زیر هدفهایی که مرتبط با هدف اصلی است تجزیه می شوند . این تجزیه سلسله مراتبی از اهداف کمک می کند تا زیر اهداف شناسایی شده به بهترین نحو به سرویس ها نگاشت شود . ضمناً این کار بسیار مهم است تا در حین کار فاکتور های کارایی کلیدی (33KPI) شناسایی شوند تا تعیین سرویس ها با در نظر گرفتن آنها مشخص شود . KPI ها و معیارهای مشخص شده به کار می روند تا تعیین کنند تا چه حد راه حل سرویس گرایی که مورد استفاده قرار گرفته است موثر است .
GSM محدوده ای که کاربر را درگیر می کند به خوبی مشخص می کند و تعیین می کند که این بخش های کسب و کار نیاز به تغییر برای سرویس گرایی دارد . این مدلسازی بهترین اهداف کسب و کار را که تغییر در آنها تاثیر چشم گیری بر کسب و کار دارند شناسایی می کند . این کار ضمناً امکان محقق شدن اهداف توسط سرویس ها را نیز فراهم می آورد .

• تجزیه دامنه
این تکنیک بر تحلیل بالا به پایین دامنه کسب و کار و مدلسازی فرآیندهای کسب و کار تمرکز دارد . در این تکنیک هم از دیدگاه ثابت و هم پویا به کسب وکار نگاه می شود .
دامنه کسب و کار به نواحی عملیاتی دانه درشت تفکیک می شود تا بتوان دید ثابتی نسبت به متغیر داشت . عنصر کلیدی نواحی عملیاتی ، توابع کسب و کار هستند که بایستی برای آن پاسخگو باشند. موجودیت های کسب و کار که پاسخگو برای انجام این توابع هستند نیز در این فاز انجام می شود . فرآیند تحلیل دامنه با شناسایی موجودیت های کسب و کار مشخص می شود . موجودیت هایی که با اتصال سست خودشان ، کل محیط توزیع شده را شکل می دهند . دامنه ها و نواحی عملیاتی آنها ، اتصالات اولیه هستند که تحت نظارت معماری سرویس گرا صورت می گیرد و در نهایت مالک سرویس ها خواهند بود ودید پویا در فرآیند های کسب و کار نمود پیدا می کند . معمولاً فرآیند ها شناسایی شده اند و سلسله مراتب فرآیندها شکل می گیرند تا تجزیه دامنه محقق شود و در نهایت مجموعه ای از فرآیند های کسب و کار که قابلیت پی گیری دارند ،شکل می گیرد تا بتوان دیدی درست از تعامل های فرآیند ها داشت .
هدف مدلسازی فرآیند کسب و کار ، نشان دادن نمایشی از بایدها و داشته هاست .
• تحلیل دارایی های فعلی
در این تکنیک، معماری سرویس گرا تحلیل سطح بالایی از سیستم های فعلی ، برنامه های کاربردی ، سرویس ها و سایر دارایی هایی نظیر سیستم ها ، پکیج ها و سیستم های قدیمی را ارائه میدهد که قابلیت آن را دارند تا سرویس ها را در عمل پشتیبانی کنند. تمرکز بر دارایی هایی است که نقش کلیدی در فرآیند های کسب و کار دارد . در ابتدا نگاشتی بین اهداف کسب و کار و برنامه های کاربردی فعلی صورت می گیرد و سرویس های دانه درشت شناسایی می شوند . مشخصه سازی سرویس های دانه ریز تر و مشخصه پیغام ها شکل می گیرد .
• انتخاب سرویس های کاندید
این فعالیت متشکل از سه بخش است : فاکتوردهی مجدد به سرویس ها ، تست لیتموس و عقلایی سازی سرویس ها . سرویس ها در سلسله مراتب ، فاکتوردهی مجدد می شوند به نحوی که سرویس های سطح پایین که به نحوی با هم وابستگی منطقی دارند در یک سرویس سطح بالاتر با هم همگروه می شوند . متعاقباً تست لیتموس به یکسوی از سرویس های کاندید اعمال می شود .طرح سرویس ارائه شده در نهایت شامل وابستگی بین سرویس ها ، کامپوننت ها ، جریان های اطلاعاتی و قوانین است .در عقلایی سازی مدل سرویس که مروری کلی توسط ذی نفعان صورت می گیرد تا تایید شود سرویس ها در نهایت رابطه عقلایی باهم دارند.
3.4 تطابق رویکرد با مدل محاسباتی ابری
همانطور که اشاره شد هدف این تحقیق ارائه رویکردی راهبردی ب
رای ارائه سیستمهای اجرایی تولید توزیعشده با استفاده از مدل محاسبات ابری است. با در نظر داشتن این نکته و بانظر به رویکرد، که در بخش پیش مطرح شد، در این بخش درباره نحوه بهکارگیری مدل محاسبات ابری به عنوان بستری قدرتمند جهت ارائه توابع سیستمهای اجرایی تولید به صورت توزیعشده بحث خواهد شد. در این نگاشت تلاش بر این بودهاست که تا حد امکان از قابلیتهای ابر استفاده بهینه شود و تا حد امکان جامع بوده باشد تا سیستمهای اجرایی تولید را در حوزههای مختلف شامل شود.
در ادامه این فصل، در ابتدا ، نحوه به کارگیری مدل محاسبات ابری برای سیستمهای اجرایی تولید از نگاه کلان بررسی شده است، سپس با توجه به مبانی این مدل، سرویسهای مختلفی که در سیستمهای اجرایی تولید تحت عنوان XasS ارائه میشود، شناسایی میشود.
3.4.1 مراحل چارچوب از دید محاسبات ابری
در سالهای اخیر فلسفه ” طراحی در همه جا، تولید

Author: mitra6--javid

پاسخی بگذارید

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