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

سیستم های اجرایی تولید در حقیقت واسطی بین برنامه ریزی ها در سطح کلان و کارهای ریز شده در سطح ایستگاه های کاری هستند، عده ای هدف رسیدن به این سیستم ها را تامین واسطی که دیدی روشن و شفاف نسبت به امور به آنها بدهد می دانند، مشکل اینجاست که این سیستم ها چگونه می توانند پاسخگوی این نیاز باشند. ( هدف رسیدن به شفافیت در گزارش گیری کلان )
برنامه ریزی های سطح کلان که از لایه ی برنامه ریزی منابع سازمان به این لایه ارسال می شود اغلب در سطح کلان می باشد و جزئیات در آن لحاظ نشده است، چگونه سیستم های اجرایی تولید توزیع شده می توانند زمان بندی دقیق و جزئی شده از اقدامات واقعی داشته باشد. هدف : طرح رسیدن به برنامه ریزی جزئی شده است .
سفارش کاری که از لایه های برنامه ریزی منابع سازمان دریافت می شود چگونه مدیریت می شود تا در زمان مناسب تحویل داده شود ضمن آن که از منابع به حد بهینه استفاده کرده باشد. هدف : ارائه راه حل مدیریت سفارش ها برای رسیدن به بهینگی
دید، نسبت به منابع از نگاه کلان با آنچه در عمل موجود است تفاوت بسیار دارد. آنچه در عمل دیده می شود شامل اطلاعات از منابع ، وضعیت آنها ، رزرو شدن و مکان آنها است. مشکل اینجاست که چگونه اطلاعات به روزی از وضعیت منابع همواره آماده داشته باشیم.
سفارش های کار، نحوه استفاده از منابع و چگونگی زمان بندی و بسیاری از موارد دیگر تولید را لحظه به لحظه پیش می برند ، اینکه بتوان پیگیری دقیقی از کارهای در جریان توسط عوامل داخلی سیستم فراهم آورد ، خود نوعی مشکل برای این سیستم ها می باشد.
در صورت وقوع اتفاق غیر منتظره، این سیستم ها چگونه باید قادر باشند واکنش نشان دهند و وضعیت را به بهترین نحو مدیریت کنند.
در صورت اعمال تغییرات چگونه می توان به نرمی آنها را به سیستم اعمال کرد طوری که بتوان توازنی بین انعطاف پذیری و بهینگی ایجاد کرد.
فرایند هر تولیدی شامل تعاریف متعددی از مواد اولیه تا نحوه کارایی پرسنل فرایند تولید و غیره می باشد که دائماً در حین اجرا به سیستم اضافه می شود ، چگونه می توان مدیریت درستی بر این تعاریف برای تسهیل فرایند اجرا داشت.
۳٫۲٫۲ انتخاب الگوهای راه حل( 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 یک لایه پیغام رسانی مبتنی بر استاندارد ایجاد می کند که نقش پل ارتباطی است که منطق کسب و کار مختلف را به هم پیوند می دهد .
شکل۳٫۳ قالب ESB
این قالب متشکل از ۵ بخش است :
برنامه کاربردی : سرویس ها در معماری سرویس گرا با لایه ای از برنامه کاربردی که زیر آن قرار می گیرد نمایش داده می شود : این برنامه های کاربردی شامل برنامه های کاربردی سمت سرور نظیر IBM Web Sphere ، برنامه های کاربردی قدیمی نظیر CICS ، برنامه های کاربردی NET ، و … برنامه های کاربردی بسته بندی شده شامل SAP ، People soft ،Oracle و … است.
اتصالات
ESB قابلیت اتصال را از طریق کاربران JMS و کانال MQ پروتکل وب سرویس ها و … فراهم می آورد .
باس
جنبه ی باس ESB ، کامپوننت اصلی پیغام رسانی برای سکوی نرم افزاری این قالب است و یکپارچگی را از طریق پارادایم های پیغام دهی نظیر نقطه به نقطه ، درخواست/ پاسخ ، انتشار/ تصدیق فراهم می آورد .
این پیغام ها در مودهای مداوم و غیر مداوم صورت می گیرد . سایر فاکتورهای کلیدی در باس شامل موارد زیر است :
این باس بر روی زیرساختار Web Sphere ایجاد می شود .
ویژگی های آن ، امکان این را فراهم می آورد تا دسترسی سریع و کنترل شکست را با WAS5/6 که از کلاسترهای شبکه استفاده می کنند پشتیبانی کند .
یک پایگاه داده رابطه ای ایجاد شده است تا مکانیزم تداوم و سازگاری پیغام ها را حفظ کند .