مذاکره میان مدیریت منابع مختلف: طی این مذاکره دو مدیر منبع مختلف در حین اجرا با هم مذاکره نموده و منابع را برای اجرای چندین سفارش به طور همزمان مدیریت می کنند. اجرای این مذاکره منجر به برقراری مذاکراتی با زمانبند نیز خواهد شد.
(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت nefo.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 است که شامل یک موتور ارکسترازیسیون است که علاوه بر خودکارسازی فرایند های فناوری اطلاعات مدیریت فرایند های کسب و کار را نیز به خوبی انجام می دهد.
همانطور که در شکل۳ نشان داده شده است به جز موجودیت اصلی سفارش که با رویکرد ارکسترازیسیون به هم متصل شده اند ، سایر ماژولهای اصلی از این موجودیت جدا شده و به صورت توزیع شده در ابر قرار دارند، لذا در چنین شرایطی الگوی تعاملی مناسب برای کنترل چیروگرافی است.
به طور خلاصه چیروگرافی امکان همکاری را بین شرکای توزیع شده فراهم می آورد.هدف، ایجاد همکاری سازماندهی شده بین سرویس های توزیع شده بدون هیچ منطق کنترلی مرکزی است. برای اعمال چیروگرافی، هر سرویس خاص بایستی نقش خود را در محیط ابر بداند بدین معنی که چگونه در شرایط خاص واکنش نشان دهد.
هر تعامل بین نقش های مختلف تحت عنوان رابطه شناخته می شود و نقش های مختلف روابط مختلف می توانند باهم داشته باشند. قالب ارتباطات یا به عبارتی الگوی پیغام های تبادلی بین دو نقش توسط کانال ایجاد می شود. اطلاعات کانال از طریق پیغام های بین سرویس ها مشخص می شود و درنتیجه سرویس مشخص می کند که چگونه با یک سرویس خاص ارتباط برقرار می کند. علاوه بر آن منطق تبادل ارتباط نیز در حین تعامل ارسال می شود.
مشابه ارکسترازیسیون، چیروگرافی نیز می تواند شامل سطوح مختلفی از انتزاع باشد. یک الگوی کنترلی چیروگرافی، می تواند شامل الگوهای چیروگرافی داخلی نیز باشد که تحت عنوان بلاک شناخته می شود تا بتوان با ترکیب آنها رفتارهای پیچیده تر را کنترل کرد.
شکل۳٫۴۱ چیروگرافی
با در نظر گرفتن این دو الگوی کنترلی آنچه از ماژولهای اصلی در محیط ابر و نحوه تعامل آنها مشهود است ، در شکل بعدی آمده است.
۳٫۹ زمانبندی جزئی تحت عنوان سرویس
در حین اجرای سفارش ، درخواست زمانبندی جزئی توسط نود اصلی اجرای سفارش ویا سایر سرویس ها که نیاز به اصلاح زمانبندی دارند به نود زمانبندی ارسال می شود.سرویس زمانبندی ابتدا چک می کند که آیا از لحاظ زمان آغاز و یا پایان قابل اجرا هست یا نه و یا اینکه مدت رزرو منابع قابل قبول هست یا نه. اگر درخواست رزرو بودن کماکان معتبر باشد،سرویس زمانبندی سپس مشخص می کند که آیا کدامیک از ایستگاههای کاری قابلیت اجرای این زمانبندی را دارا هستند قبل از این که درخواست توزیع را برای نود توزیع کننده ارسال کند و گرنه درخواست زمانبندی جزئی شده در صف باقی می ماند. به روز رسانی زمانبندی صورت گرفته و تغییرات اعمال شده به سایر نود های سرویسی ارسال می شود تا همواره دید به روزی از زمانبندی و از اجرای تولید در ابر موجود باشد.
در ادامه پس از شرح کلی شمای زمانبندی ، این سرویس را از دیدگاه تامین کننده،سازمان و کاربر نهایی بررسی نموده و ملزومات به کارگیری چنین سیستمی را به عنوان سرویس شرح خواهیم داد.
شکل۳٫۴۲ توزیع سرویسها در محیط ابر
۳٫۹٫۱ ملزومات تامین کننده ابر
مدل تحویل زمانبندی به عنوان سرویس
چنانچه اشاره شد مدلهای تحویل متنوعی در محیط ابر وجود دارد، اما آنچه در این مدل کاملا مشهود است به کارگیری برنامه های کاربردی زمانبندی جزئی شده(AasS) است چنانچه متقاضیان متعدد از سفارش های مختلف خواهان زمانبندی می باشند،شمای چند مستأجری را در این مدل می توان لحاظ کرد، منابع مشترک و نمونه های یکسانی از کد و برنامه کاربردی و همچنین پایگاه داده زیرین آن مورد استفاده قرار می گیرد و سفارش های مختلف زمانبندی می شود تا بتوان مشتریان(درخواست زمانبندی سفارش مختلف) را بطورهمزمان زمانبندی کرد.
