معرفی روش WSO2

مقدمه

یکی از مشکلات مشترک فناوری اطلاعات اکثر سازمان¬ها در کشور، بحث عدم یکپارچگی سرویس¬های نرم¬افزاری و بانک¬های اطلاعاتی است. حتی تحقیقات جهانی نشان می¬دهد که این مشکل فقط مخصوص به ایران نیست به طوری که در ارزیابی صورت گرفته از مدیران فناوری اطلاعات شرکت¬های بزرگ جهانی مشخص شده که بالاترین اولویت کاری اکثر آن¬ها " یکپارچه سازی و سرویس¬گرایی " بوده است. برای انجام یکپارچه¬سازی تاکنون چندین روش و فناوری در طی سال¬ها توسعه یافته است که کامل-ترین و جدیدترین آن¬ها گذرگاه سرویس سازمانی (ESB) است.

گذرگاه سرویس باس ESB از یک سو، SOA برنامه¬ها و ویژگی¬های کسب وکار را به عنوان سرویس از طریق یک رابط پیدا می¬کند. از سوی دیگر ESB می¬تواند از این رابط استفاده کند. الگوی SOA و همزمانی با یکدیگر، سیستم¬های پیچیده¬ای را به دنبال استانداردهای باز تشکیل می¬دهند که برای کسب و کارها از اهمیت حیاتی برخوردار است.

•به عنوان یک راه¬حل برای یکپارچه¬سازی برنامه¬های کاربردی ناهمگن به دنیا آمده و بنابراین نشان داده¬شده که یک راه¬حل یکپارچه¬سازی قوی بر اساس استانداردهای باز و به عنوان مبنایی برای محیط¬های پیچیده SOA می¬باشد.

•در زمینه شبکه¬های توزیع شده و کاربردهای وابسته به شل که توسط SOA ارائه شده، یک روش جدید برای یکپارچه-سازی است، همچنین به عنوان یک لایه میان¬افزار دیده می¬شود که امکان یکپارچه¬سازی برنامه¬های کاربردی ناهمگن را فراهم می¬کند.

ویژگی¬های اساسی ESB

مجازی¬سازی : مجازی¬سازی به عنوان یک Proxy برای ارائه دهنده سرویس عمل می¬کند و درخواست¬های مشتری را مدیریت می¬کند. مشتری می¬تواند اعتبار، اجازه و حسابرسی را مدیریت کند، بنابراین ارائه دهنده سرویس می¬تواند صرفا بر منطق تجاری تمرکز کند.

میانجی¬گری : میانجی¬گری یا انتقال پیام؛ در این نقش، شرکت کنندگان قابلیت دریافت درخواست ورودی و انتقال بار مفید پیام، قبل از ارسال آن به سرویس وب نهایی را دارند.

مسیریابی : در این نقش، کاربر قابلیت عبور از درخواست¬های ورودی را روی یک نقطه پایانی به سرویس مناسب دارد. کاربران می¬توانند به طیف گسترده¬ای از چیزهایی مانند محتوای پیام یا سرصفحه پیغام نگاه کنند تا تعیین کنند که چگونه درخواست باید روندیابی شود.

این ویژگی¬ها به عنوان ویژگی¬های اصلی یک برنامه کاربردی شناخته شده¬اند و باید ادغام شوند.

انواع میان¬افزارهای ESB

محصولات زیادی به عنوان ESB به بازار عرضه شده¬اند که هر یک دارای امکانات مختلف و متفاوتی می¬باشند. متاسفانه استانداردی برای تعریف دقیق ویژگی¬های یک میان¬افزار ESB وجود ندارد و از این رو قبل از استفاده از هر یک از محصولات باید بدانید که دقیقا از ESB چه انتظاراتی دارید و متناسب با آن محصول مربوطه را انتخاب نمایید. معمولا محصولاتی که به عنوان ESB به باز عرضه می¬شوند را می¬توان در سه سطح مختلف دسته¬بندی کرد.

•سطح اول ESB ها، میان¬افزارهایی هستند که صرفا برای یکپارچه¬سازی نرم¬افزارهای سازمان استفاده می¬شوند و اصطلاحاً به آن¬ها Integration Frafnework می¬گویند. برای یکپارچه¬سازی استانداردهای مختلفی وجود دارد که از Splitter وContentbase Routers می¬توان به عنوان نمونه¬هایی از این الگوهای استاندارد نام برد.

•سطح دوم، سطح گسترده¬تری از Integration Framework ها هستند که به آن" گذرگاه خدمات سازمان " یا همان ESB گفته می¬شود. این گروه از ابزارها امکانات مناسبی برای Develop و مانیتورینگ و مدیریت (Administration) در زمان اجرا را فراهم می¬کنند و محیط گرافیکی آن¬ها بستر بسیار کارآمدی را برای پیاده¬سازی سناریوهای مختلف یکپارچه¬سازی فراهم می¬آورد.

•سطح سوم ابزارها که به آن Integration Suite می¬گویند، ترکیبی از ESB ها و BPMS ها هستند که علاوه بر یکپارچه¬سازی نرم¬افزارهای سازمان، قابلیت یکپارچه کردن فرآیندهای سازمان را نیز با نرم¬افزارها فراهم می¬کند به طوری که در سازمان، می¬توان یکپارچگی کامل ایجاد نمود.

شناسایی نیاز به سفارش پیغام

دستور پیغام می¬تواند با روش¬های گوناگون به دست آید. سفارش پیغام می¬تواند با پیکربندی Proxy ها که مولف به صراحت این اتفاق را مشخص می¬کند، تضمین شود. اگر قبل از این که رابطه بیان شود، پیغام فرستاده نشده باشد، یک پیام نمی¬تواند دریافت شود. بسته¬ها چون به دلیل تاخیر شبکه ارسال می¬شوند، می¬توانند به ترتیبی متفاوت وارد شوند و گاهی اوقات حتی اندازه می¬تواند منجر به اولویت دادن به بسته¬های کوچک¬تر شود. جایگزین¬های دیگری برای سفارش پیام، مثل اضافه کردن یک برچسب و اصلاح Proxy می¬توان نام برد. زمانی که یک برچسب اضافه می¬شود، هر دو طرف کانال باید بر روی برچسب و توالی اولیه توافق کنند. هنگام اصلاح، Proxy انتهای مقصد کانال انتظار دریافت پیام¬های برچسب دار را دارد و اگر آن¬ها از رده خارج شوند دوباره سفارش خواهد داد.

در زمان¬های دیگر، هر زیرساخت روش خاص خود برای اجرای سفارش پیام دارد. برای مثال، محصول WSO2 به چند مولفه تکیه دارد. اولا کاربران (مشتریان سرویس وب) چگونه باید از سرویس استفاده کنند، ثانیا کاربران معمولا از یک مرورگر وب استفاده می¬کنند و ثالثا سیستم ESB مسئول مسیریابی آن به ارائه دهنده مربوطه خود خواهد بود. هنگامی که از طریق یک واسط، پیغام از شارژ ذخیره زمانی پیغام¬ها عبور می¬کند، آن¬ها به ترتیب پردازش خواهند شد و در نهایت سرویس دهنده خدمات اطلاعاتی، مسئول نوشتن در پایگاه دادهاست.

اگر چه به بسیاری از تکنیک¬های دستور دهنده پیام توصیه می شود که از نرم¬افزار اختصاصی استفاده کنند مانند تغییر Proxy و اضافه کردن برچسب¬ها. یک روش کلی¬تر برای سفارش دادن پیام، روش بهینه برای کاهش سربار با اجرای رابطه وابستگی فوری IDR است که در حقیقت، می¬تواند تحویل پیام¬ها در ارتباطات گروهی را تضمین کند و به طور قابل توجهی مقدار اطلاعات کنترلی را کاهش دهد؛ اطلاعات در هر پیام برای حفظ تمامیت داده¬ها انجام می¬شود.

مقایسه ابزار WSO2 ESB با Mule ESB وApigee :

WSO2 ESB:

§ سبک وزن، کارایی بالا و جامع، 100% منبع باز

§ به طور موثر استانداردهای ادغام را مورد بررسی قرار می­دهد.

§ از تمامی الگوهای ادغام پشتیبانی می­کند، قابلیت همکاری بین سیستم ­های ناهمگن مختلف و برنامه­ های تجاری را فراهم می­آورد.

§ تنها فروشنده­ای است که مجموعه کاملی را ارائه می­دهد که براساس یک پایه کد و یک محیط توسعه منفرد است.

§ قابلیت توسعه و سفارشی­ سازی را فراهم می­کند و آزادی از قفل شدن را تضمین می­کند.

§ به عنوان یک رهبر Forrester Wave درگزارش Q4 2018 ‌برگزیده شده است.

§ یکی از مزایای استفاده از نرم­ افزار میانجی WSO2 این است که یکپارچه و ایمن است و توسعه سریع و نوآورانه را که متناسب با نیازهای یک توسعه دهنده ایجاد می­ کند، تشویق می­ کند و از آن جا که این برنامه روی ابر است توسعه دهندگان می­ توانند از آن برای کار مشترک و سریع در محیط­ های در خواستی استفاده کنند.

Mule ESB :

§ یک گذرگاه خدمات سازمانی مبتنی بر سبک جاوا و بستر ادغام است.

§ به توسعه دهندگان امکان می­دهد تا برنامه­ها را به سرعت و به راحتی متصل کنند و آن­ها را قادر به تبادل اطلاعات می­کند.

§ برخلاف چارچوب­هایی مانند Spring Integration یا Apache Camel ویرایشگرهای گرافیکی برای اجرای کارآمد سناریوهای ادغام و اتصالات موجود برای محصولات B2B مانند SAP یا Salesforce هستند.

§ جنبه­های منفی Mule ESB : جامعه کوچک، الگوی محدودیت صدور مجوز و دسترسی محدود به منبع

§ وزن توزیع شده به طور کامل در ۴۰ مگابایت

§ از یک مدل پیکربندی XML شبیه به فنر برای تعریف منطق کد سفارشی استفاده می­کند.

§ بستر ادغام را برای ابر و شرکت فراهم می­کند.

§ بیشتر از ۱۰۳۰۰۰ توسعه دهنده از Mule استفاده می­کنند .

Apigee Edge :

§ یک پلت­فرم مدیریت API است که هم اکنون متعلق به گوگل و در آن ارائه شده است، زیرا گوگل Apigee را در سال ۲۰۱۶ بدست آورد، ما از Apigee به عنوان یک دروازه API استفاده می­کنیم.

§ تصمیم کسب وکار برای استفاده ازApigee ، این بود که بتواند در خواست­های نادرست مربوط به مسیریابی از UI ها را به API های ما مدیریت کند.

§ رمز عبور خود را در فواصل تصادفی و بدون اطلاع فراموش می­کند.

§ کنسول و راه آسان برای استفاده از خط مشی در Apigee نیز فوق العاده است.

§ تجزیه و تحلیل و تولید گزارش در Apigee به درک بهتر مشاغل و تنظیم فاکتور هزینه کمک کرده­است.

معرفی WSO2

این فناوری یک تکنولوژی متن باز و میان¬ابزاری با زبان جاوا است که در مارس 2016 ارائه شده است. تکنولوژی WSO2 به صورت یک چهارچوب¬کاری و مبتنی بر میکروسرویس WSO2 MSF4Jاست و پلت¬فرمی برای توسعه نرم¬افزارهای جدید می-باشد. ادعای این فناوری توسعه سریع و آسان نرم¬افزار، کارایی بالا میکروسرویس و پشتیبانی از کانتینرها است. WSO2 برای ساخت بسیار سریع برنامه¬ها و کدنویسی و تولید نرم¬افزار به سبک¬های بسیار سریع استفاده می¬شود. WSO2 در کنار ویژگی¬های زیادی که دارد به طور گسترده¬ای پشتیبانی از چارچوب Spring را نیز انجام می¬دهد. طبق ادعایی که از WSO2 می¬کند در موارد زیر نسبت به Sprin Boot برتری دارد¬:

• Memory Consumption

• Latency

در معماری مایکروسرویس، برنامه سمت سرویس دهنده به سرویس‌های مختلفی تقسیم می¬شود که هر سرویس یک فرآیند پردازشی مستقل است و به عنوان یکی از قابلیت‌¬های خاص برنامه سمت سرور به حساب می‌آید. به عنوان مثال یک سرویس وظیفه مدیریت حساب کاربران را به عهده دارد و سرویس دیگر به طور مستقل برای گردش کار استفاده می‌شود. برنامه‌های نوشته شده با این معماری اجباری برای اجرا شدن در سرورهای جداگانه را ندارند، مگر این که یک سرویس، شرایط خاصی از جمله مصرف بالای RAM یا نیاز به پردازش ویژه و زیاد در CPU را داشته باشد که در این صورت بهتر است سرویس از یک سرور مجزا اجرا شود. در ضمن لازم است که سرویس¬ها در بستر شبکه با یکدیگر در ارتباط باشند.

ایده اصلی معماری میکروسرویس این است که نرم¬افزار را به بخش¬های کوچک مستقل از هم تقسیم کنیم که ارتباط این سیستم¬ها با هم، نرم¬افزار اصلی ما را شکل خواهد داد. در این معماری هر کدام از سرویس¬ها، می¬تواند با زبان برنامه نویسی و پایگاه داده جداگانه¬ای نوشته شوند و از طریق واسط¬هایی مثل REST فراخوانی و استفاده شوند.

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

هر کدام از این سیستم¬ها کاملا مستقل از هم باید طراحی شود به گونه¬ای که بتوان آن را به تیم جداگانه¬ای داد فقط ابتدا باید خدماتی که یک سرویس ارائه می¬کند و نحوه فراخوانی آن¬ها را مشخص کنیم و بعد کار را به توسعه گران تحویل دهیم. اگر از پروتکل REST برای ورودی خروجی این سرویس¬ها هم استفاده کنیم، نیاز به درایور یا واسط خاصی هم نداریم. هر سرویس با فراخوانی یک URL، خدمتی که نیاز دارد را دریافت می¬کند.

البته با همه مزایایی که معماری میکروسرویس دارد با مشکلات زیر نیز مواجه هستیم :

•از آنجایی که برنامه‌های سمت سرور نوشته شده با این معماری به سرویس‌های مختلفی تقسیم می¬شوند، گسترش و تنظیمات آن¬ها می‌تواند کاری وقت¬گیر و طاقت¬فرسا باشد.

•چون ارتباط بین سرویس‌ها در بستر شبکه انجام می‌شود، انتظار کندی عملکرد سرویس‌ها دور از ذهن نیست.

•به دلیل ارتباطات شبکه‌ای، احتمال آسیب پذیری‌های امنیتی در این نوع برنامه‌ها بیشتر است.

•نوشتن سرویس‌هایی که در بستر شبکه با سایر سرویس‌ها در ارتباط هستند سختی و مشکلات خود را دارد. برنامه‌ نویس در این شرایط، درگیر برقراری ارتباط، در صورت نیاز رمزگذاری داده‌ها و تبدیل آن¬ها می‌شود.

•به دلیل مجزا بودن بخش¬های مختلف برنامه، مانیتورکردن و ردیابی عملکرد سرویس‌ها، یکی از کارهای اصلی توسعه دهنده یا استفاده کننده از برنامه است.

•در مجموع سرعت برنامه¬های نوشته شده با معماری میکروسرویس کندتر از برنامه‌های نوشته شده با معماری Monolithic است. دلیل آن محیط اجرایی برنامه‌ها است. برنامه‌هایی با معماری Monolithic بر روی حافظه سرور پردازش می‌شوند.

نتیجه گیری

کامل¬ترین و جدیدترین روش، گذرگاه سرویس سازمانی (ESB) است. که ما از بین میان¬ابزارهای ESB، ابزار WSO2 ESB را به دلیل این که 100% متن باز، سبک و بسیار مقیاس پذیر است، انتخاب کردیم. این روش‬ ‫در طول‬ ‫سال¬ها‬ ‫به‬ ‫منظور‬ ‫برآورده‬ ‫کردن‬ ‫نیازهای‬ ‫گرایش¬های‬ ‫ابر‬ ‫و‬ ‫کانتینر، تکامل ‌یافته‬¬ است.‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬‬