/ مدیریت / مدیریت فناوری

نرم افزارهای یکپارچه سازمانی - ESB

      مرتبط
         اولویت پروژه ESB
      جایگزین
      چه کاری می‌کند؟
      کی بخریم؟
      نمونه‌ها
      رابطه sso  و esb

ESB برگرفته شده از واژه‌های Enterprise Service Bus و بمعنای ابزاری برای یکپارچه کردن انواع برنامه‌های کاربردی که توسط چندین شرکت تهیه شده است. بعبارت دیگر ESB بستر مناسبی برای یکپارچگی کل نرم‌افزارهای سازمان فراهم می‌آورد؛ بطوریکه امروزه در سطح دنیا، بسیاری از شرکتهای قدرتمند و مشهور در زمینه ESB فعالیت دارند.
-    اما بطور عمیق‌تر مفهوم ESB چیست؟
-    ESB چگونه یکپارچگی بین نرم‌افزارهای سازمان را فراهم می‌آورد؟
-    ESB از چه رویکردهایی برای یکپارچه‌سازی پشتیبانی می‌کند؟
    آیا الگوهای استانداردی در زمینه یکپارچه‌سازی نرم‌افزارهای سازمان وجود دارد؟
    ضرورت بکارگیری ESB برای سازمان‌هایی که از نرم‌افزارهای مختلف استفاده می‌کنند چقدر است؟
    آیا شرکتهای بزرگ دنیا مثل ebay، Amazon، Fujitsu، Dell و … هم از ESB بهره می‌برند؟
    ارتباط ESB با BPMS چگونه است؟
-    ESB چگونه می‌تواند باکمک BPMS، نرم‌افزارهای سازمان یا فرآیندهای سازمان را یکپارچه کند؟

مفهوم ESB
ESB را در سه سطح می‌توان دسته‌بندی کرد که در شکل زیر آنها را مشاهده می‌نمایید:

-    سطح اول ابزارهایی هستند که صرفا برای یکپارچه‌سازی نرم‌افزارهای سازمان استفاده می‌شوند و اصطلاحاً به آنها Integration Framework می‌گویند.
-    سطح دوم ESBها، سطح گسترده‌تری از Integration Frameworkها هستند که به آن «اتوبوس خدمات سازمان» یا همان ESB گفته می‌شود.
-    سطح سوم ESBها نیز که به آن Integration Suite می‌گویند، ترکیبی از ESBها و BPMSها هستند که علاوه بر یکپارچه‌سازی نرم‌افزارهای سازمان، قابلیت یکپارچه کردن فرآیندهای سازمان را نیز با نرم‌افزارها فراهم می‌کند بطوریکه در سازمان، میتوان یک یکپارچگی کامل ایجاد نمود.

در ادامه به بررسی هر سه بخش فوق می‌پردازیم:

1. چارچوبی برای یکپارچه‌سازی (Integration Framework): Integration Frameworkها به پیاده‌سازی الگوهای یکپارچه‌سازی استاندارد کمک می‌کنند. برای آشنایی با الگوهای یکپارچه‌سازی، می‌توانید به سایت http://www.eaipatterns.com مراجعه نمایید.
   از Splitter و Content base routers می‌توان بعنوان نمونه‌هایی از الگوهای استاندارد یکپارچه‌سازی نام برد. دستوراتی که بصورت API در این ابزارها وجود دارند به برنامه نویسان اجازه می‌دهد تا بتوانند بصورت شفاف و قابل فهم نرم‌افزارها را با یکدیگر یکپارچه نمایند.
   Nservice Bus، Apache Camel و Spring Integration نمونه‌هایی از این چارچوبهای کاری هستند. NService Bus بمنظور استفاده در محیط .Net و Apache Camel و Spring Integration بمنظور استفاده در محیط Java می‌باشند. توسط این چارچوب‌های کاری بسیاری از فعالیت‌های تیمی خلاصه شده و ضریب موفقیت پروژه افزایش می‌یابد.
2. اتوبوس خدمات سازمان (Enterprise Service Bus): همانند Integration Frameworkها، ESBها نیز باعث ایجاد یکپارچگی در سطح برنامه‌های کاربردی سازمان می‌شوند. پایه ESBها نیز Integration Frameworkها هستند ولی قدرت و توان بسیار بالاتری نسبت به چارچوبهای کاری دارند.
   ESBها ابزارهای قدرتمندی علاوه بر یکپارچه‌سازی، برای انتشار (Deployment)، مدیریت (Administration) و پایش، در زمان اجرا دارند. محیط گرافیکی آنها بستر بسیار کارآمدی را برای پیاده‌سازی سناریوهای مختلف یکپارچه‌سازی فراهم می‌آورد. عملیات یکپارچه‌سازی بصورت گرافیکی و با Drag & Drop و بدون برنامه‌نویسی گسترده انجام می‌شود. ابزارهای ESB مزیت فوق‌العاده‌ای را درخصوص کاهش هزینه و رفع پیچیدگی‌های یکپارچه‌سازی فراهم می‌آورد.
3. مجموعه کامل یکپارچه‌سازی (Integration Suite): ساختار فناوری اطلاعات سازمان از افراد، فرآیندها و برنامه‌های کاربردی تشکیل شده است، بنابراین برای ایجاد یکپارچه‌سازی کامل در سطح سازمان باید کلیه عناصر مطرح شده با یکدیگر به نحو مناسبی ارتباط برقرار نمایند. همانگونه که در بخش ESB مطرح شد، ESB‌ها تنها قابلیت یکپارچگی در سطح برنامه‌های کاربردی را داشتند اما برای ایجاد یکپارچگی بین تمام عناصر موجود در سازمان اعم از افراد، فرآیندها و برنامه‌های کاربردی ضروریست تا از قابلیت‌های سیستم‌های BPM نیز در کنار ESBها بهره برد تا با بکارگیری فعالیت‌های این سیستم‌ها در کنار یکدیگر یکپارچگی کامل را در سطح سازمان ایجاد نمود.

سیستمهای BPM، فرآیندها و افراد را به یکدیگر متصل می‌کند و برنامه‌های کاربردی نیز از طریق ارتباط تنگاتنگ BPM و ESB به افراد و فرآیندها متصل می‌شوند. از این روست که شرکتهای بزرگ دنیا که بدلیل نیازهای انکارناپذیر از سیستم‌های متفاوت استفاده می‌نمایند، در سطح جامعی یکپارچه هستند و از مزایای آن بهره می‌برند.
در پایان میتوان به نام برخی از نرم‌افزارهای ESB مطرح در دنیا اشاره نمود:
-     IBM Websphere
-     dBoss EAP
-     WSO2
-     Mule ESB
-     Oracle ESB

مرتبط

java - PHP and ESB (with Mule) (ESB: Enterprise Service Bus) - Stack Overflow

5 Excellent Open Source ESB (Enterprise Service Bus) Alternatives - FROMDEV

اولویت پروژه ESB

۱. بررسی و تصویب اولویت پروژه ESB طبق اعلام نظر کارگروه تعیین شده در جلسه ۲۴ کمیته 
۲. گزارش اقدامات صورت گرفته در خصوص پروژه ESB 
۳‌. بررسی و تامین نیازهای فرآیندی جهت اجرای پروژه ESB

جهت خرید (تعیین قیمت)، استقرار و بهره برداری از زیرساخت ESB نیاز به ۳ مورد ذیل وجود دارد:
۱. تهیه و استقرار سامانه ESB
۲. شناسایی اطلاعات مورد نیاز جهت تبادل بین بخشی در فرآیندهای سازمانی جهت پوشش عملیات سازمان
۳. تولید وب سرویس‌ها و میکروسرویس‌های مورد نیاز جهت تبادل اطلاعات بر روی ESB

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

ضمنا شرکت مجری ESB نیز برای نهایی کردن قیمت و همچنین زمانبندی استقرار، نیاز به مشخص شدن تعداد و حجم سرویس‌ها دارد.

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

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

۱) Service Mesh – «شبکهٔ خدمات» برای ترافیک درون‌سازمانی

جایگزین	چه کاری می‌کند؟	کی بخریم؟	نمونه‌ها
Service Mesh	لایهٔ زیرساخت مجزّا برای ارتباط شرق-به-غرب بین پادها / میکروسرویس‌ها (کشف سرویس، mTLS، رهگیری، circuit-breaking، مدیریت ترافیک Canary و …) بدون نیاز به تغییر کد	وقتی ده‌ها تا صدها میکروسرویسِ کانتینری روی Kubernetes دارید و نیاز به سیاست یکپارچهٔ امنیت و مشاهد‌پذیری دارید	Istio، Linkerd، Consul، AWS App Mesh servicemesh.es

مزایا: رمزگذاری خودکار، رصد متمرکز، جدا شدن concerns‌ متقاطع از کد.
هزینه/ریسک: مصرف CPU/RAM و منحنی یادگیری بالا؛ اگر فقط چند سرویس دارید Mesh پیچیدگی زائد است.

۲) API Gateway – «درِ ورودی» ترافیک بیرونی

جایگزین	چه کاری می‌کند؟	کی بخریم؟	نمونه‌ها
API Gateway	نقطهٔ ورودی واحد برای شمال-به-جنوب؛ احراز هویت/مجاز‌سازی، محدودسازی نرخ، تبدیل پروتکل، نسخه‌بندی و مانیتورینگ API	هر زمان سرویس‌های پشت صحنه را می‌خواهید در برابر مشتری یا موبایل محافظت و ساده کنید؛ حتی اگر هنوز تک‌سرویسید	Kong، NGINX, Amazon API Gateway, Apigee MediumAWS Documentation

نکتهٔ کلیدی: API Gateway و Service Mesh مکمل همند؛ اولی «دروازه» لبهٔ سیستم است، دومی «مسیر» داخل سیستم.

---

۳) Message Broker / Event-Driven Arcitecture – «چسبِ ناهمزمان»

جایگزین	چه کاری می‌کند؟	کی بخریم؟	نمونه‌ها
Broker (Kafka, RabbitMQ…)	صف/استریم پیام برای ارتباط ناهمزمان، انتشار/اشتراک، جداسازی تهیه-کننده و مصرف-کننده، تکرارپذیری رویداد	رویدادهای هم‌زمان زیاد، پردازش آنی، سست‌کوپل کردن دامنه‌ها، یا مهاجرت تدریجی از ESB	Apache Kafka، RabbitMQ، Pulsar ConfluentRabbitMQ

مزایا: مقیاس‌پذیری افقی، تحمل خطا، پشتیبانی از جریان رویداد در لحظه.
چالش: تغییر مدل ذهنی از RPC به رویداد؛ ردیابی End-to-End سخت‌تر، نیاز به الگوهای سِگا (Saga)، DLQ و … .

---

۴) Middleware Platform / iPaaS – «ESB ابریِ سبک»

جایگزین	چه کاری می‌کند؟	کی بخریم؟	نمونه‌ها
iPaaS / Cloud Integration	پلتفرم SaaS برای اتصال SaaS-ها، دیتابیس‌ها، API-ها و اتوماسیون جریان‌های کاری با کانکتورهای آماده	وقتی بیشتر سرویس‌ها در Cloud هستند و تیم کوچک می‌خواهد سریع یکپارچه کند بدون نگه‌داری زیرساخت	Celigo, Workato, Boomi, MuleSoft CloudHub Celigo

برتری نسبت به ESB: مدل اشتراکی، صورتحساب بر اساس مصرف، به‌روزرسانی خودکار در پشت صحنه.
محدودیت: سناریوهای on-prem سنگین یا latency بحرانی ممکن است مناسب نباشد.

چگونه مسیر مهاجرت از ESB را طراحی کنیم؟

1. دامنه-بندی: سرویس‌ها را بر اساس bounded-context (DDD) جدا کنید و وابستگی‌های گذرگاه را شناسایی کنید.

2. الگوی Strangler: ابتدا یک قابلیت از ESB جدا کرده و پشت Gateway یا Broker قرار دهید، در حالی که باقی سامانه روی ESB می‌چرخد.

3. خرد کردن تدریجی: برای تماس‌های هم‌زمان REST → API Gateway، برای رویدادها → Broker، و برای سیاست‌های شبکه → Service Mesh.

4. زیرساخت ابری/کانتینری: Mesh و Gateway معمولاً روی Kubernetes استقرار می‌یابند؛ برنامهٔ Capacity Planning و Observability را از روز اول در نظر بگیرید.

5. Governance جدید: Logging متمرکز، Tracing (OpenTelemetry)، مدیریت نسخهٔ API، و سیاست دسترسی در لایه‌های جدید پیاده کنید.

یک راهنمای سریع انتخاب

• ارتباط خارجی + امنیت/نرخ-محدودی؟ → API Gateway

• ارتباط داخلی بین ده‌ها میکروسرویس؟ → Service Mesh

• پردازش ناهمزمان، رویداد زمان‌واقعی، یا صف طولانی؟ → Kafka / RabbitMQ

• تعداد زیادی SaaS و دادهٔ ابری با تیم کوچک؟ → iPaaS

در عمل سازمان‌های بزرگ اغلب هرسه لایهٔ Gateway + Mesh + Broker را هم‌زمان به کار می‌گیرند و تنها نقش تاریخی ESB را به تدریج بازنشسته می‌کنند.

رابطه sso  و esb

رابطه بین SSO (Single Sign-On) و ESB (Enterprise Service Bus) از نوع تعاملی در سطح زیرساخت امنیت و مدیریت هویت است. این دو فناوری در معماری‌های سازمانی مکمل یکدیگرند، ولی کارکرد آن‌ها متفاوت است. در ادامه، این رابطه را به صورت دقیق و مرحله‌ای توضیح می‌دهم:
🔑 1. تعریف مفاهیم اولیه
فناوری    نقش اصلی
SSO (ورود یک‌باره)    فراهم‌سازی ورود یک‌باره کاربر به چند سامانه با یکبار احراز هویت.
ESB (گذرگاه خدمات سازمانی)    مسیر مرکزی برای ارتباط، هماهنگ‌سازی و تبدیل پیام بین سرویس‌های نرم‌افزاری مختلف.
🔄 2. نقاط اتصال SSO و ESB در معماری سازمانی
موضوع    نقش SSO    نقش ESB    تعامل چگونه شکل می‌گیرد؟
احراز هویت کاربران نهایی (مثلاً کارکنان)    ورود یک‌باره با توکن (مثل SAML, OAuth, JWT)    دریافت درخواست کاربر از Frontend یا API Gateway    ESB نیاز به اعتبارسنجی توکن از طریق SSO دارد قبل از ارسال درخواست به سرویس‌ها
مجوزدهی سطح سرویس‌ها (Service Authorization)    تعیین سیاست‌های دسترسی به سرویس‌ها    اجرای مسیرها و فراخوانی سرویس‌های backend    ESB ممکن است توکن را به سرویس‌ها انتقال دهد یا قبل از فراخوانی، آن را ارزیابی کند
ثبت وقایع امنیتی    ارائه اطلاعات احراز هویت    مصرف یا ذخیره اطلاعات کاربر در لاگ‌ها    اطلاعات کاربر احراز شده توسط SSO در ESB ثبت یا انتقال می‌یابد
هماهنگی با IAM    بخشی از زیرساخت Identity & Access Management    مصرف‌کننده اطلاعات هویتی برای تصمیم‌گیری    ESB باید با SSO یا IAM مرکزی سازمانی یکپارچه شود (از طریق LDAP، OAuth2، OpenID Connect و ...)
🎯 مثال کاربردی:
سناریو:

کاربری از طریق یک پورتال وارد سیستم می‌شود و نیاز دارد به سامانه‌های متعددی دسترسی داشته باشد (HR، حسابداری، ERP، CRM). این سامانه‌ها به‌صورت سرویس‌محور از طریق ESB یکپارچه شده‌اند.
جریان:

    کاربر با SSO (مثلاً Keycloak یا Azure AD) وارد می‌شود و یک توکن JWT دریافت می‌کند.

    پورتال یک درخواست HTTP به یکی از APIهای ESB می‌فرستد، توکن را در Header می‌گذارد.

    ESB با ماژول امنیتی خود، اعتبار توکن را با SSO یا Authorization Server بررسی می‌کند.

    در صورت تأیید، درخواست را به سرویس هدف (مثلاً سیستم منابع انسانی) منتقل می‌کند.

    پاسخ برگشتی به کاربر ارسال می‌شود — بدون نیاز به احراز هویت مجدد.

✅ جمع‌بندی رابطه
ESB بدون SSO    مشکلات زیادی در احراز هویت و نگهداری اعتبار کاربران در سیستم‌های پراکنده دارد.
SSO بدون ESB    در سازمان‌های دارای سرویس‌های توزیع‌شده نیازمند واسطه‌ای برای جریان توکن‌هاست.
✅ با هم:

SSO و ESB در کنار هم می‌توانند:

    امنیت احراز هویت و مجوزدهی متمرکز فراهم کنند.

    تجربه کاربری بهتر ایجاد کنند.

    مدیریت هویت و دسترسی‌ها را ساده‌تر و مقیاس‌پذیرتر کنند..

نام صحیح	توضیح کوتاه
Okta (اوکتا)	پلتفرم بسیار معروف مدیریت هویت و SSO ابری برای شرکت‌ها
Auth0 (اُث-زیرو یا آت-صفر)	سرویس محبوب برای احراز هویت و SSO، حالا زیرمجموعه Okta
Keycloak	SSO و مدیریت دسترسی متن‌باز، ساخته‌شده توسط Red Hat
ForgeRock	راهکار قدرتمند IAM سازمانی
OneLogin	پلتفرم SSO برای کسب‌وکارها
JumpCloud	پلتفرم جامع ابری برای هویت، دایرکتوری و SSO