سرویس های وب ، نقطه عطفی در معماری برنامه های توزیع شده بر روی اینترنت می باشند . بدون شک، یکی از مهمترین تحولات در زمینه برنامه های توزیع شده ، مطرح شدن سرویس های وب است که تاثیرات فراوانی را در رابطه با وضعیت نرم افرار خصوصا" بر روی اینترنت بدنبال خواهد داشت . ما شاهد نقطه عطفی در ظهور نسل جدیدی از برنامه های کامپیوترهای با قابلیت استفاده بر روی بستر وب ، خواهیم بود که گفتمان برنامه ها در عرصه جهانی را محقق خواهد کرد ( تحقق آرزوئی بزرگ برای صنعت نرم افزار) .
در مجموعه مقالاتی که بدین منظور نوشته خواهد شد به بررسی اصولی سرویس های وب و جایگاه آنان در فرآیند طراحی و پیاده سازی برنامه های توزیع شده پرداخته می گردد . در این راستا لازم است در ابتدا به مقاهیم اولیه برنامه های توزیع شده ، تکامل تدریجی برنامه های توزیع شده ، محدودیت های موجود در رابطه با معماری برنامه های توزیع شده ، رویکردهای متفاوت بمنظور طراحی و پیاده سازی برنامه های توزیع شده ، پرداخته گردد تا زمینه علمی مناسب، برای پرداختن به مفاهیم اولیه سرویس های وب فراهم گردد .
مقدمه
قبل از ابداع کامپیوترهای شخصی، عملا" برنامه های توزیع شده ای وجود نداشته است . در آن دوران ، استفاده از کامپیوتر، شامل نشستن پشت یک ترمینال و برقراری ارتباط با یک سیتستم بزرگ (Mainframe) بود. با اینکه ترمینال ها در چندین ساختمان و یا حتی محل فیزیکی قرار می گرفتند ، ولی عملا" یک کامپیوتر مرکزی وجود داشت که مسئولیت انجام تمامی پردازش ها و ذخیره سازی داده ها را برعهده می گرفت .
تعریف برنامه توزیع شده
با ابداع مینی کامپیوترها و کامپیوترهای شخصی، فعالیت های غیرمتمرکز، در دو زمینه پردازش و ذخیره سازی ، آرزوئی دست یافتنی گردید. با طراحی برنامه های توزیع شده ، امکان پردازش و ذخیره سازی داده ها از حالت متمرکز خارج گردید.یک برنامه توزیع شده، برنامه ای است که پتانسیل های پردازشی آن ممکن است توسط چندین کامپیوتر فیزیکی تامین و داده های آن در چندین محل فیزیکی، مستقر شده باشد .
چرا به برنامه های توزیع شده نیاز داریم ؟
در این رابطه دلایل متعددی عنوان می شود که مهمترین آنان عبارتند از :
هزینه سیستم های Mainfarme . یکی از اولین دلایل مهم ، هزینه های بالای سیستم های Mainframe است . این مسئله از دو زاویه متفاوت قابل بررسی است : هزینه بالای سرمایه گذاری اولیه که بسیاری از سازمان ها و موسسات توان مالی آن را ندارند و دوم اینکه در این مدل ، دارای صرفا" یک نقطه آسیب پذیر با ریسک بالا می باشیم .
مالکیت اختصاصی داده ها. یکی از فاکتورهای مهم دیگر، سیاست های مربوط به مالکیت داده ها است . سازمان ها و موسسات که دارای داده های اختصاصی خود می باشند، علاقه مند به واگذاری مسئولیت مدیریت داده های مربوطه ، به سایر مکان های فیزیکی نمی باشند .
امنیت . یکی دیگر از فاکتورهای مهم در این زمینه موضوع امنیت است . برای یک سازمان ، اولا" دستیابی به اغلب داده های آن می بایست بسادگی محقق گردد و ثانیا" داده ها ی حساس موجود در سازمان می بایست از بعد امنیتی، ایمن نگهداری گردند . تامین دو خواسته فوق ( رویکردهای رقابتی و رویکردهای امنیتی ) با جدا سازی فیزیکی داده ا از یکدیگر محقق خواهد شد ( انباشت داده ها، با نگرش های متفاوت در رابطه با سرعت در دستیابی و ایمن در ذخیره سازی ، ضرورت وجود برنامه های توزیع شده را بخوبی نمایان می سازد )
مسائل فوق، ضرورت حرکت بسمت ایجاد یک الگوی جدید بمنظور طراحی برنامه های کامپیوتری را مطرح و بر همین اساس نسل جدیدی از برنامه های کامپیوتری با عنوان " برنامه های توزیع شده" در عرصه نرم افزار بوجود آمد .
برنامه های توزیع شده و ارائه دهندگان سرویس
با توجه به ضرورت و تعجیل در طراحی یک الگوی جدید برای برنامه های توزیع شده و عدم وجود استانداردهای صنعتی لازم در این خصوص ، شرکت های عظیم نرم افزاری هر یک با توجه به دیدگاه های خود ، اقدام به عرضه راهکارهائی در این زمینه نمودند.شرکت های فوق، در رابطه با اینکه می بایست برنامه های توزیع شده بصورت عناصر توزیع شده ، تولید گردند ، اتحاد نظر داشتند . بدین ترتیب عناصر متفاوت و توزیع شده در یک برنامه، بعنوان ارائه دهندگان سرویس به یک برنامه منطقی ایفای وظیفه می نمایند. با توزیع قابلیت ها و پتانسیل ها ، امکانات اساسی( بلاک های اولیه ) بمنظور ایجاد برنامه های بزرگ، بسادگی فراهم می گردد . رویکرد فوق ، مسائل و تبعات خاص خود را بدنبال داشت که در ادامه به بررسی برخی از آنان خواهیم پرداخت .
برنامه های توزیع شده و وب
با اینکه اینترنت بیش از بیست سال است بوجود آمده است ولی صرفا" در اواسط دهه 1990 به این موضوع توجه گردید، که اینترنت زیر ساخت مناسب و مهمی برای ایجاد برنامه های توزیع شده است . پروتکل های ساده مبتنی بر متن در ابتدا بمنظور مبادله سرویس های درخواستی و ارسال اطلاعات بر روی اینترنت پیاده سازی گردید . گسترش و پذیرش چنین پروتکل هائی، باعث شد که اینترنت بعنوان یک محیط موفق برای برنامه های توزیع شده، مطرح گردد. بدین ترتیب در مقابل سروکار داشتن با تکنولوژی های رقابتی و اغلب انحصاری، وجود استانداردهای وب ، دلیلی موجه برای توجه جدی به وب بعنوان بستری مناسب برای طراحی و پیاده سازی برنامه های توزیع شده، گردید.
مسائل مربوط به برنامه های توزیع شده سنتی
پیاده سازی برنامه های توزیع شده مستلزم استفاده از تکنیک ها و مدل های جدید است . راهکارهای انتخابی و استفاده شده ، خود باعث بروز مسائل جدید نیز خواهند شد. در این بخش به بررسی مسائل مرتبط با طراحی برنامه های توزیع شده پرداخته و دو معماری خاص در این زمینه را بررسی خواهیم کرد :
معماری RPC)Remote Procedure Call-based)
معماری مبتنی بر پیام (Message-based)
ملاحظات مربوط به طراحی برنامه های توزیع شده
در زمان طراحی برنامه های توزیع شده مسائل متعددی وجود دارد که می بایست به آنها توجه کرد :
نوع داده های متفاوت . سیستم های عامل متفاوت، انواع مختلفی از نوع داده ها را حمایت می نمایند. در برخی موارد ، نوع داده ها در سیستم های عامل متفاوت کاملا" با یکدیگر سازگار، نمی باشند . بنابراین می بایست از راهکارهای مناسب بمنظور برخورد منطقی با نوع داده های متفاوت موجود در سیستم های مختلف ، استفاده گردد.
بروز اشکال در سرویس دهنده . با توجه به اینکه عناصر یک سیستم توزیعی، عموما" بصورت از راه دور اجراء می گردند، ما دارای چندین نقطه ( مکان) برای بروز اشکال خواهیم بود. بروز اشکال در یکی از نقاط ، می تواند باعث بروز مسائل عمده ای در رابطه با عملکرد تمام برنامه توزیع شده گردد. بنابراین می بایست راهکارهای مناسب در خصوص مواجه شدن با چنین مواردی، اتخاذ گردد .
بروز اشکال در سرویس گیرنده . در صورتیکه سرویس دهنده ای وضعیت خاصی را ازطرف سرویس گیرنده ، اخذ و ذخیره می نماید و سرویس گیرنده با اشکال مواجه گردد، می بایست از روشی بمنظور اعلام بروز اشکال به سرویس دهنده استفاده کرد. تصمیم گیری و نحوه برخورد با منابع در اختیار سرویس گیرنده نیز از جمله مواردی است که می بایست راهکارهای آن بدرستی مشخص گردد.
تلاش برای فراخوانی مجدد . در صورتیکه یک متد از راه دور فراخوانده شود و از طرف سرویس دهنده واکنش لازم داده نشود، نباید تلاش مجددی برای فراخوانی متد صورت پذیرد. مثلا" در صورتیکه متدی برای محاسبه هزینه یک سفارش فراخوانده شده و سرویس دهنده درخواستی را دریافت تا سفارش را انجام ولی پاسخ گم گردد منطقی نخواهد بود سفارش مربوطه مجددا" ارسال گردد .
امنیت . در برنامه های توزیع شده فرصت های زیادی برای تهدید های امنیتی وجود دارد . در این راستا لازم است از یکطرف به مسائل تائید اعتبار و صلاحیت قانونی و از طرف دیگر به ایمن سازی ارتباطات بین یک سرویس گیرنده و یک سرویس دهنده ، توجه جدی صورت پذیرد . حفاظت در مقابل انواع حملات اطلاعاتی از چالش های مهم در زمینه ایمن سازی برنامه های توزیع شده است .
یکسان سازی زمان (Clock) . عملیات و فرآیندهای متعددی در برنامه های توزیع شده به پارامتر زمان ارتباط خواهد داشت .. مثلا" در یک سیستم سفارشات تا تکلیف وضعیت نحوه پرداخت، مشخص نگردد نمی توان اقدام به پردازش و ثبت سفارش مربوطه نمود. بنابراین می بایست در رابطه با نحوه همسان سازی کلاک(Clock) کامپیوترهای متفاوت که در یک برنامه توزیع شده با یکدیگر ارتباط دارند، تصمیم لازم اتخاذ گردد .
بخش های دیگر مقاله :
بخش دوم : بررسی دو نمونه معماری در رابطه با برنامه های توزیع شده
بخش سوم : تاثیر استانداردهای وب در فرآیند طراحی و پیاده سازی برنامه های توزیع شده
بخش چهارم : مفاهیم اولیه سرویس های وب
مفاهیم اولیه سرویس های وب - بخش دوم
در بخش اول این مقاله ، به مفاهیم اولیه دررابطه با برنامه های توزیع شده و چالش های مربوطه اشاره گردید . در این بخش به بررسی اجمالی دو نمونه از راهکارهای ارائه شده در رابطه با برنامه های توزیع شده یعنی معماری RPC و مبتنی بر پیام، خواهیم پرداخت .
معماری مبتنی بر RPC
معماری مبتنی بر RPC ، اولین گزینه موجود بمنظور ارائه یک راه حل مناسب در ارتباط با برنامه های توزیع شده است .
RPC)Remote Procedure Call) ، یک نوع فراخوانی به تابع و یا روتپنی است که برروی یک سیستم از راه دور مستقر است .RPC ، مشابه فراخوانی یک روتین و یا یک تابع معمولی است که کدهای مربوط به فراخوانی تابع ، توسط کاربر بکار گرفته می شود . RPC ، دارای مشخصات زیر است :
مشخص بودن محل سرویس . برنامه نویس ، ضرورتی به آگاهی از محل فیزیکی ارائه دهنده سرویس نخواهد داشت .
یک مدل آشنا برای برنامه نویسان . اغلب برنامه نویسان نسبت به استفاده از اشکال خاصی از فراخوانی توابع، آشنا بوده و بدفعات در برنامه های خود اقدام به این کار نموده اند . زیر ساخت RPC ، یک Stub ایجاد که نمایانگر کد روتین از راه دور بوده و باعث فراخوانی تابع از راه دور بهمراه پارامترهای مربوطه از طریق شبکه و ارسال اطلاعات ذیربط برای سرویس دهنده RPC ، خواهد شد.بر روی سرویس دهنده RPC ، اطلاعات ارسالی (Stub) از حالت فشرده خارج ، و اطلاعات مربوطه ( آرگومان ها ) برای پردازش در اختیتار تابع صدازده شده ، قرار خواهند گرفت . نتایج مربوطه پس از فراخوانی تابع مربوطه و انجام عملیات ، برای صدا کننده تابع ، ارسال می گردد.
فراخوانی همزمان توابع
در مدل RPC ، یک برنامه ارتباطی را با یک سرویس دهنده RPC برقرار می نماید. فراخوانی توابع RPC ، شباهت بسیاری به فراخوانی روتین های محلی دارد . سمنتیک بلاک های RPC ، مشابه آنهائی است که در فراخوانی روتین های محلی، مورد استفاده قرار می گیرد. این حقیقت که سمنتیک بلاک ها مشابه است، بدین معنی است که فراخوانی ها بصورت همزمان می تواند صورت پذیرد. در این حالت در مواقع ضروری بخشی از کدهای مربوط به اجرای روتین ، بلاک تا پس از برگرداندن مقدار توسط تابع مجددا" آزاد و امکان اجرای آنها فراهم گرد .بمنظور پیاده سازی قابلیت پردازش همزمان لازم است که با توجه به ماهیت کدهای موجود در یک روتین ، امکان اجراء یک نمونه از آنان را در هر لحظه فراهم و پس از اطمینان از تکمیل عملیات مربوطه ، بخش مربوطه آزاد تا زمینه اجرای سایر پردازه های در نوبت انتظار ، فراهم گردد. وضعیت فوق نظیر تابع XOR است و شرط وجود یکی منوط به عدم وجود دیگری خواهد بود. برای اکثر پیاده کنندگان نرم افزار ، مدل برنامه نویسی فوق مناسب و بکارگیری آن آسان خواهد بود گرچه استقرار یک مدل همزمان در بالای معماری توزیع شده ، می تواند باعث بروز مسائلی خاص و از نگاهی دیگر گردد .
ایجاد افزونگی
اولین مسئله در ارتباط با معماری مبتنی بر RPC ، به یافتن ( کشف ) اطلاعات بر می گردد. برنامه ها چگونه اطلاعات مورد نیاز خود را برای ارتباط با یک نقطه پایانی بمنظور دریافت سرویس مورد نظر، پیدا می نمایند.ساده ترین گزینه در این راستا که توسط اکثر برنامه نویسان استفاده می گرد ، درج مستقیم (Hard code ) کدهای مربوط به نقطه پایانی ( نقطه تماس ) است . روش فوق مکانیزمی بهینه در این رابطه نبوده و از یکطرف افزونگی اطلاعات را بدنبال داشته و از طرف دیگر امکان اشکال زدائی یک برنامه را با موانع جدی روبرو خواهد ساخت .
تجمع دردستیابی
زمانیکه برنامه ای با چندین سرویس توزیع شده ارتباط برقرار می نماید نسبت به برنامه دیگر که صرفا" با یک سرویس توزیع شده مرتبط می گردد ، دارای استعداد بیشتر، بمنظور پذیرش اشکالات خصوصا" در مواردیکه سرویس ها در دسترس نمی باشند ، خواهد بود. تجمع و انباشت در دستیابی یک برنامه توزیع شده ، مستقیما" تاثیر منفی خود را از نحوه پیاده سازی برنامه ها اخذ می نماید.