اصول معماري سرويس گرا

معماري سرويس گرا روشي براي طراحي سيستم هاي نرم افزاري با استفاده از سرويس هااست. از اين رو اصولي در اين پارادايم تعريف شده اند كه مبناي توسعه، نگهداري و استفاده از معماري سرويس گرا مي باشند. اين قواعد زمينه هاي زير را در بر مي گيرند[22].

• استفاده مجدد، دانه بندي، پيمانه اي بودن، قابليت تركيب،مولفه سازي و قابليت هاي همكاري
• پيروي از استانداردها( استاندارد هاي عمومي و خاص صنايع)
• شناسايي و طبقه بندي ، تهيه و تحويل، و نظارت و رديابي سرويس ها.

علاوه بر موارد فوق، قواعد معماری دقیقی برای طراحی و تعریف سرویس ها پیشنهاد شده است که بر رفتار طبیعی سیستم و سبک طراحی آن تاثیر می گذارند.[23]اصول زیر برای طراحی معماری سرویس گرای کارآمد پیشنهاد شده است :

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

معماری سرویس گرا و راه حل های مبتنی بر وب سرویس از دو نقش کلیدی پشتیبانی می کنند : یک درخواست کننده سرویس (مشتری) و یک تولید کننده سرویس که از طریق درخواست های سرویس با یکدیگر تعامل دارند. در نتیجه نقش ، نوع شرکت کننده در معماری سرویس گرا را مشخص می کند[24]. میان درخواست کننده و تولید کننده یک رابطه اتصال ضعیف وجود دارد ،که به طور خاص در اینترنت ، از اهمیت بالایی برخوردار است زیرا دو طرف ممکن است در سازمان های متفاوتی باشند .

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

تولیدکننده های سرویس ، سرویس ها را در در قالب استاندارد تعریف و توصیف کرده سپس آنها را در مخازن سرویس، همراه با اطلاعاتی در مورد جزئیات فنی و نحوه دسترسی به سرویس منتشر می کنند . توصیف سرویس ها معمولاً در قالب فایل های زبان توصیف سرویس های وب (WSDL[1]) صورت می گیرد. هر فایل WSDL شامل اطلاعاتی در مورد نوع متغیر های ، عملیات ، واسط ، نقاط و زمان اتصال سرویس می شود. درخواست کننده سرویس از روی اطلاعات موجود در مخازن ، سرویس مورد نیاز خود را پیدا می کند. سپس با استفاده از اطلاعاتی که تولید کننده فراهم کرده است اتصال خود با تولید کننده را برقرار کرده و از سرویس استفاده می کنند . نمای این معماری در شکل 2-4 نمایش داده شده است .

شکل 2.7مدل معماری وب سرویس] 26[

در ادامه با توجه به موضوع این تحقیق به معرفی روش های کشف سرویس پرداخته می شود .

2.6.1 کشف سرویس

یکی از مزایای معماری سرویس گرا فراهم کردن بستری برای استفاده از سرویس های تولید شده در خارج از سازمان است که سبب صرفه جویی در هزینه و سرعت بخشیدن به فرآیند توسعه سیستم می شود[25].از این رو به ساز وکارها و روش هایی نیاز است تا یک سازمان را در شناسایی سرویس های مورد نیاز خود کمک کنند. موضوع کشف سرویس در همین راستا مطرح می شود و رابطه نزدیکی با روش های انتشار سرویس و بازیابی اطلاعات دارد .

کشف سرویس عمل تطبیق نیازهای یک مشتری با اطلاعات ارائه شده در توصیف سرویس توسط ارائه دهندگان سرویس است.

درخواست کننده سرویس می تواند توصیف سرویس را در زمان طراحی یا زمان اجرا از مخازن توصیف سرویس ، مانند[2] UDDI، بدست آورد[26]. کشف سرویس در اکثر مواقع در ادامه شناسایی سرویس انجام می شود . در شناسایی سرویس با تحلیل نیازمندی های سیستم ، تشخیص داده می شود که به چه سرویس هایی نیاز است . در مرحله بعد یا این سرویس ها تولید می شوند و یا با استفاده از روش های کشف سرویس، سرویس های متناظر با سرویس های شناسایی شده کشف می شوند .

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

 2.6.2 روش های کشف سرویس

هدف کشف سرویس تسهیل دسترسی درخواست کنندگان به توصیف سرویس ها است . برای این منظور روش های متفاوتی ارائه شده اند که تلاش می کنند دسترسی آسان با دقتی بالا به سرویس ها را برای درخواست کنندگان فراهم کنند. این روش ها عمل تطبیق بین سرویس درخواستی و سرویس های موجود را بر روی توصیفات سرویس ها که در قالب فایل های WSDL آمده است انجام می دهند . روش های کشف سرویس را می توان به دو دسته کلی روش های کارکردی و روش های غیر کارکردی تقسیم کرد. در ادامه در مورد هر دسته از این روش ها توضیح مختصری داده می شود[28] .

[1] ^{Web Service Description Language}

[2] ^{Universal Description, Discovery and Integration}

روش های کشف سرویس مبتنی بر توصیف کارکردی

در این دسته ، روش ها توصیفات عملکردی سرویس ها را با نیاز های عملکردی درخواستی تطبیق می دهند . توصیفات عملکردی یک سرویس را مشخص می کند . این روش ها به سه دسته تطابق لغوی ، تطابق معنایی و تطابق رفتاری تقسیم می شوند[28] .

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

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

در روش های تطابق معنایی ، روابط و مفاهیم معنایی توصیف سرویس ها نیز در فرآیند تطبیق لحاظ می شود . این روش ها بسته به نحوه کشف روایط معنایی به چهار دسته روش های بازیابی اطلاعات ، روش های مبتنی بر هستان شناسی و روش های مبتنی بر محتوا ، تقسیم می شوند .

روش های مبتنی بر بازیابی اطلاعات از موتورهای جستجو و خزنده های وب برای پیدا کردن فایل های  WSDL در اینترنت استفاده می کنند . سپس روش های بازیابی اطلاعات را برای فرآیند تطبیق به کار می برند . تشابه معنایی بین توصیف و درخواست سرویس با استفاده از پایگاه های داده ای لغوی ، مانندWordNet، انجام می شود. ایراد این روش در این است که نتایج فرآیند جستجو ممکن است دقت 100 درصد نداشته باشند[28] .

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

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

روش های کشف سرویس مبتنی بر توصیف غیر کارکردی

این دسته از روش های کشف سرویس بر اهمیت ویژگی های غیرعملکردی از دیدگاه درخواست کننده تاکید دارد. عامل اصلی در این روش ها سطح کیفیت خدمات (QoS[1]) ارائه شده توسط تولید کنندگان است . برای این منظور مدل توسعه داده شده UDDI نیز پیشنهاد شده است تا از QoS ها ، ویژگی­های قابلیت استفاده از پرکاربردترین ویژگی ها در زمینه پیدا کردن سرویس های مورد نیاز درخواست کنندگان را شناسایی کند . بر این مبنا روشی ارائه شده است که انتظارات و ترجیحات درخواست کنندگان را در شناسایی سرویس مناسب دخالت می دهد . در اغلب این روش ها از محاسبات فازی برای رسیدن به توازن میان ویژگی های مختلف، در حالتی که سرویسی که تطابق کامل با نیازهای درخواست کننده داشته باشد پیدا نشود ، استفاده می شود[29].

 2.6.3 معماری های کشف سرویس

معماری های متفاوتی برای کشف سرویس ارائه شده اند که بیشتر به محل مخازن سرویس و نحوه دسترسی به آنها می پردازند . معماری های پیشنهاد شده را می توان به دو دسته کلی معماری های متمرکز و معماری های توزیع شده تقسیم کرد.

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

روش هایی که معماری توزیع شده را پیشنهاد می کنند از قابلیت انعطاف پذیری و توسعه پذیری بهره می برند . در چنین معماری هایی سرویس ها در وب سایت تولید کننده نگهداری می شوند و از ساز و کارهای متفاوتی برای پیدا کردن سرویس ها استفاده  می شود. روش هایی که از معماری توزیع شده استفاده می کنند را می توان بر اساس نحوه دست یابی به سرویس ها به سه دسته معماری های مبتنی بر اینترنت ، معماری های مبتنی بر عامل ها و معماری های همتا به همتا تقسیم کرد[30] .

[1] ^{Quality of Service}