موضوع مقاله: گذرگاه سرویس سازمانی | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # گذرگاه سرویس سازمانی | مقدمه: گذرگاه سرویس سازمانی (ESB) یک سیستم ارتباطی بین برنامه‌های نرم‌افزاری درحال تعامل مستقیم را در یک معماری سرویس گرا (SOA) پیاده‌سازی می‌کند. | ## بخش 1: گذرگاه سرویس سازمانی | ESB یک معماری نرم‌افزاری برای رایانش توزیع شده‌است و نوع خاصی از مدل کلی کلاینت-سرور است، که در آن هر برنامه ممکن است مانند سرور یا کلاینت رفتار کند. ESB چابکی و انعطاف‌پذیری را با توجه به پروتکل ارتباطی سطح بالا بین برنامه‌ها ارتقا می‌دهد. کاربرد اصلی ESB در یکپارچه سازی برنامه‌های سازمانی (EAI) متشکل از سرویسهای ناهمگن و پیچیده‌است. معماری مفهوم گذرگاه سرویس سازمانی مشابه مفهوم گذرگاه در معماری سخت‌افزار کامپیوتر است که همراه با طراحی ماژولار و همروند سیستم عامل‌های رایانه دارای کارایی-بالا ارائه می‌شود. انگیزه توسعه این معماری، یافتن یک مفهوم استاندارد، ساختار یافته و همه منظوره برای توصیف پیاده‌سازی مولفه‌های نرم‌افزاری (در اینجا منظورسرویسها می‌باشد) که به روش همراهی آزادانه کار می‌کنند و انتظار می‌رود هر کدام بصورت مستقل در شبکه در حال کار بوده و با یکدیگر ناهمگن و ناهم شکل باشند. ESB همچنین یک الگوی پیاده‌سازی معمول برای معماری سرویس گرا می‌باشد که شامل طراحی ذاتی پذیرفته شده برای شبکه جهانی وب نیز می‌شود. اغلب ارائه دهندگان میان افزارهای پیام گرا مفهوم گذرگاه سرویس سازمانی را به عنوان استاندارد بالفعل برای معماری سرویس گرا پذیرفته‌اند. پیاده‌سازی‌های ESB از ترکیب میان افزار پیام محور مبتنی بر رویداد و میان افزار پیام محور مبتنی بر استانداردها و صف‌های پیام به عنوان چارچوب فناوری استفاده می‌کنند. با این حال، برخی از تولیدکنندگان نرم‌افزار بدون در نظر گرفتن جنبه‌های مهم مفاهیم گذرگاه، میان افزارهای قدیمی و راه حل‌های ارتباطی قبلی خود را مجدداً تحت عنوان عنوان ESB برچسب گذاری نموده‌اند! کارکردها ESB مفهوم طراحی سیستم عامل‌های مدرن را برای سرویس‌های مستقل و در شبکه‌هایی متشکل از رایانه‌های متفاوت و مستقل اعمال می‌کند. مانند سیستم عامل‌های همروند، ESB علاوه بر تطبیق، ترجمه و مسیریابی درخواستهای مشتری به سوی سرویسهای پاسخگوی مناسب، خدمات تبادل سرویس را نیز ارائه می‌دهد. وظایف اصلی ESB عبارتند از: مسیریابی پیام‌ها بین سرویس‌ها مانیتور و کنترل مسیریابی تبادل پیام بین سرویس‌ها حل اختلاف بین اجزای سرویس ارتباطی کنترل استقرار و نسخه بندی سرویس‌ها حکمروایی در استفاده از سرویسهای جایگزین خدمات تبادل سرویس مانند رسیدگی به رویدادها، تبدیل و نگاشت داده‌ها، صف بندی و ترتیب بندی پیامها و رویدادها، مدیریت امنیت یا استثنا، تبدیل پروتکلها و حاکم کردن کیفیت مناسب بر سرویسهای ارتباطی تاریخچه اولین استفاده از عبارت "گذرگاه سرویس سازمانی" به روی. | ## بخش 2: گذرگاه سرویس سازمانی | اگرچه تعدادی از شرکت‌ها امتیاز این عبارت را متعلق به خودشان می‌دانند، اما شولت در مصاحبه ای گفت که اولین بار این عبارت را از یک شرکت به نام کندل (Candle)شنید و ادامه داد: "مستقیم‌ترین جد ESB، نرم‌افزار روما (Roma) محصول شرکت کندل بود که در سال ۱۹۹۸ ساخته شد. روما برای اولین بار در سال ۱۹۹۸ به فروش رسید که آنرا به اولین ESB تجاری در بازار تبدیل کرد، اما محصول سونیک (محصول سال ۲۰۰۲) نیز یکی از محصولات اولیه ESB در بازار بود. سرویس - برنامه‌های غیر تکراری و خودکار را نشان می‌دهد که از طریق تبادل پیام با سایر سرویسها ارتباط برقرار می‌کنند. سازمان - این مفهوم در اصل برای کاهش پیچیدگی یکپارچه سازی برنامه‌های سازمانی در یک شرکت یا سازمان ابداع شده بود. اما این محدودیت امروزه دیگر منسوخ شده‌است زیرا ارتباطات مدرن اینترنتی دیگر محدود به موجودیتهای یک نهاد، شرکت یا سازمان نیست. ESB به عنوان نرم‌افزار ESB اغلب بصورت سامانه ای نرم‌افزاری پیاده‌سازی می‌شود که بین برنامه‌های تجاری کار می‌کند و امکان برقراری ارتباط بین آنها را فراهم می‌کند. در حالت ایده‌آل، ESB باید بتواند تمام تماس‌های مستقیم را قطع و آنها را از طریق اتصالات نرم‌افزاری موجود در گذرگاه جایگزین کند، به طوری که تمام ارتباطات از طریق ESB انجام شود. برای رسیدن به این هدف، ESB باید قابلیتهای ارائه شده توسط اجزاء نرم‌افزاریش را به روش صحیحی کپسوله سازی کند. مدل پیام یک مجموعه استاندارد از پیام‌ها را تعریف می‌کند که ESB ارسال و دریافت می‌کند. غالباً، برنامه دریافت کننده، قالب پیام دریافت شده را در خود پیاده‌سازی نکرده و در نتیجه آن مدل پیام را نمی‌تواند بخواند، درنتیجه ESB باید پیام را به قالبی تبدیل کند که برنامه بتواند آن را تفسیر کند. یک آداپتور نرم‌افزاری وظیفه ایجاد این تبدیلها را به روشی مشابه با آداپتور فیزیکی انجام می‌دهد. ESBها به ساخت دقیق مدل پیام سازمانی و طراحی صحیح عملکرد ارائه شده توسط برنامه‌ها متکی هستند. | ## بخش 3: گذرگاه سرویس سازمانی | اگر مدل پیام عملکرد برنامه ای را به‌طور کامل کپسوله سازی نکند، برنامه‌های دیگری که تمایل دارند از این عملکرد استفاده کنند باید گذرگاه را کنار بگذارند و برنامه ناسازگار را مستقیماً فراخوانی کنند. انجام این کار اصول مدل ESB را نقض می‌کند و بسیاری از مزایای استفاده از این معماری را نفی می‌کند. زیبایی ESB در ماهیت زیرساختی-غیر مقید و توانایی ادغام با هر چیزی و هر شرایطی نهفته‌است. مهم است که شرکتهای مدیریت چرخه حیات نرم‌افزار حین استفاده از SOA واقعاً تمام قابلیت‌های ESB را در محصولات یکپارچه خود اعمال کنند؛ بنابراین، چالش‌ها و فرصت‌های شرکتهای ارائه دهنده EAI ارائه یک راهکار یکپارچه است که کم هزینه، به راحتی قابل پیکربندی، بصری، کاربرپسند و برای هر ابزاری که مشتری انتخاب می‌کند باز باشد. ² در حالی که طراحی هماهنگی فرایندها از اجرای فرایندهای پیچیده کسب و کار که به هماهنگی چندین سرویس تجاری (معمولاً با استفاده از BPEL) نیاز دارد، پشتیبانی می‌کند، ارکستراسیون سرویس برای پاسخگویی به یک درخواست مستقل، امکان هماهنگی چندین سرویس پیاده‌سازی را فراهم می‌کند (که به‌طور مناسب به عنوان یک سرویس کلی نشان داده می‌شود) . این راه حل‌ها اغلب بر عملکردهای سطح پایین ESB مانند اتصال، مسیریابی و دگرگونی متمرکز هستند و برای اجرای ارکستراسیون به کدگذاری یا برنامه‌نویسی نیاز دارند. توسعه دهندگانی که در سطح یک پروژه یا سطح تاکتیکی کار می‌کنند، مثلاً فقط در تلاش برای حل یک مشکل، ببیشتر به سمت فناوری‌های متعلق به گذرگاه‌های سرویس سبک‌وزن (ساده) تمایل دارند، اما اغلب بین این راه اندازان ابتدایی و معماری سازمانی که هدف آن بهینه‌سازی زیرساخت در چندین پروژه است، تنش مداوم وجود دارد. اگر کارگزار پیام سامانه ESB، پیامی را از یک قالب به قالب دیگر ترجمه کند، مانند هر ترجمه دیگری، مسئله تفسیر معنایی پیام وجود دارد. به عنوان مثال، یک رکورد را می‌تواند از JSON به XML ترجمه کرد، اما یک برنامه ممکن است مجموعه ای از فیلدها را به شکلی تفسیر کند و برنامه دیگری همان مجموعه فیلد را به شکل دیگری. به ویژه در موارد گوشه ای (موارد خاص) که معمولاً فقط برای توسعه دهندگانی قابل تفسیر هستند که تجربه زیادی در استفاده از برنامه ای داشته‌اند که اکنون می‌خواهیم به ESB متصل کنیم. | ## جمع‌بندی | در این گونه موارد، تعداد آزمایشهایی که همه موارد خاص را پوشش می‌دهد با افزودن هر نرم‌افزار متصل به ESB به‌طور تصاعدی افزایش می‌یابد، زیرا نرم‌افزار جدیداً متصل شده به ESB، باید در مقابل سایر برنامه‌هایی که به ESB متصل هستند، بصورت یک به یک آزمایش شود.