.:رویال آی تی:.

مقاله ارائه روشي براي طراحي مبتني بر سرويس

فهرست مطالب

چکيده ۱
مقدمه ۲

فصل اول: کليات معماري سرويس گرا
۱-۱) تعاريف اوليه ۵
۱-۱-۱) سبک معماري مبتني بر سرويس ۵
۲-۱) اهداف تحقيق ۷
۳-۱) پيشينه تحقيق ۸
۴-۱) روش کار و تحقيق ۱۰
۵-۱) مقايسه اي بر مدلهاي توسعه وابسته به معماري ۱۱
۱-۵-۱) توسعه مبتني بر object 11
۲-۵-۱) توسعه مبتني بر مؤلفه ۱۲
۳-۵-۱) محاسبات توزيع يافته ۱۳
۴-۵-۱) معماري سرويس گرا ۱۴
۱-۴-۵-۱) توسعه مبتني بر سرويس ۱۵
۲-۴-۵-۱) قابليتهاي معماري سرويس گرا ۱۷
۶-۱) مؤلفه هاي SOA 18
۷-۱) اصول سرويس گرائي
۲۱
۸-۱) سرويس گرائي و تشکيلات سازماني ۲۷
۱-۸-۱) لايه هاي سرويس ۲۹
۱-۱-۸-۱) لايه سرويس کاربردي ۳۲
۲-۱-۸-۱) لايه سرويس تجاري ۳۴
۳-۱-۸-۱) لايه سرويس همنوائي ۳۴
۲-۸-۱) سرويسهاي Agnostic 37

فصل دوم : تحليل مبتني بر سرويس
۱-۲) چرخه حيات معماري سرويس گرا ۴۰
۲-۲) استراتژيهاي تحويل SOA 41
۱-۲-۲) روش پايين به بالا ۴۱
۲-۲-۲) روش بالا به پايين ۴۳
۳-۲-۲) روش Meet-In-The-Middle 45
۳-۲) تحليل سرويس گرا ۴۷
۱-۳-۲) اهداف تحليل سرويس گرا ۴۷
۲-۳-۲) پروسه تحليل سرويس گرا ۴۸

فصل سوم : الگوها و اصول طراحي
۱-۳) نکات قابل توجه طراحي ۵۲
۱-۱-۳) مديريت دانه بندي سرويس و مؤلفه ۵۲
۲-۱-۳) طراحي براي قابليت استفاده مجدد ۵۳
۳-۱-۳) طراحي براي قابليت ترکيب سرويس ۵۴
۱-۳-۱-۳) اتصال و همبستگي
۵۴
۲-۳) رهنمودهاي عمومي ۵۵
۱-۲-۳) استانداردهاي نامگذاري ۵۵
۲-۲-۳) طراحي عمليات سرويس به شکلي که ذاتا قابل توسعه باشد ۵۶
۳-۲-۳) تعيين متقاضيان مطرح سرويس ۵۶
۳-۳) الگوهاي طراحي و انواع معماري ۵۷
۱-۳-۳) الگوها ۵۸
۲-۳-۳) طراحي بنيادي ۵۹

فصل چهارم : راهکار پيشنهادي
۱-۴) مرحله ۱ بازبيني لايه بندي سيستم SOA 64
۱-۱-۴) فعاليت ۱ مروري بر استراتژيهاي لايه بندي ۶۴
۲-۱-۴) فعاليت ۲ بازبيني لايه بندي فاز تحليل ۶۶
۳-۱-۴) فعاليت ۳ معرفي لايه هاي تخصصي تر ۶۷
۱-۳-۱-۴) لايه داده ۶۷
۲-۳-۱-۴) لايه دسترسي سرويس ۷۰
۳-۳-۱-۴) لايه تعامل ۷۱
۲-۴) مرحله ۲ تحليل تغييرپذيري ۷۷
۱-۲-۴) فعاليت ۱ شناسايي انواع تغييرپذيري ۷۹
۲-۲-۴) فعاليت ۲ مدلهاي موجود براي تغييرپذيري ۸۳
۳-۲-۴) فعاليت ۳ گروهبندي و مدلسازي تغييرپذيري ۸۴
۴-۲-۴) فعاليت ۴ نگاشت نقاط تغييرپذير ۸۷
۳-۴) مرحله ۳ سرويسهاي فاز طراحي
۸۹
۱-۳-۴) فعاليت ۱ تعيين سرويسها ۹۰
۲-۳-۴) فعاليت ۲ جايگاه سرويسهاي کنترلي ۹۸
۴-۴) مرحله ۴ مروري بر دانه بندي ۹۹
۱-۴-۴) فعاليت ۱ تکنيک دانه بندي سرويسها و چنددانه اي بودن ۱۰۲
۲-۴-۴) فعاليت ۲ متدهاي چند دانه اي سرويسها ۱۰۴
۵-۴) مرحله ۵ مدلسازي فرايند ۱۰۸
۱-۵-۴) استفاده از مدلسازي فرايند براي طراحي معماري سرويس گرا ۱۰۸
۲-۵-۴) ابزار مدلسازي فرايند ۱۰۹
۳-۵-۴) فعاليت طراحي فرايند کسب و کار مبتني بر سرويس ۱۱۳

فصل پنجم : بررسي موردي
۱-۵) انتخاب بررسي موردي ۱۱۵
۱-۵) سيستم سفارش کالا ۱۱۶
۳-۵) تحليلي بر راهکار پيشنهادي ۱۳۴

فصل ششم : نتيجه گيري و پيشنهادات
۱-۶) نتيجه گيري ۱۳۶
۲-۶) پيشنهادات ۱۳۸
مقاله ۱۳۹
پيوستها ۱۴۰
منابع و ماخذ
فهرست منابع فارسي ۱۹۶
فهرست منابع لاتين ۱۹۷
سايتهاي اطلاع رساني ۲۰۰
اختصارات ۲۰۱
چکيده انگليسي ۲۰۲

فهرست شکلها

شکل ۱-۱) ميان افزار مبتني بر پيغام[۲۴] ۱۴
شکل ۲-۱) مدل مفهومي معماري سرويس گرا[۲۴] ۱۵
شکل ۳-۱) توسعه مبتني بر سرويس[۲۴] ۱۶
شکل ۴-۱) يک ديدگاه اوليه از چگونگي قرار گرفتن منطق خودکارسازي در داخل واحدها توسط SOA 20
شکل ۵-۱) عملياتهايي که به سرويسهاي متفاوتي تعلق دارند و بخشهاي متنوعي از منطق پروسه را نمايش مي دهند. ۲۰
شکل ۶-۱) چگونه مؤلفه هاي يک معماري سرويس گرا با يکديگر ارتباط دارند. ۲۱
شکل ۷-۱) پيمانهاي سرويس به طور رسمي مؤلفه هاي سرويس, عمليات و پيغام از يک معماري سرويس گرا را تعريف مي کند. ۲۳
شکل ۸-۱) سرويسها وابستگي ها را به قرارداد سرويس محدود مي کنند و با اين کار به منطق سرويس دهنده زيرين و تقاضاکننده اجازه مي دهند که loosely coupled باقي بمانند. ۲۴
شکل ۹-۱) عمليات Update Everything يک ترکيب سرويس را بسته بندي مي کند ۲۵
شکل ۱۰-۱) مراحل statelessو stateful که يک سرويس درهنگام پردازش يک پيغام از آنها عبور مي کند . ۲۷
شکل ۱۱-۱) جايگاه سرويسها[۱] ۲۸
شکل ۱۲-۱) لايه هاي تخصصي سرويس[۱] ۳۲
شکل ۱۳-۱) سلسله مراتب چرخه حيات توسعه سرويسهاي وب[۹] ۳۶
شکل ۱۴-۱) بخش بندي سرويسها که محيط راه حل و پردازشهاي تجاري را تفکيک کرده است[۱]. ۳۸

شکل ۱-۲) چرخه حيات معماري سرويس گرا ۴۰
شکل ۲-۲) گامهاي تکنيک پائين به بالا ۴۲
شکل ۳-۲) گامهاي تکنيک بالا به پائين ۴۴
شکل ۴-۲) گامهاي تکنيک meet in the middle [1] 46

شکل ۱-۳) در صورت تجزيه يک سرويس , الگوهاي نظارتي به عدم تاثيرگذاري در قرارداد سرويس کمک مي کنند.[۲۷]
۵۹

شکل ۲-۳) منطق Agnostic و [۲۷] Non Agnostic 60

شکل ۱-۴) فعاليتهاي فاز طراحي
۶۳
شکل ۲-۴) مدل گسترش سيستم تحت تاثير لايه بندي [۳۰] ۶۵
شکل ۳-۴) پنهان سازي پيچيدگي توسط لايه انتزاعي داده ۶۹
شکل ۴-۴) لايه دسترسي سرويس[۲] ۷۰
شکل ۵-۴) ساختار منطقي از سرويسهاي تعاملي ۷۳
شکل ۶-۴) مثالهايي از سرويس تعاملي در SOA
۷۶
شکل ۷-۴) چارچوب مبتني بر سرويس براي سرويسهاي تعاملي ۷۶
شکل ۸-۴) ۴ نو ع تغييرپذيري ۸۰
شکل ۹-۴) واسط مورد نياز فرايند کسب و کار ۸۱
شکل ۱۰-۴) نقاط تغييرپذير ممکن ۸۲
شکل ۱۱-۴) شمايي از تغييرپذيري در XML [6] 83
شکل ۱۲-۴) مدل تصميم , مدل واسطي براي سازگاري سرويسها مي باشد[۶] ۸۴
شکل ۱۳-۴) دياگرام فعاليت و نقاط تغيير پذير[۳۱] ۸۵
شکل ۱۴-۴) مدل خصيصه[۳۱] ۸۶
شکل ۱۵-۴) سرويسهاي Gateway [2] 92
شکل ۱۶-۴) سرويسهاي Façade [2] 93
شکل ۱۷-۴) جايگاه دستورات کنترلي درمقايسه دو راه حل [۲] ۹۶
شکل ۱۸-۴) سرويسهاي دانه درشت[۱۱] ۱۰۱
شکل ۱۹-۴) ارتباط سرويس دانه درشت و سرويس دانه ريز[۱۱] ۱۰۳
شکل ۲۰-۴) متد جديدي براي ارسال اطلاعات آدرس اضافه شده است.[۱۱] ۱۰۵
شکل ۲۱-۴) يک متدي که هر دو نوع اطلاعات آدرس و حساب را بر مي گرداند.[۱۱] ۱۰۵
شکل ۲۲-۴) متدي که مؤلفه هاي درخواست داده شده را برمي گرداند[۱۱] ۱۰۷
شکل ۲۳-۴) مدلسازي سلسله مراتبي با BPMN [5] 112
شکل ۲۴-۴) مجموعه مدلهاي فاز طراحي و ارتباط آنها ۱۱۳
شکل ۱-۵) دياگرام فعاليت ۳ عامل ۱۱۷
شکل ۲-۵) سرويسهاي کانديد
۱۲۰
شکل ۳-۵) مدل لايه بندي سيستم ۱۲۱
شکل ۴-۵) تغيير پذيري در گردش کار ۱۲۲
شکل ۵-۵) مدل خصيصه ۱۲۳
شکل ۶-۵) دياگرام فعاليت براي شناسايي وابستگيها ۱۲۴
شکل ۷-۵) دياگرام General Composition 125
شکل ۸-۵) مدل نگاشت ۱۲۵
شکل ۹-۵) لايه تامين کننده QOS 126
شکل ۱۰-۵) سرويسهاي دانه ريز ۱۲۷
شکل ۱۱-۵) دياگرام Consignee Collaboration 127
شکل ۱۲-۵) دياگرام Consignee Sequence Diagram 128
شکل ۱۳-۵) دياگرام Shipper Collaboration 128
شکل ۱۴-۵) دياگرام Shipper Sequence 129
شکل ۱۵-۵) دياگرام Partial Order Process Collaboration 129
شکل ۱۶-۵) دياگرام Partial Order Process Sequence
۱۳۰
شکل ۱۷-۵) دياگرام تعاملات مابين سرويس فرايند و سرويسهاي همکار
۱۳۱
شکل ۱۸-۵) مدل BPMN 132

فهرست جداول

جدول ۱-۱) مقايسه مدلهاي توسعه وابسته به معماري ۱۷
جدول ۱-۶) راهکار پيشنهادي در تامين اصول طراحي ۱۳۷

چکيده

معماري سرويس گرا به سرعت به عنوان نخستين ائتلاف و راه حل معماري محيطهاي محاسباتي ناهمگون و پيچيده معاصر پديدار گشته است . SOA نيازمند اين است که سازمانها مدلهاي کسب و کار خود را ارزيابي کنند, به ايجاد تکنيکهاي تحليل و طراحي مبتني بر سرويس بيانديشند و طرحهاي گسترش و پشتيباني روابط مابين فروشنده , مشتری و شريک تجاری را ارزيابي کنند . طراحان نمي توانند انتظار مديريت توسعه يک پروژه سرويس گرا را داشته باشند بدون اينکه به شيوه طراحي دقيق و متدولوژي توسعه تکيه داشته باشند . از آنجايي که متدولوژي توسعه مبتني بر سرويس اهميت حياتي در توصيف ,ساخت , پالايش و تطبيق فرايندهاي کسب وکاري دارد که تغييرپذيري بالايي دارند و تا به حال روش مناسب و منسجمي براي توسعه برنامه هاي کاربردي تجاري قدرتمند وجود ندارد , هدف اين تحقيق ارائه روشي براي طراحي مبتني بر سرويس مي باشد . در اين تحقيق از تکنيکها و مباحث مطرح درSOA استفاده شده و براي طراحي سرويس گرا روشي پيشنهاد مي شود . تمرکز تحقيق بر روي فرايند طراحي مي باشدکه اصول و تکنيکهاي کافي براي مشخص کردن , ساخت و پالايش فرايندهاي کسب وکاري که به سرعت دچار تغيير مي شوند فراهم مي کند . روش پيشنهاي براي ايجاد کنترل متمرکز از تجريد لايه های سرويس و طبقه بندی انواع سرويس استفاده نموده و در کنار استفاده از سيستمهاي موروثي در حمايت از استراتژيهاي کوتاه مدت سازمانها ,بر اساس اصول طراحي و اصول سرويس گرائي در راستاي استراتژيهاي بلند مدت عمل مي کند تا در تامين اهداف تجاري و حمايت از فرايندهايي که به سرعت دچار تغيير مي شوند مفيد واقع شود . همچنين زمينه تعامل عاملهاي مختلف فرايند که در سطح چندين سازمان گسترده شده اند فراهم مي شود و با تحليل تغييرپذيري, انعطاف پذيري سيستم در حمايت از نقاط متغير فرايندها و تغيير در سياستهاي کسب و کار افزايش مي يابد . بدين منظور در ادامه بحث ابتدا سبکهاي مختلف توسعه نرم افزار به همراه سبک مبتني بر سرويس و اصول سرويس گرائي به تفصيل بررسي مي گردد , سپس چرخه حيات معماري سرويس گرا و فاز تجزيه و تحليل که مقدمه اي براي طراحي مي باشد مورد بررسي قرار مي گيرد و در ادامه با بيان اصول و الگوهاي طراحي موجود , راهکار پيشنهادي با نمونه پياده سازي شده به صورت مشروح بيان مي گردد .

کلمات کليدي : SOA , Layer, Service Type , Process ,Variation , Granularity .Composition

مقدمه

در طول چهار دهه اخير، ميزان پيچيدگي نرم افزارها بصورت صعودي افزايش يافته و تقاضا براي نرم افزارهاي قدرتمندتر بيشتر شده است. در اين ميان، به نظر مي رسد که روشهاي قديمي جوابگوي نيازهاي در حال رشد کنوني نيستند و نياز به ايجاد و بکارگيري روشهائي است که بوسيله آنها بتوان بر اين پيچيدگيها بصورت کاراتر و در زماني کوتاهتر غلبه کرد. از سوي ديگر امكان كنار گذاشتن يکباره سيستمهاي نرم افزاري موجود که تا به حال مشغول سرويس دهي به مشتريان بوده اند، وجود ندارد و مي بايست سيستمهاي جديد را بصورت يکپارچه و در کنار همين سيستمهاي فعلي بوجود آورد. معماري سرويس گرا، با تکيه بر اصول سرويس گرائي و محاسبات و سرويس هاي توزيع شده و بر پايه پروتکلهاي شبکه و لايه هاي منطقي سرويس و همچنين زبانهايي که توليد نرم افزارهاي توزيع شده را فراهم مي كنند، به عنوان راه حلي مناسب جهت از ميان برداشتن مشکلات و مسائل مذكور مطرح گرديده است[۲۰,۲۱].
SOA مجموعه اي از اصول , نظريه ها و تکنيکهايي را فراهم مي کند که فرايندهاي کسب و کار , اطلاعات و دارايي هاي تشکيلات بتوانند به شيوه مؤ ثري سازماندهي شوند و اين فرايندها مي توانند براي پشتيباني از طرحهاي استراتژيک و سطوح بهره وري که در محيطهاي رقابتي کسب و کار مورد نياز هستند, گسترش داده شوند . بسياري از تشکيلات اقتصادي در استفاده اوليه شان از SOA چنين پنداشتند که از مولفه هاي موجود به عنوان سرويس وب مي توانند استفاده کنند و عنوان کردند تنها با ايجاد سرويسهاي پوشاننده و رها کردن مولفه هاي زيرين غير قابل دسترس, اين کار عملي خواهد بود . در نتيجه پياده سازي لايه نازکي از SOAP/WSDL/UDDI بالاي برنامه کاربردي موجود يا مولفه هايي که سرويسهاي وب را تحقق مي بخشند , تا حد گسترده اي در صنعت نرم افزار تجربه شد . اما تا به حال روش مناسبي براي ايجاد برنامه هاي کاربردي تجاري قدرتمند وجود ندارد . اگرچه طبيعت مولفه ها مناسب استفاده از آنها به عنوان سرويس وب مي باشد , در بيشتر موارد اينطور نيست و براي طراحي مجدد و ارائه کارکرد مولفه ها به شيوه صحيح و از طريق سرويس وب نيازمند تلاش مضاعفي مي باشيم[۹] .
پياده سازي موفق SOA مستلزم اين است که به مفاهيم و استراتژيهاي پياده سازي که خصوصيات و ويژگيهاي اساسي SOA را فرموله مي کنند , توجه شود . به مجرد پياد ه سازي موفق SOA , مزايايي در جهت کاهش زمان توسعه و ايجاد محصول , بهره برداري از کاربردهاي انعطاف پذير با پاسخ دهي سريع و امکان اتصال پوياي استدلالهاي کاربردي شرکاي تجاري , حاصل مي شود . يک پياده سازي کامل SOA نه تنها در ارتباط با گسترش و صف آرايي سرويسها مي باشد بلکه امکان استفاده از سرويسها درجهت اجتماع برنامه هاي کاربردي متمايز و ايجاد کاربرد مرکب را منعکس مي سازد.

معماري  سرويس گرا (SOA)

SOA مجموعه قوانين ، سياستها و چارچوبهايي است كه نرم افزارها را قادر مي سازد تا عملكرد خود را از طريق مجموعه سرويسهاي مجزا و مستقل و در عين حال مرتبط با هم در اختيار ساير درخواست كنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پياده سازي سرويس و تنها از طريق رابطهاي استاندارد و تعريف شده، اين سرويسها را يافته و فراخواني نمايند و يا در تعريف ديگر مي توان گفت معماري سرويس گرا روشي براي ساخت سيستمهاي توزيع شده اي است که در آنها عملکرد سيستم بصورت سرويس در اختيار کاربران و يا ساير سرويسها قرار مي گيرد. از ديگرتعاريف ارائه شده مرتبط با معماري هاي سرويس گرا مي توان به واحدهاي نرم افزاري آماده در شبكه[۱] يا سرويسهاي سطح حرفه اي[۲]  اشاره كرد. در حال حاضر، تکنولوژي سرويسهاي وب  و پياده سازي نمونه هاي موفق از آن، نشان داده است که SOA مي تواند به عنوان راه حلي عملي و دست يافتني در طراحي سيستمهاي توزيع شده جديد و يکپارچه سازي سيستمهاي بزرگ موجود مطرح گردد[۳].  در اين معماري، همه توابع به عنوان سرويس تعريف مي گردند. اين توابع شامل توابع تجاري و تراكنشهاي تجاري مي باشند كه تراكنشهاي تجاري خود شامل توابع سطح پايين و توابع سيستمي سرويسها هستند. سرويسها بصورت مستقل طراحي و پياده سازي شده و به عنوان جعبه سياه عمل مي نمايند. قطعات ديگر در خارج از اين قطعه,  نيازي به دانستن نحوه انجام کار در اين سرويس را ندارند و تنها به نتيجه آن نيازمندند. قطعات، سرويسهاي خود را از طريق رابطهاي تعريف شده در اختيار قطعات ديگر قرار ميدهند که اين رابطها قابل دستيابي و فراخواني هستند، بدون اينکه محل قرار گيري آنها اهميت داشته باشد (رابطهاي محلي يا دور ). در ضمن، اين رابطها مي توانند به همان نرم افزار كاربردي  يا به آدرسي در محل ديگري از شبکه مرتبط باشند. رابطها به عنوان کليدي در برقراري اين ارتباطها هستند و از طريق آنها نوع پارامترهاي ورودي و نتايج (خروجي) مشخص مي گردد[۱,۳۴,۲۶].

نياز به معماري سرويس گرا و امکانات آن از جنبه هاي مختلف به نحوه بارزي در برنامه هاي كاربردي توزيع شده جديد خصوصا برنامه هاي مرتبط باE-Commerce  مشهود و ملموس است. به عنوان نمونه اگر مثلا سرويس مربوط به پرداخت با كارت اعتباري غير فعال باشد، ‌قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوند وعمليات پرداخت به وقت ديگري موكول شود.  همانند ساير معماري هاي توزيع شده،‌ SOA  ساخت برنامه هاي كاربردي با استفاده از اجزايي كه در حوزه هاي جدا از هم قرار دارند را ممكن مي سازد  و غالبا از سرويسهاي وب به عنوان نقاط ورود برنامه كاربردي استفاده مي كند كه از لحاظ مفهومي معادل همان اجزاي proxy و  stub  در سيستمهاي توزيع شده سنتي مبتني بر اجزاء هستند. با اين تفاوت كه در اين جا ارتباط بين سرويس وب و استفاده كننده خيلي آزادانه تر و مستقل تر است. به علاوه SOA به خاطر در بر داشتن فاكتورهايي كه اهميت حياتي در تجارت دارند، نيز منحصر به فرد است ( فاكتورهايي نظير قابليت اطمينان سرويس،‌ جامعيت پيام ، يكساني تراكنش و امنيت پيام ). اگر سيستمي توانايي هاي خود را در قالب سرويسي روي وب ارائه كند، در آن صورت نحوه فراخواني آن سرويس بايد به طور واضح مستند سازي و اعلام شود. بسياري از مسائل دسترس پذيري و مقياس پذيري برنامه هاي كاربردي امروزي در SOA به نحو مطلوبي حل شده است. البته در SOA فرض بر اين است كه احتمال خطا هميشه وجود دارد و مي تواند اتفاق بيفتد، بنابراين استراتژي هايي براي پاسخگوئي به خطاها در آن تعبيه شده است . براي مثال اگر يك سرويس نتواند يك پيغام را در مرحله اول بپذيرد، اين معماري طوري طراحي شده است كه مجددا پيام را بفرستد و اگر يك سرويس به طور كامل قابل دسترس نباشد، (كه هرگز نبايد در يك سيستم SOA پايدار اتفاق بيفتد ) آنگاه معماري طوري طراحي شده است كه روي دادن خطاهايي كه منجر به قطع كامل در خواست سرويس مي شود، ‌امكان پذير نباشد. استفاده از معماري سرويس گرا همچنين قابليت اطمينان را افزايش مي دهد، زيرا خطاهاي موقت در بخشي از جريان كار نمي توانند كل فرايند تجاري را از كار بياندازند. به بيان كلي،‌ SOA  فرايندي تكامل يافته را ارائه مي نمايد و از اين نظر مي توان آن را بلوغ سريسهاي وب و تكنولوژي هاي يكپارچه سازي به حساب آورد. در SOA  به اين امر توجه شده است كه سيستمهاي با اهميت حياتي كه بر مبناي تكنولوژي هاي توزيع شده ساخته مي شوند، بايد تضمين هاي خاصي را تامين نمايند. در اين گونه سيستمها بايد اين اطمينان وجود داشته باشد كه در خواستهاي سرويسهاي موردنياز, به طور صحيح مسير دهي و هدايت  شوند، در زمان مناسب به آنها پاسخ داده شود و اين سرويسها به طور واضح و دقيق, سياستهاي ارتباطي و رابطهاي خود را اعلام كنند.[۱-۳۴-۳۵-۳۶]

۲-۱ اهداف تحقيق

راهکارهاي نوين توسعه سيستم هاي نرم افزاري که هم اکنون بطور گسترده استفاده مي گردند عليرغم نکات برجسته و نقاط کارامد غالبا سيستم هائي ايجاد مي کنند که از کمبودهائي رنج مي برند. مهمترين نقاط ضعف اين سيستم هاي نرم افزاري شامل موارد زير است:

• کمبود انعطاف پذيري محيط کسب و کار سازمان
• کند بودن در پشتيباني از تغييرات نيازمنديهاي کسب و کار و پشتيباني اهداف و سياستهاي جديد
• سربارها و پيچيدگيهاي عملياتي و قابليت استفاده مجدد کم سرمايه هاي فعلي سازمان
• کمبود تعامل پذيري مناسب و دشواري گسترش سريع استانداردهاي صنعتي نوين
• عدم پشتيباني اصول پايه مهندسي نرم افزار و استانداردهاي شفاف و صريح

SOA ، با تکيه بر محاسبات توزيع شده و بر پايه پروتکلهاي شبکه و لايه هاي مياني سرويس و همچنين زبانهايي که توليد نرم افزارهاي توزيع شده را فراهم مي كنند، بعنوان راه حلي مناسب جهت از ميان برداشتن مشکلات و مسائل مذكور مطرح گرديده است. بمنظور توسعه سيستم هاي نرم افزاري با رويکرد SOA و طراحي فرايند سرويس گرا و شناسائي سرويس هاي مختلف تکنيکهاي مختلفي وجود دارد که غالب اين روشها عليرغم مزايائي که دارند داراي معايبي نيز  مي باشند .

از آنجايي که متدولوژي توسعه مبتني بر سرويس اهميت حياتي در توصيف  ,ساخت , پالايش و تطبيق فرايندهاي کسب وکاري دارد که به سرعت دچار تغيير[۳] مي شوند و تا به حال روش مناسب و منسجمي براي توسعه برنامه هاي کاربردي تجاري قدرتمند وجود ندارد هدف ما ارائه روشي براي طراحي مبتني بر سرويس مي باشد . طراحي سرويسها شامل چندين موضوع اساسي مي باشد که به منظور غلبه بر پيچيدگي در ساخت کاربردهاي مبتني بر سرويس ضرورت دارد روشن شود .در اين تحقيق ما از تکنيکها و مباحث مطرح درSOA   به شکل منسجم استفاده نموده و براي طراحي سرويس گرا روشي پيشنهاد خواهيم کرد . تمرکز ما بر روي فرايند طراحي مي باشدکه اصول و تکنيکهاي کافي براي مشخص کردن , ساخت و پالايش فرايندهاي کسب وکاري که به سرعت دچار تغيير مي شوند , فراهم مي کند . در طي فاز طراحي يک سيستم مبتني بر سرويس , سرويسها بر اساس ملاحظات خاصي – از قبيل پيمانه اي بودن ,  در نظر گرفتن نقاط تغييرپذير  براي ارائه قابليت تصميم گيري در راستاي استفاده هاي مختلف از سرويسها , دارا بودن قابليت استفاده مجدد , خود مختاري و غيره , طراحي وساختاردهي مي شوند . به دليل اينکه اساس وپايه SOA قابليت استفاده مجدد مي باشد , هدف ما رعايت اصول طراحي سيستم شامل اعمال ملاحظات پياده سازي در صورت وجود يک پيکربندي اوليه SOA براي سازمان و همچنين اعمال نيازمنديهاي غير کارکردي , اصول طراحي سرويسها و بازبيني پيکربندي لايه هاي شناسائي شده مي باشد .

۳-۱ پيشينه تحقيق

از گذشته هاي دور برنامه نويسان تلاش مي كردند تا كدهاي نرم افزاري را بصورت پيمانه اي بنويسند تا بتوان از آن كدها در توليد نرم افزارهاي ديگر استفاده كرد . تفاوت نوشتن كد بصورت پيمانه اي و بر اساس معماري سرويس گرا در حجم مخاطبان آن است. در جهان امروز طيف مخاطباني كه مي توانند بصورت بالقوه از يك سرويس استفاده كنند، كل كاربران روي شبكه اينترنت است. بنابراين بايد مكانيزمي بوجود مي آمدكه مي توانست پاسخگوي اين محيط جديد (اينترنت) و كاربران آن باشد، بنابراين تفکر ايجاد معماري سرويس گرا بوجود آمد . ايده SOA اولين بار توسط دو شركت IBM  , Microsoft  در اواخر دهه ۱۹۸۰ پيشنهاد گرديد، كه هر دو شركت طي سالهاي اخير از حاميان اصلي سرويس هاي وب و عامل بسياري از ابداعات جديد در حيطه پشتيباني SOA و سرويس هاي وب، مانند UDDI ,WSE بوده اند. [۳-۲۲]  در زمينه طراحي مبتني بر  سرويس متدولوژي  RUP توسعه اي داشته است که چارچوب کاري ذيل را ارائه کرده است :

1. service identification
2. service specification
3. service realization
4. service deployment

در سال ۲۰۰۵Tomas Erl  تکنيکي ارائه نمود که قراردادها و اصول سرويس گرايي را در درون فرايند طراحي سرويس قرار مي دهد و تصميمات کليدي اتخاذ مي گردد[۱] . در سال ۲۰۰۴ Dijkman and Dumas  مدلي در زمينه طراحي مبتني بر سرويس با لحاظ چندين ديدگاه ارائه نمودند . ديدگاههاي مطرح در مدل ارائه شده  ,  رفتار واسط[۴] , رفتار سرويس دهنده[۵] , ترتيب و نظم[۶] و همنوائی[۷] مي باشد [۷] . در مدل ارائه شده محدوديتهاي موجود بررسي و ارتباط مابين اين ۴ ديدگاه اخذ مي شود در نهايت مدل ارائه شده زمينه  ارزيابي  سازگاري مابين سرويسهاي ترکيب شده را فراهم مي کند . Christian Emig از يک process language از قبيل [۸]BPMN براي نگاشت اتوماتيک مدل به يک زبان قابل اجرا استفاده کرده است[۵]  . Soo Ho Chang براي مدلسازي تغييرپذيري  متدي ارائه کرده است [۶]  . Thomas  Oliver نشان داده است که چگونه مدل فرايند براي طراحي و تحقق معماريهاي سرويس گرا استفاده مي شود[۱۰] . روشهاي موجود به شکل کامل به فاز طراحي نپرداخته اند و مي توان گفت تنها در بخشي از مباحث مطرح SOA تکنيکهايي ارائه کرده اند .

تعدادي از سوالاتي که در زمينه طراحي مطرح مي شود از اين قرار است که چه استانداردهاي طراحي وجود دارد ؟ چه ترکيبات سرويسي ممکن است ؟ براي حمايت فرايندهاي تجاري بايد چه تصميماتي براي پيکربندي لايه هاي سرويس اتخاذ گردد؟ …

[۱]  Network Available Software  Unit

[۲]  Service Business Level

[۳]  Highly Volatile

[۴] Interface Behaviour

[۵] Provider Behaviour

[۶] Choreography

[۷] Orchestration

[۸] Business Process Model Notation

۲۰۵ صفحه Word

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