مقدمه‌ای بر معماری مبتنی بر سرویس (SOA)

از جمله مسائل مهمی که در پروژه‌های نرم‌افزاری مطرح است بحث هزینه نگهداری سیستم‌های نرم‌افزاری است. علاوه بر این موضوع، در سیستم‌های اطلاعاتی بزرگ بحث یکپارچه‌سازی واحد‌های مختلف نرم‌افزاری و استفاده از نرم‌افزار‌ها و سیستم‌های موجود مطرح می‌گردد. با در نظر گرفتن تنوع سیستم‌های عامل و محیط‌ها و زبان‌های توسعه نرم‌افزار، عمل یکپارچه‌سازی و نگهداری این قبیل سیستم‌ها با هزینه‌ها و مشکلات فراوانی مواجه می‌گردد.
از سوی دیگر، با وجود رشد و توسعه سریع فناوری‌های اطلاعاتی و ارتباطی، نیازمندی‌های سازمان‌ها نیز به سرعت در حال افزایش است. آنچه به عنوان راهکاری مناسب برای غلبه بر پیچیدگی‌های روز‌افزون سیستم‌های اطلاعاتی مطرح می‌گردد، استفاده از معماری نرم‌افزاری مناسب در توسعه و پیاده‌سازی نرم‌افزار‌ها در این قبیل سیستم‌ها است.
معماری مبتنی بر سرویس رویکرد جدیدی در دنیای نرم‌افزار است که با رفع محدودیت‌ها و نواقص معماری‌های پیشین به عنوان بهترین گزینه در این زمینه محسوب می‌گردد. در این مقاله سعی شده است مفاهیم و اصول پایه‌ای این معماری به طور اجمالی مورد بررسی قرار گیرد.
سیستم‌های اطلاعاتی به سرعت در حال رشد هستند؛ سازمان‌ها نیازمند پاسخگویی سریع به نیازمندی‌های جدید کسب‌وکار هستند. این در حالی است که معماری‌های نرم‌افزاری موجود به حد نهایی قابلیت‌های خود رسیده‌اند. معماری مبتنی بر سرویس SOA قدم تکاملی بعدی برای کمک به سازمان‌ها جهت مدیریت چالش‌های پیچیده است.
معماری مبتنی بر سرویس حالت بلوغ یافته معماری مبتنی بر اجزا، طراحی مبتنی بر واسطه (شی‌گرا) و سیستم‌های توزیع ‌شده است. در معماری مبتنی بر اجزا عملکرد کلی به کارهای کوچک‌تری تقسیم می‌شود که هر یک در یک جزء بسته‌بندی خواهند شد. یک سیستم توزیع‌شده، تعمیمی از یک معماری مبتنی بر اجزا است که به اجزائی که در موقعیت‌های فیزیکی مختلف وجود دارند، اشاره می‌کند.
مهم‌ترین مزیت معماری مبتنی بر اجزا سهولت در استفاده مجدد و تغییر هدف اجزای خاص و سهولت در امر نگهداری سیستم است. استفاده مجدد و تغییر هدف معمولاً مهم‌ترین پیشران‌های کسب‌و کار جهت استفاده از این نوع معماری در دهه ۹۰ میلادی بوده است. بر اساس منطق معماری مبتنی بر سرویس، سیستم‌های نرم‌افزاری بزرگ می‌توانند از گردآوری مجموعه‌هایی از عملکردهای مستقل و قابل استفاده مجدد تشکیل گردند.
برخی از این عملیات می‌تواند از طریق سیستم‌های موجود و یا سیستم‌های دیگر فراهم گردد ولی سایر عملیات لازم باید پیاده‌سازی شوند. هر سرویس امکان دسترسی به مجموعه خوش‌ تعریفی از عملیات را می‌دهد. سیستم به عنوان یک کل به صورت مجموعه‌ای از تعاملات بین این سرویس‌ها طراحی می‌شود. معماری مبتنی بر سرویس، سرویس‌هایی را که سیستم از آنها تشکیل شده را تعریف ‌می‌کند و تعاملات لازم بین سرویس‌ها جهت ارائه رفتار مشخص را توصیف ‌می‌کند و در نهایت سرویس‌ها را به یک یا چند پیاده‌سازی در تکنولوژی‌های خاص تصویر می‌کند.
SOA بر اساس استفاده از اشیاء و اجزا توزیع شده است و قدم تکامل بعدی در محیط‌های محاسبه‌ای است. این معماری در حال حاضر مدل مرجع استانداردی ندارد؛ اما پیاده‌سازی‌های موجود مفاهیم مشترکی را مورد استفاده قرار می‌دهند که در ادامه این مفاهیم پایه مورد بررسی قرار می‌گیرند.
● مفاهیم اصلی در معماری مبتنی بر سرویس
در حال حاضر استاندارد مشخصی برای تعریف SOA وجود ندارد اما مواردی که در ادامه می‌آید مهم‌ترین و سازگارترین موارد در پیاده‌سازی SOA هستند.
▪ سرویس‌
یک سرویس رفتار تعریف شده قراردادی است که می‌تواند به‌وسیله یک جزء برای استفاده جزء دیگر پیاده‌سازی شده و فراهم گردد.
▪ شرح سرویس
شرح سرویس پارامترهای فنی، قیود و سیاست‌هایی را شامل می‌شود که قالب‌های لازم برای فراخوانی سرویس را تعریف می‌کند. هر سرویس باید شامل تعریف سرویس در قالب استاندارد باشد. این موضوع کاربردها و کاربران انسانی را قادر می‌سازد تا با بررسی شرح سرویس و تعیین موضوعاتی نظیر این‌ که سرویس چه کاری انجام می‌دهد، چگونه به آن انتصاب می‌یابند و این‌که چه پروتکل‌های امنیتی (در صورت وجود) باید به همراه آن مورد استفاده قرار گیرد، از آن سرویس استفاده کند.
این اعلان همچنین ممکن است شامل جزئیاتی در مورد هر فرایند ضمنی و دیگر واژه‌های کاری و قانونی باشد که ممکن است در زمان فراخوانی سرویس اتفاق بیفتد. به عنوان مثال، اگر یک استفاده‌کننده سرویس، سرویسی را فراخوانی کند که یک درخواست خرید را برای فراهم‌کننده سرویس ارسال نماید، و اجرا موفقیت‌آمیز باشد، این موضوع ممکن است منجر به مسئولیت مالی نسبت به فراهم‌کننده سرویس یا بخش قانونی دیگر می‌شود.
در حالیکه طبیعت سرویس‌ها ممکن است تغییر کند، استاندارد مشترکی جهت اعلان یک سرویس هنگام تهیه یک زیرساخت مطلوب است. دو نمونه از چنین استانداردهای موجود ebXML و WSDL هستند.
● اعلان و یابش سرویس‌ها
شرح سرویس باید به شیوه‌ای قابل دسترسی در اختیار کاربران بالقوه قرار گیرد که به این امر اعلان سرویس اطلاق می‌شود.
یابش، ‌زمانی انجام می‌شود که یک مشتری بالقوه اطلاعاتی در مورد وجود یک سرویس، پارامترهای قابل اعمال و واژگان آن به دست آورد. یافتن، بحث تصدیق هویت جهت اجرای سرویس را شامل نمی‌شود؛ گرچه این جزئیات ممکن است در الگوی یافتن قرار گیرد.
اجزای اعلان و یابش در SOA به شیوه‌های مختلف از جمله استفاده از روش ثبات / مخزن و یا روش دایرکتوری سرویس قابل پیاده سازی هستند.
▪ پیاده‌سازی به روش ثبات / مخزن
یک ثبات / مخزن جزئی است که در آن کاربران امکان ذخیره و مدیریت سرویس‌های لازم برای عملکرد سازمانشان را خواهند داشت. این موضوع شامل سرویس‌هایی است که تسهیم بین بیش از یک کاربر (نظیر xml schemas و شرح web-service) را فراهم می‌آورد که به ثبات به گونه‌ای منتسب می‌شود که ثبات در مورد تمامی رویدادهای قابل ارزیابی نسبت به محصولات در مخزن اطلاع دارد.
▪ پیاده‌سازی به روش دایرکتوری
دایرکتوری یک واسط است که اطلاعات انتساب به محصولات را فراهم می‌آورد. افرادی که مالک محصولات هستند و یا آنها را کنترل می‌کنند، می‌توانند یک مدخل به دایرکتوری باز کرده تا به محصولات ارجاع داده و خود انتسابات به آن را توضیح دهند. دیگران ممکن است این اطلاعات را بازیابی کرده و از آن جهت انتساب به محصولات استفاده کنند. مهم‌ترین مشکل دایرکتوری این است که هیچ کنترل یا اطلاع‌رسانی در صورت حذف، تغییر و جایگزین شدن یک محصول انجام نمی‌دهد و قادر به اعلام این رویدادها به کاربران نیست.
هر دو پیاده‌سازی دایرکتوری و ثبات / مخزن امکان سازگاری با یکدیگر را دارند. به این معنا که عملکرد اجازه می‌دهد که محتوا از یک پیاده‌سازی توسط یک پیاده‌سازی دیگر مورد ارجاع قرار گیرد.
چندین استاندارد وجود دارد که پیاده‌سازی‌ها دایرکتوری و ثبات / مخزن را دارند.
▪ رایج‌ترین استانداردها عبارتند از:
ـ OASIS ebXML Registry-Repository Technical Specifications۱۶
ـ OASIS Universal Description and Discovery Interface (UDDI) Technical Specification۱۷.۲
● خصوصیات مدل داده‌ای مرتبط
در هنگام فراخوانی یک سرویس، پارامترهای مشخصی ممکن است برای انجام درخواست سرویس مورد نیاز باشد. سرویس همچنین ممکن است پارامترهایی را به کاربر سرویس بازگرداند. W۳C WSDL یک نمونه شناخته شده از پیاده‌سازی این بخش است.
● اصطلاحات رایج در معماری مبتنی بر سرویس
▪ فراهم‌کننده سرویس:
یک موجودیت نرم‌افزاری که خصوصیات سرویس را پیاده‌سازی می‌کند.
▪ درخواست‌کننده سرویس:
یک موجودیت نرم‌افزاری که یک فراهم‌کنندهٔ سرویس را فراخوانی می‌کند، به‌طور سنتی این مورد به عنوان "کلاینت" شناخته می‌شود؛ اما یک درخواست‌کننده سرویس می‌تواند یک کاربر برنامه کاربردی و یا سرویس دیگر باشد.
▪ موقیعت‌یاب سرویس:
یک نوع خاص از فراهم‌کننده سرویس که به‌عنوان یک ثبات عمل می‌کند و امکان جست‌وجوی واسطه‌های فراهم‌کننده سرویس و موقعیت سرویس را می‌دهد.▪ واسط سرویس:
یک نوع خاص از فراهم‌کننده سرویس است که می‌تواند درخواست سرویس را به یک یا چند فراهم‌کننده سرویس منتقل کند.
● چارچوب SOA
▪ زیرساخت SOA
▪ نقشه مفهومی
نقشه‌های مفهومی غیر رسمی بوده و نمایش گرافیکی از مفاهیم و رابطه بین آنها را شامل می‌شود.
اغلب معماری‌هایی که SOA نامیده می‌شوند، شامل یک فراهم‌کننده سرویس، یک کاربر سرویس و برخی زیرساخت‌های پیام‌رسانی هستند.
● مفاهیم اختیاری و زیرساخت‌های SOA اشتراکی
جهت اجرای تعهدات در زمان اجرا، اغلب SOAها ممکن است شامل مفاهیمی اضافه بر آنچه در شکل ۳ نشان داده شده است، باشند. مفاهیم دیگر کاربران سرویس، کلاینت سرویس، قرارداد پذیرش سرویس و فراخوانی سرویس هستند. فراخوانی یک سرویس یا وجود کاربر سرویس در مدل SOAالزامی نیست. فراهم‌کننده یک سرویس، قرارداد سرویس جهت استفاده آن و شرح سرویس را ارائه می‌کند. شرح سرویس به مدل داده‌های مرتبط با فراخوانی سرویس ارجاع می‌کند.
شرح سرویس از طریق یکی از چندین روش اعلان می‌شود. کاربر سرویس خصوصیات سرویس را از طریق مکانیزم اعلان شناسایی می‌کند. شناسایی، پذیرش قرارداد را شامل نمی‌شود. همچنین فراخوانی سرویس را نیز القا نمی‌کند. این امر صرفاً عملی برای پیدا کردن اطلاعات در مورد سرویس است. این امر لزوماً در یک عمل اتفاق نمی‌افتد و ممکن است به تعدادی از کارها نیاز داشته باشد. همچنین ممکن است از طریق وسایل غیر الکترونیکی صورت پذیرد.
سایر عملکردهای خاص اختیاری را حذف کرده و از پیاده‌سازی‌های خاص نظیر پیام‌رسانیSOAP ، WDSL و ebXML خودداری می‌کند.
● الگوهای SOA
شکل ۵ یک الگوی ساده سرویس را نمایش می‌دهد. در جایی که یک فراهم‌کننده سرویس، سرویس را پیشنهاد می‌دهد و یک کاربر سرویس، از سرویس‌ها استفاده می‌کند. چندین نوع از پروتکل‌های ارتباطی ممکن است زوج درخواست/ پاسخ را مورد استفاده قرار دهد و روش‌های متنوعی نظیر سنکرون یا آسنکرون ممکن است استفاده شود. SOA به هیچ پروتکل ارتباطی خاص محدود نمی‌شود. شکل ۵ الگوی "درخواست – پاسخ" را نمایش می‌دهد.
● چرخه حیات SOA
بر اساس طرح IBM، برای SOA می‌توان یک چرخه حیات در نظر گرفت. در فاز "مدل" نیازمندی‌های کسب‌و کار جمع‌آوری شده و فرایندهای کسب و کار آنها طراحی می‌شود. بعد از بهینه شدن فرایندها، از طریق کنار هم قرار دادن سرویس‌های موجود و سرویس‌های جدید این فرایندهای کسب‌و کار شکل می‌گیرد. سپس این سرمایه‌ها در یک محیط امن و با قابلیت تجمیع بالا نصب می‌شود. بعد از نصب فرایندهای کسب و کار، کاربران IBM این فرایندهای کسب و کار را هم از منظر فنی و هم از منظر فرایندهای کسب و کار مورد نظارت و مدیریت قرار می‌دهند.
اطلاعات جمع‌آوری شده در فاز مدیریت به چرخه حیات بازخورد خواهد داشت تا بهبود پیوسته فرایندها را امکان‌پذیر سازد. در زیر همه این مراحل در چرخه حیات، حاکمیت و فرایندهایی هستند که رهنمود‌ها و افق‌های آینده را برای پروژه SOA فراهم می‌کنند.
▪ مرحله مدل‌سازی
فاز مدل با جمع‌آوری و تحلیل نیازمندی‌های کسب‌و کار آغاز می‌شود که بعداً برای مدل کردن، شبیه‌سازی و بهینه کردن فرایندهای کسب و کار مورد استفاده قرار می‌گیرند. فرایندهای کسب و کار حاصل برای طراحی سرویس‌های نرم‌افزاری مرتبط و سطوح سرویس جهت حمایت از این فرایندها مورد استفاده قرار می‌گیرند. در طول این فاز، مدلی جهت ایجاد درک مشترک بین کسب و کار و فناوری اطلاعات در فرایندهای کسب و کار، اهداف و خروجی‌ها استفاده می‌شود. به علاوه این مدل می‌تواند این اطمینان را به وجود آورد که کاربردهای حاصل، نیازمندی‌های کسب و کار تعریف شده را براورده می‌سازد. این مدل همچنین می‌تواند مبنایی جهت اندازه‌گیری کارآیی کسب و کار باشد.
▪ مرحله گردآوری
در طول فاز گردآوری، کتابخانه سرویس‌های موجود می‌تواند جهت یافتن سرویس‌های مورد نظر و موجود در سازمان بررسی شود. در صورتی که سرویس مورد نظر یافت نشد این امکان وجود دارد که یک سرویس جدید ایجاد و پس از تست به مجموعه افزوده شود. هنگامی که سرویس‌های مورد نیاز فراهم شد، سرویس‌ها جهت پیاده‌سازی فرایندهای کسب‌و کار هماهنگ می‌گردند.
▪ مرحله نصب
در طول فاز پیاده‌سازی، مقیاس و محیط زمان اجرا جهت تأمین نیازمندی‌های سطوح سرویس به وسیله فرایندهای کسب‌وکار پیکربندی می‌شود. پس از پیکربندی یک فرایند کسب‌وکار، امکان پیاده‌سازی آن در یک محیط امن، مطمئن و مقیاس‌پذیر سرویس‌ها وجود خواهد داشت. محیط سرویس‌ها به گونه‌ای بهینه‌سازی می‌شود که علاوه بر اجرای مطمئن فرایندهای کسب‌وکار، امکان انعطاف‌پذیری جهت بروز کردن به طور پویا و در صورت تغییر نیازمندی‌های کسب‌وکار را فراهم می‌آورد. این رویکرد مبتنی بر سرویس همچنین هزینه و پیچیدگی نگهداری سیستم را نیز کاهش می‌دهد.
▪ مرحله مدیریت
فاز مدیریت شامل نظارت و نگهداری از زمان پاسخ و در دسترس بودن سرویس می‌شود. همچنین مدیریت منابع سرویس‌های زیرین در این فاز انجام می‌شود. درک کارایی زمان واقعی فرایندهای کسب‌وکار امکان ایجاد بازخورد ضروری به مدل فرایند کسب و کار جهت بهبود دائمی را فراهم می‌آورد. این کار همچنین مدیریت و نگهداری کنترل نسخه برای سرویس‌های تشکیل دهنده فرایندهای کسب و کار را شامل می‌شود. فاز مدیریت در نهایت امکان اتخاذ تصمیمات کسب و کار بهتر و سریع‌تر را فراهم می‌سازد.
▪ مرحله حاکمیت و فرایندها
حاکمیت و فرایندها جهت موفقیت هر نوع پروژه SOA ضروری هستند. جهت تخمین موفقیت، ممکن است یک مرکز تعالی در کسب‌وکار، برای پیاده‌سازی سیاست‌های حاکمیتی و دنبال کردن استانداردهای حاکمیتی بین‌المللی جهت اهداف کنترلی برای اطلاعات و تکنولوژی مرتبط ایجاد گردد. پیاده‌سازی سیاست‌های حاکمیتی قوی می‌تواند منجر به پروژه‌های SOA موفق گردد.
● خصوصیات اساسی جهت استفادهٔ بهینه از سرویس‌ها
▪ درشت‌دانه بودن:
عملکردها روی سرویس‌ها به طور متفاوت پیاده‌سازی می‌شوند تا کارآیی بیشتری را در برگیرند و بر روی مجموعه‌های داده‌ای بزرگ‌تر در مقایسه با طراحی مبتنی بر اجزا عمل می‌کند. (شکل ۸)
▪ طراحی مبتنی بر واسط:
سرویس‌ها، واسط‌های مجزا‌ ‌تعریف‌شده را پیاده‌سازی می‌کنند. مزیت این امر آن است که چندین سرویس می‌توانند یک واسط مشترک را پیاده‌سازی کنند و یک سرویس می‌تواند چندین واسط را پیاده‌سازی کند. (شکل ۹)
▪ قابل یافت بودن:
سرویس‌ها لازم است هم در زمان طراحی و هم در زمان اجرا قابل یافت باشند، نه تنها با شناسهٔ یکتا بلکه همچنین با شناسهٔ واسط و با نوع سرویس.
▪ نمونه منفرد:
بر خلاف توسعهٔ مبتنی بر جزء که از اجزا بر حسب نیاز نمونه‌هایی ایجاد می‌شود، هر سرویس یک نمونه منفرد و همواره در حال اجرا است که مجموعه‌ای از کلاینت‌ها با آن ارتباط برقرار می‌کنند.
▪ اتصال ست:
سرویس‌ها با دیگر سرویس‌ها و کلاینت‌ها از طریق تبادل اطلاعات استاندارد xml با یکدیگر در ارتباط هستند؛ این ارتباط باعث کاهش وابستگی و جداسازی بر اساس پیام‌رسانی می‌شود.
▪ آسنکرون:
به طور کلی، سرویس‌ها از رویکرد انتقال پیام آسنکرون استفاده می‌کنند. اما این امر ضروری نیست. در بعضی مواقع در پیاده‌سازی سرویس‌ها از انتقال پیام سنکرون نیز استفاده می‌شود.
● مقیاس‌پذیری از طریق رفتار آسنکرون و صف‌بندی
بهتر است که از ماهیت آسنکرون در ‌سرویس‌ها استفاده شود. با توجه به سربار انتقال اضافه و همچنین این انتظار که سرویس‌ها، ماهیتاً در فواصل فیزیکی دور از یکدیگر خواهند بود، کاهش زمان انتظار درخواست‌کننده برای پاسخ بسیار اهمیت دارد. از طریق آسنکرون کردن فراخوانی یک سرویس، با یک پیام بازگشت مجزا، به درخواست‌کننده امکان ادامهٔ اجرا تا زمان فراهم شدن پاسخ داده می‌شود.
البته این به معنای اشتباه بودن رفتار سنکرون سرویس نیست، بلکه به این معنا است که رفتار سرویس آسنکرون مطلوب است، به خصوص در جایی که هزینه‌های ارتباطی زیاد است و یا تأخیر شبکه قابل پیش‌بینی نیست.
با استفاده از فراخوانی آسنکرون، به فراهم‌کننده این امکان داده می‌شود که از چندین رشتهٔ کاری جهت مدیریت چندین درخواست کلاینت استفاده کند. جهت اجرای فراخوانی آسنکرون، درخواست‌کننده باید نشانی بازگشت را به سرویس پیاده‌ساز یک واسط ارسال کند.
● جمع‌بندی
معماری مبتنی بر سرویس گام تکاملی بعدی در دنیای نرم‌افزار است. معماری‌های نرم‌افزاری فعلی قادر به حل تمامی مشکلات و چالش‌های فرا روی سازمان‌ها و سیستم‌های اطلاعاتی بزرگ و پیچیده نیستند. ویژگی‌های خاص معماری مبتنی بر سرویس این معماری را به عنوان بهترین گزینه برای این موضوع مطرح کرده است.

منبع : اخبار فن‌آوری اطلاعات ایتنا