Borna66
03-15-2009, 12:43 PM
بررسی معماری سرویس گرا
اشاره :
در چهار دهه اخیر ، پیچیدگی نرم افزارها روز بروز بیشتر شده و تقاضا برای نرم افزارهای قدرتمندتر افزایش یافته است. در این میان ، به نظر می رسد که روشهای قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روشهایی است که بوسیله آنها بتوان بر این پیچیدگیها در زمانهایی کوتاهتر غلبه کرد. از طرفی امكان كنار گذاشتن سیستمهای نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند ، وجود ندارد و می بایست سیستمهای جدید را بصورت یکپارچه و در کنار همین سیستمها بوجود آورد. معماری سرویس گرا ، با تکیه بر محاسبات توزیع شده و بر پایه شبکه ها و لایه های میانی و همچنین زبانهایی که تولید نرم افزارهای توزیع شده را فراهم می كنند ، بعنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذكور مطرح گردیده است. در این مقاله ضمن معرفی این معماری به محاسبات سرویس گرا و نیازهای آن پرداخته و معماری سرویس گرای توسعه یافته به عنوان راه حلی برای رفع این نیازها ارائه می شود.
معرفی
تعاریف گوناگونی از معماری سرویس گرا ارائه شده است كه از جمله آنها می توان به تعاریف زیر اشاره كرد:
مجموعه قوانین ، سیاستها و چهارچوبهایی كه نرم افزارها را قادر می سازد تا عملكرد خود را از طریق مجموعه سرویسهای مجزا و در عین حال مربوط به هم در اختیار سایر درخواست كنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابطهای استاندارد و تعریف شده ، این سرویسها را پیدا كرده و فراخوانی نمایند.و یا معماری سرویس گرا روشی برای ساخت سیستمهای توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویسها قرار می گیرد.
از دیگرتعاریف ارائه شده می توان به "واحدهای نرم افزاری آماده در شبكه (Network-available Software Unit) " یا "سرویسهای سطح حرفه (Business-level services) " اشاره كرد.
در حال حاضر ، تکنولوژی سرویسهای وب(Web Services) و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستمهای جدید و یکپارچه-سازی سیستمهای بزرگ موجود ، مطرح گردد. البته ذکر تفاوت سرویسهای وب و SOA در اینجا لازم به نظر می رسد.
سرویسهای وب مجموعه ای از تکنولوژیهایی همچون XML,SOAP,WSDL و UDDI می باشد که امکان ارائه راه حل و برنامه نویسی جهت رفع مشکلی خاص را فراهم می نماید.
در حالی که SOA یک معماریست و از مجموعه مشخصی از تکنولوژیها فراتر می باشد. اگرچه SOA بر اساس این تکنولوژیها راه حل ارائه می نماید ، اما در عین حال مستقل از هر یک از آنها است.
آنچه اهمیت دارد تعریف سرویس به عنوان مهمترین عنصر این معماری می باشد.
سرویس ، رفتار قرادادی تعریف شده ایست که هر قطعه ای می تواند آنرا جهت استفاده سایر قطعات در سیستم تهیه و پیاده سازی نماید.
در این معماری ، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع حرفه (Business functions) و تراكنشهای حرفه‌ای (Business transactions)می باشند كه تراكنشهای حرفه خود شامل توابع سطح پایین (Low-level functions) و توابع سیستمی سرویسها(System service functions) هستند.
سرویسها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند.
قطعات، سرویسهای خود را از طریق رابطها (interface) در اختیار قطعات دیگر قرار میدهند که این رابطها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابطهای محلی یا دور ) . در ضمن این رابطها می توانند به همان نرم افزار كاربردی یا به آدرسی در محل دیگری از شبکه مرتبط باشند .
رابطها به عنوان کلیدی در برقراری این ارتباطها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد.
بعلاوه ، با ایجاد قابلیت توزیع شدگی به شكلی مناسب و بدون وابستگی زیاد ، می توان سرویسها را در قسمتهای مختلف شبکه و بصورت بعضا تکراری ( مخصوصا برای سرویسهای مهم ) قرار داد تا این سرویسها همیشه در دسترس بوده و در صورت زیاد شدن درخواستها بتوان با استفاده از تکنیکهای Load Balancing به تمامی آنها به‌خوبی پاسخ داد.
ویژگیهای سرویس و محاسبات سرویس گرا
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پایه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
از آنجا که سرویسها از طریق سازمانها و شرکتهای گوناگون تهیه می شوند و جهت دسترسی كاربران مختلف می بایست همواره در دسترس باشند ، رعایت ویژگیهای زیر ضروری می باشد:
- مستقل از تکنولوژی باشند؛ به این معنا که بکارگیری و مکانیزم فراخوانی و پیدا کردن سرویسها به راحتی و از تمام محیطها ( سیستمهای عامل مختلف و زبانهای برنامه سازی گوناگون ) میسر بوده و وابسته به پلتفرم خاصی نباشد.
- وابستگی بسیار پایینی بین درخواست کننده و ارائه دهنده سرویس وجود داشته باشد و یا بعبارتی Loosly Coupled باشد. به این معنا که درخواست کننده نباید هیچ نیازی به دانستن ساختار داخلی و نحوه پیاده سازی سرویس داشته باشد. برای این منظور ، فراخوانی سرویس از طریق بکار گیری مکانیزم پیغام (Message) بجای فراخوانی API انجام می گردد.
- درخواست کننده نباید نیازی به دانستن محل قرارگیری سرویس داشته باشد و بعبارتی معماری سرویس گرا می بایست Location Transparency را پشتیبانی نماید. به این ترتیب که محل قرارگیری سرویس و مشخصات آن در مخزنی (Repository) قرار می گیرد و درخواست کننده ، محل و اطلاعات لازم را از طریق بازیابی آن از این مخزن بدست می آورد.
سرویس ها می توانند به دو شکل ساده و ترکیبی ارائه شوند. سرویسهای ترکیبی ، سرویسهایی هستند که بر اساس بکارگیری چند سرویس ساده ( یا ترکیبی) ایجاد می شوند. برای مثال ، ممکن است سیستم توزیع شده ای بر اساس چند سرویس ساده صدور صورتحساب ، ثبت سفارش ، مدیریت روابط مشتری و ... سرویسهای ترکیبی گسترده تری در ارتباط با حرفه ای خاص ایجاد نماید.
سیستمهای ساخته شده بر اساس سرویس ، ترکیبی از سرویسهای مستقل هستند که عملکردهای خود را از طریق رابطهای تعریف شده ای در اختیار کاربران (بالقوه ) خود قرار میدهند. (Web Service Description Language)WSDL از جمله راههایی است که بطور گسترده برای تعریف این رابطها بکار می رود تا بوسیله آن جزئیات لازم برای اتصال درخواست کننده به ارائه دهنده سرویس تعریف شود.
نرم افزار به‌عنوان سرویس
اصل ارائه شده " نرم افزار- بعنوان- سرویس" از محاسبات سرویس گرا ، بر اساس مدل ASP مطرح گشته است. ASP هویت سوم شخصیست که بكارگیری سرویسهای نرم افزاری و دسترسی مشتری را به بسته نرم افزاری از طریق شبكه، مدیریت و میزبانی می نماید.به‌عبارتی ASP ها راهی برای رفع نیازهای IT شرکتها از طریق واگذاری بخشی از این نیازها یا تمامی آنها به بیرون از سازمان می باشند.
برای این منظور ASP با استفاده از زیر ساختهای خود ، ارتباط بین مشتری و نرم افزار ارائه شده را برقرار کرده و دسترسی وی به داده ها و توابع موجود را بصورت در دسترس (online)، مدیریت می نماید.
اگرچه نظریه "نرم افزار بعنوان سرویس" اولین بار توسط ASP ارائه شد ، اما مشكلات این روش باعث ایجاد کدهایی می شد که معمولا قابل استفاده مجدد نبوده و محدود به مشتری خاص می بود ، بعبارتی وابستگی زیادی بین سرویس ارائه شده و سیستم استفاده کننده بوجود می آمد.
معماری سرویس گرا اجازه میدهد تا نظریه "نرم افزار بعنوان سرویس"، گسترش یافته تا از طریق آن بتوان پردازشها و تراکنشهای پیچیده را بعنوان سرویسهایی با قابلیت استفاده مجدد ارائه کرد و به این ترتیب سیستمها را مستقل از سرویسها طراحی و تولید نمود.
معماری سرویس گرای مقدماتی
SOA شیوه ای منطقی برای طراحی سیستمهای نرم افزاری است که از طریق آن سرویسهایی جهت ارائه به کاربران یا سایر سرویسهای توزیع شده بر روی شبکه ایجاد می شود و این سرویسها از طریق رابطهای تعریف شده در دسترس می باشند.
معماری سرویس گرای مقدماتی ، راهی برای تبادل اطلاعات بین عاملهای نرم افزاری بوسیله پیغام تعریف می نماید. این عاملها ، درخواست کننده سرویس (مشتری) و یا تهیه کننده سرویس می باشند. علاوه بر این دو، عامل دیگری بعنوان عامل کشف سرویس نیز وجود دارد. در معماری سرویس گرا معرفی سرویسها و همچنین نحوه ارتباط این سه شرکت کننده نیز اهمیت دارد. این ارتباطات عبارتند از : منتشر کردن سرویس ، پیدا کردن سرویس و متصل شدن به سرویس.
http://www.pnu-club.com/imported/mising.jpg
شکل 1
در یک سناریو بر پایه سرویس ، تهیه کننده ، سرویس را پیاده سازی کرده و از طریق شبکه به ارائه توضیحات آن سرویس برای درخواست کننده یا عامل کشف سرویس می پردازد. در خواست کننده معمولا درخواست پیدا کردن سرویس را به عامل کشف سرویس میدهد تا از طریق آن به توضیحات ارائه شده سرویس و محل آن دسترسی پیدا کند. سپس با بکارگیری این اطلاعات به تهیه کننده سرویس متصل شده و از سرویس ارائه شده استفاده می نماید.
بدین ترتیب ، سرویس بعنوان قطعه نرم افزاری پیاده سازی شده ای که توسط یک رابط تعریف شده مستند گردیده است و نه تنها بوسیله خود تهیه کننده بلکه توسط سایر عواملی که از نحوه پیاده سازی آن خبر ندارند ، نیز قابل استفاده و فراخوانی است. این ویژگی جعبه سیاه بودن سرویس از اصل ماژولاریتی در مهندسی نرم افزار به ارث رسیده است. البته سرویس با تعاریفی مانند ماژول ، قطعه نرم افزاری یا شی تفاوت دارد ، زیرا نه تنها در سطح برنامه ها و نرم افزارهای کاربردی ، بلکه در سطح حرفه و حتی مابین سازمانها نیز قابل بكارگیری و استفاده مجدد می باشد.
در واقع سرویسها، نمایش عملکرد معنی داری از حرفه هستند که می توانند بنا به نیاز مشتری در سرویسها و توابع بزرگتر یا جدید بکار گرفته شوند.
رابطها به سادگی مکانیزمی جهت برقراری ارتباط بین سرویس و نرم افزارها یا سایر سرویسها ایجاد می نمایند. از لحاظ تکنیکی، رابط سرویسها ، توضیحاتی در مورد نام و امضاء متدهای یک سرویس هستند که توسط درخواست کننده ، قابل فراخوانی می باشند.
معماری سرویس گرای توسعه یافته
معماری سرویس گرای مقدماتی به برخی از مسائل موجود در یک معماری مبتنی بر سرویس نمی پردازد. از جمله این مسائل، مدیریت، هماهنگ سازی سرویسها ، متناسب کردن آنها ، امنیت ، مدیریت تراکنشها و ... می باشد.این نکات که در شکل 2 نمایش داده شده است ، در معماری سرویس گرای توسعه یافته در نظر گرفته شده است.
http://www.pnu-club.com/imported/mising.jpg
شکل 2
معماری مقدماتی در لایه پایینی این معماری لایه ای قرار گرفته است. لایه ترکیب سرویس در معماری توسعه یافته ، شامل توابع و نقشهای لازم برای یکپارچه کردن چند سرویس بعنوان سرویس ترکیبی می باشد. سرویس ترکیبی بدست آمده ، توسط Service Aggregator بعنوان یک سرویس مقدماتی استفاده می گردد و یا توسط درخواست کنندگان سرویس بکارگرفته می شود.
Service Aggregator تهیه کننده سرویسی است که سرویسهای ارائه شده توسط سایر تهیه کنندگان را یکپارچه می نماید تا از آنها سرویسهای جدید بسازد، همچنین مشخصات و کدهایی را تهیه می کند تا در مورد سرویسهای ترکیبی عملیات زیر را انجام دهد:
- متناسب کردن : کنترل اجرای سرویسهای ترکیب شده و مدیریت گردش داده ها در بین آنها و انتقال آن به خروجی.
- کنترل کردن : مجوز دادن به رخدادها و اطلاعات تولید شده توسط سرویسهای ترکیبی جهت به اشتراک گذاشتن و منتشر کردن رخدادهای ترکیبی سطح بالاتر ( برای مثال از طریق فیلتر کردن و خلاصه سازی)
- مطابقت دادن : حصول اطمینان از حفظ جامعیت سرویسهای ترکیبی از طریق تطبیق دادن محدودیتها و نوع پارامترهای سرویسهای بکار رفته.
- ترکیب خواص سرویسها : بکارگیری ، مجتمع سازی و دسته بندی ویژگی های سرویسهای ترکیب شده جهت بدست آوردن خواص ترکیبی جدید که دربردارنده کارایی ، هزینه ، امنیت ، جامعیت ، قیاس پذیری ، در دسترس بودن و قابلیت اطمینان می باشد.
استانداردهای جدید ارائه شده با عنوان زبان اجرای پردازشهای حرفه برای سرویسهای وب ، تلاشی است که بر اساس XML ، تعریف سرویسهای وب جدید را که از ترکیب سرویسهای موجود بدست می آیند ، ارائه دهد.یک پردازش BPEL بصورت انتزاعی با ارجاع و اتصال به portTypeهای تعیین شده در WSDL ای ایجاد می شود كه در سرویسهای وب موجود در یک پردازش ، تعریف شده است.
مدیریت نرم افزارهای کاربردی مهم و بحرانی تجارت الکترونیک ، می بایست نظارت عمیق و جامعی در محیطهای توزیع شده داشته باشد. خارج از دسترس بودن یک عنصر کلیدی در سیستمهای توزیع شده، تاثیر منفی زیادی بر کل چرخه گذاشته و باعث بیرون رانده شدن ارائه کننده سرویس از بازار می شود.
برای رویارویی با چنین موقعیتهایی ، سازمانها نیاز به کنترل دائم سرویس و حصول اطمینان از سلامتی سیستم دارند. کارایی می بایست همیشه ، در هر شرایطی و با هر بار کاری ، در سطح قابل قبولی باشد.
برای مدیریت قسمتهای مهم و بحرانی و سرویسهای ویژه ، معماری توسعه یافته ، در لایه مدیریت سرویس بعنوان بالاترین سطح ، سرویسهای مدیریت شده را ارائه کرده است.
این لایه شامل دو قسمت مدیریت عملکرد و مدیریت بازار می باشد. کارکرد مدیریت عملکرد بدین صورت است که قسمتهای مهم سیستم را پشتیبانی می نماید. این لایه جزئیاتی از کارایی سیستم را جهت ارزیابی آن ارائه میدهد و بدین صورت سازمان را قادر می سازد تا بر اساس وضعیت نرم افزار و تکمیل شدن تراکنشهای حرفه ، تصمیم گیری نماید. اپراتور سرویس ، مسئول انجام امور مربوط به این واحد است.
مدیریت عملکرد ، قابلیت بسیار مهم و کلیدی است که می تواند صحت و کارایی کلی سیستم را کنترل نماید و بدین ترتیب از بروز مشکلات شدید و خطا در سرویسها جلوگیری کند.
این خطاها ممکن است بر اثر اجتماع و هماهنگ سازی سرویسها و بخاطر عدم رعایت توافقهای در سطح سرویس (SLA) اتفاق بیافتد.
مدیریت و کنترلهای مناسب باعث کاهش احتمال بروز چنین خطاهایی می شود؛ بدین ترتیب که صحت ، پایداری و همچنین مناسب بودن ارتباط بین توابع بکار رفته در سرویسهای ورودی و خروجی را بررسی و کنترل می نماید.
قسمت دیگر در لایه مدیریت ، مدیریت بازار می باشد. مسئولیت این واحد ارائه پروتکلها و قوانین استاندارد در سطح حرفه می باشد تا از این طریق امکان استفاده از سرویسهای تعبیه شده در بازارهای مختلف بوجود آید.
در ضمن برخی از تسهیلات و سرویسهای پایه برای امور مالی ، تضمین کیفیت و ... در این لایه قرار می گیرد تا از این طریق بازارهای مختلف بتوانند در کمترین زمان به سرویسها دسترسی یابند.
این قسمت از لایه مدیریت ، توسط سازندگان بازار که کنسرسیومی از شرکتهای فعال در این عرصه هستند ، کنترل و نگهداری می گردد.
درنهایت ، با توجه به نكات مذكور می توان معماری سرویس گرا را روشی در جهت بهبود طراحی و استفاده از سیستمهای نرم افزاری دانست ، اگرچه مشكلات و چالشهای پیش روی آن همچنان نیازمند بررسی تجارب گذشته و نیز ارائه راه حل مناسب پیرامون مسائل مطرح در این معماری می باشند.
منابع:
- Channabasavaiah. Kishore, et al., Migrating to a service-oriented architecture, Part 1, IBM official web site, 16 December 2003.
2- Bieber .guy , Carpenter.Jeff , Introduction to Service-Oriented Programming , Motorola ISD , 2003
3- Zimmermann.Olaf, et al., Elements of Service Oriented Analysis and Design, IBM official web site, 2 June 2004.
4- Papazoglou Mike, Service-Oriented Computing :Concepts, Characteristics and Directions, Tilburg University , Proceeding of the forth international conference on web information system engineering , IEEE , 2003
5- Hao Ding, Exploiting Extended Service-Oriented Architecture for Federated Digital Libraries, Information Management Group, Norwegian Univ. of Sci.& Tech, 2004
6- Andrew Yang , Critical Infrastructure for Service-Oriented Architecture, Westbridge Technology ,2004
7- Mark Colan , Service-Oriented Architecture Expands the Vision of Web Services , Part 1 , IBM official web site , 21 April 2004
نوشته: سهیل توده فلاح
برگرفته از :
كد - لینک:
ایستنا | آخرین اخبار و تحلیل های حوزه فناوری اطلاعات و ارتباطات (http://www.ictna.ir)
اشاره :
در چهار دهه اخیر ، پیچیدگی نرم افزارها روز بروز بیشتر شده و تقاضا برای نرم افزارهای قدرتمندتر افزایش یافته است. در این میان ، به نظر می رسد که روشهای قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روشهایی است که بوسیله آنها بتوان بر این پیچیدگیها در زمانهایی کوتاهتر غلبه کرد. از طرفی امكان كنار گذاشتن سیستمهای نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند ، وجود ندارد و می بایست سیستمهای جدید را بصورت یکپارچه و در کنار همین سیستمها بوجود آورد. معماری سرویس گرا ، با تکیه بر محاسبات توزیع شده و بر پایه شبکه ها و لایه های میانی و همچنین زبانهایی که تولید نرم افزارهای توزیع شده را فراهم می كنند ، بعنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذكور مطرح گردیده است. در این مقاله ضمن معرفی این معماری به محاسبات سرویس گرا و نیازهای آن پرداخته و معماری سرویس گرای توسعه یافته به عنوان راه حلی برای رفع این نیازها ارائه می شود.
معرفی
تعاریف گوناگونی از معماری سرویس گرا ارائه شده است كه از جمله آنها می توان به تعاریف زیر اشاره كرد:
مجموعه قوانین ، سیاستها و چهارچوبهایی كه نرم افزارها را قادر می سازد تا عملكرد خود را از طریق مجموعه سرویسهای مجزا و در عین حال مربوط به هم در اختیار سایر درخواست كنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابطهای استاندارد و تعریف شده ، این سرویسها را پیدا كرده و فراخوانی نمایند.و یا معماری سرویس گرا روشی برای ساخت سیستمهای توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویسها قرار می گیرد.
از دیگرتعاریف ارائه شده می توان به "واحدهای نرم افزاری آماده در شبكه (Network-available Software Unit) " یا "سرویسهای سطح حرفه (Business-level services) " اشاره كرد.
در حال حاضر ، تکنولوژی سرویسهای وب(Web Services) و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستمهای جدید و یکپارچه-سازی سیستمهای بزرگ موجود ، مطرح گردد. البته ذکر تفاوت سرویسهای وب و SOA در اینجا لازم به نظر می رسد.
سرویسهای وب مجموعه ای از تکنولوژیهایی همچون XML,SOAP,WSDL و UDDI می باشد که امکان ارائه راه حل و برنامه نویسی جهت رفع مشکلی خاص را فراهم می نماید.
در حالی که SOA یک معماریست و از مجموعه مشخصی از تکنولوژیها فراتر می باشد. اگرچه SOA بر اساس این تکنولوژیها راه حل ارائه می نماید ، اما در عین حال مستقل از هر یک از آنها است.
آنچه اهمیت دارد تعریف سرویس به عنوان مهمترین عنصر این معماری می باشد.
سرویس ، رفتار قرادادی تعریف شده ایست که هر قطعه ای می تواند آنرا جهت استفاده سایر قطعات در سیستم تهیه و پیاده سازی نماید.
در این معماری ، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع حرفه (Business functions) و تراكنشهای حرفه‌ای (Business transactions)می باشند كه تراكنشهای حرفه خود شامل توابع سطح پایین (Low-level functions) و توابع سیستمی سرویسها(System service functions) هستند.
سرویسها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند.
قطعات، سرویسهای خود را از طریق رابطها (interface) در اختیار قطعات دیگر قرار میدهند که این رابطها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابطهای محلی یا دور ) . در ضمن این رابطها می توانند به همان نرم افزار كاربردی یا به آدرسی در محل دیگری از شبکه مرتبط باشند .
رابطها به عنوان کلیدی در برقراری این ارتباطها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد.
بعلاوه ، با ایجاد قابلیت توزیع شدگی به شكلی مناسب و بدون وابستگی زیاد ، می توان سرویسها را در قسمتهای مختلف شبکه و بصورت بعضا تکراری ( مخصوصا برای سرویسهای مهم ) قرار داد تا این سرویسها همیشه در دسترس بوده و در صورت زیاد شدن درخواستها بتوان با استفاده از تکنیکهای Load Balancing به تمامی آنها به‌خوبی پاسخ داد.
ویژگیهای سرویس و محاسبات سرویس گرا
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پایه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
از آنجا که سرویسها از طریق سازمانها و شرکتهای گوناگون تهیه می شوند و جهت دسترسی كاربران مختلف می بایست همواره در دسترس باشند ، رعایت ویژگیهای زیر ضروری می باشد:
- مستقل از تکنولوژی باشند؛ به این معنا که بکارگیری و مکانیزم فراخوانی و پیدا کردن سرویسها به راحتی و از تمام محیطها ( سیستمهای عامل مختلف و زبانهای برنامه سازی گوناگون ) میسر بوده و وابسته به پلتفرم خاصی نباشد.
- وابستگی بسیار پایینی بین درخواست کننده و ارائه دهنده سرویس وجود داشته باشد و یا بعبارتی Loosly Coupled باشد. به این معنا که درخواست کننده نباید هیچ نیازی به دانستن ساختار داخلی و نحوه پیاده سازی سرویس داشته باشد. برای این منظور ، فراخوانی سرویس از طریق بکار گیری مکانیزم پیغام (Message) بجای فراخوانی API انجام می گردد.
- درخواست کننده نباید نیازی به دانستن محل قرارگیری سرویس داشته باشد و بعبارتی معماری سرویس گرا می بایست Location Transparency را پشتیبانی نماید. به این ترتیب که محل قرارگیری سرویس و مشخصات آن در مخزنی (Repository) قرار می گیرد و درخواست کننده ، محل و اطلاعات لازم را از طریق بازیابی آن از این مخزن بدست می آورد.
سرویس ها می توانند به دو شکل ساده و ترکیبی ارائه شوند. سرویسهای ترکیبی ، سرویسهایی هستند که بر اساس بکارگیری چند سرویس ساده ( یا ترکیبی) ایجاد می شوند. برای مثال ، ممکن است سیستم توزیع شده ای بر اساس چند سرویس ساده صدور صورتحساب ، ثبت سفارش ، مدیریت روابط مشتری و ... سرویسهای ترکیبی گسترده تری در ارتباط با حرفه ای خاص ایجاد نماید.
سیستمهای ساخته شده بر اساس سرویس ، ترکیبی از سرویسهای مستقل هستند که عملکردهای خود را از طریق رابطهای تعریف شده ای در اختیار کاربران (بالقوه ) خود قرار میدهند. (Web Service Description Language)WSDL از جمله راههایی است که بطور گسترده برای تعریف این رابطها بکار می رود تا بوسیله آن جزئیات لازم برای اتصال درخواست کننده به ارائه دهنده سرویس تعریف شود.
نرم افزار به‌عنوان سرویس
اصل ارائه شده " نرم افزار- بعنوان- سرویس" از محاسبات سرویس گرا ، بر اساس مدل ASP مطرح گشته است. ASP هویت سوم شخصیست که بكارگیری سرویسهای نرم افزاری و دسترسی مشتری را به بسته نرم افزاری از طریق شبكه، مدیریت و میزبانی می نماید.به‌عبارتی ASP ها راهی برای رفع نیازهای IT شرکتها از طریق واگذاری بخشی از این نیازها یا تمامی آنها به بیرون از سازمان می باشند.
برای این منظور ASP با استفاده از زیر ساختهای خود ، ارتباط بین مشتری و نرم افزار ارائه شده را برقرار کرده و دسترسی وی به داده ها و توابع موجود را بصورت در دسترس (online)، مدیریت می نماید.
اگرچه نظریه "نرم افزار بعنوان سرویس" اولین بار توسط ASP ارائه شد ، اما مشكلات این روش باعث ایجاد کدهایی می شد که معمولا قابل استفاده مجدد نبوده و محدود به مشتری خاص می بود ، بعبارتی وابستگی زیادی بین سرویس ارائه شده و سیستم استفاده کننده بوجود می آمد.
معماری سرویس گرا اجازه میدهد تا نظریه "نرم افزار بعنوان سرویس"، گسترش یافته تا از طریق آن بتوان پردازشها و تراکنشهای پیچیده را بعنوان سرویسهایی با قابلیت استفاده مجدد ارائه کرد و به این ترتیب سیستمها را مستقل از سرویسها طراحی و تولید نمود.
معماری سرویس گرای مقدماتی
SOA شیوه ای منطقی برای طراحی سیستمهای نرم افزاری است که از طریق آن سرویسهایی جهت ارائه به کاربران یا سایر سرویسهای توزیع شده بر روی شبکه ایجاد می شود و این سرویسها از طریق رابطهای تعریف شده در دسترس می باشند.
معماری سرویس گرای مقدماتی ، راهی برای تبادل اطلاعات بین عاملهای نرم افزاری بوسیله پیغام تعریف می نماید. این عاملها ، درخواست کننده سرویس (مشتری) و یا تهیه کننده سرویس می باشند. علاوه بر این دو، عامل دیگری بعنوان عامل کشف سرویس نیز وجود دارد. در معماری سرویس گرا معرفی سرویسها و همچنین نحوه ارتباط این سه شرکت کننده نیز اهمیت دارد. این ارتباطات عبارتند از : منتشر کردن سرویس ، پیدا کردن سرویس و متصل شدن به سرویس.
http://www.pnu-club.com/imported/mising.jpg
شکل 1
در یک سناریو بر پایه سرویس ، تهیه کننده ، سرویس را پیاده سازی کرده و از طریق شبکه به ارائه توضیحات آن سرویس برای درخواست کننده یا عامل کشف سرویس می پردازد. در خواست کننده معمولا درخواست پیدا کردن سرویس را به عامل کشف سرویس میدهد تا از طریق آن به توضیحات ارائه شده سرویس و محل آن دسترسی پیدا کند. سپس با بکارگیری این اطلاعات به تهیه کننده سرویس متصل شده و از سرویس ارائه شده استفاده می نماید.
بدین ترتیب ، سرویس بعنوان قطعه نرم افزاری پیاده سازی شده ای که توسط یک رابط تعریف شده مستند گردیده است و نه تنها بوسیله خود تهیه کننده بلکه توسط سایر عواملی که از نحوه پیاده سازی آن خبر ندارند ، نیز قابل استفاده و فراخوانی است. این ویژگی جعبه سیاه بودن سرویس از اصل ماژولاریتی در مهندسی نرم افزار به ارث رسیده است. البته سرویس با تعاریفی مانند ماژول ، قطعه نرم افزاری یا شی تفاوت دارد ، زیرا نه تنها در سطح برنامه ها و نرم افزارهای کاربردی ، بلکه در سطح حرفه و حتی مابین سازمانها نیز قابل بكارگیری و استفاده مجدد می باشد.
در واقع سرویسها، نمایش عملکرد معنی داری از حرفه هستند که می توانند بنا به نیاز مشتری در سرویسها و توابع بزرگتر یا جدید بکار گرفته شوند.
رابطها به سادگی مکانیزمی جهت برقراری ارتباط بین سرویس و نرم افزارها یا سایر سرویسها ایجاد می نمایند. از لحاظ تکنیکی، رابط سرویسها ، توضیحاتی در مورد نام و امضاء متدهای یک سرویس هستند که توسط درخواست کننده ، قابل فراخوانی می باشند.
معماری سرویس گرای توسعه یافته
معماری سرویس گرای مقدماتی به برخی از مسائل موجود در یک معماری مبتنی بر سرویس نمی پردازد. از جمله این مسائل، مدیریت، هماهنگ سازی سرویسها ، متناسب کردن آنها ، امنیت ، مدیریت تراکنشها و ... می باشد.این نکات که در شکل 2 نمایش داده شده است ، در معماری سرویس گرای توسعه یافته در نظر گرفته شده است.
http://www.pnu-club.com/imported/mising.jpg
شکل 2
معماری مقدماتی در لایه پایینی این معماری لایه ای قرار گرفته است. لایه ترکیب سرویس در معماری توسعه یافته ، شامل توابع و نقشهای لازم برای یکپارچه کردن چند سرویس بعنوان سرویس ترکیبی می باشد. سرویس ترکیبی بدست آمده ، توسط Service Aggregator بعنوان یک سرویس مقدماتی استفاده می گردد و یا توسط درخواست کنندگان سرویس بکارگرفته می شود.
Service Aggregator تهیه کننده سرویسی است که سرویسهای ارائه شده توسط سایر تهیه کنندگان را یکپارچه می نماید تا از آنها سرویسهای جدید بسازد، همچنین مشخصات و کدهایی را تهیه می کند تا در مورد سرویسهای ترکیبی عملیات زیر را انجام دهد:
- متناسب کردن : کنترل اجرای سرویسهای ترکیب شده و مدیریت گردش داده ها در بین آنها و انتقال آن به خروجی.
- کنترل کردن : مجوز دادن به رخدادها و اطلاعات تولید شده توسط سرویسهای ترکیبی جهت به اشتراک گذاشتن و منتشر کردن رخدادهای ترکیبی سطح بالاتر ( برای مثال از طریق فیلتر کردن و خلاصه سازی)
- مطابقت دادن : حصول اطمینان از حفظ جامعیت سرویسهای ترکیبی از طریق تطبیق دادن محدودیتها و نوع پارامترهای سرویسهای بکار رفته.
- ترکیب خواص سرویسها : بکارگیری ، مجتمع سازی و دسته بندی ویژگی های سرویسهای ترکیب شده جهت بدست آوردن خواص ترکیبی جدید که دربردارنده کارایی ، هزینه ، امنیت ، جامعیت ، قیاس پذیری ، در دسترس بودن و قابلیت اطمینان می باشد.
استانداردهای جدید ارائه شده با عنوان زبان اجرای پردازشهای حرفه برای سرویسهای وب ، تلاشی است که بر اساس XML ، تعریف سرویسهای وب جدید را که از ترکیب سرویسهای موجود بدست می آیند ، ارائه دهد.یک پردازش BPEL بصورت انتزاعی با ارجاع و اتصال به portTypeهای تعیین شده در WSDL ای ایجاد می شود كه در سرویسهای وب موجود در یک پردازش ، تعریف شده است.
مدیریت نرم افزارهای کاربردی مهم و بحرانی تجارت الکترونیک ، می بایست نظارت عمیق و جامعی در محیطهای توزیع شده داشته باشد. خارج از دسترس بودن یک عنصر کلیدی در سیستمهای توزیع شده، تاثیر منفی زیادی بر کل چرخه گذاشته و باعث بیرون رانده شدن ارائه کننده سرویس از بازار می شود.
برای رویارویی با چنین موقعیتهایی ، سازمانها نیاز به کنترل دائم سرویس و حصول اطمینان از سلامتی سیستم دارند. کارایی می بایست همیشه ، در هر شرایطی و با هر بار کاری ، در سطح قابل قبولی باشد.
برای مدیریت قسمتهای مهم و بحرانی و سرویسهای ویژه ، معماری توسعه یافته ، در لایه مدیریت سرویس بعنوان بالاترین سطح ، سرویسهای مدیریت شده را ارائه کرده است.
این لایه شامل دو قسمت مدیریت عملکرد و مدیریت بازار می باشد. کارکرد مدیریت عملکرد بدین صورت است که قسمتهای مهم سیستم را پشتیبانی می نماید. این لایه جزئیاتی از کارایی سیستم را جهت ارزیابی آن ارائه میدهد و بدین صورت سازمان را قادر می سازد تا بر اساس وضعیت نرم افزار و تکمیل شدن تراکنشهای حرفه ، تصمیم گیری نماید. اپراتور سرویس ، مسئول انجام امور مربوط به این واحد است.
مدیریت عملکرد ، قابلیت بسیار مهم و کلیدی است که می تواند صحت و کارایی کلی سیستم را کنترل نماید و بدین ترتیب از بروز مشکلات شدید و خطا در سرویسها جلوگیری کند.
این خطاها ممکن است بر اثر اجتماع و هماهنگ سازی سرویسها و بخاطر عدم رعایت توافقهای در سطح سرویس (SLA) اتفاق بیافتد.
مدیریت و کنترلهای مناسب باعث کاهش احتمال بروز چنین خطاهایی می شود؛ بدین ترتیب که صحت ، پایداری و همچنین مناسب بودن ارتباط بین توابع بکار رفته در سرویسهای ورودی و خروجی را بررسی و کنترل می نماید.
قسمت دیگر در لایه مدیریت ، مدیریت بازار می باشد. مسئولیت این واحد ارائه پروتکلها و قوانین استاندارد در سطح حرفه می باشد تا از این طریق امکان استفاده از سرویسهای تعبیه شده در بازارهای مختلف بوجود آید.
در ضمن برخی از تسهیلات و سرویسهای پایه برای امور مالی ، تضمین کیفیت و ... در این لایه قرار می گیرد تا از این طریق بازارهای مختلف بتوانند در کمترین زمان به سرویسها دسترسی یابند.
این قسمت از لایه مدیریت ، توسط سازندگان بازار که کنسرسیومی از شرکتهای فعال در این عرصه هستند ، کنترل و نگهداری می گردد.
درنهایت ، با توجه به نكات مذكور می توان معماری سرویس گرا را روشی در جهت بهبود طراحی و استفاده از سیستمهای نرم افزاری دانست ، اگرچه مشكلات و چالشهای پیش روی آن همچنان نیازمند بررسی تجارب گذشته و نیز ارائه راه حل مناسب پیرامون مسائل مطرح در این معماری می باشند.
منابع:
- Channabasavaiah. Kishore, et al., Migrating to a service-oriented architecture, Part 1, IBM official web site, 16 December 2003.
2- Bieber .guy , Carpenter.Jeff , Introduction to Service-Oriented Programming , Motorola ISD , 2003
3- Zimmermann.Olaf, et al., Elements of Service Oriented Analysis and Design, IBM official web site, 2 June 2004.
4- Papazoglou Mike, Service-Oriented Computing :Concepts, Characteristics and Directions, Tilburg University , Proceeding of the forth international conference on web information system engineering , IEEE , 2003
5- Hao Ding, Exploiting Extended Service-Oriented Architecture for Federated Digital Libraries, Information Management Group, Norwegian Univ. of Sci.& Tech, 2004
6- Andrew Yang , Critical Infrastructure for Service-Oriented Architecture, Westbridge Technology ,2004
7- Mark Colan , Service-Oriented Architecture Expands the Vision of Web Services , Part 1 , IBM official web site , 21 April 2004
نوشته: سهیل توده فلاح
برگرفته از :
كد - لینک:
ایستنا | آخرین اخبار و تحلیل های حوزه فناوری اطلاعات و ارتباطات (http://www.ictna.ir)