گذرگاه سرویس سازمانی

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

 معماری 
مفهوم گذرگاه سرویس سازمانی مشابه مفهوم گذرگاه در معماری سخت‌افزار کامپیوتر است که همراه با طراحی ماژولار و همروند سیستم عامل‌های رایانه دارای کارایی-بالا ارائه می‌شود.
انگیزه توسعه این معماری، یافتن یک مفهوم استاندارد، ساختار یافته و همه منظوره برای توصیف پیاده‌سازی مولفه‌های نرم‌افزاری (در اینجا منظورسرویسها می‌باشد) که به روش همراهی آزادانه کار می‌کنند و انتظار می‌رود هر کدام بصورت مستقل در شبکه در حال کار بوده و با یکدیگر ناهمگن و ناهم شکل باشند. ESB همچنین یک الگوی پیاده‌سازی معمول برای معماری سرویس گرا می‌باشد که شامل طراحی ذاتی پذیرفته شده برای شبکه جهانی وب نیز می‌شود.

هیچ استاندارد جهانی برای مفاهیم یا پیاده‌سازی گذرگاه خدمات سازمانی وجود ندارد. اغلب ارائه دهندگان میان افزارهای پیام گرا مفهوم گذرگاه سرویس سازمانی را به عنوان استاندارد بالفعل برای معماری سرویس گرا پذیرفته‌اند. پیاده‌سازی‌های ESB از ترکیب میان افزار پیام محور مبتنی بر رویداد و میان افزار پیام محور مبتنی بر استانداردها و صف‌های پیام به عنوان چارچوب فناوری استفاده می‌کنند. با این حال، برخی از تولیدکنندگان نرم‌افزار بدون در نظر گرفتن جنبه‌های مهم مفاهیم گذرگاه، میان افزارهای قدیمی و راه حل‌های ارتباطی قبلی خود را مجدداً تحت عنوان عنوان ESB برچسب گذاری نموده‌اند!

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

وظایف اصلی ESB عبارتند از:
 مسیریابی پیام‌ها بین سرویس‌ها
 مانیتور و کنترل مسیریابی تبادل پیام بین سرویس‌ها
 حل اختلاف بین اجزای سرویس ارتباطی
 کنترل استقرار و نسخه بندی سرویس‌ها
 حکمروایی در استفاده از سرویسهای جایگزین
 خدمات تبادل سرویس مانند رسیدگی به رویدادها، تبدیل و نگاشت داده‌ها، صف بندی و ترتیب بندی پیامها و رویدادها، مدیریت امنیت یا استثنا، تبدیل پروتکلها و حاکم کردن کیفیت مناسب بر سرویسهای ارتباطی

 تاریخچه 
اولین استفاده از عبارت "گذرگاه سرویس سازمانی" به روی. دبلیو. شولت از گروه گارتنر ۲۰۰۲ و کتاب The Enterprise Service Bus نوشته دیوید چاپل نسبت داده شده‌است. اگرچه تعدادی از شرکت‌ها امتیاز این عبارت را متعلق به خودشان می‌دانند، اما شولت در مصاحبه ای گفت که اولین بار این عبارت را از یک شرکت به نام کندل (Candle)شنید و ادامه داد: "مستقیم‌ترین جد ESB، نرم‌افزار روما (Roma) محصول شرکت کندل بود که در سال ۱۹۹۸ ساخته شد. "

معمار ارشد و دارنده امتیاز این برنامه، گری آون بود. روما برای اولین بار در سال ۱۹۹۸ به فروش رسید که آنرا به اولین ESB تجاری در بازار تبدیل کرد، اما محصول سونیک (محصول سال ۲۰۰۲) نیز یکی از محصولات اولیه ESB در بازار بود.
 سرویس - برنامه‌های غیر تکراری و خودکار را نشان می‌دهد که از طریق تبادل پیام با سایر سرویسها ارتباط برقرار می‌کنند.
 گذرگاه- به دلیل شباهت عملکردش با گذرگاه سخت‌افزار کامپیوتر چنین نامیده می‌شود.
 سازمان - این مفهوم در اصل برای کاهش پیچیدگی یکپارچه سازی برنامه‌های سازمانی در یک شرکت یا سازمان ابداع شده بود. اما این محدودیت امروزه دیگر منسوخ شده‌است زیرا ارتباطات مدرن اینترنتی دیگر محدود به موجودیتهای یک نهاد، شرکت یا سازمان نیست.

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

برای رسیدن به این هدف، ESB باید قابلیتهای ارائه شده توسط اجزاء نرم‌افزاریش را به روش صحیحی کپسوله سازی کند. این امر معمولاً از طریق استفاده از مدل پیام سازمانی اتفاق می‌افتد. مدل پیام یک مجموعه استاندارد از پیام‌ها را تعریف می‌کند که ESB ارسال و دریافت می‌کند. وقتی ESB پیامی را دریافت می‌کند، پیام را به برنامه مناسب هدایت می‌کند. غالباً، برنامه دریافت کننده، قالب پیام دریافت شده را در خود پیاده‌سازی نکرده و در نتیجه آن مدل پیام را نمی‌تواند بخواند، درنتیجه ESB باید پیام را به قالبی تبدیل کند که برنامه بتواند آن را تفسیر کند. یک آداپتور نرم‌افزاری وظیفه ایجاد این تبدیلها را به روشی مشابه با آداپتور فیزیکی انجام می‌دهد.http://shop.oreilly.com/product/9780596006754.do

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

زیبایی ESB در ماهیت زیرساختی-غیر مقید و توانایی ادغام با هر چیزی و هر شرایطی نهفته‌است. مهم است که شرکتهای مدیریت چرخه حیات نرم‌افزار حین استفاده از SOA واقعاً تمام قابلیت‌های ESB را در محصولات یکپارچه خود اعمال کنند؛ بنابراین، چالش‌ها و فرصت‌های شرکتهای ارائه دهنده EAI ارائه یک راهکار یکپارچه است که کم هزینه، به راحتی قابل پیکربندی، بصری، کاربرپسند و برای هر ابزاری که مشتری انتخاب می‌کند باز باشد.
بندانگشتی| کندوی ESB از اجزای تبادل سرویس

 شاخصه‌ها 
دسته‌بندی کارکرد استعلام پشتیبانی از پروتکل‌های انتقال همزمان و ناهمزمان، نگاشت سرویس‌ها (پیدا کردن و متصل کردن) مسیریابی قابلیت آدرس دهی، مسیریابی ثابت / قطعی، مسیریابی مبتنی بر محتوا، مسیریابی مبتنی بر قوانین، مسیریابی مبتنی بر سیاست پادرمیانی آداپتورها، تبدیل پروتکل‌ها، نگاشت سرویس‌ها پیام رسانی پردازش پیام، تبدیل پیام و توسعه پیام طراحی هماهنگی فرایندها¹ اجرای فرایندهای پیچیده تجارت ارکستراسیون سرویس² هماهنگی سرویس‌های پیاده‌سازی متعدد که به عنوان یک سرویس واحد و تجمیع شده در معرض دید قرار دارند پردازش رویداد پیچیده تفسیر رویداد، همبستگی، تطبیق الگو کیفیت خدمات دیگر امنیت (رمزگذاری و امضا)، تحویل قابل اعتماد، مدیریت تراکنش مدیریت نظارت، ممیزی، لاگ برداری، اندازه‌گیری، کنسول مدیریت، مدیریت فعالیت‌های تجاری BAM (باید گفت BAM یک توانایی مدیریت نیست به عبارت دیگر ESB به یک آستانه خاص واکنش نشان نمی‌دهد. این یک قابلیت خدمات تجاری است که برای کاربران نهایی ظاهر می‌شود) مقید نبودن مقید نبودن عمومی به سیستم عامل‌ها و زبان‌های برنامه‌نویسی؛ به‌عنوان مثال، باید قابلیت همکاری بین جاوا و برنامه‌های دات‌نت را فراهم آورد تبدیل پروتکل پشتیبانی جامع از استانداردهای سرویس مربوط به پروتکل‌های ارتباطی موضوعی الگوهای تبادل پیام پشتیبانی از چندین MEP (الگوهای تبادل پیام) (به عنوان مثال: درخواست / پاسخ همزمان، درخواست / پاسخ ناهمزمان، ارسال و فراموش کردن، انتشار / اشتراک) آداپتورها آداپتورهای پشتیبانی از یکپارچگی با سیستم‌های قدیمی، احتمالاً براساس استانداردهایی مانند JCA امنیت یک مدل امنیتی استاندارد برای اجازه دادن، احراز هویت و حسابرسی استفاده از ESB دگرگونی تسهیل دگرگونی قالب‌ها و مقادیر داده‌ها به یکدیگر، از جمله سرویس‌های دگرگونی (اغلب از طریق XSLT یا XQuery) بین قالب‌های برنامه ارسال کننده و برنامه دریافت‌کننده اعتبار سنجی اعتبارسنجی در برابر اسکیما‌های ارسال و دریافت پیام حکم روایی توانایی اعمال قوانین تجاری به‌طور یکنواخت غنی سازی غنی سازی پیام از منابع دیگر تقسیم و ادغام تقسیم و ترکیب چندین پیام و مدیریت استثناها انتزاع - مفهوم - برداشت ارائه یک انتزاع واحد در چندین لایه مسیریابی و تحول مسیریابی یا تبدیل پیام‌ها به‌طور مشروط، براساس سیاست غیرمتمرکز (بدون نیاز به موتور اصلی قوانین) خدمات کالا بسته‌بندی سرویس‌های پرتقاضا به عنوان سرویس‌های اشتراکی بسته به زمینه
¹ برخی‌ها، طراحی هماهنگی فرایندها را به عنوان عملکرد ESB در نظر نمی‌گیرند. برای مثال، به م. ریچاردز مراجعه کنید.

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

این راه حل‌ها اغلب بر عملکردهای سطح پایین ESB مانند اتصال، مسیریابی و دگرگونی متمرکز هستند و برای اجرای ارکستراسیون به کدگذاری یا برنامه‌نویسی نیاز دارند. توسعه دهندگانی که در سطح یک پروژه یا سطح تاکتیکی کار می‌کنند، مثلاً فقط در تلاش برای حل یک مشکل، ببیشتر به سمت فناوری‌های متعلق به گذرگاه‌های سرویس سبک‌وزن (ساده) تمایل دارند، اما اغلب بین این راه اندازان ابتدایی و معماری سازمانی که هدف آن بهینه‌سازی زیرساخت در چندین پروژه است، تنش مداوم وجود دارد.

اگر کارگزار پیام سامانه ESB، پیامی را از یک قالب به قالب دیگر ترجمه کند، مانند هر ترجمه دیگری، مسئله تفسیر معنایی پیام وجود دارد.

به عنوان مثال، یک رکورد را می‌تواند از JSON به XML ترجمه کرد، اما یک برنامه ممکن است مجموعه ای از فیلدها را به شکلی تفسیر کند و برنامه دیگری همان مجموعه فیلد را به شکل دیگری.

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

 مزایای اصلی 
 مقیاس پذیری: از راهکارهای نقطه ای تا استقرار در کل سازمان را در بر می‌گیرد (گذرگاه توزیع شده)
 استفاده بیشتر ازپیکربندی نسبت به کد نویسی جهت یکپارچه سازی
 تمرکز زدایی: بدون موتور مرکزی قوانین، بدون هیچ کارگزار مرکزی
 وصل کردن و قطع کردن آسان و سیستم همراهی آزادانه

 معایب اصلی 
 سرعت ارتباط پایین‌تر، به ویژه برای سرویس‌هایی که از قبل سازگار بوده‌اند
 نقطه یکتای شکست، در صورت خرابی گذرگاه، ممکن است تمام ارتباطات موجود در سازمان قطع شود
 پیچیدگی بالای پیکربندی و نگهداری

 محصولات 
محصولات قابل توجه عبارتند از:

 Commercial
 Candle's Roma ESB - bought by IBM and became WebSphere ESB
 IBM App Connect, formerly IBM Integration Bus and IBM WebSphere ESB
 InterSystems Ensemble
 Information_Builders iWay Service Manager
 Microsoft Azure Service Bus
 Microsoft BizTalk Server
 Mule ESB
 Oracle Enterprise Service Bus
 Progress Software Sonic ESB (acquired by Trilogy)
 SAP Process Integration
 TIBCO Software ActiveMatrix BusinessWorks
 webMethods enterprise service bus (acquired by Software AG)
 Sonic ESB from Aurea
 Open-source software
 Apache Camel
 Apache ServiceMix
 Apache Synapse
 Fuse ESB from Red Hat
 JBoss ESB
 NetKernel
 Open ESB
 Petals ESB
 Spring Integration
 UltraESB
 WSO2 ESB

 جستارهای وابسته 
 الگوهای یکپارچگی سازمانی
 پیام رسانی رویدادگرا
 یکپارچگی تجاریجاوا
 مدیریت فرایند تجارت
 پلت فرم یکپارچه سازی عمومی
 یکپارچه سازی برنامه کاربردی تجاری
 ارائه دهنده خدمات کسب و کار
esb
 میان افزار پیام گرا
 پردازش رویداد پیچیده
 پردازش جریان رویداد
 برنامه‌نویسی مبتنی بر رویداد
 مقایسه نرم‌افزار یکپارچه سازی کسب و کار
 مقایسه موتورهای BPEL
 مقایسه موتورهای BPMN 2.0
 برنامه ترکیبی
 SOA رویداد گرا
 پلت فرم یکپارچه سازی به عنوان یک سرویس (iPaaS)

 منابع 

 بیشتر خواندن 
 دیوید چاپل، «گذرگاه سرویس سازمانی» (O'Reilly: ژوئن ۲۰۰۴ ،)
 Binildas A. Christudas، «یکپارچه سازی تجاری جاوا سرویس گرا» (ناشران Packt: فوریه ۲۰۰۸ ، ؛)
 مایکل بل، «مدل‌سازی سرویس گرا: تجزیه و تحلیل خدمات، طراحی و معماری» (2008 Wiley & Sons،)

 پیوند به بیرون 
 "مفهوم ماندگار یا جدیدترین واژه پوشالی؟" (Nicolas Farges، ۲۰۰۳)
 گذرگاه‌های سرویس سازمانی به راه افتادند: مرکز آزمون Infoworld (22 ژوئیه ۲۰۰۵)
 JSR-208:یکپارچه سازی تجاری جاوا (اوت ۲۰۰۵)
 نقش گذرگاه سرویس سازمانی (InfoQ - ارائه ویدئو) (۲۳ اکتبر ۲۰۰۶)
 گردهمایی ESB قسمت اول: تعریف ESB (InfoQ) (13 ژوئیه ۲۰۰۶)
 گردهمایی ESB قسمت دوم: استفاده از موارد (InfoQ) (5 ژوئیه ۲۰۰۶)
 "بافت سرویسها - بافت‌های خوب برای سیستم‌های عصر جدید" (Binildas A. Christudas، ۲۰۰۷)
 "ESBها در سال ۲۰۰۷: استفاده از گذرگاه منبع باز در SOA" (دنیس بایرون، ۲۰ سپتامبر ۲۰۰۷)
 سرویسهای یکپارچه ساز در ServiceMix JBI ESB: ناشران PACKT (Binildas A. Christudas، ۳۰ نوامبر ۲۰۰۷)
 جایگزینهایی توپولوژی ESB (InfoQ , A. Louis، ۲۳ مه ۲۰۰۸)
 بازنگری در ESB: ساخت یک گذرگاه سرویس ساده ، امن و قابل مقیاس با SOA Gateway

(Computerworld , J. Ryan، ۲۰۱۱)

 گذرگاه سرویس سازمانی ، بررسی مجدد (توسعه دهنده IBM Works , Greg Flurry و Kim Clark، مه ۲۰۱۱)

رده:خدمت‌گرا (رایانش کسب‌وکار)
رده:معماری نرم‌افزار
رده:میان‌افزار پیام محور
رده:واژه‌های ابداع‌شده در ۲۰۰۲ (میلادی)