شکل ۳٫۲۹ مذاکره میان مدیر منابع و مدیر سفارش

مذاکره میان مدیریت منابع مختلف: طی این مذاکره دو مدیر منبع مختلف در حین اجرا با هم مذاکره نموده و منابع را برای اجرای چندین سفارش به طور همزمان مدیریت می­ کنند. اجرای این مذاکره منجر به برقراری مذاکراتی با زمانبند نیز خواهد شد.
برای دانلود متن کامل پایان نامه به سایت tinoz.ir مراجعه کنید.

شکل ۳٫۳۰ مذاکره میان مدیریت منابع مختلف

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

شکل ۳٫۳۱ بخشی از مذاکرات کنترل فرایند اجرای سفارش

مذاکرات بین مدیر منابع و بازرس: هدف انجام این مذاکره این است تا بازرس تولید را قادر سازد به جمع­آوری اطلاعات از مدیر بپردازد. این اطلاعات می ­تواند شامل در دسترس بودن منابع، قابلیت منابع، وضعیت برنامه ­های کنترلی و داده ­های مرتبط با هریک.

شکل ۳٫۳۲ مذاکرات بین مدیر منابع و بازرس

مذاکرات میان مدیر منابع و بازرس: در حین این مذاکره مدیربا بازرس درباره اجرای تولید مذاکره می­ کند، ضمن اینکه زمانبند را در حین مذاکره درگیر می­سازند.

مذاکره میان سرویس­های سطح بالاتر و مدیر سفارش: میانجی­ها صرفاً برای برقراری ارتباط با ماژول­های درون سیستم­های اجرایی تولید نمی ­باشد، بلکه برای برقراری ارتباط اعم از تغییر اطلاعات سفارش از لایه ­های بالاتر نیز دیده می­شوند.

شکل ۳٫۳۳ مذاکره میان سرویس­های سطح بالاتر و مدیر سفارش

ارائه گزارش: برای دریافت گزارش از جریان اجرای تولید که این کار یکی از اهداف شکل­ گیری این سیستم­ها است ، با میانجی واسطی را بین سرویس­های سطوح بالاتر و مدیر سفارش قرار می­دهیم.

شکل ۳٫۳۴ ارائه گزارش

برای دریافت وضعیت فعلی تولید نیز مذاکراتی بین بازرس و مدیر منابع صورت می­گیرد، این مذاکرات می ­تواند شامل اطلاعاتی مبنی بر ترکیب یا تجزیه سفارش­های مختلف نیز می­باشد.

شکل ۳٫۳۵ مذاکره بین بازرس و مدیر

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

شکل ۳٫۳۶ مذاکراتی برای کنترل میان چندین مدیر منبع
در بخش گذشته مراحل چارچوب از دید محاسبات ابری مرور شد و با تحلیل سرویس­گرا زیر­سیستم­های اصلی و سرویس­های جزئی­تر که در سیستم­های اجرایی تولید وجود دارد شناسایی شدند. با شناسایی این موجودیت­ها، برای بسط و تعمیم موضوع، نیازمندی­های اصلی ایجاد یک معماری در محیط محاسباتی ابر شرح داده­می­ شود.
در ابتدا جایگاه ماژول­های سیستم­های اجرایی تولید را در محیط محاسباتی ابر از دیدگاه کلان بررسی می­کنیم، سپس با در نظر گرفتن ویژگی­های این سیستم و الگوهای طراحی سرویس­گرا که در فصل پیش مناسب این سیستم­ها در نظر گرفته شد، یک معماری کنترلی مناسب برای کنترل برنامه­کاربردی در محیط ابر شناسایی می­ شود، در گام بعدی نیازمندی­های این ماژول­های اصلی را از دیدگاه تامین کننده، سازمان و کاربر نهایی در محیط ابرشناسایی می­کنیم.

۳٫۷ توابع سیستم­های اجرایی تولید به عنوان سرویس

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

شکل ۳٫۳۷ همه چیز تحت عنوان سرویس
نکته شایان ذکر این است که مفهوم مدل محاسبات ابری مفهوم جدیدی نیست ، اما مفاهیم جدیدی که در سالهای اخیر متداول شده اند باعث شده اند که این پدیده قدرتمندتر شده و به کارگیری آن آسانتر شود . پدیده هایی نظیر محاسبات توزیع شده) distributed computing (پردازش گریدی) (Grid computing ، محاسبات بر مبنای سودمندی(utility computing) ، مجازی سازی (virtualization)و سرورهای کلاستری . این جنبه های این مدل به خوبی در چهارچوب فعلی لحاظ شده است . از طرفی مدل محاسبات ابری گاهی اوقات تحت عنوان جنبه ی مبتنی بر کسب و کار محاسبات گریدی در نظر گرفته می شود . که جوانب این موضوع نیز در چارچوب پیشنهادی مطرح شده است .
در ادامه مهمترین جوانب معماری برای سیستم های محاسباتی ابری از نگاه کاربران سازمان نظیر زیر ساختار ، ذخایر ، مقیاس پذیری و رقابت و امنیت بررسی می شود . بررسی این جوانب نقشه راهی برای خلق چارچوب مطلوب فراهم می آورد . چارچوبی که برای معماران نرم افزار و توسعه دهندگان هنگام طراحی سیستم های اجرایی تولید مفید خواهد بود .
ملزومات مورد بررسی به سه دسته تامین کنندگان ابر ، سازمانها و کاربران نهایی دسته بندی می شوند و در نهایت یک دسته بندی سه لایه ای از ملزومات سیستم های ابری ایجاد می شود . چنانچه در شکل ۲ دیده می شود از دیدگاه تامین کننده سرویس ، معماری سرویس گرا بسیار کار آمد، برای پشتیبانی از زیرساختار و سرویس ها مورد نیاز است تا بتوان سرویس های پویا و مجازی شده را خلق کرد. مدیریت داده امن و با سازمان دهی مناسب و مکانیزم ذخیره سازی مناسبی لازم است تا متناسب با مدل هزینه های تامین کننده باشد .
از دیدگاه سازمان ، اول از همه یک سیستم مقیاس پذیر ، امن و با کیفیت سرویس مطلوب مورد نیاز است . ضمن آنکه سازمان بایستی قادر باشد تا سرویس های مدیریت کسب و کار مناسبی به همراه مکانیزم های قابلیت کار متقابل به صورت داخلی و خارجی فراهم آورد . چنین چیزی توسط مدل ها ، ابر متفاوت قابل به کارگیری است . نهایتاً اینکه از دیدگاه کاربران ابر ملزومات پایه آنها به ساده ترین نحو در یک واسط سازگاری پذیر و با قابلیت یادگیری مناسب خلاصه می شود . این واسط بایستی قابلیت خودآموزی ، قیمت گذاری شفاف و قراردادهای سطح سرویس مناسب را داشته باشد . ضمن آنکه محرمانگی سمت کاربر ، رمز گذاری و رمز گشایی بایستی به خوبی لحاظ شود .
ارتباط بینابینی ، در این ملزومات از این سه نظر وجود دارد . به عنوان مثال اگر یک تامین کننده سرویس به خوبی از مسائل شفافیت و یا نظارت بر داده ها آگاه نباشد، کاربران ابر همواره نگران این موضوع خواهند بود که هزینه پرداختی ، به درستی محاسبه شده است یا نه . مشابه این موضوع اگر در سرویس ابر مشکلات امنیتی وجود داشته باشد، سازمان های بزرگ تمایلی برای قرار دادن برنامه های کاربردی خودشان در محیط ابر نخواهند داشت . علاوه بر آن امنیت ، مشارکت ، قابلیت اتحاد ، مهاجرت داده ها و قرارداد سطح سرویس کاملاً مرتبط با کارایی سرویس های ابر است . آن ملزومات ، نقش حیاتی را برای سازمانها برای توسعه استراتژی های کسب و کار خود در محیط ابر خواهند داشت .

۳٫۸ سبک معماری مناسب برای کنترل سیستم های اجرایی تولید توزیع شده در ابر

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

شکل ۳٫۳۸ مدیریت چرخه حیات سفارش
همانطور که در بخش قبل اشاره شد متدولوژی هایی که معمولاً مورد استفاده قرار می گیرد تا این تعامل ها به خوبی سازماندهی شوند عبارتست از ارکسترازیسیون و چیروگرافی و یا ترکیبی از هر دو که

شکل ۳٫۳۹ ملزومات کاربران، سازمان­ها و تامین کنندگان
ممکن است توسط مدلهای مختلف یا حتی زبانهای مختلف پیاده سازی شوند.
باتوجه به ماژولهای شناسایی شده در بخش گذشته و الگوهای طراحی عنوان شده در متدولوژیSOMA می توان دریافت که موجودیت اصلی در سیستم های اجرایی تولید موجودیت مدیریت سفارش آن است که ماژولهای دیگر به نحوی از آن خارج شده و تحت عنوان سرویس ابر ارائه می شوند. برای اتخاذ رویکرد کنترلی مناسب برای چنین سیستم هایی مناسب است که تعاملات سرویس های موجودیت سفارش به صورت ارکسترازیسیون صورت گیرد.
در رویکرد ارکسترازیسیون مجموعه ای متمرکز از منطق های جریان های کاری تعامل بین سرویس های مختلف را تسهیل می کند. در این رویکرد، فرایند های مجزا دیگر نیازی ندارند تا راه حل هایی را مجددا برای خودکارسازی خود توسعه دهند.منطق جریان کاری که در ارکسترازیسیون وجود دارد متشکل از قوانین متعدد، شرایط و رویدادهایی است که مشخص می کند که چگونه اجزای دیگر با گره مرکزی تعامل داشته باشند تا بتوان یک وظیفه خاص را انجام داد. منطق فرایند به صورت متمرکز وجود دارد ولی قابل گسترش و ترکیب است. در این رویکرد حتی می توان دیدی سلسله مراتبی داشت به نحوی که ارکستراتور های مختلف در سطوح مختلف قرار گیرند. در اینجا نیز منطق اصلی تولید یک سفارش با رویکرد ارکسترازیسیون کپسوله می شود.

شکل ۳٫۴۰ ارکسترازیسون ماژول مدیریت سفارش
از آنجا که هر ارکستراتور منطق خاص خود را داردگاهی اوقات لازم می شود که هر ارکستراتور در حین اجرا سرویس هایی که توسط یک ارکستراتور دیگر اجرا می شود را فراخوانی کند و یا برعکس در چنین شرایطی ارکستراتور اجرای سفارش رویکردی مشابه چیروگرافی به خود می گیرد.
وب سرویس های زبان اول اجرای فرایند کسب و کار(WS-BPEL[37]) ،مهمترین مشخصه­های مرتبط با ارکسترازیسیون سرویس­ها و منطق جریان های کاری را با فعالیت های اولیه ازپیش تعیین شده ای نظیر(دریافت، احضار، پاسخ، پرتاب و انتظار) انجام می دهد.
در سالهای اخیر ارکستراتور های مختلف مبتنی بر BPEL ایجاد شده اند، نظیر Active VOS که استاندارد بازی را ایجاد کرده است که توسعه دهندگان بتوانند به راحتی سیستم ها وسرویس های مختلف را ارکستریت نمایند. Apache ODE که در حقیقت یک موتور ارکسترازیسیون دو لایه که مبتنی بر Apache Axis2و Java business integration است Oracle BPEL process managers که یک چارچوب برای طراحی ، به کارگیری، نظارت بر فرایند ها مبتنی بر استاندارد باز BPEL است و نمونه دیگر Microsoft system center orchestrator است که شامل یک موتور ارکسترازیسیون است که علاوه بر خودکارسازی فرایند های فناوری اطلاعات مدیریت فرایند های کسب و کار را نیز به خوبی انجام می دهد.
همانطور که در شکل۳ نشان داده شده است به جز موجودیت اصلی سفارش که با رویکرد ارکسترازیسیون به هم متصل شده اند ، سایر ماژولهای اصلی از این موجودیت جدا شده و به صورت توزیع شده در ابر قرار دارند، لذا در چنین شرایطی الگوی تعاملی مناسب برای کنترل چیروگرافی است.
به طور خلاصه چیروگرافی امکان همکاری را بین شرکای توزیع شده فراهم می آورد.هدف، ایجاد همکاری سازماندهی شده بین سرویس های توزیع شده بدون هیچ منطق کنترلی مرکزی است. برای اعمال چیروگرافی، هر سرویس خاص بایستی نقش خود را در محیط ابر بداند بدین معنی که چگونه در شرایط خاص واکنش نشان دهد.
هر تعامل بین نقش های مختلف تحت عنوان رابطه شناخته می شود و نقش های مختلف روابط مختلف می توانند باهم داشته باشند. قالب ارتباطات یا به عبارتی الگوی پیغام های تبادلی بین دو نقش توسط کانال ایجاد می شود. اطلاعات کانال از طریق پیغام های بین سرویس ها مشخص می شود و درنتیجه سرویس مشخص می کند که چگونه با یک سرویس خاص ارتباط برقرار می کند. علاوه بر آن منطق تبادل ارتباط نیز در حین تعامل ارسال می شود.