گذرگاه سرویس سازمانی
گذرگاه سرویس سازمانی (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 را نقض می‌کند و بسیاری از مزایای استفاده از این معماری را نفی می‌کند.
زیبایی ESB در ماهیت زیرساختی-غیر مقید و توانایی ادغام با هر چیزی و هر شرایطی نهفته‌است. مهم است که شرکتهای مدیریت چرخه حیات نرم‌افزار حین استفاده از SOA واقعاً تمام قابلیتهای ESB را در محصولات یکپارچه خود اعمال کنند؛ بنابراین، چالش‌ها و فرصت‌های شرکتهای ارائه دهنده EAI ارائه یک راهکار یکپارچه است که کم هزینه، به راحتی قابل پیکربندی، بصری، کاربرپسند و برای هر ابزاری که مشتری انتخاب می‌کند باز باشد.
شاخصه‌ها
[ویرایش]| دسته‌بندی | کارکرد |
|---|---|
| استعلام | پشتیبانی از پروتکل‌های انتقال همزمان و ناهمزمان، نگاشت سرویسها (پیدا کردن و متصل کردن) |
| مسیریابی | قابلیت آدرس دهی، مسیریابی ثابت / قطعی، مسیریابی مبتنی بر محتوا، مسیریابی مبتنی بر قوانین، مسیریابی مبتنی بر سیاست |
| پادرمیانی | آداپتورها، تبدیل پروتکلها، نگاشت سرویسها |
| پیام رسانی | پردازش پیام، تبدیل پیام و توسعه پیام |
| طراحی هماهنگی فرایندها¹ | اجرای فرایندهای پیچیده تجارت |
| ارکستراسیون سرویس² | هماهنگی سرویسهای پیاده‌سازی متعدد که به عنوان یک سرویس واحد و تجمیع شده در معرض دید قرار دارند |
| پردازش رویداد پیچیده | تفسیر رویداد، همبستگی، تطبیق الگو |
| کیفیت خدمات دیگر | امنیت (رمزگذاری و امضا)، تحویل قابل اعتماد، مدیریت تراکنش |
| مدیریت | نظارت، ممیزی، لاگ برداری، اندازه‌گیری، کنسول مدیریت، مدیریت فعالیت‌های تجاری 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
جستارهای وابسته
[ویرایش]- الگوهای یکپارچگی سازمانی
- پیام رسانی رویدادگرا
- یکپارچگی تجاریجاوا
- مدیریت فرایند تجارت
- پلت فرم یکپارچه سازی عمومی
- یکپارچه سازی برنامه کاربردی تجاری
- ارائه دهنده خدمات کسب و کار
- esb
- میان افزار پیام گرا
- پردازش رویداد پیچیده
- پردازش جریان رویداد
- برنامه‌نویسی مبتنی بر رویداد
- مقایسه نرم‌افزار یکپارچه سازی کسب و کار
- مقایسه موتورهای BPEL
- مقایسه موتورهای BPMN 2.0
- برنامه ترکیبی
- SOA رویداد گرا
- پلت فرم یکپارچه سازی به عنوان یک سرویس (iPaaS)
منابع
[ویرایش]- ↑ Lapeira, Raul. "ESB is an architectural style, a software product, or a group of software products?". Artifact Consulting. Archived from the original on 2014-08-08. Retrieved 2010-04-16.
The first thing a ESB architect should have in mind is that as of 2010 there is no global standard for ESB.
- ↑ McKendrick, Joe. "The great ESB squabble of 2005". ZDNet (به انگلیسی). Retrieved 2020-12-31.
- ↑ "Difference between a Message Broker and an ESB". Retrieved 2017-07-19.
- ↑ http://shop.oreilly.com/product/9780596006754.do
- ↑ Richards, Mark. "The Role of the Enterprise Service Bus (presentation)". Retrieved 2009-06-04.
I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability.
- ↑ Feraga, Matthias (6 Jun 2011). "How to: choosing between lightweight and traditional ESBs". Octo. Retrieved 23 April 2014.
- ↑ Fulton, Larry (12 Sep 2007). "Learn How to Embrace Lightweight ESBs". Fo2014. Archived from the original on 27 January 2022. Retrieved 27 March 2021.
بیشتر خواندن
[ویرایش]- دیوید چاپل، «گذرگاه سرویس سازمانی» (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، ۲۰۱۱)
- Louis, Adrien; Marc Dutoo (2010-07-02). "انتخاب بین مسیریابی و ارکستراسیون در یک ESB". InfoQ. Retrieved 2009-07-02.
- گذرگاه سرویس سازمانی ، بررسی مجدد (توسعه دهنده IBM Works , Greg Flurry و Kim Clark، مه ۲۰۱۱)