مقاله29-ارائه روشی برای طراحی مبتنی بر سرویس80ص

مقاله29-ارائه روشی برای طراحی مبتنی بر سرویس80ص فهرست مطالب عنوان شماره صفحه چکیده 1 مقدمه 2 فصل اول: کلیات معماری سرویس گرا   1-1) تعاریف اولیه 5 1-1-1) سبک معماری مبتنی بر سرویس 5 2-1) اهداف تحقیق 7 3-1) پیشینه تحقیق 8 4-1) روش کار و تحقیق 10 5-1) مقایسه ای بر مدلهای توسعه وابسته به معماری 11 1-5-1) توسعه مبتنی بر object 11 2-5-1) توسعه مبتنی بر مؤلفه 12 3-5-1) محاسبات توزیع یافته 13 4-5-1) معماری سرویس گرا 14 1-4-5-1) توسعه مبتنی بر سرویس 15 2-4-5-1) قابلیتهای معماری سرویس گرا 17 6-1) مؤلفه های SOA 18 7-1) اصول سرویس گرائی 21 8-1) سرویس گرائی و تشکیلات سازمانی 27 1-8-1) لایه های سرویس 29 1-1-8-1) لایه سرویس کاربردی 32 2-1-8-1) لایه سرویس تجاری 34 3-1-8-1) لایه سرویس همنوائی 34 2-8-1) سرویسهای Agnostic 37 فصل دوم : تحلیل مبتنی بر سرویس   1-2) چرخه حیات معماری سرویس گرا 40 2-2) استراتژیهای تحویل SOA 41 1-2-2) روش پایین به بالا 41 2-2-2) روش بالا به پایین 43 3-2-2) روش Meet-In-The-Middle 45 3-2) تحلیل سرویس گرا 47 1-3-2) اهداف تحلیل سرویس گرا 47 2-3-2) پروسه تحلیل سرویس گرا 48 فصل سوم : الگوها و اصول طراحی   1-3) نکات قابل توجه طراحی 52 1-1-3) مدیریت دانه بندی سرویس و مؤلفه 52 2-1-3) طراحی برای قابلیت استفاده مجدد 53 3-1-3) طراحی برای قابلیت ترکیب سرویس 54 1-3-1-3) اتصال و همبستگی 54 2-3) رهنمودهای عمومی 55 1-2-3) استانداردهای نامگذاری 55 2-2-3) طراحی عملیات سرویس به شکلی که ذاتا قابل توسعه باشد 56 3-2-3) تعیین متقاضیان مطرح سرویس 56 3-3) الگوهای طراحی و انواع معماری 57 1-3-3) الگوها 58 2-3-3) طراحی بنیادی 59 فصل چهارم : راهکار پیشنهادی   1-4) مرحله 1 بازبینی لایه بندی سیستم SOA 64 1-1-4) فعالیت 1 مروری بر استراتژیهای لایه بندی 64 2-1-4) فعالیت 2 بازبینی لایه بندی فاز تحلیل 66 3-1-4) فعالیت 3 معرفی لایه های تخصصی تر 67 1-3-1-4) لایه داده 67 2-3-1-4) لایه دسترسی سرویس 70 3-3-1-4) لایه تعامل 71 2-4) مرحله 2 تحلیل تغییرپذیری 77 1-2-4) فعالیت 1 شناسایی انواع تغییرپذیری 79 2-2-4) فعالیت 2 مدلهای موجود برای تغییرپذیری 83 3-2-4) فعالیت 3 گروهبندی و مدلسازی تغییرپذیری 84 4-2-4) فعالیت 4 نگاشت نقاط تغییرپذیر 87 3-4) مرحله 3 سرویسهای فاز طراحی 89 1-3-4) فعالیت 1 تعیین سرویسها 90 2-3-4) فعالیت 2 جایگاه سرویسهای کنترلی 98 4-4) مرحله 4 مروری بر دانه بندی 99 1-4-4) فعالیت 1 تکنیک دانه بندی سرویسها و چنددانه ای بودن 102 2-4-4) فعالیت 2 متدهای چند دانه ای سرویسها 104 5-4) مرحله 5 مدلسازی فرایند 108 1-5-4) استفاده از مدلسازی فرایند برای طراحی معماری سرویس گرا 108 2-5-4) ابزار مدلسازی فرایند 109 3-5-4) فعالیت طراحی فرایند کسب و کار مبتنی بر سرویس 113 فصل پنجم : بررسی موردی   1-5) انتخاب بررسی موردی 115 1-5) سیستم سفارش کالا 116 3-5) تحلیلی بر راهکار پیشنهادی 134 فصل ششم : نتیجه گیری و پیشنهادات   1-6) نتیجه گیری 136 2-6) پیشنهادات 138 مقاله 139 پیوستها 140 منابع و ماخذ   فهرست منابع فارسی 196 فهرست منابع لاتین 197 سایتهای اطلاع رسانی 200 اختصارات 201 چکیده انگلیسی 202 فهرست شکلها عنوان شماره صفحه شکل 1-1) میان افزار مبتنی بر پیغام[24] 14 شکل 2-1) مدل مفهومی معماری سرویس گرا[24] 15 شکل 3-1) توسعه مبتنی بر سرویس[24] 16 شکل 4-1) یک دیدگاه اولیه از چگونگی قرار گرفتن منطق خودکارسازی در داخل واحدها توسط SOA 20 شکل 5-1) عملیاتهایی که به سرویسهای متفاوتی تعلق دارند و بخشهای متنوعی از منطق پروسه را نمایش می دهند. 20 شکل 6-1) چگونه مؤلفه های یک معماری سرویس گرا با یکدیگر ارتباط دارند. 21 شکل 7-1) پیمانهای سرویس به طور رسمی مؤلفه های سرویس, عملیات و پیغام از یک معماری سرویس گرا را تعریف می کند. 23 شکل 8-1) سرویسها وابستگی ها را به قرارداد سرویس محدود می کنند و با این کار به منطق سرویس دهنده زیرین و تقاضاکننده اجازه می دهند که loosely coupled باقی بمانند. 24 شکل 9-1) عملیات Update Everything یک ترکیب سرویس را بسته بندی می کند 25 شکل 10-1) مراحل statelessو stateful که یک سرویس درهنگام پردازش یک پیغام از آنها عبور می کند . 27 شکل 11-1) جایگاه سرویسها[1] 28 شکل 12-1) لایه های تخصصی سرویس[1] 32 شکل 13-1) سلسله مراتب چرخه حیات توسعه سرویسهای وب[9] 36 شکل 14-1) بخش بندی سرویسها که محیط راه حل و پردازشهای تجاری را تفکیک کرده است[1]. 38 شکل 1-2) چرخه حیات معماری سرویس گرا 40 شکل 2-2) گامهای تکنیک پائین به بالا 42 شکل 3-2) گامهای تکنیک بالا به پائین 44 شکل 4-2) گامهای تکنیک meet in the middle[1] 46 شکل 1-3) در صورت تجزیه یک سرویس ,الگوهای نظارتی به عدم تاثیرگذاری در قرارداد سرویس کمک می کنند.[27] 59 شکل 2-3) منطق Agnostic و [27] Non Agnostic 60 شکل 1-4) فعالیتهای فاز طراحی 63 شکل 2-4) مدل گسترش سیستم تحت تاثیر لایه بندی [30] 65 شکل 3-4) پنهان سازی پیچیدگی توسط لایه انتزاعی داده 69 شکل 4-4) لایه دسترسی سرویس[2] 70 شکل 5-4) ساختار منطقی از سرویسهای تعاملی 73 شکل 6-4) مثالهایی از سرویس تعاملی در SOA 76 شکل 7-4) چارچوب مبتنی بر سرویس برای سرویسهای تعاملی 76 شکل 8-4) 4 نو ع تغییرپذیری 80 شکل 9-4) واسط مورد نیاز فرایند کسب و کار 81 شکل 10-4) نقاط تغییرپذیر ممکن 82 شکل 11-4) شمایی از تغییرپذیری در XML[6] 83 شکل 12-4) مدل تصمیم , مدل واسطی برای سازگاری سرویسها می باشد[6] 84 شکل 13-4) دیاگرام فعالیت و نقاط تغییر پذیر[31] 85 شکل 14-4) مدل خصیصه[31] 86 شکل 15-4) سرویسهای Gateway[2] 92 شکل 16-4) سرویسهای Façade[2] 93 شکل 17-4) جایگاه دستورات کنترلی درمقایسه دو راه حل [2] 96 شکل 18-4) سرویسهای دانه درشت[11] 101 شکل 19-4) ارتباط سرویس دانه درشت و سرویس دانه ریز[11] 103 شکل 20-4) متد جدیدی برای ارسال اطلاعات آدرس اضافه شده است.[11] 105 شکل 21-4) یک متدی که هر دو نوع اطلاعات آدرس و حساب را بر می گرداند.[11] 105 شکل 22-4) متدی که مؤلفه های درخواست داده شده را برمی گرداند[11] 107 شکل 23-4) مدلسازی سلسله مراتبی با BPMN[5] 112 شکل 24-4) مجموعه مدلهای فاز طراحی و ارتباط آنها 113 شکل 1-5) دیاگرام فعالیت 3 عامل 117 شکل 2-5) سرویسهای کاندید 120 شکل 3-5) مدل لایه بندی سیستم 121 شکل 4-5) تغییر پذیری در گردش کار 122 شکل 5-5) مدل خصیصه 123 شکل 6-5) دیاگرام فعالیت برای شناسایی وابستگیها 124 شکل 7-5) دیاگرام General Composition 125 شکل 8-5) مدل نگاشت 125 شکل 9-5) لایه تامین کننده QOS 126 شکل 10-5) سرویسهای دانه ریز 127 شکل 11-5) دیاگرام Consignee Collaboration 127 شکل 12-5) دیاگرام Consignee Sequence Diagram 128 شکل 13-5) دیاگرام Shipper Collaboration 128 شکل 14-5) دیاگرام Shipper Sequence 129 شکل 15-5) دیاگرام Partial Order Process Collaboration 129 شکل 16-5) دیاگرام Partial Order Process Sequence 130 شکل 17-5) دیاگرام تعاملات مابین سرویس فرایند و سرویسهای همکار 131 شکل 18-5) مدل BPMN 132 فهرست جداول عنوان شماره صفحه جدول 1-1) مقایسه مدلهای توسعه وابسته به معماری 17 جدول 1-6) راهکار پیشنهادی در تامین اصول طراحی 137 چکیده معماری سرویس گرا به سرعت به عنوان نخستین ائتلاف و راه حل معماری محیطهای محاسباتی ناهمگون و پیچیده معاصر پدیدار گشته است . [1]SOA نیازمند این است که سازمانها مدلهای کسب و کار خود را ارزیابی کنند, به ایجاد تکنیکهای تحلیل و طراحی مبتنی بر سرویس بیاندیشند و طرحهای گسترش و پشتیبانی روابط مابین فروشنده , مشتری و شریک تجاری را ارزیابی کنند . طراحان نمی توانند انتظار مدیریت توسعه یک پروژه سرویس گرا را داشته باشند بدون اینکه به شیوه طراحی دقیق و متدولوژی توسعه تکیه داشته باشند . از آنجایی که متدولوژی توسعه مبتنی بر سرویس اهمیت حیاتی در توصیف ,ساخت, پالایش و تطبیق فرایندهای کسب وکاری دارد که تغییرپذیری بالایی دارند و تا به حال روش مناسب و منسجمی برای توسعه برنامه های کاربردی تجاری قدرتمند وجود ندارد , هدف این تحقیق ارائه روشی برای طراحی مبتنی بر سرویس می باشد . در این تحقیق از تکنیکها و مباحث مطرح درSOA استفاده شده و برای طراحی سرویس گرا روشی پیشنهاد می شود . تمرکز تحقیق بر روی فرایند طراحی می باشدکه اصول و تکنیکهای کافی برای مشخص کردن , ساخت و پالایش فرایندهای کسب وکاری که به سرعت دچار تغییر می شوند فراهم می کند . روش پیشنهای برای ایجاد کنترل متمرکز از تجرید لایه های سرویس و طبقه بندی انواع سرویس استفاده نموده و در کنار استفاده از سیستمهای موروثی در حمایت از استراتژیهای کوتاه مدت سازمانها ,بر اساس اصول طراحی و اصول سرویس گرائی در راستای استراتژیهای بلند مدت عمل می کند تا در تامین اهداف تجاری و حمایت از فرایندهایی که به سرعت دچار تغییر می شوند مفید واقع شود . همچنین زمینه تعامل عاملهای مختلف فرایند که در سطح چندین سازمان گسترده شده اند فراهم می شود و با تحلیل تغییرپذیری, انعطاف پذیری سیستم در حمایت از نقاط متغیر فرایندها و تغییر در سیاستهای کسب و کار افزایش می یابد . بدین منظور در ادامه بحث ابتدا سبکهای مختلف توسعه نرم افزار به همراه سبک مبتنی بر سرویس و اصول سرویس گرائی به تفصیل بررسی می گردد , سپس چرخه حیات معماری سرویس گرا و فاز تجزیه و تحلیل که مقدمه ای برای طراحی می باشد مورد بررسی قرار می گیرد و در ادامه با بیان اصول و الگوهای طراحی موجود , راهکار پیشنهادی با نمونه پیاده سازی شده به صورت مشروح بیان می گردد . کلمات کلیدی :SOA , Layer, Service Type , Process ,Variation , Granularity .Composition مقدمه در طول چهار دهه اخیر، میزان پیچیدگی نرم افزارها بصورت صعودی افزایش یافته و تقاضا برای نرم افزارهای قدرتمندتر بیشتر شده است. در این میان، به نظر می رسد که روشهای قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روشهائی است که بوسیله آنها بتوان بر این پیچیدگیها بصورت کاراتر و در زمانی کوتاهتر غلبه کرد. از سوی دیگر امکان کنار گذاشتن یکباره سیستمهای نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند، وجود ندارد و می بایست سیستمهای جدید را بصورت یکپارچه و در کنار همین سیستمهای فعلی بوجود آورد. معماری سرویس گرا، با تکیه بر اصول سرویس گرائی و محاسبات و سرویس های توزیع شده و بر پایه پروتکلهای شبکه و لایه های منطقی سرویس و همچنین زبانهایی که تولید نرم افزارهای توزیع شده را فراهم می کنند، به عنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذکور مطرح گردیده است[20,21]. SOA مجموعه ای از اصول , نظریه ها و تکنیکهایی را فراهم می کند که فرایندهای کسب و کار , اطلاعات و دارایی های تشکیلات بتوانند به شیوه مؤ ثری سازماندهی شوند و این فرایندها می توانند برای پشتیبانی از طرحهای استراتژیک و سطوح بهره وری که در محیطهای رقابتی کسب و کار مورد نیاز هستند, گسترش داده شوند . بسیاری از تشکیلات اقتصادی در استفاده اولیه شان از SOA چنین پنداشتند که از مولفه های موجود به عنوان سرویس وب می توانند استفاده کنند و عنوان کردند تنها با ایجاد سرویسهای پوشاننده[2] و رها کردن مولفه های زیرین غیر قابل دسترس, این کار عملی خواهد بود . در نتیجه پیاده سازی لایه نازکی از SOAP/WSDL/UDDI بالای برنامه کاربردی موجود یا مولفه هایی که سرویسهای وب را تحقق می بخشند , تا حد گسترده ای در صنعت نرم افزار تجربه شد . اما تا به حال روش مناسبی برای ایجاد برنامه های کاربردی تجاری قدرتمند وجود ندارد . اگرچه طبیعت مولفه ها مناسب استفاده از آنها به عنوان سرویس وب می باشد , در بیشتر موارد اینطور نیست و برای طراحی مجدد و ارائه کارکرد مولفه ها به شیوه صحیح و از طریق سرویس وب نیازمند تلاش مضاعفی می باشیم[9]. پیاده سازی موفق SOA مستلزم این است که به مفاهیم و استراتژیهای پیاده سازی که خصوصیات و ویژگیهای اساسی SOA را فرموله می کنند , توجه شود . به مجرد پیاد ه سازی موفق SOA, مزایایی در جهت کاهش زمان توسعه و ایجاد محصول , بهره برداری از کاربردهای انعطاف پذیر با پاسخ دهی سریع و امکان اتصال پویای استدلالهای کاربردی شرکای تجاری , حاصل می شود . یک پیاده سازی کامل SOA نه تنها در ارتباط با گسترش و صف آرایی سرویسها می باشد بلکه امکان استفاده از سرویسها درجهت اجتماع برنامه های کاربردی متمایز و ایجاد کاربرد مرکب را منعکس می سازد. فصل اول: کلیات معماری سرویس گرا 1-1 تعاریف اولیه 1-1-1 معماری سرویس گرا (SOA) SOA مجموعه قوانین ، سیاستها و چارچوبهایی است که نرم افزارها را قادر می سازد تا عملکرد خود را از طریق مجموعه سرویسهای مجزا و مستقل و در عین حال مرتبط با هم در اختیار سایر درخواست کنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی سرویس و تنها از طریق رابطهای استاندارد و تعریف شده، این سرویسها را یافته و فراخوانی نمایند و یا در تعریف دیگر می توان گفت معماری سرویس گرا روشی برای ساخت سیستمهای توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویسها قرار می گیرد. از دیگرتعاریف ارائه شده مرتبط با معماری های سرویس گرا می توان به واحدهای نرم افزاری آماده در شبکه[3] یا سرویسهای سطح حرفه ای[4] اشاره کرد.در حال حاضر، تکنولوژی سرویسهای وب و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستمهای توزیع شده جدید و یکپارچه سازی سیستمهای بزرگ موجود مطرح گردد[3]. در این معماری، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع تجاری و تراکنشهای تجاری می باشند که تراکنشهای تجاری خود شامل توابع سطح پایین و توابع سیستمی سرویسها هستند. سرویسها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه, نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند. قطعات، سرویسهای خود را از طریق رابطهای تعریف شده در اختیار قطعات دیگر قرار میدهند که این رابطها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابطهای محلی یا دور ). در ضمن، این رابطها می توانند به همان نرم افزار کاربردی یا به آدرسی در محل دیگری از شبکه مرتبط باشند. رابطها به عنوان کلیدی در برقراری این ارتباطها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد[1,34,26]. نیاز به معماری سرویس گرا و امکانات آن ازجنبه های مختلف به نحوه بارزی در برنامه های کاربردی توزیع شده جدید خصوصا برنامه های مرتبط باE-Commerce مشهود و ملموس است. به عنوان نمونه اگرمثلا سرویسمربوط به پرداخت با کارت اعتباری غیر فعالباشد، ‌قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوندوعملیات پرداخت به وقت دیگری موکول شود. همانند سایر معماری های توزیع شده،‌ SOA ساخت برنامه های کاربردی با استفاده از اجزایی که در حوزه های جدا از هم قراردارند را ممکن می سازد و غالبا از سرویسهای وب به عنوان نقاط ورود برنامه کاربردیاستفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستمهایتوزیع شده سنتی مبتنی بر اجزاء هستند. با این تفاوت که در این جا ارتباط بین سرویسوب و استفاده کننده خیلی آزادانه تر و مستقل تراست. به علاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند، نیز منحصر به فرداست ( فاکتورهایی نظیر قابلیت اطمینان سرویس،‌ جامعیت پیام ، یکسانی تراکنش وامنیت پیام ). اگر سیستمی توانایی های خود را در قالب سرویسیروی وب ارائه کند، در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازیو اعلام شود. بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردیامروزی در SOA به نحو مطلوبی حل شده است. البته در SOA فرض بر این است که احتمال خطا همیشه وجود دارد و می تواند اتفاق بیفتد، بنابرایناستراتژی هایی برای پاسخگوئی به خطاها در آن تعبیه شده است . برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد،این معماری طوری طراحی شده است که مجددا پیام را بفرستد و اگر یک سرویس به طورکامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار اتفاق بیفتد ) آنگاه معماری طوری طراحی شده است که روی دادن خطاهایی که منجر به قطع کامل در خواستسرویس می شود، ‌امکان پذیر نباشد. استفاده از معماری سرویس گرا همچنین قابلیت اطمینان را افزایش می دهد، زیرا خطاهایموقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند.به بیان کلی،‌ SOA فرایندی تکامل یافته را ارائه می نماید و از این نظر می توانآن را بلوغ سریسهای وب و تکنولوژی های یکپارچه سازی به حساب آورد. در SOA به اینامر توجه شده است که سیستمهای با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شدهساخته می شوند، باید تضمین های خاصی را تامین نمایند. در این گونه سیستمها بایداین اطمینان وجود داشته باشد که در خواستهای سرویسهای موردنیاز, به طور صحیح مسیر دهی و هدایت شوند، در زمان مناسب به آنها پاسخ داده شود و این سرویسها به طور واضح ودقیق, سیاستهای ارتباطی و رابطهای خود را اعلام کنند.[1-34-35-36] 2-1 اهداف تحقیق راهکارهای نوین توسعه سیستم های نرم افزاری که هم اکنون بطور گسترده استفاده می گردند علیرغم نکات برجسته و نقاط کارامد غالبا سیستم هائی ایجاد می کنند که از کمبودهائی رنج می برند. مهمترین نقاط ضعف این سیستم های نرم افزاری شامل موارد زیر است: ¨ کمبود انعطاف پذیری محیط کسب و کار سازمان ¨ کند بودن در پشتیبانی از تغییرات نیازمندیهای کسب و کار و پشتیبانی اهداف و سیاستهای جدید ¨ سربارها و پیچیدگیهای عملیاتی و قابلیت استفاده مجدد کم سرمایه های فعلی سازمان ¨ کمبود تعامل پذیری مناسب و دشواری گسترش سریع استانداردهای صنعتی نوین ¨ عدم پشتیبانی اصول پایه مهندسی نرم افزار و استانداردهای شفاف و صریح SOA ، با تکیه بر محاسبات توزیع شده و بر پایه پروتکلهای شبکه و لایه های میانی سرویس و همچنین زبانهایی که تولید نرم افزارهای توزیع شده را فراهم می کنند، بعنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذکور مطرح گردیده است. بمنظور توسعه سیستم های نرم افزاری با رویکرد SOA و طراحی فرایند سرویس گرا و شناسائی سرویس های مختلف تکنیکهای مختلفی وجود دارد که غالب این روشها علیرغم مزایائی که دارند دارای معایبی نیز می باشند . از آنجایی که متدولوژی توسعه مبتنی بر سرویس اهمیت حیاتی در توصیف ,ساخت, پالایش و تطبیق فرایندهای کسب وکاری دارد که به سرعت دچار تغییر[5] می شوند و تا به حال روش مناسب و منسجمی برای توسعه برنامه های کاربردی تجاری قدرتمند وجود ندارد هدف ما ارائه روشی برای طراحی مبتنی بر سرویس می باشد . طراحی سرویسها شامل چندین موضوع اساسی می باشد که به منظور غلبه بر پیچیدگی در ساخت کاربردهای مبتنی بر سرویس ضرورت دارد روشن شود .در این تحقیق ما از تکنیکها و مباحث مطرح درSOA به شکل منسجم استفاده نموده و برای طراحی سرویس گرا روشی پیشنهاد خواهیم کرد . تمرکز ما بر روی فرایند طراحی می باشدکه اصول و تکنیکهای کافی برای مشخص کردن , ساخت و پالایش فرایندهای کسب وکاری که به سرعت دچار تغییر می شوند , فراهم می کند . در طی فاز طراحی یک سیستم مبتنی بر سرویس , سرویسها بر اساس ملاحظات خاصی - از قبیل پیمانه ای بودن , در نظر گرفتن نقاط تغییرپذیر برای ارائه قابلیت تصمیم گیری در راستای استفاده های مختلف از سرویسها , دارا بودن قابلیت استفاده مجدد , خود مختاری و غیره , طراحی وساختاردهی می شوند . به دلیل اینکه اساس وپایه SOA قابلیت استفاده مجدد می باشد , هدف ما رعایت اصول طراحی سیستم شامل اعمال ملاحظات پیاده سازی در صورت وجود یک پیکربندی اولیه SOA برای سازمان و همچنین اعمال نیازمندیهای غیر کارکردی , اصول طراحی سرویسها و بازبینی پیکربندی لایه های شناسائی شده می باشد . 3-1 پیشینه تحقیق از گذشته های دور برنامه نویسان تلاش می کردند تا کدهای نرم افزاری را بصورت پیمانه ایبنویسند تا بتوان ازآن کدها در تولید نرم افزارهای دیگر استفاده کرد . تفاوت نوشتن کد بصورتپیمانه ای و براساس معماری سرویس گرا در حجم مخاطبان آن است. در جهانامروز طیف مخاطبانی که می توانند بصورت بالقوه از یک سرویس استفاده کنند، کل کاربران رویشبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمدکه می توانست پاسخگوی اینمحیط جدید (اینترنت) و کاربران آن باشد، بنابراین تفکر ایجاد معماری سرویس گرا بوجود آمد . ایده SOA اولین بار توسط دو شرکت IBM ,Microsoft در اواخر دهه 1980 پیشنهاد گردید، که هر دو شرکت طی سالهای اخیر ازحامیان اصلی سرویس های وب و عامل بسیاری از ابداعات جدید در حیطه پشتیبانی SOA و سرویس های وب، مانند UDDI ,WSE بوده اند. [3-22] در زمینه طراحی مبتنی بر سرویس متدولوژی RUP توسعه ای داشته است که چارچوب کاری ذیل را ارائه کرده است : service identification service specification service realization service deployment در سال 2005Tomas Erl تکنیکی ارائه نمود که قراردادها و اصول سرویس گرایی را در درون فرایند طراحی سرویس قرار می دهد و تصمیمات کلیدی اتخاذ می گردد[1] . در سال 2004 Dijkman and Dumas مدلی در زمینه طراحی مبتنی بر سرویس با لحاظ چندین دیدگاه ارائه نمودند . دیدگاههای مطرح در مدل ارائه شده , رفتار واسط[6] , رفتار سرویس دهنده[7] , ترتیب و نظم[8] و همنوائی[9] می باشد [7] . در مدل ارائه شده محدودیتهای موجود بررسی و ارتباط مابین این 4 دیدگاه اخذ می شود در نهایت مدل ارائه شده زمینه ارزیابی سازگاری مابین سرویسهای ترکیب شده را فراهم می کند . Christian Emig از یک process language از قبیل [10]BPMN برای نگاشت اتوماتیک مدل به یک زبان قابل اجرا استفاده کرده است[5] . Soo Ho Chang برای مدلسازی تغییرپذیری متدی ارائه کرده است [6] . Thomas Oliver نشان داده است که چگونه مدل فرایند برای طراحی و تحقق معماریهای سرویس گرا استفاده می شود[10] . روشهای موجود به شکل کامل به فاز طراحی نپرداخته اند و می توان گفت تنها در بخشی از مباحث مطرح SOA تکنیکهایی ارائه کرده اند . تعدادی از سوالاتی که در زمینه طراحی مطرح می شود از این قرار است که چه استانداردهای طراحی وجود دارد ؟ چه ترکیبات سرویسی ممکن است ؟ برای حمایت فرایندهای تجاری باید چه تصمیماتی برای پیکربندی لایه های سرویس اتخاذ گردد؟ ... 4-1 روش کار و تحقیق در این پایان نامه در زمینه مدلها و سبکهای مختلف توسعه نرم افزار بحث شده و با توسعه مبتنی بر سرویس مقایسه خواهند شد . سپس SOA با توجه به مولفه هایش شرح داده خواهد شد و معماری لایه و ویژگیهای آن بیان خواهد شد . بخش بعدی در ارتباط با روشن نمودن اصول مبتنی بر سرویس در طراحی و توسعه نرم افزاری خواهد بود و ویژگیهای طراحی مبتنی بر سرویس بیان خواهد شد . سپس فاز تحلیل سرویس گرا از دیدگاه استراتژیهای مختلف و ایجاد خروجی قابل استفاده برای فاز طراحی بیان می شود . بخش بعدی به اصول طراحی سرویس گرا و رهنمودهای عمومی طراحی می پردازد و الگوهای طراحی موجود معرفی می شود . درنهایت روشی برای طراحی مبتنی بر سرویس ارائه خواهد شد . گامهای طراحی دربردارنده تکنیک و اصول مربوطه از جهت حمایت سرویس گرائی می باشند . هر یک از گامهای طراحی حاوی مثالی به منظور نمایش فرایند تعریف شده خواهند بود و در پایان نمونه کاربردی پیاده سازی شده و نتیجه گیری را خواهیم داشت . روش ارائه شده با بازبینی لایه بندی مرحله تحلیل آغاز می شود و با اضافه نمودن لایه های تخصصی تر به فرایند همکاری سرویسها کمک می کند . سپس تحلیل بر روی نیازمندهای تغییر پذیر صورت می گیرد و نقاط تغییر پذیر[11] شناسایی می شوند . ممکن است مجموعه این نقاط بعدا دچار تغییر شود ویا اینکه نقاط جدیدی تعریف شود . سپس بر اساس انواع سرویسهایی که در فرایند طراحی با آنها رو به رو هستیم نگاشت سرویسها به لایه های مجزای تعریف شده انجام می پذیرد . حوزه عملکرد سرویسها , نیازمندیهای پردازشی سرویسها ,سرویسهای ترکیبی و ترتیب هماهنگی از سرویسها برای دست یافتن به اهداف فرایندکسب وکار مشخص می شود . با شناسایی قوانین تجاری , استثناها و شروط , لایه سرویس فرایند که یک لایه کنترلی است تعریف می شود . سپس با استفاده از مبحث دانه بندی[12] ,بر روی سرویسهای مرحله قبل بازبینی خواهیم داشت و متدهای هر کدام از سرویسها از جهت حوزه عملکرد و خروجی تولید شده مورد بررسی قرار خواهند گرفت . در صورت نیاز ممکن است برای تامین امنیت ضرورت متدهای چند دانه[13] تعریف شود . در این مرحله مدلسازی سرویسهای ترکیبی انجام می شود و خروجی این مرحله Sequence Diagam , Collaboration Diagram, Generic model خواهد بود . در مرحله نهایی با استفاده از BPMN - بر خلاف UML که مبتنی بر object است , BPMNقابلیتهایی در مدلسازی فرایند دارد - می توان به مدلسازی فرایند پرداخت و با امکانات این ابزار کد قابل اجرای فرایند ایجاد می شود . 5-1 مقایسه ای بر مدلهای توسعه وابسته به معماری در این بخش درزمینه مدلهای مختلف توسعه نرم افزار و سبکهای معماری, بحث شده و با توسعه مبتنی بر سرویس مقایسه می شوند . سپس سبک معماری سرویس گرا با بیان جزئیات و با توجه به مولفه ها , ویژگیها و معماری لایه لایه شرح داده می شود . 1-5-1 توسعه مبتنی بر object توسعه مبتنی بر object با کپسوله سازی داده و رفتار در یک نوع داده مجازی به نام کلاس از توسعه نرم افزار حمایت می کند . اشیاء از طریق ارسال پیغام با همدیگر ارتباط برقرار می کنند . توسعه مبتنی بر شی با حمایت کافی از پنهان سازی رفتار و داده در اشیاء و کلاسها ,پیشرفت طراحی نرم افزار را موجب می شود . طراحی مبتنی بر object فاز اساسی در تولید نرم افزار است که موفقیت تجاری در بازار نرم افزار داشته است . طراحی مبتنی بر شی شامل طرح ریزی ساختار نرم افزار , بهبود کیفیت نرم افزار از طریق یافتن کمبودهای ساختار و نمونه سازی سریع از سیستم نرم افزاری می باشد . مزیت مبتنی بر شئ بودن این است که ساختارهای نرم افزار به سادگی به نمونه های واقعی نگاشت می یابند . امروزه تکنولوژی مبتنی بر شیء به طور گسترده ای به کار گرفته می شود و الگوی برجسته ای برای توسعه نرم افزارهای کاربردی می باشد . این تکنولوژی زمانی که با زیرسازی های مولفه ای ترکیب می شود , قابلیت همکاری محیطهای مختلف نرم افزاری را فراهم می کند[24] . 2-5-1 توسعه مبتنی بر مؤلفه مؤلفه ها , ماژولهای نرم افزاری پیچیده ای نسبت به اشیاء هستند و نیازمند برقراری تغییراتی در تفکر سیستمها , فرایندهای نرم افزاری و به کارگیری تکنولوژی می باشند . توسعه مبتنی بر مؤلفه به توسعه دهندگان اجازه می دهد تا سیستمهای با کیفیت تر و پیچیده تر ایجاد کنند به دلیل اینکه متدهای بهتری برای مدیریت پیچیدگیها و وابستگیهای داخل یک کاربرد فراهم می کند . یک مؤلفه نرم افزار به مثابه یک واحد ترکیبی , با وابستگیهای مفهومی صریح و واسطهایی که مبتنی بر قرارداد هستند تعریف می شود . یک مؤلفه نرم افزاری می تواند به شکل مستقلی گسترش داده شود و این مبحثی است که بوسیله third parties برای ترکیب استفاده می شود . ممکن است که مؤلفه ها برای ایجاد واحدهای بزرگتر مجتمع شوند که این واحد می تواند یک مؤلفه جدید , یک چارچوب مؤلفه ای و یا یک سیستم کامل . مؤلفه ترکیب شده خصوصیات به اشتراک گذاشته شده را از مؤلفه های سازنده کسب می کند که اغلب اجتماع plug-and-play نامیده می شود . مؤلفه های با قابلیت استفاده مجدد بازتاب صحیحی از طراحی نرم افزارهای موثر می باشند . در این معماری یک زمینه طراحی فراهم می شود که در آن مولفه ها ساخته شده و مجددا استفاده می شوند . جنبه مهم دیگر مؤلفه ها این است که توسعه معماری نرم افزار مبتنی بر توصیفات مؤلفه از ساخت مستقل و همزمان اجزاء سیستم حمایت می کند . این ویژگی موجب می شود که بخشهای مستقل سیستم , زیر سیستمهای قابل تست باشند و بتوان سیستم را مابین یک یا چندین تیم توزیع یافته تقسیم کرد . 3-5-1 محاسبات توزیع یافته اگرچه معماری سرویس گرا دلالت مستقیمی به محاسبات توزیع یافته[14] ندارد , اما ناگزیر است که تکنولوژیهای میان افزار موجود و مفاهیم محاسبات توزیع یافته را بهم پیوند دهد . یک معماری سرویس گرای موفق باید به مشکلات رویارویی با تکنولوژیهای میان افزار موجود از طریق حمایت یک راه حل موثر در توسعه برنامه های کاربردی و تکنولوژیهای آتی غلبه کند و این کار از طریق توجه به مفاهیم و تکنولوژیهای قابل حصول انجام می شود . راه حلهای اخیر در محاسبات توزیع یافته به برپایی یک ارتباط مستقیم مابین دو برنامه توزیع یافته بر روی پروتکل فیزیکی شبکه مربوط می شود . پروتکلهای سطح بالاتر از قبیل SNA ,TCP/IP,IPX واسطهایی فراهم می کنند که تلاش برای پیاده سازی و وابستگی تکنولوژی را کاهش می دهد . نظر به اینکه تکنولوژی محاسبات توزیع یافته تکامل پیدا می کند , ضرورت فراهم نمودن چندین پیاده سازی شبکه ای برای تامین نیازمندیهای کیفیتی سرویس نیز افزایش پیدا می کند . ممکن است این نیازمندیها شامل وقت شناسی در تحویل پیغام , کارایی , توان عملیاتی , قابلیت اطمینان , امنیت