در معماری های متمرکز ، سرویس ها در یک مخزن مرکزی مانند UDDI یا پورتال وب نگهداری می شوند . معماری هایی که از UDDI به عنوان مخزن استفاده می کنند خود به دو دسته معماری های مرکب و معماری های مبتنی بر واسطه تقسیم می شوند . از مزایای معماری متمرکز این است که دسترسی سریع به تمام توصیفات سرویس ها را فراهم می کند . اما در مقابل این روش با چالش هایی نیز مواجه است از جمله اینکه خود مخزن مرکزی به یک گلوگاه تبدیل می شود زیرا دسترسی به سرویس ها فقط از طریق آن انجام می شود . مسئله دیگر در ارتباط با این معماری این است که ثبت سرویس ها بر عهده خود تولیدکننده ها است و در صورتی که این کار انجام نشود مخازن سرویس قدیمی شده و سرویس های تازه را شامل نمی شوند .
روش هایی که معماری توزیع شده را پیشنهاد می کنند از قابلیت انعطاف پذیری و توسعه پذیری بهره می برند . در چنین معماری هایی سرویس ها در وب سایت تولید کننده نگهداری می شوند و از ساز و کارهای متفاوتی برای پیدا کردن سرویس ها استفاده می شود. روش هایی که از معماری توزیع شده استفاده می کنند را می توان بر اساس نحوه دست یابی به سرویس ها به سه دسته معماری های مبتنی بر اینترنت ، معماری های مبتنی بر عامل ها و معماری های همتا به همتا تقسیم کرد[۳۰] .
۲٫۷٫جمع­بندی
با توجه به مطالب مطرح شده واضح است که سیستم­های اجرایی تولید توزیع­شده می­توانند مزایای فراوانی را برای سازمان­ها فراهم­آورند، اما در مراحل مقدماتی خود نیاز به تحقیقات و بررسی­های زیادی دارند. اولین گام می­توانند ارائه چارچوبی راهبردی باشد که تمامی فعالیت­های موجود در سیستم­های اجرایی تولید را شامل شود. این چارچوب بایستی به نحوی باشد که راه­حلی برای چالش­های مطرح­شده در ارتباط با سیستم­های اجرایی تولید توزیع­شده باشد.
یکی از مهمترین فعالیت­ها در سیستم­های اجرایی تولید توزیع­شده شناسایی سرویس­هایی است که بتواند به عنوان دارایی پایه در این سیستم در نظر گرفته شود. همانطور که در بخش سیستم­های اجرایی تولید توزیع­شده عنوان شد بیشتر کارهای مرتبط تمرکز بر معماری هولونی و چند­عاملی داشته­است. این تحقیق به دلیل تمرکز برروی کشف سرویس و با توجه به کمبود روش­های سرویس­گرا، سیستم­های اجرایی تولید، سعی در رفع چالش­های همروندی، یکپارچگی و قابلیت کار متقابل اجزای سیستم را دارد. دلیلی که از سرویس­ها در این روش استفاده شده است، قابلیت استفاده مجدد بالای آن­ها است. با پیدا کردن سرویس­های مورد نیاز این سیستم­ها، می­توان طراحی و شناسایی سرویس را به نیازمندی­های پوشش داده نشده، محدود و در نتیجه در هزینه و زمان صرفه­جویی کرد.

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

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

۳٫۱ مقدمه

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

۳٫۲ نگاهی کلی

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

شکل۳٫۱ نمایی کلی از رویکرد مورد استفاده
۳٫۲٫۱ تشریح سیستم های اجرایی تولید و طرح مساله در محیط توزیع شده
در این مرحله ، فرایند های کسب و کار بررسی شده و نقاط عطف برای دگرگونی و تغییر شناسایی می شود، نقاطی که با شناسایی آنها مراحل بعدی با وجود آنها آغاز می شود. با بررسی سیستم های اجرایی تولید فعلی و بسط آنها در محیط توزیع شده و بررسی آنها با مجموعه ای از مشکلات پایه و اصلی این سیستم ها آشنا شدیم که بعضاً تامین آنها در محیط توزیع شده منجر به تقلیل اثرات مشکل و گاهی نیز منجر به تشدید آن مشکلات شده است. در ادامه به معرفی مسائل پایه این سیستم ها می پردازیم.

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

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

سفارش کاری که از لایه های برنامه ریزی منابع سازمان دریافت می شود چگونه مدیریت می شود تا در زمان مناسب تحویل داده شود ضمن آن که از منابع به حد بهینه استفاده کرده باشد. هدف : ارائه راه حل مدیریت سفارش ها برای رسیدن به بهینگی

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

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

در صورت وقوع اتفاق غیر منتظره، این سیستم ها چگونه باید قادر باشند واکنش نشان دهند و وضعیت را به بهترین نحو مدیریت کنند.

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

فرایند هر تولیدی شامل تعاریف متعددی از مواد اولیه تا نحوه کارایی پرسنل فرایند تولید و غیره می باشد که دائماً در حین اجرا به سیستم اضافه می شود ، چگونه می توان مدیریت درستی بر این تعاریف برای تسهیل فرایند اجرا داشت.

۳٫۲٫۲ انتخاب الگوهای راه حل( Solution pattern ) های SOMA[30]
راه حل های سرویس گرا ذاتاً ترکیبی هستند و معمولاً شامل چندین نوع راه حل می شوند و این به دلیل آن است که در SOMA ، مرحله شناسایی و تشخیص سرویس ها ، بسیار زود انجام می شود و راه حل های متنوعی نظیر توسعه سفارشی ، یکپارچه سازی با سیستم های قدیمی ، توسعه پکیج های برنامه های کاربردی ، طراحی ESB[31] و استفاده از آن و سرویس های کسب و کار مرکب پیشنهاد داده شده است .
SOMA به نوعی طراحی شده است که بتواند به خوبی ماهیت ترکیبی راه حل های سرویس گرا را به کار ببرد و فعالیت های خاص و راهنمایی ها را برای پیاده سازی هر یک از راه حل های عنوان شده را به کار گیرد . در متدولوژی SOMA ، محتوای هر یک از راه حل ها ، متناظر با همان راه حل است که حاوی وظایف ، تولیدات کاری ، نقش ها و راهنمایی هایی شود که از آن تحت عنوان الگوی راه حل استفاده می کنیم.
۳٫۲٫۳ الگوی راه حل های پیشنهادی توسط SOMA
ESB ، یک الگوی راه حل می باشد ، نه یک محصول ، به نحوی که معماری سرویس گرا می تواند از آن استفاده کند تا چالش ها را در محیط های بزرگ و توزیع شده برطرف سازد، چالش هایی از قبیل اینکه : چگونه می توان سطح بالایی از یکپارچگی و قابلیت کار متقابل بین سیستم هایی که به طور همزمان کار می کنند ایجاد کرد . سیستم هایی که به صورت مجزا مالکیت خود را دارند و به صورت توزیع شده عمل می کنند و به طور همزمان معایب وجود تکنولوژی های مختلف در نقاط توزیع شده مختلف را کاهش داد و از به کارگیری راه حل های سطحی و برهه ای اجتناب کرد، چیزی که منجر به کاهش هزینه ها، افزایش امنیت و افزایش چابکی می شود .
ESB ، در حقیقت تحولی بزرگ در استفاده از واسط های پیغام گرا و وب سرویس ها در سازمان است . در کلامی کوتاه ، ESB یک هاب است که مصرف کنندگان برنامه های کاربردی و سرویس ها را قادر می سازد تا به یکدیگر متصل شوند . اتصالی که به ظاهر متمرکز ولی به صورت فیزیکی به صورت توزیع شده و متمرکز دیده می شود .
محصولات مختلف که در زیر ساختار ESB وجود دارد ، قابلیت های مختلف سیستم های اجرایی تولید و توزیع شده را پشتیبانی می کنند . محصولاتی نظیر:

واسط پیغام ها

پرتال سرورها

مدیریت سیستم ها

شکل۳٫۲ ESB
ESB نه تنها پیشنهاد استفاده از وب سرویس ها را می دهد بلکه امکان این را فراهم می کند که نقش الگویی متداول برای به کارگیری برنامه های کاربردی قدیمی را ایفا کند. این برنامه های کاربردی می توانند در چارچوب SOA با بهره گرفتن از به کارگیری سرویس های اضافه تر نظیر اداپترها قابل استفاده باشند .
به طور کلی ESB ، اقدامات زیر را انجام می دهد:

امکان این را فراهم می آورد تا اتصال مناسب بین سرویس ها ایجاد شود.

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

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

نقش میانجی را بین درخواست ها و پاسخ های سرویس گرا ایجاد می کند.

– با ایجاد سرویس های متغیر ، ردیابی و سرویس های ارزش افزوده
– ایجاد اتصال شفاف بین سرویس ها
ESB پتانسیل برآورده کردن فاکتور بحرانی کسب و کار را دارد :

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

ESB ، تکنولوژی مبتنی بر استانداردی را فراهم می آورد که ملزومات برای نگهداری واسط های پیغام گرا که به عنوان مثال مرتبط با هزینه های پرسنل ، نگهداری و … هستند را کاهش می دهد .

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