واژه ESB کوتاه شدهی واژههایEnterprise Service Bus است و ابزاری برای یکپارچه کردن انواع برنامههای کاربردی که توسط چندین شرکت تهیه شده است.ESB یک سیستم ارتباطی بین برنامههای نرمافزاری در تعامل در معماری سرویسگرا (SOA) پیادهسازی میکند و یک معماری نرمافزاری برای محاسبات توزیعشده ارئه میدهد. در واقع یک نوع خاص از مدل کلاینت-سرور است که در آن هر برنامه کاربردی به عنوان سرور و یا مشتری رفتار میکند. ESBبا توجه به ارتباطات پروتکل سطح بالا بین برنامهها سبب افزایش چابکی و انعطاف پذیری سیستم میشود. این تکنیک برای یکپارچهسازی برنامههای کاربردی سازمانی (EAI) شامل سرویسهای پیچیده مورد استفاده قرار میگیرد. امروزه در سطح دنیا، بسیاری از شرکتهای قدرتمند و مشهور در زمینه ESB فعالیت دارند.
بهترین راه توصیف این ابزار این است که آن را به عنوان مجموعه ای از سوئیچ ها تجسم کرد که میتوانند یک پیام را در امتداد یک مسیر خاص میان اجزای برنامه بر اساس محتوای پیام و اجرای سیاست های کسب و کاری هدایت کنند.
مفهوم ESB مشابه مفهوم bus در معماری سختافزار کامپیوتر است که با طراحی ماژولار و همزمان سیستمعاملهای کامپیوتری با کارایی بالا ترکیب شده است. هدف از توسعه معماری، یافتن مفهومی استاندارد، ساختاریافته برای توصیف پیادهسازی اجزای نرمافزاری به نام سرویسها است. همچنین ESB یک الگوی پیاده سازی متداول برای معماری سرویس گرا است.
استاندارد بین المللی برای مفاهیم و پیاده سازی گذرگاه خدمات سازمانی وجود ندارد. ارائه دهندگان میان افزار پیام محور مفهوم گذرگاه خدمات سازمانی را به عنوان استاندارد برای معماری سرویس گرا پذیرفته اند. پیادهسازیهای ESB از میانافزار پیاممحور مبتنی بر رویداد و استاندارد در ترکیب با صفهای پیام به عنوان چارچوبهای فناوری استفاده میکنند.
یک ESB طراحی سیستم عاملهای مدرن را برای سرویسهای مستقل که در شبکههای کامپیوتری متفاوت و مستقل اجرا می شوند، اعمال میکند. مانند سیستمهای همروند، یک ESB علاوه بر خدمات پذیرش، تطبیق و مسیریابی درخواستهای مشتری، خدمات پاسخگویی مناسب را ارائه میکند. وظایف اصلی ESB را میتوان به طور خلاصه به شکل زیر توصیف کرد:
اولین استفاده منتشر شده از روش ESB به آقای Roy از گروه گارتنر در سال 2002 و کتاب The Enterprise Service Bus نوشته شده توسط دیوید چاپل نسبت داده شده است. اگرچه تعدادی از شرکتها این روش را منتسب به خود میدانند، اما آقای Roy در مصاحبهای گفت: ابتدا این عبارت را از شرکتی به نام Candle شنیده است و افزود: اصلیترین استفاده از ESB محصولی به نام روما در سال 1998 در شرکت کندل است. روما اولین بار در سال 1998 به عنوان محصول ESB فروخته شد و آن را تجاری کرد. محصول سونیک در سال 2002 نیز یکی از ESB های اولیه در بازار بود.
ابتدا تعریفی از هر یک از قسمتها ارائه میشود.
برنامه های غیر تکراری و مستقلی که از طریق تبادل پیام با سرویس های دیگر ارتباط برقرار میکنند را شامل میشود.
متناظر با گذرگاه سخت افزار کامپیوتر است.
این مفهوم در ابتدا برای کاهش پیچیدگی یکپارچه سازی برنامههای کاربردی سازمانی در یک شرکت تعریف شده است و هم اکنون مورد استفاده قرار میگیرد.
معماری ESBدر نرمافزاری که میان برنامههای کاربردی کار میکند و ارتباط بین آنها را امکانپذیر میسازد، پیاده سازی میشود. در حالت ایده آل، ESB باید بتواند تمام ارتباطات مستقیم را با برنامههای موجود در گذرگاه جایگزین کند، به طوری که تمام ارتباطات از طریق ESB انجام شود. جهت رسیدن به این هدف، ESB باید عملکرد برنامههای کاربردی اجزای خود را به روشی معنادار کپسولهسازی کند. به طور معمول به کمک استفاده از یک مدل پیام سازمانی امکان پذیر است. در این مدل، مجموعهای استاندارد از پیام های ارسلی و دریافتی در ESB تعریف میشود. هنگامی که ESBپیامی دریافت میکند، با توجه به سیاستهای تعریف شده، پیام را به برنامه مربوطه هدایت میکند. اغلب، بدلیل آنکه برنامه بدون مدل پیام یکسانی توسعه یافته است، ESB باید پیام را در قالبی مشخص که برنامه بتواند آن را تفسیر کند، ارسال کند.
این معماری بر ساخت دقیق مدل پیام سازمانی و طراحی مناسب عملکرد ارائه شده توسط برنامهها پایه گذاری شده اند. اگر مدل پیام به طور کامل عملکرد برنامه را کپسوله سازی نکند، برنامههای کاربردی دیگری که مایل به انجام آن عملکرد هستند ممکن است مجبور شوند گذرگاه را دور بزنند و برنامههای ناهماهنگ را مستقیماً فراخوانی کنند که با اهداف این معماری مغایرت دارد.
برتری این معماری در ماهیت غیر وابسته به زیرساخت و توانایی ادغام در هر شرایط پنهان است.
روش ESB اغلب مواردی از جمله روش پیادهسازی و مدیریت مؤثر معماریهای مبتنی بر SOAP، مانند معماری سنتی سرویسگرا را بررسی میکند. با این حال، ESB ها استراتژی جریان کار بسیار متفاوتی را نسبت به رویکرد مرتبط با میکروسرویس ها ارئه میدهند.
برخلاف میکروسرویس ها یا استراتژی های مشابه که واسط اتصالات API بین اجزا هستند، ESB مرکز جریان کار در برنامه است و در واقع یک صف پیام است و تبادل اطلاعات در سراسر برنامه را مدیریت میکند.
یک ESB تعیین نمی کند که آیا اجزایی که از گذرگاه استفاده میکنند محلی یا غیرمحلی هستند یا هیچ الزامات خاصی را برای زبانهای برنامه نویسی ندارد. ESB روشهای مختلفی را که اجزا میتوانند اطلاعات را دریافت یا به دیگر عناصر برنامه ارسال کنند، یکپارچه میکند.
در قسمت بعد به مزیت، معایب و چالشهای رو به رو در این معماری پرداخته میشود.
در ESB نحوه جریان کار کنترل میشود و تغییرات در اجزا یا افزودن اجزای اضافی به یک برنامه به آسانی انجام میشود. همچنین ابزاری مناسب برای اجرای موارد امنیتی و برآورد نیازمندیها، ثبت شرایط عادی یا خطاها و حتی نظارت بر عملکرد تراکنش است. همچنین ESB تعادل بار در سیستم را نیز فراهم میکند. به این ترتیب میتوان چندین نسخه از یک مؤلفه را برای بهبود عملکرد و همچنین پشتیبانی از خطا و شکست در صورت خرابی یک مؤلفه یا منبع، نگهداری کرد.
همچنین این ابزار دارای ویژگی مقیاس پذیری است و از سطح خرد تا استقرار در سطح سازمان را پشتیبانی میکند. اتصال و قطع کردن سیستم آسان است و به اصطلاح coupling در سیستم کم میشود.
یک چالش رایج در ESB عدم وجود یک استاندارد پذیرفته شده واحد برای ویژگیها و رفتارها است. اگرچه وظیفه اصلی ESB این است که به عنوان یک گذرگاه پیام عمل کند و پیام ها را بین برنامهها یا مؤلفهها مطابق با یک سیاست تعریف شده، هدایت میکند. گاهی این کلید واژه برای توصیف هر چیزی که به نوعی از جریان و فرآیند کار پشتیبانی میکند، استفاده می شود. به عنوان مثال، اوراکل شرکت ارائهدهنده تکنولوژی، از گذشته چندین نوع میانافزار را در دستهبندی ESB قرار داده است.
هدایت پیامها بر اساس سیاست تعریف شده، یک عملکرد تمایز دهنده ESB از سایر میان افزارها است. برای کاربران بسیار مهم است که به وضوح نیازهای کسب و کار خود را تعریف کنند و سپس ویژگیهای ESB کاندید خود را در برابر نیازهای از پیش تعریف شده، تأیید کنند.
این ابزار معایبی نیز دارد. از جمله معایب آن میتوان به این موارد اشاره کرد. در ESB سرعت ارتباط سرویسها به ویژه سرویسهای سازگار، کندتر است. همچنین وجود یک نقطه شکست، ممکن است سبب از بین رفتن تمام ارتباطات در سازمان شود. دیگر عیب این ابزار، پیچیدگی بالا در نگهداری و پیکربندی آن است.
از جمله محصولات ESB میتوان موارد زیر را نام برد.
محصولات تجاری و اختصاصی:
و محصولات متن باز:
در ادامه دو نمونه از ابزارهای ESB نام برده، بررسی میشود.
این ابزار یک فریمورک یکپارچه منبع باز است و امکان ادغام با سرعت و به راحتی در سیستمهای مختلف مصرف کننده یا تولید داده را فراهم میکند. Camel از بسیاری از الگوهای یکپارچه سازی سازمانی در کتاب آقای گرگور هوپ و بابی وولف و الگوهای ادغام جدیدتر در معماریهای میکروسرویس نیز پشتیبانی میکند.
ابزار Apache Camel مستقل است و می تواند به عنوان یک کتابخانه در Spring Boot، Quarkus، Application Servers و در ابرها تعبیه شود. همچنین این ابزار دارای چندین مؤلفه است که برای دسترسی به پایگاههای داده، صفهای پیام و API استفاده میشود و به یکپارچگی تمام اجزا کمک میکند. این ابزار بیش از 50 فرمت داده را پشتیبانی میکند و امکان ترجمه پیام ها در قالبهای مختلف را فراهم میآورد.
"خدمات خود را به روشی هوشمندانه مدیریت کنید." این شعار شرکت open ESB است. بیش از یک دهه است که OpenESB در حال تولید بوده است و یک شالوده اصلی به عنوان پلتفرم یکپارچه سازی فراهم میکند. کاربران OpenESB آن را به عنوان یک محصول سبک وزن، با قابلیت اطمینان، مقیاس پذیر، مقاوم در برابر خطا و آسان در کارکرد و پیاده سازی معرفی میکنند. OpenESB میلیاردها پروژههای و فرآیند پیچیده را در سرتاسر جهان برای بانکها، مؤسسات مالی، شرکتهای لجستیک یا دولت اجرا میکنند. در ادامه ویژگیهای این ابزار بررسی میشود.
مفهوم رابط و پیادهسازی را به میکرو سرویسهایی مانند جاوا یا C++ میآورد، طراحی با رابطها و فراخوانی پیادهسازی آنها در زمان اجرا، کپسولهسازی و جداسازی سرویس را بهبود میبخشد و انعطافپذیری به برنامهها میدهد.
شامل فرآیند توسعهی تعریف شده بر اساس سه وظیفه اصلی تعریف سرویس، هماهنگ سازی سرویس و ترکیب سرویس است و امکان اتصال و پیکربندی گرافیکی اجزای مختلف و فرآیند را فراهم میکند.
میتوان به صورت دقیق جزئیات استقرار میکروسرویس را تعریف کرد و با کار تیم توسعه مطابقت داد.
برای یک فرآیند تجاری، ترکیب سرویس برای مدیریت آن کافی نیست و نیاز به جبران خدمات مورد نیاز یا همبستگی دارد. این ابزار کمک میکند تا فرآیندهای پیچیده از سرویسهای میکرو ساخته شود.
همانطور که بررسی شد، ESB ابزاری برای یکپارچه کردن انواع برنامههای کاربردی که توسط چندین شرکت تهیه شده است و یک سیستم ارتباطی بین برنامههای نرمافزاری در تعامل در معماری سرویسگرا (SOA) پیادهسازی میکند و یک معماری نرمافزاری برای محاسبات توزیعشده ارئه میدهد. در واقع یک نوع خاص از مدل کلاینت-سرور است که در آن هر برنامه کاربردی به عنوان سرور و یا مشتری رفتار میکند. برتری این معماری در ماهیت غیر وابسته به زیرساخت و توانایی ادغام در هر شرایط پنهان است.
این تکنیک میتواند برای شرکتهای در تعامل با یکدیگر که هر یک سرویسی را ارائه میدهند و نیازمند یکپارچه سازی این سرویسها و برنامهها برای یک برنامه کاربردی اصلی اند، مفید باشد. برای مثال شرکت های ارائه دهنده خدمات زیرساخت ابری همانند ابر آروان و شرکتهای ارائه دهنده خدمات تحت یک برنامه وب همانند شرکت کوئرا میتوانند برای یکپارچگی برنامه خود از این تکنیک استفاده کنند. همچنین در یک شرکت مانند ترب برای یکپارچگی ارتباطات بخشها و سرویسهای مختلف میتواند مورد استفاده قرار گیرد.
«این مطلب، بخشی از تمرینهای درس معماری نرمافزار در دانشگاه شهیدبهشتی است»