هر چقدر یک سازمان نرم افزاری بزرگ تر باشد و پروژه های آن مربوط به بیزینس های بزرگ و پیچیده تری باشد، یا بخواهد در لحظه به تعداد زیادی از کاربران خدمات ارائه دهد، این خدمات را در قالب سرویس هایی ارائه می کند که قابلیت دسترسی هم از طریق بخش های دیگری درون سازمان مهیا باشد، هم از خارج سازمان بتوان به آن ها داشت. به عنوان مثال اگر یک سازمان توسعه دهنده خدمات بانکی را در نظر بگیرید، درون سازمان تیم های مختلفی روی بخش های متفاوتی از سامانه های بانکی کار می کنند که نیاز دارند از یکدیگر سرویس بگیرند، مثلا برای افتتاح حساب، نیاز است که اطلاعات هویتی مشتری از تیم دیگری دریافت شود؛ همچنین سرویس هایی مثل همین اطلاعات هویتی مشتری می تواند از خارج از سازمان در شعب بانک ها صدا زده شود و ارتباط لزوما دیگر محدود به داخل سازمان نباشد.
حال که اهمیت وجود این سرویس های داخلی و خارجی مشخص شد، باید روش برای ایجاد این ارتباط درون و برون سازمانی در نظر گرفته شود؛ مسلما اگر این ارتباط بخواهد نقطه به نقطه باشد، عدم وجود یک زبان مشترک، مشکل ساز خواهد شد. زیرا لزوما این سرویس ها یکسان پیاده سازی نشده اند و برای فهم هر کدام توسط مقصد، باید یک واسطی جهت ترجمه و یکسان سازی وجود داشته باشد. این نقطه جایی است که Enterprise service bus یا گذرگاه سرویس سازمانی اهمیت خود را نشان می دهد. گذرگاه سرویس سازمانی یک گذرگاه مشترک برای تمام وب سرویس های یک سازمان است که ممکن است با پروتکل های مختلفی بخواهند با هم ارتباط برقرار کنند و کار این گذرگاه ترجمه پیام از سمت مبدا و انتقال آن به مقصد خواهد بود.
در ادامه ضرورت وجود گذرگاه سرویس سازمانی، می توان به امکان متعادل سازی بار در شبکه، ارسال ناهمگام پیام ها و تبدیل پروتکل های ارتباطی به هم اشاره کرد. زیرا اگر این ارتباط بین بخش های مختلف در هر زمانی که هر کدام نیاز به سرویس داشته باشند، بخواهد نقطه به نقطه به یکدیگر متصل شوند، حتی اگر از پروتکل های ارتباطی یکسانی استفاده کنند، بار در شبکه خیلی زیاد خواهد شد و ممکن است سرویس دهنده نتواند به درخواست پاسخ دهد. همچنین مدیریت این سرویس ها اگر به صورت یکپارچه نباشد، زمینه ساز بروز مشکلات امنیتی و ساختاری فراوان خواهد شد. اگر همان سیستم بانکی را در نظر بگیرید که روزانه حجم زیادی تراکنش توسط سرویس ها در آن انجام می شود که مدیریت آن ها صرفا از طریق یک گذرگاه مشترک امکان پذیر خواهد بود. همچنین اگر یک یا چند وب سرویس در یک سازمان تغییر کند، با وجود یک گذرگاه مدیریتی مشترک، نیاز به اطلاع رسانی به تک تک سرویس گیرنده ها نخواهد بود.
طبق توضیحات کلی که تا الان داده شد، این گذرگاه ابزاری برای یکپارچه سازی مدیریت بین وب سرویس هاست اما در حقیقت در سطوح مختلفی می توان از ابزار های ESB استفاده کرد. زیرا گذرگاه یک مفهموم انتزاعی است و در هر کاری با توجه به نیاز باید از سطح مختلفی استفاده کرد.
Integration framework
انتقال داده از یک گذرگاه مشترک همان مفهموم یکپارچه سازی است و ابزارهایی مثل apache camel، spring integration برای پیاده سازی آن ها در زبان جاوا مناسب هستند.
Enterprise service bus
در این سطح علاوه بر دستیابی به هدف یکپارچه سازی تعاملات برنامه ها، ابزارهای مفیدی برای انتشار و مدیریت و پایش نیز وجود دارد
Integration suite
تا الان وجود گذرگاه های مشترک بین برنامه های کاربردی مطرح بود اما اگر این گذرگاه ها بخواهد در سطح سازمان پیاده شود، یعنی یکپارچگی بین تمام عناصر موجود در سازمان، از جمله افراد و فرآیند ها و نقش ها نیز انجام شود، لازم است از سیستم های مدیریت کسب و کار مثل BPM نیز در کنار سیستم های یکپارچه سازی سرویس ها استفاده شود که به آن یک مجموعه برای مدیریت یکپارچگی گفته می شود. در شکل زیر مثالی از آن در یک سیستم حسابداری آمده است.
MuleEsb
این ابزار هم امکان Integration و هم esb را فراهم می کند که در سال 2003 توسعه داده شد.
Wso2
یک نرم افزار بر پایه معماری سرویس گرا است که توسط کارمندان سابق شرکت آی بی ام در سال 2005 توسعه داده شد.
نرم افزار یکپارچه سازی توسعه داده شده توسط این شرکت ها، ارتباط بین نرم افزارها و سرویس های داخلی و خارجی یک سازمان را فراهم می کند و امکان مدیریت پیام های بین نرم افزاری، پایش و اعمال سطوح دسترسی مختلف در آن وجود دارد.
https://www.innovativearchitects.com/KnowledgeCenter/business-connectivity/ESB-EAI-SOA.aspx
https://platco.ir/tag/esb-software/
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
