گذرگاه سرویس سازمانی
تاریخچه > ESB به عنوان نرم‌افزار > شاخصه‌ها

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