از سوی دیگر، با وجود رشد و توسعه سریع فناوری های اطلاعاتی و ارتباطی، نیازمندی های سازمان ها نیز به سرعت در حال افزایش است. آنچه به عنوان راهکاری مناسب برای غلبه بر پیچیدگی های روز افزون سیستم های اطلاعاتی مطرح می گردد، استفاده از معماری نرم افزاری مناسب در توسعه و پیاده سازی نرم افزار ها در این قبیل سیستم ها است.
معماری مبتنی بر سرویس رویکرد جدیدی در دنیای نرم افزار است که با رفع محدودیت ها و نواقص معماری های پیشین به عنوان بهترین گزینه در این زمینه محسوب می گردد. در این مقاله سعی شده است مفاهیم و اصول پایه ای این معماری به طور اجمالی مورد بررسی قرار گیرد.
مقدمه
سیستم های اطلاعاتی به سرعت در حال رشد هستند؛ سازمان ها نیازمند پاسخگویی سریع به نیازمندی های جدید کسب وکار هستند. این در حالی است که معماری های نرم افزاری موجود به حد نهایی قابلیت های خود رسیده اند. معماری مبتنی بر سرویس SOA قدم تکاملی بعدی برای کمک به سازمان ها جهت مدیریت چالش های پیچیده است.
معماری مبتنی بر سرویس حالت بلوغ یافته معماری مبتنی بر اجزا، طراحی مبتنی بر واسطه (شی گرا) و سیستم های توزیع شده است. در معماری مبتنی بر اجزا عملکرد کلی به کارهای کوچک تری تقسیم می شود که هر یک در یک جزء بسته بندی خواهند شد. یک سیستم توزیع شده، تعمیمی از یک معماری مبتنی بر اجزا است که به اجزایی که در موقعیت های فیزیکی مختلف وجود دارند، اشاره می کند.
مهم ترین مزیت معماری مبتنی بر اجزا سهولت در استفاده مجدد و تغییر هدف اجزای خاص و سهولت در امر نگهداری سیستم است. استفاده مجدد و تغییر هدف معمولاً مهم ترین پیشران های کسب و کار جهت استفاده از این نوع معماری در دهه 90 میلادی بوده است. بر اساس منطق معماری مبتنی بر سرویس، سیستم های نرم افزاری بزرگ می توانند از گردآوری مجموعه هایی از عملکردهای مستقل و قابل استفاده مجدد تشکیل گردند.
برخی از این عملیات می تواند از طریق سیستم های موجود و یا سیستم های دیگر فراهم گردد ولی سایر عملیات لازم باید پیاده سازی شوند. هر سرویس امکان دسترسی به مجموعه خوش تعریفی از عملیات را می دهد. سیستم به عنوان یک کل به صورت مجموعه ای از تعاملات بین این سرویس ها طراحی می شود. معماری مبتنی بر سرویس، سرویس هایی را که سیستم از آنها تشکیل شده را تعریف می کند و تعاملات لازم بین سرویس ها جهت ارایه رفتار مشخص را توصیف می کند و در نهایت سرویس ها را به یک یا چند پیاده سازی در تکنولوژی های خاص تصویر می کند.
SOA بر اساس استفاده از اشیاء و اجزا توزیع شده است و قدم تکامل بعدی در محیط های محاسبه ای است. این معماری در حال حاضر مدل مرجع استانداردی ندارد؛ اما پیاده سازی های موجود مفاهیم مشترکی را مورد استفاده قرار می دهند که در ادامه این مفاهیم پایه مورد بررسی قرار می گیرند.
2- مفاهیم اصلی در معماری مبتنی بر سرویس
در حال حاضر استاندارد مشخصی برای تعریف SOA وجود ندارد اما مواردی که در ادامه می آید مهم ترین و سازگارترین موارد در پیاده سازی SOA هستند.
2-1- سرویس
یک سرویس رفتار تعریف شده قراردادی است که می تواند به وسیله یک جزء برای استفاده جزء دیگر پیاده سازی شده و فراهم گردد.
2-2- شرح سرویس
شرح سرویس پارامترهای فنی، قیود و سیاست هایی را شامل می شود که قالب های لازم برای فراخوانی سرویس را تعریف می کند. هر سرویس باید شامل تعریف سرویس در قالب استاندارد باشد. این موضوع کاربردها و کاربران انسانی را قادر می سازد تا با بررسی شرح سرویس و تعیین موضوعاتی نظیر این که سرویس چه کاری انجام می دهد، چگونه به آن انتصاب می یابند و این که چه پروتکل های امنیتی (در صورت وجود) باید به همراه آن مورد استفاده قرار گیرد، از آن سرویس استفاده کند.
این اعلان همچنین ممکن است شامل جزییاتی در مورد هر فرایند ضمنی و دیگر واژه های کاری و قانونی باشد که ممکن است در زمان فراخوانی سرویس اتفاق بیفتد. به عنوان مثال، اگر یک استفاده کننده سرویس، سرویسی را فراخوانی کند که یک درخواست خرید را برای فراهم کننده سرویس ارسال نماید، و اجرا موفقیت آمیز باشد، این موضوع ممکن است منجر به مسیولیت مالی نسبت به فراهم کننده سرویس یا بخش قانونی دیگر می شود.
در حالیکه طبیعت سرویس ها ممکن است تغییر کند، استاندارد مشترکی جهت اعلان یک سرویس هنگام تهیه یک زیرساخت مطلوب است. دو نمونه از چنین استانداردهای موجود ebXML و WSDL هستند.
2-3- اعلان و یابش سرویس ها
شرح سرویس باید به شیوه ای قابل دسترسی در اختیار کاربران بالقوه قرار گیرد که به این امر اعلان سرویس اطلاق می شود.
یابش، زمانی انجام می شود که یک مشتری بالقوه اطلاعاتی در مورد وجود یک سرویس، پارامترهای قابل اعمال و واژگان آن به دست آورد. یافتن، بحث تصدیق هویت جهت اجرای سرویس را شامل نمی شود؛ گرچه این جزییات ممکن است در الگوی یافتن قرار گیرد.
اجزای اعلان و یابش در SOA به شیوه های مختلف از جمله استفاده از روش ثبات / مخزن و یا روش دایرکتوری سرویس قابل پیاده سازی هستند.
• پیاده سازی به روش ثبات / مخزن
یک ثبات / مخزن جزیی است که در آن کاربران امکان ذخیره و مدیریت سرویس های لازم برای عملکرد سازمانشان را خواهند داشت. این موضوع شامل سرویس هایی است که تسهیم بین بیش از یک کاربر (نظیر xml schemas و شرح web-service) را فراهم می آورد که به ثبات به گونه ای منتسب می شود که ثبات در مورد تمامی رویدادهای قابل ارزیابی نسبت به محصولات در مخزن اطلاع دارد.
• پیاده سازی به روش دایرکتوری
دایرکتوری یک واسط است که اطلاعات انتساب به محصولات را فراهم می آورد. افرادی که مالک محصولات هستند و یا آنها را کنترل می کنند، می توانند یک مدخل به دایرکتوری باز کرده تا به محصولات ارجاع داده و خود انتسابات به آن را توضیح دهند. دیگران ممکن است این اطلاعات را بازیابی کرده و از آن جهت انتساب به محصولات استفاده کنند. مهم ترین مشکل دایرکتوری این است که هیچ کنترل یا اطلاع رسانی در صورت حذف، تغییر و جایگزین شدن یک محصول انجام نمی دهد و قادر به اعلام این رویدادها به کاربران نیست.
هر دو پیاده سازی دایرکتوری و ثبات / مخزن امکان سازگاری با یکدیگر را دارند. به این معنا که عملکرد اجازه می دهد که محتوا از یک پیاده سازی توسط یک پیاده سازی دیگر مورد ارجاع قرار گیرد.
چندین استاندارد وجود دارد که پیاده سازی ها دایرکتوری و ثبات / مخزن را دارند. رایج ترین استانداردها عبارتند از:
• OASIS ebXML Registry-Repository Technical Specifications16
• OASIS Universal Description and Discovery Interface (UDDI) Technical Specification17.2
2-4- خصوصیات مدل داده ای مرتبط
در هنگام فراخوانی یک سرویس، پارامترهای مشخصی ممکن است برای انجام درخواست سرویس مورد نیاز باشد. سرویس همچنین ممکن است پارامترهایی را به کاربر سرویس بازگرداند. W3C WSDL یک نمونه شناخته شده از پیاده سازی این بخش است.
3- اصطلاحات رایج در معماری مبتنی بر سرویس
• فراهم کننده سرویس: یک موجودیت نرم افزاری که خصوصیات سرویس را پیاده سازی می کند.
• درخواست کننده سرویس: یک موجودیت نرم افزاری که یک فراهم کننده سرویس را فراخوانی می کند، به طور سنتی این مورد به عنوان "کلاینت" شناخته می شود؛ اما یک درخواست کننده سرویس می تواند یک کاربر برنامه کاربردی و یا سرویس دیگر باشد.
• موقیعت یاب سرویس: یک نوع خاص از فراهم کننده سرویس که به عنوان یک ثبات عمل می کند و امکان جست وجوی واسطه های فراهم کننده سرویس و موقعیت سرویس را می دهد.
• واسط سرویس: یک نوع خاص از فراهم کننده سرویس است که می تواند درخواست سرویس را به یک یا چند فراهم کننده سرویس منتقل کند.
4- چارچوب SOA
4-1- زیرساخت SOA
4-1-1- نقشه مفهومی
شکل های 2 تا 4 نقشه هایی مفهومی هستند که مفاهیم پایه SOA را مستقل از معنی و تکنولوژی ها تشریح می کنند. نقشه های مفهومی غیر رسمی بوده و نمایش گرافیکی از مفاهیم و رابطه بین آنها را شامل می شود. شکل 2 مثالی از یک نقشه مفهومی است.

شکل1- مثالی از نقشه مفهومی
اغلب معماری هایی که SOA نامیده می شوند، شامل یک فراهم کننده سرویس، یک کاربر سرویس و برخی زیرساخت های پیام رسانی هستند.

شکل2- مدل مرجع معماری مبتنی بر سرویس پایه
4-1-2- مفاهیم اختیاری و زیرساخت های SOA اشتراکی

شکل3-مفاهیم اختیاری برای SOA و نمایش تعامل آنها با مفاهیم پایه این معماری
جهت اجرای تعهدات در زمان اجرا، اغلب SOAها ممکن است شامل مفاهیمی اضافه بر آنچه در شکل 3 نشان داده شده است، باشند. مفاهیم دیگر کاربران سرویس، کلاینت سرویس، قرارداد پذیرش سرویس و فراخوانی سرویس هستند. فراخوانی یک سرویس یا وجود کاربر سرویس در مدل SOAالزامی نیست. فراهم کننده یک سرویس، قرارداد سرویس جهت استفاده آن و شرح سرویس را ارایه می کند. شرح سرویس به مدل داده های مرتبط با فراخوانی سرویس ارجاع می کند.
شرح سرویس از طریق یکی از چندین روش اعلان می شود. کاربر سرویس خصوصیات سرویس را از طریق مکانیزم اعلان شناسایی می کند. شناسایی، پذیرش قرارداد را شامل نمی شود. همچنین فراخوانی سرویس را نیز القا نمی کند. این امر صرفاً عملی برای پیدا کردن اطلاعات در مورد سرویس است. این امر لزوماً در یک عمل اتفاق نمی افتد و ممکن است به تعدادی از کارها نیاز داشته باشد. همچنین ممکن است از طریق وسایل غیر الکترونیکی صورت پذیرد.
شکل 4 سایر عملکردهای خاص اختیاری را حذف کرده و از پیاده سازی های خاص نظیر پیام رسانیSOAP ، WDSL و ebXML خودداری می کند.
4-2- الگوهای SOA
شکل 5 یک الگوی ساده سرویس را نمایش می دهد. در جایی که یک فراهم کننده سرویس، سرویس را پیشنهاد می دهد و یک کاربر سرویس، از سرویس ها استفاده می کند. چندین نوع از پروتکل های ارتباطی ممکن است زوج درخواست/ پاسخ را مورد استفاده قرار دهد و روش های متنوعی نظیر سنکرون یا آسنکرون ممکن است استفاده شود. SOA به هیچ پروتکل ارتباطی خاص محدود نمی شود. شکل 5 الگوی "درخواست - پاسخ" را نمایش می دهد.

شکل4-الگوی پایه برای معماری مبتنی بر سرویس
5- چرخه حیات SOA
بر اساس طرح IBM، برای SOA می توان یک چرخه حیات در نظر گرفت. در فاز "مدل" نیازمندی های کسب و کار جمع آوری شده و فرایندهای کسب و کار آنها طراحی می شود. بعد از بهینه شدن فرایندها، از طریق کنار هم قرار دادن سرویس های موجود و سرویس های جدید این فرایندهای کسب و کار شکل می گیرد. سپس این سرمایه ها در یک محیط امن و با قابلیت تجمیع بالا نصب می شود. بعد از نصب فرایندهای کسب و کار، کاربران IBM این فرایندهای کسب و کار را هم از منظر فنی و هم از منظر فرایندهای کسب و کار مورد نظارت و مدیریت قرار می دهند.
اطلاعات جمع آوری شده در فاز مدیریت به چرخه حیات بازخورد خواهد داشت تا بهبود پیوسته فرایندها را امکان پذیر سازد. در زیر همه این مراحل در چرخه حیات، حاکمیت و فرایندهایی هستند که رهنمود ها و افق های آینده را برای پروژه SOA فراهم می کنند.

شکل 5- چرخه حیات معماری مبتنی بر سرویس
6-1- مرحله مدل سازی
فاز مدل با جمع آوری و تحلیل نیازمندی های کسب و کار آغاز می شود که بعداً برای مدل کردن، شبیه سازی و بهینه کردن فرایندهای کسب و کار مورد استفاده قرار می گیرند. فرایندهای کسب و کار حاصل برای طراحی سرویس های نرم افزاری مرتبط و سطوح سرویس جهت حمایت از این فرایندها مورد استفاده قرار می گیرند. در طول این فاز، مدلی جهت ایجاد درک مشترک بین کسب و کار و فناوری اطلاعات در فرایندهای کسب و کار، اهداف و خروجی ها استفاده می شود. به علاوه این مدل می تواند این اطمینان را به وجود آورد که کاربردهای حاصل، نیازمندی های کسب و کار تعریف شده را براورده می سازد. این مدل همچنین می تواند مبنایی جهت اندازه گیری کارآیی کسب و کار باشد.
6-2- مرحله گردآوری
در طول فاز گردآوری، کتابخانه سرویس های موجود می تواند جهت یافتن سرویس های مورد نظر و موجود در سازمان بررسی شود. در صورتی که سرویس مورد نظر یافت نشد این امکان وجود دارد که یک سرویس جدید ایجاد و پس از تست به مجموعه افزوده شود. هنگامی که سرویس های مورد نیاز فراهم شد، سرویس ها جهت پیاده سازی فرایندهای کسب و کار هماهنگ می گردند.
6-3- مرحله نصب
در طول فاز پیاده سازی، مقیاس و محیط زمان اجرا جهت تامین نیازمندی های سطوح سرویس به وسیله فرایندهای کسب وکار پیکربندی می شود. پس از پیکربندی یک فرایند کسب وکار، امکان پیاده سازی آن در یک محیط امن، مطمین و مقیاس پذیر سرویس ها وجود خواهد داشت. محیط سرویس ها به گونه ای بهینه سازی می شود که علاوه بر اجرای مطمین فرایندهای کسب وکار، امکان انعطاف پذیری جهت بروز کردن به طور پویا و در صورت تغییر نیازمندی های کسب وکار را فراهم می آورد. این رویکرد مبتنی بر سرویس همچنین هزینه و پیچیدگی نگهداری سیستم را نیز کاهش می دهد.
6-4- مرحله مدیریت
فاز مدیریت شامل نظارت و نگهداری از زمان پاسخ و در دسترس بودن سرویس می شود. همچنین مدیریت منابع سرویس های زیرین در این فاز انجام می شود. درک کارایی زمان واقعی فرایندهای کسب وکار امکان ایجاد بازخورد ضروری به مدل فرایند کسب و کار جهت بهبود دایمی را فراهم می آورد. این کار همچنین مدیریت و نگهداری کنترل نسخه برای سرویس های تشکیل دهنده فرایندهای کسب و کار را شامل می شود. فاز مدیریت در نهایت امکان اتخاذ تصمیمات کسب و کار بهتر و سریع تر را فراهم می سازد.
6-5- مرحله حاکمیت و فرایندها
حاکمیت و فرایندها جهت موفقیت هر نوع پروژه SOA ضروری هستند. جهت تخمین موفقیت، ممکن است یک مرکز تعالی در کسب وکار، برای پیاده سازی سیاست های حاکمیتی و دنبال کردن استانداردهای حاکمیتی بین المللی جهت اهداف کنترلی برای اطلاعات و تکنولوژی مرتبط ایجاد گردد. پیاده سازی سیاست های حاکمیتی قوی می تواند منجر به پروژه های SOA موفق گردد.
7- خصوصیات اساسی جهت استفاده بهینه از سرویس ها
• درشت دانه بودن: عملکردها روی سرویس ها به طور متفاوت پیاده سازی می شوند تا کارآیی بیشتری را در برگیرند و بر روی مجموعه های داده ای بزرگ تر در مقایسه با طراحی مبتنی بر اجزا عمل می کند. (شکل 8)
• طراحی مبتنی بر واسط: سرویس ها، واسط های مجزا تعریف شده را پیاده سازی می کنند. مزیت این امر آن است که چندین سرویس می توانند یک واسط مشترک را پیاده سازی کنند و یک سرویس می تواند چندین واسط را پیاده سازی کند. (شکل 9)
• قابل یافت بودن: سرویس ها لازم است هم در زمان طراحی و هم در زمان اجرا قابل یافت باشند، نه تنها با شناسه یکتا بلکه همچنین با شناسه واسط و با نوع سرویس.
• نمونه منفرد: بر خلاف توسعه مبتنی بر جزء که از اجزا بر حسب نیاز نمونه هایی ایجاد می شود، هر سرویس یک نمونه منفرد و همواره در حال اجرا است که مجموعه ای از کلاینت ها با آن ارتباط برقرار می کنند.
• اتصال ست: سرویس ها با دیگر سرویس ها و کلاینت ها از طریق تبادل اطلاعات استاندارد xml با یکدیگر در ارتباط هستند؛ این ارتباط باعث کاهش وابستگی و جداسازی بر اساس پیام رسانی می شود.
• آسنکرون: به طور کلی، سرویس ها از رویکرد انتقال پیام آسنکرون استفاده می کنند. اما این امر ضروری نیست. در بعضی مواقع در پیاده سازی سرویس ها از انتقال پیام سنکرون نیز استفاده می شود.
در شکل های زیر برخی از ویژگی های فوق نمایش داده شده است:

شکل 6- تاکید بر درشت دانه بودن در سرویس ها

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

شکل8- روش سنکرون در مقابل روش آسنکرون
با استفاده از فراخوانی آسنکرون، به فراهم کننده این امکان داده می شود که از چندین رشته کاری جهت مدیریت چندین درخواست کلاینت استفاده کند. جهت اجرای فراخوانی آسنکرون، درخواست کننده باید نشانی بازگشت را به سرویس پیاده ساز یک واسط ارسال کند.
9- جمع بندی
معماری مبتنی بر سرویس گام تکاملی بعدی در دنیای نرم افزار است. معماری های نرم افزاری فعلی قادر به حل تمامی مشکلات و چالش های فرا روی سازمان ها و سیستم های اطلاعاتی بزرگ و پیچیده نیستند. ویژگی های خاص معماری مبتنی بر سرویس این معماری را به عنوان بهترین گزینه برای این موضوع مطرح کرده است.
رضا گرگان محمدی- فصلنامه طیف برق