معماری سرویس گرا

مفاهيم مربوط به معماري سرويس­گرا[1] اوايل سال 1990 مطرح شد، مفاهيمي که بر روي اصولي همچون اتصال سست[2]، توزيع­شدگي و استفاده مجدد[3] تاکيد دارند. معماري سرويس­گرا يکي از  روش­هايي است که در رابطه با مباحث محاسبات توزيع­شده با ويژگي­هاي اتصال سست و بر اساس استانداردها و پروتکل­هاي مشخص مطرح شد. معماري سرويس­گرا با توجه به جايگاه معماري در مهندسي نرم­افزار در سال­هاي اخير با استقبال زيادي در دنياي فناوري اطلاعات و کسب­وکار و در توليد سيستم­هاي نرم­افزاري روبرو شده است. آنچه باعث افزايش روند گسترش استفاده از اين معماري شده­است ظهور وب سرویس‌ها است که در آن امکان عملياتي کردن اکثر اصول و مشخصات معماري سرويس­گرا فراهم است. استفاده و سازماندهی منابع گسترده، اعم از برنامه و داده در این معماری به نحوی صورت می­گیرد که به­کارگیری این قابلیت­ها به شکل یکسان و با تعاریف مشخص صرف­نظر از سکو، مشخصه شیء و دامنه امکان­پذیر باشد[14].

معماري سرويس­گرا واژه­اي­ است براي نمايش مدلي که در آن منطق توالي و هدايت به بخش­هاي منطقي کوچک‌تر تقسيم مي­شوند. اين بخش­ها خود شامل بخش­هاي منطقي کوچک‌تری هستند که   مي­توانند به صورت توزيع­پذير باشند. معماري سرويس گرا اين بخش­ها را به خودمختار بودن و دوري از انزوا سوق مي­دهد و از آن­ها مي­خواهد از مجموعه اصولي استاندارد و مشترک براي رشد و نمو به صورت مستقل پيروي کنند. در معماري سرويس­گرا به اين بخش­ها سرويس مي­گويند[15]. این سرویس­ها هم توسط دیگر نرم­افزارها قابل فراخوانی هستند و هم برای ساخت سرویس­های جدید مورد استفاده قرار می­گیرند. این راهکار برای یکپارچه­سازی فناوری­ها در محیط­هایی که انواع مختلفی از سکوهای نرم­افزاری و سخت­افزاری در آن وجود دارد، ایده­آل است.

معماری سرویس­گرا از جنبه­های مختلفی قابل بررسی می­باشد، هر ذینفعی بر اساس جایگاه خود برداشتی از این معماری دارد که در ادامه به بررسی آن‌ها می­پردازیم:

• متخصصان کسب­و­کار: معماری سرویس­گرا مجموعه­ای از سرویس­ها است که سازمان مایل به ارائه آن‌ها به مشتریان یا شرکای کاری خود می­باشد [6].
• معماران: معماری سرویس­گرا یک سبک از معماری است که حاوی قوانین، الگوها و ضوابطی است که باعث ایجاد خصوصیاتی مانند پیمانه­ای بودن، بسته­بندی، اتصال سست، استفاده مجدد و ترکیب پذیری شده و از نظر ساختار از یک ارائه­دهنده سرویس و یک درخواست‌کننده سرویس تشکیل شده است[16].
• طراحان و پیاده­سازان: معماری سرویس­گرا یک سبک و مدل برنامه­نویسی است که از استانداردهایی مانند (WSDL,UDDI,SOAP,…) و فناوری­هایی نظیر سرویس­های وب استفاده می­کند و قابلیت تعامل پذیری بین مؤلفه‌های نرم­افزاری را بدون توجه به سکو و فناوری پیاده­سازی آن‌ها پشتیبانی می­کند[15].

2-2-1 تعاریف معماری سرویس­گرا

برای معماری سرویس­گرا تعاریف متنوع و متفاوتی ارائه شده است که به نحوی خصوصیات آن را بیان نموده است. برای درک بهتر این مفهوم در ادامه مروری بر تعدادی از این تعاریف خواهیم داشت.

• یک سبک برای ساخت سیستم­های توزیع شده مطمئن است که امکاناتش را به صورت سرویس تحویل می­دهد و بیشتر روی سست اتصالی بین تعاملات سرویس­ها تاکید دارد[17].
• مدلی ارائه می­دهد که در آن منطق خودکارسازی به واحدهای منطق کوچک‌تر و مجزا تفکیک شده­است[15].
• چارچوب وسیع و استانداردی که سرویس­ها در آن ساخته شده، استقرار می­یابند و مدیریت می­شوند. هدف این چارچوب افزایش چابکی زیر­ساخت­های فناوری اطلاعات در جهت واکنش سریع به تغییرات نیازهای کسب­و­کار می­باشد[9].

در جمع­بندی از تعاریف معماری سرویس­گرا می­توان به ویژگی­های زیر اشاره نمود[15]:

• هم­راستا با کسب­و­کار سازمان است.
• هم­ موضوعی فنی است و هم نوعی تفکر است.
• مبتنی بر اتصال سست است و از پیام­رسانی استفاده می­کند.
• قادر به ساخت سیستم­های ترکیبی است.
• مهم­ترین دستاورد آن انعطاف­پذیری و چابکی فناوری اطلاعات در برابر تغییرات حرفه است.
• منجر به تعامل پذیری سامانه‌ها و سازمان­ها می­گردد.
• امکان ارائه یک سرویس با واسطه­های متنوع را محقق می­سازد.

در مدل پایه­ای این معماری، تعدادی سرویس وجود دارد که قرار است مشتریان از آن­ها استفاده کنند. مشتریان ممکن است کاربران، سرویس­های دیگر یا برنامه­های کاربردی باشند؛ ابتدا سرویس مورد نظر را بر اساس قراردادهای سرویس شناسایی، سپس درخواست خود را به آن سرویس ارسال     می­کنند. مکانیزم کلی عملکرد معماري سرويس­گرا به وسیله سه مؤلفه اوليه درخواست­دهنده سرويس^[4] يا مشتري، فراهم­کننده سرويس^[5]، انباره سرويس^[6] بيان مي­شود (شکل 2-1) [15].

 

شکل 2-1 مدل پایه سرویس­گرایی[15]

هر فراهم­کننده سرويس، براي معرفي خود توصيف­کننده خود را در انباره سرويس قرار مي­دهد. درخواست­کننده سرويس با جستجو در انباره سرويس، سرويس مورد نظر خود را انتخاب و بدون واسطه با فراهم­کننده آن سرويس ارتباط برقرار مي­کند. همان‌طور که گفته شد انباره سرويس شامل توصيف­کننده­هاي فراهم­کننده­هاي سرويس است. در ضمن هر سرويس مي­تواند هر دو نقش   فراهم­کننده و درخواست­دهنده را داشته باشد. در هنگام فراخوانی یک سرویس، پارامترهای معینی ممکن است برای انجام درخواست مورد نیاز باشد که به آن خصوصیات مدل داده­ای مرتبط می­گویند و یک سرویس ممکن است پارامترهایی را به کاربران سرویس بازگرداند. W3[7]C , WSD[8]L یک نمونه از این پیاده­سازی می­باشد [18].

2-2-2 سرویس

سرويس­ها در واقع همان بخش­هاي منطقي، در معماري سرويس­گرا می­باشند. هر سرويس در برگيرنده وظيفه مشخص، موجوديت و يا مجموعه­اي از فعاليت­هاي مرتبط است که در ابعاد مختلف تعريف مي­شوند. هر سرويس شامل منطق جداگانه­اي است. طبق تعریفی ديگر سرويس مكانيزمي براي فعال كردن دسترسي به يك يا چند قابليت است، دسترسي با استفاده از يك واسط مورد تأييد و سازگار با قيود و سياست‌هاي تعيين شده در شرح سرويس فراهم مي‌شود[19]. سرویس رفتار قراردادی تعریف شده­ای است که می­تواند به وسیله یک جزء برای استفاده جزء دیگر پیاده­سازی شده، فراهم شود[20]. مفهوم سرويس بر تمايز بين قابليتی كه مجموعه عملياتي براي رفع نيازها ارائه مي‌دهد و نقطه دسترسي به سرويس را که در متن معماري سرويس­گرا آورده مي‌شود تاكيد دارد. يک سرويس را مي­توان تابعي خوش­تعريف^[9] و جامع در نظر گرفت که به زمينه و حالت سرويس­هاي ديگر بستگي ندارد[21].

هر سرویس شامل پارامترهای فنی، قیود و سیاست­هایی است که قالب­های لازم برای فراخوانی سرویس را تعریف می­کند. هر سرویس، شرح سرویسی را در قالب استانداردی تعریف می­کند. مزیت شرح سرویس برای کاربران و طراحان سرویس این است که به آن‌ها کمک می­کند تا بدانند سرویس چه کاری انجام می­دهد و ورودی و خروجی آن چیست [20]. از آنجایی که طبیعت سرویس­ها دائماً در حال تغییر است، باید واژه­هایی را به صورت قانونی و استاندارد برای برقراری ارتباط بین  سرویس­ها تعریف نمود. که می­توان به عنوان نمونه زبان توصیفی وب سرویس­ را نام برد[9] .

شرح سرویس باید به شیوه­ای قابل دسترس در اختیار کاربران بالقوه قرار گیرد که به این امر اعلان سرویس می­گویند. پایش سرویس زمانی صورت می­گیرد که یک مشتری بالقوه اطلاعاتی در مورد وجود یک سرویس، پارامترهای قابل اعمال و واژگان آن بیابد[15]. اجزای اعلان و پایش در معماری سرویس­گرا به شیوه­های مختلفی پیاده­سازی می­شود که در ادامه به برخی از آن‌ها می­پردازیم:

• پیاده­سازی به روش ثبات/مخزن: در این حالت کاربران امکان ذخیره و مدیریت سرویس­های لازم برای عملکرد سازمانشان را خواهند داشت. این موضوع شامل سرویس­هایی است که تسهیم بین بیش از یک کاربر (مانند شرح وب سرویس‌ها) را فراهم می­آورد و ثبات در مورد تمامی رویدادهای قابل ارزیابی به نسبت محصولات درون مخزن اطلاع دارد[15].
• پیاده­سازی به روش کتاب راهنما[10] : کتاب راهنما یک واسط است که اطلاعات نسبت داده شده به محصولات را فراهم می­آورد. افرادی که مالک هستند یا آن‌ها را کنترل می­کنند، می­توانند یک راه به کتاب راهنما باز کنند و به محصولات ارجاع شده و اطلاعات نسبت داده شده توضیح دهند. همچنین ممکن است این اطلاعات توسط دیگران نیز بازیابی شود. مهم‌ترین مشکل کتاب راهنما این است که هیچ کنترلی یا اطلاع رسانی در صورت حذف، تغییر و جایگزینی یک محصول انجام نمی­دهد و قادر به اعلام این رویدادها به کاربران نیست[18].

سرويس­­گرايي در تئوري جداسازي نگراني­ها^[11] ریشه دارد. بر اساس اين تئوري هر مسئله بزرگ را مي­توان با شکستن به بخش­هاي کوچک‌تر و مستقل و مرتبط به هم حل کرد. سرويس­گرايي براي تحقق اين تئوري اصول زير را براي سرويس­ها در نظر گرفته است[15]:

• سرويس­ها قابل استفاده مجدد^[12] هستند: سرويس­گرايي تمام سرويس­ها را به استفاده مجدد بدون در نظر گرفتن نيازهاي فعلي تشويق مي­کند. با رعايت استانداردهاي طراحي پتانسيل استفاده مجدد از سرويس­ها بيشتر مي­شود که سبب برطرف کردن سريع نيازهاي آينده مي­شود. همچنين به صورت چشمگيري نياز به سرويس­هاي پنهان­ساز^[13] براي قرار دادن واسطي بر روي سرويس­ها را کاهش مي­دهد. استفاده مجدد يکي از مهم­ترين اصول سرويس­گرايي است.
• سرويس­ها قرارداد رسمي^[14] را به اشتراک مي­گذارند: هر قرارداد شامل تعريفي رسمي از نقطه تماس^[15] سرويس، عمل­هاي سرويس، پيغام­هاي ورودي و خروجي و قواعد و مشخصات عمل­هاي سرويس است. به بياني ديگر بخش­هاي مختلف در مدل پایه معماري سرويس­گرا را تعريف مي­کند.
• سرويس­ها به صورت ارتباط سست^[16] هستند: ارتباط سست شرايطي است که يک سرويس دانش مربوط به سرويس ديگر را بدست مي­آورد در حالی که به صورت مستقل از آن سرويس باقي مي­ماند. ارتباط سست به وسیله استفاده از قرارداد رسمي میان سرويس­ها محقق مي­شود. در معماري سرويس­گرا منظور از اتصال سست قابليت تعامل بين سرويس‌ها به صورت مستقل از کد نویسی و مکان سرويس‌ها است، به گونه‌اي که سرويس‌ها در زمان اجرا مي‌توانند تغيير مکان داده، روال­هاي داخلي خود را تغيير دهند يا حتي از يک فناوري جديدتر استفاده کنند، بدون اينکه تأثیری منفي بر سرويس­گيرندگان گذاشته شود. ارتباط سست يکي ديگر از مهم­ترين اصول سرويس­گرايي است.
• سرويس­ها منطق زيرين خود را به صورت تجرید^[17] محقق مي­سازند:به عبارتی سرویس­ها منطق محصور شده درون خود را از عالم خارج مخفی می‌کنند. نکته قابل ذکر در اینجا این است که تفاوت میان مجرد سازی و مخفی سازی در چیست؟ مجرد سازی به تعریف موجودیت­های رویه‌ای و یا اطلاعاتی که نرم­افزار را می‌سازند کمک می­کند، ولی  پنهان­سازی محدودیت­های دسترسی را برای جزئیات رویه­ای داخل پیمانه و هر ساختمان داده محلی استفاده شده در پیمانه را تعریف و اجباری می­نماید.
• سرويس­ها قابل ترکيب^[18] هستند: هر سرويس مي­تواند مقدار متفاوتي از منطق را از منابع متفاوت که شامل سرويس­ها نيز مي­شود تأمین کند. دليل اصلي از اين اصل براي اطمينان از طراحي سرويس­ها به صورتی که بتوانند به عنوان عضوي از يک سرويس ترکيبي باشند، است.
• سرويس­ها خودمختار هستند: هر سرويس منطق خويش را به صورت محدوده مشخص بيان مي­کند. سرويس به تمام فرآيندهاي خويش خودمختار است. اين اصل تنها ضمانت مي­کند که در زمان اجرا سرويس نسبت به منطق خويش کنترل دارد.
• سرويس­ها قابل کشف و شناسايي هستند: اين خاصيت سرويس­ها سبب مي­شود تا سرويس­هاي تکراري ايجاد نشوند. خاصيت مهم ديگر آن امکان ارائه مکانيزم کشف و شناسايي است که معمولاً بر اساس انباره سرويس صورت می­گیرد

.

2-2-3 مفاهیم مرتبط با معماری سرویس­گرا

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

• فراهم­کننده سرویس: یک موجودیت نرم­افزاری است که خصوصیات سرویس را پیاده­سازی می­کند[15].
• درخواست کننده سرویس: یک موجودیت نرم­افزاری است که یک فراهم­کننده سرویس را فراخوانی می­کند. به طور سنتی این مورد به عنوان سرویس­گیرنده شناخته می­شود. اما یک درخواست کننده سرویس می­تواند به عنوان یک برنامه کاربردی و یا به عنوان یک سرویس دیگر قرار گیرد[15].
• موقعیت یاب سرویس: یک نوع خاصی از فراهم­کننده سرویس است که به عنوان یک ثبات عمل می­کند و امکان جستجوی واسطه­های فراهم­کننده سرویس و همچنین موقعیت سرویس مورد نظر را می­دهد[15].
• واسط سرویس: یک نوع خاصی از فراهم کننده سرویس است که می­تواند درخواست سرویس را به یک یا چند فراهم­کننده سرویس منتقل کند[15].
• محصورسازی سرویس: محصورسازی یکی از اصول شی­گرایی است که در معماری سرویس­گرا نمود پیدا کرده است. در شی­گرایی شی را محصور می­کنند تا از تأثیرات ناخواسته در امان باشد، همچنین از واسط­ جهت ارتباط با شی استفاده می­کنند و طرق دسترسی به شی را به آن محدود می­کنند. در معماری سرویس­گرا هم این منطق است؛ و باز هم با همین اهداف محصورسازی می­شود. اما باید توجه داشت که این منطق دارای    اندازه­های متفاوت است به طوری که این دانه­بندی برای سرویس و منطق آن مانع از محصورسازی آن‌ها نمی­شود و در این حالت نیز محصورسازی انجام می­شود (شکل 2-3) [15].

شکل 2-2 دانه­بندی سرویس­ها[15]

هر سرویس می­تواند یک وظیفه که توسط یک گام مشخص اجرا می­شود را بسته­بندی کند. این کوچک‌ترین دانه­بندی در محصورسازی منطق راه­حل توسط سرویس به شمار می­آید. همچنین می­تواند یک­ زیر فرآیند که شامل مجموعه­ای از گام­هاست یا تمامی منطق فرآیند را محصورسازی کند. در دو مورد اخیر محدوده بزرگ ارائه شده توسط سرویس­ها ممکن است شامل منطق ارائه شده توسط دیگر سرویس­ها نیز باشد. برای آنکه سرویس­ها از منطقی که محصور کرده­اند استفاده نمایند، می­توانند در اجرای فعالیت­های کسب­و­کار سهیم شوند [15].

• هم­نواسازی[19] و هم­خوانی[20] : دو واژه پر کاربرد در حوزه کسب­و­کار و معماری سرویس­گرا که معمولاً به جای هم اشتباه گرفته می­شوند. هم­نواسازی در خصوص ترتیب اجرای سرویس­ها در فرآیند بحث می­کند، هم­نواساز اصلی مجموعه­ای از سرویس­ها را فراخوانی می­کند تا نتیجه مورد نظر حاصل شود و فرآیند تکمیل گردد (ممکن است سرویس­های خارج سازمان نیز در این راستا فراخوانی و استفاده شوند که این کار با کمک موتور فرآیند تحقیق انجام می­شود). در حالی که هم­خوانی به فرآیندهایی می­گویند که بدون موتور فرآیندی (رهبر ارکستر) اقدام به تبادل پیام کرده و ترتیب و توالی پیام­های مبادلاتی را خود بازیگران ثبت و کنترل می­کنند (شکل 2-3)[22] .

شکل 2-3 هم­نواسازی و هم­خوانی

بنابراین هم­نواسازی به معنای وجود یک موتور فرآیندی است که ترتیب و توالی را کنترل کرده و از شرکا داخلی یا خارجی برای انجام کارها استفاده می­کند. نمونه این مدل، سیستم مدیریت فرآیندهای کسب­و­کار است که فرآیندها در موتور فرآیندی اجرا می­شوند[22].   هم­خوانی به معنای پردازش­های توزیع­شده بین چند فرآیند است که بدون یک رهبر مرکزی با هم تعامل دارند و یا چندین موتور فرآیندی که در کنار و هم­سطح هم اجرا می­شوند و با همکاری هم هدفی را محقق می­سازند. نمونه این حالت در پردازش­های توزیع­شده و یا فعالیت­های بین سازمانی که هر دو طرف با مشارکت هم به دنبال یک هدف معین هستند دیده می­شود[22]. بنابراین مهم‌ترین تفاوت هم­خوانی و هم­نواسازی در داشتن مالک و کنترل­کننده مرکزی است.

[1]  Service Oriented Architecture

[2] Loosely-coupled

[3] Reuse

[4] Service requester

[5] Service provider

[6] Service Registry

[7]  World Wide Web Consortium

[8] Web Service Description Language

[9] Well-defined

[10] Directory

[11] Separation of concerns

[12] Reusable

[13] Wrapper

[14] Formal contract

[15] Endpoint

[16] Loosely coupled

[17] Abstraction

[18] Composable

[19] Orchestration

[20]  Chereography