بررسی معماری RPC و مبتنی بر پيام در رابطه با برنامه های توزيعی New Page 1



ساير




 

 

 

SAKHA RAVESH CO.

 ا مروز

 جمعه  6  مرداد  1396  2017  Jul.  28   Friday ToDay
صفحه اصلی  مقالات نکته هادايره المعارف خودآموزها | تازه ها خود آزمون ها    
  نسخه قابل چاپ  

    5 4 3 2 1 

 عنوان

 نويسنده

  مشاهده

 تعداد آراء

 امتياز

 مفاهيم اوليه سرويس های وب ( بخش دوم )

 مديريت وب

19894

77

4.4

با توجه به جایگاه داده در عصر حاضر و  لزوم نگاه جامع به این مقوله مهم ، بر آن شدیم تا محوریت فعالیت های خود را بر  روی این موضوع متمرکز نمائیم . از این رو گروه فابک با شعار فناوری اطلاعات برای کسب وکار شکل گرفت و  خدمات خود  را از طریق  سایت www.fabak.ir  به مخاطبان محترم عرضه می نماید

 

مفاهيم اوليه سرويس های وب - بخش دوم

مفاهيم اوليه سرويس های وب - بخش دوم

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

معماری مبتنی بر RPC  
معماری مبتنی بر RPC ،  اولين گزينه موجود بمنظور ارائه يک راه حل مناسب در ارتباط با  برنامه های توزيع شده است .

 RPC)Remote Procedure Call) ،  يک نوع فراخوانی به تابع و يا  روتپنی است که برروی يک سيستم از راه دور مستقر است .RPC ، مشابه فراخوانی يک روتين و يا يک تابع معمولی است که کدهای مربوط به فراخوانی تابع ، توسط کاربر بکار گرفته می شود . RPC ، دارای مشخصات زير است :

  • مشخص بودن  محل سرويس . برنامه نويس ، ضرورتی به آگاهی از محل فيزيکی ارائه دهنده سرويس نخواهد داشت .

  • يک مدل آشنا برای برنامه نويسان . اغلب برنامه نويسان نسبت به استفاده از اشکال خاصی از فراخوانی توابع، آشنا بوده و بدفعات در برنامه های خود اقدام به اين کار نموده اند . زير ساخت RPC ، يک Stub ايجاد که نمايانگر کد روتين از راه دور بوده و باعث فراخوانی تابع از راه دور بهمراه پارامترهای مربوطه از طريق شبکه و ارسال اطلاعات ذيربط برای سرويس دهنده RPC ، خواهد شد.بر روی سرويس دهنده RPC ، اطلاعات ارسالی (Stub) از حالت فشرده خارج ، و اطلاعات مربوطه ( آرگومان ها ) برای پردازش در اختيتار تابع صدازده شده ، قرار خواهند گرفت . نتايج مربوطه پس از فراخوانی تابع مربوطه و انجام عمليات ، برای صدا کننده تابع ، ارسال می گردد.

فراخوانی  همزمان توابع
در مدل RPC ، يک برنامه ارتباطی را با يک سرويس دهنده RPC برقرار می نمايد. فراخوانی توابع RPC ، شباهت بسياری به فراخوانی روتين های محلی دارد . سمنتيک بلاک های RPC ، مشابه آنهائی است که در فراخوانی روتين های محلی، مورد استفاده قرار می گيرد. اين حقيقت که سمنتيک بلاک ها مشابه است، بدين معنی است که فراخوانی ها بصورت همزمان می تواند صورت پذيرد. در اين حالت در مواقع ضروری بخشی از کدهای مربوط به اجرای روتين ، بلاک تا پس از برگرداندن مقدار توسط تابع مجددا" آزاد و امکان اجرای آنها فراهم گرد .بمنظور پياده سازی قابليت پردازش همزمان لازم است که با توجه به ماهيت کدهای موجود در يک روتين ، امکان اجراء يک نمونه از آنان را  در هر لحظه فراهم و پس از اطمينان از تکميل عمليات مربوطه ، بخش مربوطه آزاد تا زمينه اجرای ساير پردازه های در نوبت انتظار ، فراهم گردد. وضعيت فوق نظير تابع XOR است و شرط وجود يکی منوط به عدم وجود ديگری خواهد بود. برای اکثر پياده کنندگان نرم افزار ، مدل برنامه نويسی فوق مناسب و بکارگيری آن آسان خواهد بود  گرچه استقرار يک مدل همزمان در بالای معماری توزيع شده ، می تواند باعث بروز مسائلی خاص و از نگاهی ديگر گردد .

ايجاد افزونگی
اولين مسئله در ارتباط با معماری مبتنی بر RPC  ، به يافتن ( کشف ) اطلاعات بر می گردد. برنامه ها چگونه اطلاعات مورد نياز خود را  برای ارتباط با يک نقطه پايانی بمنظور دريافت سرويس مورد نظر، پيدا می نمايند.ساده ترين گزينه در اين راستا که توسط اکثر برنامه نويسان استفاده می گرد ، درج مستقيم (Hard code ) کدهای مربوط به نقطه پايانی ( نقطه تماس ) است . روش فوق مکانيزمی بهينه در اين رابطه نبوده و از يکطرف افزونگی اطلاعات را بدنبال داشته و از طرف ديگر امکان اشکال زدائی يک برنامه را با موانع جدی روبرو خواهد ساخت .

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

Load balancing  و بروز اشکال  
درج مستقيم کد نقاط پايانی در يک برنامه ، باعث بروز مسئله ديگری می گردد . در اين رابطه برنامه های مبتنی برRPC قادر به استفاده از روشی مناسب و ساده  بمنظور انجام  عمليات Load Balancing پويا ، نخواهند بود .در صورت بروز اشکالات پويا  و عدم دستيابی به سرويس دهنده ، برنامه مربوطه قادر به ارائه پاسخ شايسته نخواهد بود.

اولويت بندی
در معماری مبتنی برRPC ، ا ولويت بندی درخواست ها تقريبا" غير ممکن بوده و تمام درخواست ها بصورت پيش فرض با توجه به الگوريتم FCFS)First Come First Serve) ، پردازش خواهند شد.در چنين مواردی اگر سرويس دهنده ای دارای حجم  پردازش  بالا( لود بالا ) باشد ، سرويس گيرندگان با اولويت بالا  که نيازمند دريافت خدمات مربوطه از سرويس دهنده مربوطه می باشند ، گرفتار تاخير فراوان خواهند شد.

برخورد با مسائل غيرقابل پيش بينی
يکی ديگر از مسائل مرتبط با برنامه های مبتنی بر RPC ، عدم توانائی آنان بمنظور برخورد با مسائل غير قابل پيش بينی نظير موارد زير است :

  • قطع  موقت جريان برق سرويس دهنده بر اساس بروز اشکال در  سرويس دهنده
  • بروز اشکال در منابع مورد نياز برنامه نظير ارتباط با يک بانک اطلاعاتی
  • ضرورت استفاده از  سخت افزار اضافه بمنظور برخورد با مسائل غيرقابل پيش بينی

معماری مبتنی بر پيام
يکی ديگر از معماری های موجود  برای ايجاد برنامه های توزيع شده ، معماری مبتنی بر پيام است . رويکرد فوق،  به برنامه ها امکان ارتباط با  سرويس های  داخلی را بکمک  تکنولوژی صف بندی پيام ها ، خواهد داد . تکنولوژی صف بندی ، مسيريابی يک پيام را دنبال و ثبت می نمايد . تکنولوژی فوق ، سطح مناسبی از اطمينان بمنظور تشخيص سريع اشکال و در صورت صلاحديد اصلاحات لازم بدون دخالت کاربر  را فراهم می نمايد.   معماری مبتنی بر پيام، عموما" در کنار پروتکل های صف بندی  پيام ها نظير MSMQ)Microsoft Message Queuing) ايجاد می گردد.

پيام های غير همزمان
 مهمترين ويژگی  معماری مبتنی بر پيام ،  قابليت غير همزمانی آنان و ارسال پيام در مقابل فراخوانی تابع است . مزايای هر يک از موارد فوق بشرح زير است :

  • امکان مسير يابی پيام ها بر اساس لود و اولويت وجود خواهد داشت .
  • امکان استفاده بهينه از زمان برای سرويس گيرندگان در موارديکه در انتظار در اختيار گرفتن زمان مربوطه برای انجام عمليات می باشند،  فراهم می گردد.

ويژگی های فوق ،  خود می توانند باعث بروز مسائل ديگری گردند.

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

Interoperability  
اغلب  سيستم های مبتنی بر پيام با استفاده از محصولات خاص صف بندی پيام ،  پياده سازی می گردند . در اين رابطه لازم است برای پياده سازی سيستم هائی که می بايست با يکديگر تعامل اطلاعاتی بکمک پيام های مربوطه داشته باشند ،  تدابير خاصی انديشيده گردد . مثلا" تمامی سازمان ها ی سهيم در عمليات توزيع شده،   می بايست دارای  امکانات زير باشند :

  • نرم افزار صف بندی پيام ها
  • نرم افزارهای ارتباطی که بين محيط های متمايز و متفاوت پيام ،  قادر به ارائه توانائی خود باشد .

در صورت تامين ملزومات فوق و پس از پذيرش هزينه های اضافی ،  ممکن است نتايج مطلوب و مورد نظر کسب نگردد . راه حل های مبتنی بر پيام،  بعنوان روشی استاندارد بمنظور پياده سازی برنامه های توزيع شده  موفق عمل نمی نمايند.

اولويت نادرست پيام ها
در معماری مبتنی بر پيام ، پيام ها بصورت غير همزمان ارسال می گردند ،  بناراين ممکن است پيام ها با توجه به اولويت خود به مقصد نرسند .در صورتيکه پيام ها با يک اولويت نادرست پردازش گردند،  می تواند نتايج منفی را بدنبال داشته باشد .بدين ترتيب پياده کنندگان نرم افزار دارای مسئوليتی اضافه برای ايجاد يک لايه پروتکل سطح بالا بر روی پروتکل پيام ها ،  بمنظور  ثبت دنباله و اولويت پيام ها ،  خواهند بود .

در بخش سوم اين مقاله به بررسی استانداردهای وب و تاثير آنها در ارتباط با طراحی و پياده سازی برنامه های توزيع شده خواهيم پرداخت .



جستجو

مقالات                 
دايره المعارف       
دوره های آموزشی


 

 

مشاهده گروه ها



              

 

 تهيه شده در شرکت سخا روش -  1382