بخشی از مقاله
ارائه راه حلي براي طراحي سرويس هاي وب اتکاپ ير با استفاده از تکنيک هاي تحمل پذيري خطاو WS-BPEL
چکيده
در شرايطي که کاربردهاي مبتني بر سرويس تبديل به واقعيت رو به روشدي مي گردد، اه يت توجه به مقوله اتکاپذيري در آنها آشکار مي گردد.خرابي سرويس و يا نتايج غلط در اين يستم ها ممکن است عواقب متغيري در بر داشته باشد و اين عواقب از يک نارضايتي ساده گرفته تا خطرات جاني رامي تواند در برگيرد.در اين مقاله ابتدا به حالات مختلف از کار افتادگي سرويس هاي وب و انواع خطاهاي ممکن در عرصه سرويس هاي وب و طبقه بندي آنها اشاره کرده و تاثيرات اين خرابي ها را مورد ارزيابي قرارمي د يم تا راه برخورد با آنها را به روش تحليلي استخراج کنيم ،سپس معماريهاي مختلف ارائه شده در مورد اتکاپذيري سرويسهاي وب معرفي شده و به ارزيابي آنها خوا يم پرداخت . معماريهاي ارائه شده به تفکيک تکنيکهاي تحمل پذيري خطا١همچون افزونگي زماني ٢، افزونگي فضايي ٣، گونه هاي مختلف تکراراعم ازتکرار فعال ٤ياتکرارغ رفعال ٥ و استفاده از تنوع طراحي است .
ايده نهايي اين مقاله استفاده از WS-BPEL و تکنيک برنامه نويسي چند نسخه اي ٧به صورت توام است ک تيجه آن ارائه يک معماري کارا و انعطاف پذير خواهد بود.معماري حاصل اين قا ليت را خواهد داشت که به شبکه پتري معادل تب يل شود تا ارزيابيهاي دقيق تري از لحاظ افزايش اتکاپذيري بر روي آن صورت پی يرد.
کلمات کليدي
سرويس وب ، اتکاءپذيري ، تحمل پذيري خطا، تنوع طراحي ، WS-BPEL
۱-مقدمه
با رشد روز افزون اينترنت ، سرويس هاي وب نيز به صورت قابل توجهي مورد استفاده قرار مي گيرند و رشد آنها حتي ازميزان پيش بيني شده نيز فراتر رفته است .سرويس هاي وب به صورت خود توصيف و مستقل از پلت فرم هستند. سرويس هاي تعريف شده قيقا بر اساس استاندارد- هاايجاد شده و توابع مهم و حياتي را در اختيار يستم هاي مختلف و بدون دخالت مستقيم کاربر قرار مي دهند ک يستم هاي B2B٩ ناميده مي شونددر شرايطي که کاربردهاي مبتني بر سرويس تبديل به
واقعيت رو به روشدي ي شود، چنين به نظر مي رسد که سرويس وب تکنولوژي نرم افزاري غالب در طي پنج سال آينده باشد. در نتيجه از آنجائيکه سرويس هاي وب در همه زواياي زندگي وارد خواهند شد، پس در مورد اتکاپذيري و امنيت آنها نيز تدابير متناسبي بايد اندي يده شود. در اين سمينار تقسيم بندي جامعي از خرابي هايي که در عرصه سرويس هاي وب ي تواند رخ دهد ارائه شده و نيز خطاهاي احتمالي که منجر به اين خرابي ها شده نيز مورد بررسي قرار مي گيرد.
سپس تلاش خواهيم کرد به معرفي استراتژي ها و تکنولوژي هاي حل چالش هاي موجود در سرويس هاي وب (از جمله قابليت دسترسي و قابليت اطمينان ) پرداخته و نقاط ضعف و قوت آنها را بررسي کنيم .
معماري مبتني بر سرويس بر مبناي مدل ساده اي از نقش ها طرح ريزي شده است . هر سرويس بر حسب مورد يک يا چند نقش را برعهده مي گيرد.برحسب اينکه نقش ارائه دهنده سرويس ،مشتري سرويس و يا کارگزار را برعهده داشته باشد. چندين روش براي تحمل پذيري خطا در سرويس هاي وب در مقالات متعددي پيشنهاد شده است ولي هنوز متد متناسبي براي اين زمينه مورد نياز است .
در کارهاي مرتبط قبلي از روش هايي همچون افزونگي زماني افزونگي فضايي ، چند نسخه سازي اعم ازتکرار فعال يا تکرار
غيرفعال واستفاده از تنوع طراحي اس فاده شده است . هرچند که سربار ناشي از اعمال اين تکنيک ها قابل توجه است و يا ايد طراحي آنها بسيار پر هزينه به نظر برسد، ولي وا عيت آن است که با در نظر گرفتن حساسيت فعاليت هاي حياتي و نفوذ روز افزون سرويس هاي وب در کاربردهاي خاص ، پرداخت چنين هزينه اي و تحمل کردن سربار اعمال شده از اين تکنيک ها، اجتناب ناپذير به نظر مي رسد. در مقالات متعددي معماري هاي مختلفي براي اعمال اتکاپذيري بر روي سرويس هاي وب بررسي شده که ن ايج حاصل شده از آنها مورد بررسي قرار گرفته است .
در نهايت با جمع بندي کارهاي مرتبط ، ايده اصلي مقاله که استفاده از برنامه نويسي چند نسخه اي در قالب يک WS-BPEL است ارائه خواهد شد.
۲- معماري مبتني بر سرويس (SOA١٠)
معماري مبتني بر سرويس براي پياده سازي برنامه هاي توزيع شده ، ايده آل است . معماري فوق ، امکان پياده سازي ويا، آزاد و گسترده برنامه هاي توزيع شده را فراهم مي نمايد. امروزه شاهد بکارگيري سيستم هاي متعددي مي باش م که خود از چندين برنامه و يا زير سيستم استفاده مي ن ايند. با توجه به ارتباط بين سيستمها با يکديگر ، ايجاد و اعمال يک تغيير در ارتباط با هر يک از زير يستم ها ي تواند باعث بروز اشکال در تعداد زيادي ز عناصر وابسته و يا اير برنامه ها گردد. رويکرد فوق ، افزايش هزينه نگهداري اين نو يستم ها را بدنبال خواهد داشت . معماري مبتني بر سرويس ، وابسته به سه عنصر اساسي است که هر يک داراي ايگاه خاص خود است ؛ ارائه دهنده سرويس مصرف کننده سرويس و کارگزار سرويس شکل (۱)معماري فوق را نشان مي دهد.
ارائه دهنده سرويس ، گرهي در شبکه ( اينترانت و يااينترنت )است که امکان دستيابي به اينترفيس يک سرويس نرم افزاري را فراهم مي - نمايد. گره ارائه دهنده سرويس ، امکان دستيابي به سرويس هاي يک سيستم تجاري ، يک زير سيستم و يا يک عنصر را بوجودمي آورد.
مصرف کننده سرويس ، گرهي در شبکه است که به سرويس ارائه شده توسط يک ارائه دهنده سرويس مرتبط و از امکانات و پتانسيل هاي سرويس ارائه شده در جهت پياده سازي يستم خود استفاده مي - نمايد. مصرف کننده سرويس رامي توان بمنزله يک برنامه سرويس گيرنده بر روي يک گره در نظر گرفت . کارگزار سرويس ، گره اي در شبکه است که مسئول تشريح سرويس را برعهده داشته و مي توان آن را بمنزله يک دفترچه آدرس در نظر گرفت که براي جستجو و يافتن سرويس ، مورد استفاده قرار مي گيرد. مصرف کننده سرويس ( متقاضي )، درخواست خود را در ارتباط با سرويس مورد نظر به کارگزار ارائه و کارگزار،سرويس درخواستي به همراه ارائه دهنده مورد نظر را پيدا مي نمايد.
۲-۱-تحمل پذيري خطا در سرويس هاي وب
براي اطمينان از اينکه سرويس هاي وب در لحظه اي که کلاينت ها به آنها نياز دارند، در دسترس باشند، بايد پارامترهاي قابليت اطمينان و امنيت در طراحي آن سرويس ها و عناصر تشکيل دهنده آنها در نظر گرفته شده باشد. چرا که در دسترس نبودن حتي يک قطعه از يک سرويس ، ديگر اجزا را تحت تاثير خود قرار خواهد داد.در ادامه دو پارامتر مهم و تاثير گذار از اتکاءپذيري را معرفي مي کنيم .[٤]
۲-۱-۱-قابليت دسترسي ١١
احتمال آنکه در لحظه درخواست ، سرويس در اختيار کلاينت قرار داده شود. و به بيان ساده احتمال فعال بودن و آماده سرويس بودن يک سرويس وب را در لحظه خاص ، قابليت دسترسي آن سرويس گفته مي شود. بعنوان مثال اگر قابليت دسترسي باشد. به اين معني است که در يک سال ۵.۲۵ دقيقه سرويس آماده ارائه سرويس نخواهد بود.
۲-۱-۲-قابليت ا طمینان
بازه اي از زمان ، با شروع از t0 که در آن بازه ،سرويس وب به شکل صحيحي به ارائه سرويس بپردازد (حتي پاسخ اشتباهي نيز برنگرداند). در کل ،محاسبه ميزان قابليت اطمينان مشکل تر از تحليل قا ليت دسترس پذيري است .
۲-۲-انواع خطاوطبقه بندي آنهادرسرويس هاي وب
منابع خطاي متفاوت ، مسلما واکنش متفاوتي رامي طلبند و اين در حالي است که تفکيک مورد به مورد اين موارد امکان پذير نيست ولي با اين حال مي توان ، منابع خطاها را دسته بندي کرد. واز روي اين دسته بندي عکس العمل مناسبي را اتخاذ کرد و نيزمي توان در صورت مشاهده خطاي جديد، بدنبال عکس العمل مناسبتري گشت .[١٤,٤]
۲-۲-۱-خطاهاي فيزيکي
خرابي هايي که در سطح رسانه شبکه و يا سرور رخ مي دهد در اين دسته قرار مي گيرد. سرويس هاي وب منفرد در حکم آجرهاي ساختمان يک سرويس وب مرکب هستند و اکثر مواقع ترکيب سرويس هاي وب به خاطر در دسترس نبودن يکي از اين آجرها رخ مي دهد. واضح است که در دسترس بودن هر سرويس نيز ارتباط مستقيمي با کارکرد صحيحي سرور و شبکه انتقال دارد.
۲-۲-۲-خطاهاي ناشي از توسعه سرويس وب
چنين خطاهايي ممکن است از طريق محيط توسعه توليد شود. مثلا از طريق توسعه دهندگان فردي و يا ابزارهاي توسعه . در هر صورت چنين خطاهايي ممکن است منجر به خرابي جزئي و يا حتي خرابي کل سيستم گردد. و يا تا فاز استفاده واقعي از سرويس ، کشف نشده باقي بمانند.
بعنوان مثال خطاي دريافت يک پارامتر ناسازگار يکي از خطاهاي ناشي شده از توسعه سرويس وب است . در شرايط عادي دريافت يک پارامتر نا صحيح و يا ناسازگار بعنوان ورودي يک سرويس مي تواند از طريق مدير استثنا تشخيص و جلوگيري گردد.
۲-۲-۳-خطاهاي ناشي از تعامل باسرويس هاي وب
شامل خطاهايي است که در يک يستم مرکب از چندين سرويس وب مي تواند ظاهر شود.ممکن است خطاهاي موجود در يک سرويس به سرويس ديگري منتشر شده و منجر به يک خرابي کلي شود. چنين خطاهايي زماني خود را نشان مي دهند که يک سرويس مرکب بيش از حد معمول دچار خرابي ي شود.
چنين خطاهايي به دسته هاي فرعي ترزير قابل تقسيم است :
خطاي محتوي شامل سرويس غير صحيح ، رفتاري که به خوبي درک نشده و خطاي پاسخ است . اين خطاها زماني خود را نشان مي دهند که محتوي سرويس ارائه مي شود. و در نتيجه اجراي آن انحرافي نسبت به آنچه که مورد انتظار بود مشاهده مي شود. و يا مثلا از مدت زمان انتظار معين شده درSLA تجاوز مي کند.
خطاي ترتيب ناصحيح زماني رخ مي دهد که در يک سرويس وب مرکب ، سرويس ها نياز به برقراري ارتباط با يکديگر دارند، معمولا پروتکل ارتباطي مورد استفاده SOAP ي باشد. ممکن است بسته هايي که سرويس ها به همديگر ي فرستند به آن ترتيبي که ارسال شده ، دريافت نشوند. بعنوان يک راهکار براي مقابله با اين مشکل مي توان از الگوريتم لمپارت استفاده کرد.
اتمام مهلت پاسخ يا تاخير در دريافت پاسخ مشکل ديگري است که مي تواند به خاطر سرعت پايين شبکه بوجود آيد.اگر نياز به مديريت قيق زمان باشد، مي توان با استفاده از مدير استثناء مثلا با استفاده ازبلاک Catch در BPEL چنين تا يرهايي را کشف و اصلاح کرد.
خطاي پاسخ ناظر بر حالتي است که سرويس حتي ليرغم دريافت ورودي صحيح ، نتايج اشتباهي را توليدمي کند.
شکل (۲)به تعبيري ديگر و با استفاده از تقسيم بندي متفاوتي بر اساس منشاخطا که سخت افزار، نرم افزار و يا در سطح برنامه کاربردي بوده به تشريح عکس العمل مناسب پرداخته است .
شکل ۲-راهکارهاي تحمل پذيري خطا در سرويس هاي وب [٢]
به راحتي مي توان دريافت که در اکثر راه حل ها استفاده از تنوع طراحي و افزونگي زماني پيشنهاد شده است . ما در معماري پيشنهادي خود پوشش مناسبي بر همه موارد ذکر شده بعنوان راه حل خرابي ارئه کرده ايم .
۳-بررسي تحقيقات مرتبط
دراين بخش به معرفي اجمالي معماري هايي که براي سرويس هاي وب اتکاپذير طراحي شده مي پردازيم .
۳-۱-استفاده از تکنيک برنامه نويسي چند نسخه اي
معماري نخست يکي از جامع ترين تحقيقاتي است که در اين مينه انجام گرفته .[٣,٦]
دراين معماري سرويس هاي وب بر روي ماشين هاي مختلف تکرار مي شوند؛بنابراين زماني که سرويس وب اصلي خراب مي شود، ديگران مي توانند جايگزين شده و سرويس مورد نظر را ارائه دهند.در حقيقت استفاده از مکانيسم تکرار، مدت زمان لازم براي بازيابي را کوتاه کرده و از آن جهت باعث افزايش قابليت دسترسي ي شود. عنصر اساسي موجود دراين سيستم مدير تکرار است که بعنوان هماهنگ کننده
سرويس هاي وب عمل مي کند. مدير تکرار مسئول موارد زير است :
انتخاب بهترين (سريعترين و ...) سرويس وب براي ارائه سرويس ، که سرويس وب اصلي ناميده خواهد شد،ثبت ايل WSDL متعلق به سرويس وب در UDDI،چک کردن در دسترس بودن سرويس وب اصلي و انتخاب سرويس جايگزين در صورت از کار افتادن سرويس وب اصلي به جهت بالا بردن تحمل پذيري خطا شکل (۳) عناصر معماري فوق را نشان مي دهد؛ سرويس هاي وب تکرار شده در اين روش ابن قابليت را دارند که يا به صورت سري و نوبت وار اجرا شوند و يا به صورت همزمان اجرا شده و از نتيجه نهايي آنها راي گيري به عمل آيد.
شکل ۳ –معماري يک سرويس وب اتکاپذير[٣]
۳-۲- استفاده از تکرار فعال
تعداد تحقيقاتي که از اين روش استفاده کرده اند قابل توجه است
[١٢ ,١١].بعنوان نمونه در مقاله اي که از تکرار فعال استفاده شده [٧]از يک ميان افزار براي حفظ سازگاري بين نسخه هايي که همزمان فعاليت مي کنند استفاده شده است . در اين ميان از يک بسته پياده سازي شده با جاوا براي ارتباط با ميان افزار استفاده شده که در هنگام ايجاد برنامه کاربردي طرف کلاينت از پيچيدگي هاي موجود خواهد کاست . در ادامه همين راهکار در مقاله ديگري [٨] ميان افزار کاملتري براي ارائه سرويس هاي وب به صورت اتکاپذير ارائه شده است . دراين مقاله براي حفظ سازگاري بين سرويس هاي وب تکرار شده از پروتکلي بر مبناي مهر زماني استفاده شده است . مزيت عمده اين ميان افزار آن است که در مقايسه با پروتکل هاي مشابه سربار ايجاد شده براي برنامه کاربردي کمتر خواهد بود.
۳-۳- استفاده از تکرار غيرفعال
در تحقيقات انجام گرفته کمتري به نسبت تکرار فعال از تکرار غير فعال استفاده شده است .در يکي از اين تحقيقات [١٠]براي دستيابي به تحمل پذيري خطا، تغييراتي در استانداردهاي WSDL و SOAP اعمال شده است تا امکان تعريف تکرارهاي
