گذرگاه سرویس سازمانی
گذرگاه سرویس سازمانی (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ها به ساخت دقیق مدل پیام سازمانی و طراحی صحیح عملکرد ارائه شده توسط برنامه‌ها متکی هستند. اگر مدل پیام عملکرد برنامه ای را به‌طور کامل کپسوله سازی نکند، برنامه‌های دیگری که تمایل دارند از این عملکرد استفاده کنند باید گذرگاه را کنار بگذارند و برنامه ناسازگار را مستقیماً فراخوانی کنند. انجام این کار اصول مدل ESB را نقض می‌کند و بسیاری از مزایای استفاده از این معماری را نفی می‌کند.
زیبایی ESB در ماهیت زیرساختی-غیر مقید و توانایی ادغام با هر چیزی و هر شرایطی نهفته‌است. مهم است که شرکتهای مدیریت چرخه حیات نرم‌افزار حین استفاده از SOA واقعاً تمام قابلیت‌های ESB را در محصولات یکپارچه خود اعمال کنند؛ بنابراین، چالش‌ها و فرصت‌های شرکتهای ارائه دهنده EAI ارائه یک راهکار یکپارچه است که کم هزینه، به راحتی قابل پیکربندی، بصری، کاربرپسند و برای هر ابزاری که مشتری انتخاب می‌کند باز باشد.
¹ "برخی‌ها، طراحی هماهنگی فرایندها را به عنوان عملکرد ESB در نظر نمی‌گیرند." "برای مثال، به م. ریچاردز مراجعه کنید."
² "در حالی که طراحی هماهنگی فرایندها از اجرای فرایندهای پیچیده کسب و کار که به هماهنگی چندین سرویس تجاری (معمولاً با استفاده از BPEL) نیاز دارد، پشتیبانی می‌کند، ارکستراسیون سرویس برای پاسخگویی به یک درخواست مستقل، امکان هماهنگی چندین سرویس پیاده‌سازی را فراهم می‌کند (که به‌طور مناسب به عنوان یک سرویس کلی نشان داده می‌شود) ."
این راه حل‌ها اغلب بر عملکردهای سطح پایین ESB مانند اتصال، مسیریابی و دگرگونی متمرکز هستند و برای اجرای ارکستراسیون به کدگذاری یا برنامه‌نویسی نیاز دارند. توسعه دهندگانی که در سطح یک پروژه یا سطح تاکتیکی کار می‌کنند، مثلاً فقط در تلاش برای حل یک مشکل، ببیشتر به سمت فناوری‌های متعلق به گذرگاه‌های سرویس سبک‌وزن (ساده) تمایل دارند، اما اغلب بین این راه اندازان ابتدایی و معماری سازمانی که هدف آن بهینه‌سازی زیرساخت در چندین پروژه است، تنش مداوم وجود دارد.
اگر کارگزار پیام سامانه ESB، پیامی را از یک قالب به قالب دیگر ترجمه کند، مانند هر ترجمه دیگری، مسئله تفسیر معنایی پیام وجود دارد.
به عنوان مثال، یک رکورد را می‌تواند از JSON به XML ترجمه کرد، اما یک برنامه ممکن است مجموعه ای از فیلدها را به شکلی تفسیر کند و برنامه دیگری همان مجموعه فیلد را به شکل دیگری.
به ویژه در موارد گوشه ای (موارد خاص) که معمولاً فقط برای توسعه دهندگانی قابل تفسیر هستند که تجربه زیادی در استفاده از برنامه ای داشته‌اند که اکنون می‌خواهیم به ESB متصل کنیم. در این گونه موارد، تعداد آزمایشهایی که همه موارد خاص را پوشش می‌دهد با افزودن هر نرم‌افزار متصل به ESB به‌طور تصاعدی افزایش می‌یابد، زیرا نرم‌افزار جدیداً متصل شده به ESB، باید در مقابل سایر برنامه‌هایی که به ESB متصل هستند، بصورت یک به یک آزمایش شود. محصولات قابل توجه عبارتند از: