معماری سیستمهای یکسان سازی

به طور معمول معماری برنامه های یک سازمان میتواند بسیار پیچیده باشد. و هر سازمان بنا بر سطح تکنولوژی،نیازهای کسب و کار و … میتواند از برنامه های مختلفی برپایه تکنولوژی­ها و معماری­ها متفاوتی ساخته شده است.

Point-to-Point integration

به منظور همسان سازی دیتابیس پیش از ارائه مفهوم EAI ، از روش تجمیع نقطه به نقطه (point-to-point(P2P)) استفاده میشد. در این روش تجمیع، به منظور برقراری اتصال ، بین هر دو برنامه یا سیستم، ارتباطی برقرار میگردد. این نقاط اتصال انتقال داده، همسان سازی­ها، سایر سرویسهای پیامرسان و یا هر سرویس دیگری که نیاز به یکسان سازی دارند را مدیریت میکند. این مدل در معماری هایی با تعداد برنامه کم راه حلی آسان با پیچیدگی اندک برای یکسان سازی است.حال آنکه در صورت اضافه شدن برنامه ها به این مدل نقاط اتصال نقطه به نقطه تا برقراری ارتباط کامل میان برنامه ها میبایست افزایش یابد. به همین دلیل هزینه نگهداری چنین مدلی به شکل تصاعدی افزایش می­یابد.

point to point integration

یکپارچه سازی  EAI

اصطلاح یکپارچه­سازی برنامه های سازمان (Enterprise Application Integration(EAI)برای اولین بار در سال 1996 در نشریه Gartner به کاربرده شد. EAI را میتوان بدین گونه تعبیر کرد: فرآیندی که در طی آن داده های درون یک برنامه نرم­افزاری بعلاوه داده هایی که در دیگر نرم افزارها وجود دارد یکپارچه­سازی میگردد. به طور معمول EAI یک تکنولوژی میانی (middleware technology) است و نقشی حیاتی در برقراری ارتباط در معماری برنامه های یک شرکت از طریق ساده­سازی و خودکارسازی فرآیندها ایفا میکند.

مزیت استفاده از EAI به جای P2P را میتوان این نکته برشمرد که در تکنولوژی یکسان سازی P2P احتمال بروز خطا در ارتباط میان برنامه ها هنگامی که تعداد برنامه ها اضافه میگردد به شدت افزایش می­یابد حال آنکه در EAI و با تکیه بر مفهوم میانی بودن آن در تجمیع و استاندارد­سازی ، برای تمام معماری برنامه های سازمان قابل استفاده است.

Eai با بهره گیری از آداپتورهای ارتباطی انتقال داده ، داده ها را از منابع داده و از فرمت منبع به فرمتی تبدیل میکند که برای مقصد ، سرویس های مسیریاب و هماهنگ سازی (orchestration) قابل فهم باشد. در قالب Eai و برخلاف تکنولوژی P2P، یک برنامه میتواند بدون آن که بداند گیرنده پیغام کیست و یا به چه اطلاعاتی نیاز دارد پیغامی را بفرستد و همه این اطلاعات توسط EAI  رسیدگی میشود.

براساس مواردی که ذکر شد میتوان نتیجه گرفت که این نوع از معماری بسیار انعطاف پذیرتر از P2P است و درون آن ،اجزا میتوانند برحسب نیاز اضافه یا حذف شوند حال آنکه محیط­ کاری نیز بسیار ساده سازی شده است.

مدلهای اجرای EAI

در مجموع دو گونه پیاده سازی EAI وجود دارد که که هر کدام دارای مزایا و معایب خاص خود هستند.

  1. مدل HUB

در اولین اجرای EAI در واقعیت از مدل هاب یا دلال (broker) استفاده شد. در این روش، جزء مرکزی سیستم (هاب) از ابزاری تعاملی که  برنامه­ها قادر به فهم آن هستند برای برقراری ارتباط و جابجایی داده استفاده میکند. یکی دیگر از وظایف هاب ، تبدیل پیامهای دریافتی است به فرمتی که از سوی مقصد قابل فهم باشد و درنهایت آن را به سمت کاربر نهایی پیام هدایت کند. استفاده از مدل هاب برنامه نویسان را از برقراری و برنامه نویسی تک تک وابستگی ها میان برنامه ها بی نیاز میکند ولی با این حال همچنان میبایست تنظیمات زمان اجرا را به صورت دستی برقرار کنند تا مسیر داده ها به برنامه مناسب مشخص شود.

برخی از مزایای این مدل:

  • ارتباطات میان برنامه ها را کاهش میدهد
  • برنامه ها میتوانند به طور همزمان فعالیت کنند و پیام ردوبدل کرده و فعالیت خود را ادامه دهند.

معایب:

  • داشتن یک هاب مرکزی امکان بروز خرابی در آن نقطه را بوجود می آورد.(Single Point of Failure)
  • درصورت بروز باراضافی (overload) بر روی هاب ، عملکرد کلی سیستم تحت تاثیر قرار میگیرد.
  • سختی استفاده در ارتباطهای از راه دور (وجود فواصل جغرافیایی)

  1. مدل ESB

به منظور غلبه کردن برمشکلات موجود در مدل هاب، تلاشهایی صورت پذیرفت که منجر به توسعه روشی جدید برای پیاده سازی EAI به نام BUS گردید. این روش اگرچه همچنان از یک جزء مرکزی استفاده میکند ، موفق شده است تا بتواند برخی از وظایف یکپارچه سازی جاری در سیستم را تفکیک کنند.با پیدایش این معماری جدید، اجزای جدیدی همچون : امنیت، logging، مکانیزم رسیدگی به استثنائات (exception handling mechanism) ، ردیابی پیامها و غیره اضافه شدند.

و در نهایت ، معماری­ای معرفی گردید که امکان توسعه راه های یکپارچه سازی ، اعتمادپذیری و شخصی سازی را ارائه میکند و در عین حال نسبت به سطح نرم افزار، درجه بالاتری از انتزاع را دارا می باشد که این خود منجر به ارائه مدلی پایدار شده که میتواند به شکلی ساده و به طور مستقل از برنامه ها و سیستم، اجرا و پیکربندی گردد.  این معماری با نام Enterprise Service Bus(ESB) شناخته میشود.

  1. میان افزار (MiddleWare)

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

  1. میکروسرویس ها (Microservices)

میکروسرویس ها ، امروزه استاندارد موجود برای برنامه های سازمانی هستند که در فضای ابری پیاده­سازی میشوند. سازمانهایی که برنامه های خود را بر روی فضای ابری اجرا میکنند میتوانند داده­ها را از هر میکروسرویس پیاده سازی شده دریافت کرده و آنها را از طریق API(Application Programming Interface) به سمت مقصد و پایگاه­داده موردنظر هدایت کنند.

انواع یکپارچه سازی

پس از انتخاب نوع معماری یکپارچه سازی ، سازمان ها می­بایست بر روی داده­ها و یا فرآیندهای تجاری تمرکز کرده و سپس انتخاب کنند که کدام یک از این دو نیازمند یکپارچه سازی است. در EAI چهار روش یکپارچه سازی وجود دارد:

  • یکپارچه سازی سطح داده
  • یکپارچه سازی سطح رابط برنامه
  • یکپارچه سازی سطح متد
  • یکپارچه سازی سطح رابط کاربری

 

یکپارچه سازی سطح داده

در این نوع  یکپارچه سازی، داده ها میتوانند از یک پایگاه­داده استخراج شوند و پس از طی فرآیندی مجددا در پایگاه داده دیگری ذخیره گردند. این روش به دو صورت کششی و فشاری (pull-based & Push-based) اجرا میگردد. علی رغم برخی دشواری هایی که در اجرای این روش ممکن است روی دهد، هزینه کمتر اجرای این روش، به عنوان مزیتی نسبت به سایر روش­ها محسوب میگردد. این مزیت هزینه ای، به این خاطر است که در این روش نیازی به تغییر در برنامه و تغییر کد نیست اما به منظور به دست آوردن روشهای اجرایی مناسب در سازمان های بزرگ به علت نیاز به پیاده سازی مجدد فرایندهای پیچیده متعدد و درگیرکننده چندین سیستم، پیشنهاد نمیشود.

یکپارچه سازی سطح رابط برنامه

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

  1. استخراج از یک برنامه با استفاده از API های ارائه شده توسط آن برنامه
  2. تبدیل داده ها به فرمتی که توسط برنامه مقصد قابل فهم باشد
  3. انتقال داده ها به برنامه مقصد

بیشترین مورد استفاده این روش،  “کارگذار پیام” (message broker) نام دارد. روشی که طی آن جریان اطلاعات ، از طریق هاب ها یا busها استانداردسازی و کنترل میگردد.

 

یکپارچه سازی سطح متد

روش یکپارچه سازی سطح متد بسیار شبیه به یکپارچه سازی سطح رابط کاربری است با این تفاوت که در این روش از ریزدانگی(granularity) بیشتری استفاده میگردد. ایده این روش در این است که به جای به اشتراک گذاری عملکردهای تجاری، روشهایی (متد)که از ترکیب آنها میتوان به عملکرد تجاری دست یافت، به اشتراک گذاشته میشود. و برای هر برنامه دیگری در سازمان هم که نیازمند اجرای همین متدها باشند دیگر نیاز به بازنویسی مجدد آنها نیست و میتوان بارها و بارها از آنها استفاده کرد.

اگرچه برای اجرای این سطح از یکپارچگی میتوان از تکنولوژی­های زیادی استفاده کرد (Java RMI, Corba, DCOM, etc.) ولی پدیده در حال گسترش برای اجرای این روش استفاده از وب­سرویسها برای به اشتراک گذاری متدهاست.

یکپارچه سازی سطح رابط کاربری

EAI سطح رابط­کاربری که به نام بازسازی ظاهری (refacing) نیز معروف است، از جایگزینی رابط­کاربری­های متن محور سیستمهای سنتی و رابط گرافیکی کامپیوتری، با رابط­کاربری های استانداردسازی شده­ای که معمولا برپایه مرورگرها (browser-based) هستند تشکیل شده است.

درگاه­های تجاری سازمان­ها یک راه حل برای پیاده سازی این نوع از یکپارچه­سازی­هاست. از طریق این روش میتوان چندین برنامه مجزا را به شکلی یکپارچه و از طریق رابط کاربری بر پایه مرورگر و به صورت شخصی سازی شده، به کاربران ارائه داد.

این نوع از یکپارچه سازی نسبت به سایر روش­ها، به دلیل تغییرنیافتن کد استفاده شده در برنامه های موجود کم هزینه تر خواهد بود؛ اما از سویی دیگر دقیقا به همین علت نیز از انعطاف پذیری کمتری برخورددار است.

Leave a Reply

Your email address will not be published. Required fields are marked *