وبلاگ فرهاد مرتضی پور

Farhad Mortezapour's Blog

وبلاگ فرهاد مرتضی پور

Farhad Mortezapour's Blog

اصول پیاده سازی نرم افزارهای مبتنی بر وب

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

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

هدف ما رسیدن به نقطه ای است که مشخص نمائیم، برای طراحی و پیاده سازی نرم افزار بر روی بستر وب، اولا از چه نوع مدلی برای پیاده سازی استفاده می گردد و ثانیا روند توسعه و تکامل وب را با تاکید بر نیازهای نرم افراری از بعد ابزارشناسی دنبال کرده و از این رهگذر جایگاه هر ابزار (تکنولوژی) تبین شده تا بدین وسیله بتوانیم از هر چیز در جایگاه خود و در زمان مربوطه استفاده کنیم. بهرحال وب یک واقعیت انکار ناپذیر بوده و سایه حضور آن را در همه جا می توان احساس کرد. نرم افزار نیز مجری خواسته های انسانی در سرزمین سخت افزار است، این بار با یک چالش جدی مواجه شده است : پاسخگوئی به خیل نیازهای جدید مطرح شده متکی بر بستر وب.

در بخش اول این مقاله موضوع اول یعنی شناخت مدل های پیاده سازی نرم افزار تشریح خواهد شد. به این امید که از این رهگذر به نقطه ای برسیم که یک مدل مناسب جهت پیاده سازی برنامه های تحت وب را معرفی و آن را بعنوان پایه و اسا س کار خود قرار دهیم. در ابتدا لازم است به این اصل بدیهی اشاره شود که یک برنامه کامپیوتری حاصل ترکیب داده ها و منطق است. منطق یک برنامه از طریق کدهای مربوطه که به یکی از زبانهای برنامه نویسی نوشته خواهند شد، مسئول تحقق خواسته های تعریف شده برای یک نرم افزار از طریق انجام عملیات مورد نیاز بر روی داده ها است. داده ها خود می توانند به اشکال و روش های متنوعی سازماندهی و در اختیار یک نرم افزار قرار گیرند.Program = Logic(Code) + Data

مدل های پیاده سازی یک نرم افزار از ابتدا تاکنون متاثر از عوامل متفاوتی بوده است که جایگاه سخت افزارها بعنوان پتانسیل هائی که می بایست توان خود را در جهت بالفعل نمودن نرم افزارها قرار دهند، نقش برجسته ای دارد. مدل های پیاده سازی نرم افزار را می توان در پنج گروه عمده بشرح زیر تقسیم نمود:

MainFrame Architectureدر این مدل دو عنصر فیزیکی مورد اهتمام جدی بودند: کامپیوتر اصلی که با نام Host شناخته می شد و سخت افزارهای استفاده کننده از کامپیوتر اصلی که با نام ترمینال شناخته می شدند. تمامی منطق یک برنامه (Logic) بهمراه داده های مربوطه (Data) بر روی Host نصب می شد و کاربران با استفاده از ترمینال ها که بمنزله پایانه هائی جهت ورود و خروج ( نمایش ) اطلاعات بودند، قادر به ارتباط با سیستم و اجرای یک برنامه بودند. تمرکز منطق برنامه در یک محل (Host) از مهمترین ویژگی های این مدل است.

File Server Architectureاز این مرحله دو واژه معروف Server و Client پا به عرصه وجود گذاشتند. حیات و معنی این واژه ها محدود به سخت افرار بود و به مرزهای نرم افزار نرسیده بود. در این راستا کامپیوتری که برای دیگران سرویس هائی را ارائه می کرد با نام Server یا در این حالت خاص (File Server) و کامپیوترهائی که از این خدمات بهره مند می شدند را Client می گفتند. مدل فوق پاسخی اولیه به نیازهای کاربران یک شبکه کامپیوتری بود. در مدل فوق منطق یک برنامه بر روی یک Client نصب و داده ها بر روی Server قرار می گرفتند. دراین مدل داده ها در یک فایل ( با یک ساختار خاص) قرار گرفته و یک بانک اطلاعاتی را بوجود می آوردند و سرویس دهنده مسئول ارائه تسهیلاتی برای جابجائی و ارسال اطلاعات موجود در فایل ها بود. تمرکز منطق برنامه در یک محل ( Client ) از مهمترین ویژگی های این مدل است.

Client Server Architectureمدل فوق در پاسخ به اشکالات بوجود آمده در مدل قبل ارائه گردید. در مدل فوق کامپیوتر ارائه کننده خدمات را همچنان Server و کامپیوترهای استفاده کننده را Client می نامیدند. داده های یک برنامه (بانک های اطلاعاتی) همچنان بر روی سرویس دهنده قرار داشت ولی در رابطه با منطق برنامه اصل توزیع پردازش مورد توجه جدی قرار گرفت. بنابر اصل فوق بخشی از منطق یک برنامه را در حد امکان بر روی سرویس گیرنده اجرا و بخش دیگر از منطق برنامه بر روی سرویس دهنده اجرا می گردید. در مدل فوق برای اجرای یک برنامه دو پردازش جداگانه یکی بر روی سرویس دهنده و دیگری بر روی سرویس گیرنده فعال و هر یک نقشی در اجرای یک برنامه را برعهده می گرفت. مهمترین ویژگی مدل فوق مطرح کردن اصل پردازش توزیع شده است.

Two Tire Architectureدر مدل فوق اصل تقسیم وظیفه بصورت یک واقعیت انکار ناپذیر مورد توجه جدی قرار گرفت در این مدل همچنان کامپیوترهای سرویس دهنده و سرویس گیرنده جایگاه قبلی خود را داشتند با این تفاوت بسیار مهم که حوزه انجام هر عملیات ( منطق) تا اندازه ای شفاف تر گردید. مثلا جهت دستیابی به بانک های اطلاعاتی تمامی DataBase Engine بر روی سرویس گیرنده قرار می گرفت و سرویس گیرندگان جهت استفاده از داده های موجود در بانک اطلاعاتی نیازمند نصب امکانات نرم افزاری و آگاهی از ساختار بانک اطلاعاتی نبودند. از این مرحله واژه های سرویس گیرنده و سرویس دهنده پا به عرصه نرم افزار نیز گذاشتند و مفاهیمی نظیر سرویس دهنده بانک اطلاعاتی و رایج شد. مهمترین ویژگی مدل فوق تاکید بر اصل تقسیم فعالیت در چهارچوب ارائه طبقات (Tires) بود.

Three Tire Architectureدر مدل فوق اصل تفکیک مجموعه قوانین (سیاست های) مربوط به عملکرد یک نرم افزار مورد توجه جدی قرار گرفت. بدیهی است با حجیم شدن یک نرم افزار از یکطرف و افزایش تعداد کاربران از طرف دیگر و تغییرات متوالی در سیاست های راهبردی و عملیاتی یک نرم افزار در یک سازمان، مسائل مربوط به پشتیبانی و ارتقاء یک نرم افزار از مسائل بسیار مهم و حیاتی در موفقیت افزایش طول عمر یک نرم افزار محسوب می گردد.

در مدل فوق همچنان واژه های سرویس دهنده و سرویس گیرنده حضور مستمر خود را ادامه دادند با این تفاوت بسیار مهم که حوزه عملکرد این واژه ها در رابطه با نرم افزار بسیار برجسته گردید. در این مدل از سه لایه استفاده می گردد: لایه اول مسئول تماس و ارتباط با کاربر و ارائه دهنده محیط رابط کاربر، لایه دوم ( میانی ) مسئول نگهداری و اجرای سیاست ها و قوانین کلیدی و راهبردی حاکم بر نرم افزار و لایه سوم مسئولیت نگهداری بانک اطلاعاتی و ارائه سرویس و خدمات به لایه متقاضی ( لایه دوم ) است. عملکرد لایه دوم ( میانی ) بسیار گسترده بوده و می توان با همگرا نمودن این عملکردها به چند بخش، لایه های دیگری را نیز در این بخش داشته باشیم، در چنین حالتی این مدل اصطلاحا N-Tire نامیده می شود.

مدل فوق بهترین انتخاب برای پیاده سازی نرم افزار بر روی بستر وب است. کلید طلائی طراحی این نوع نرم افزارها توانائی نوشتن عناصر (اجزا) بگونه ای است که از یکطرف امکان بکارگیری آنها بسادگی در لایه ها و حتی چندین برنامه فراهم شده و از طرف دیگر امکان ارتباط این عناصر با یکدیگر صرفنظر از زبان برنامه نویسی استفاده شده و سایر موارد مرتبط فراهم گردد. ما می بایست جعبه های سیاهی را طراحی کنیم که صرفنظر از ماهیت درون هریک، قادر به استفاده از توان آنها در بخش یا بخش هائی از یک و یا چندین نرم افزار باشیم. مطلب فوق شاید مهمترین دلیل رویکرد شرکت های عظیم نرم افزاری جهت ارائه یک ساختار استاندارد برای تولید این عناصر باشد. تکنولوژی Component Object Model یا COM پاسخ شرکت مایکروسافت به این نیاز حیاتی بود.

تکنولوژی COMمهمترین ویژگی تکنولوژی فوق قابلیت استفاده مجدد و ارتباط متقابل برای عناصر( اشیاء) توزیع شده است. بدین ترتیب پیاده کنندگان نرم افزار این امکان را پیدا خواهند کرد تا با در کنار هم قرار دادن این عناصر و استفاده چندباره از آنان (حتی اگر تولیدکنندگان آنها متفاوت باشند) قادر به خلق آثار ماندگار خود در سریعترین زمان ممکن و متکی بر اصول مهندسی نرم افزار باشند.

ریشه COMتکنولوژی COM بصورت ناگهانی مطرح نگردید و ریشه در تلاش هائی دارد که از مدت ها قبل بعنوان یک نیاز مطرح شده بود. معرفی تکنولوژی Object Linking & Embedding یا OLE در سال 1991 اولین تلاش در این زمینه بود که توسط شرکت مایکروسافت برای ارتباط و پیوستگی بین مستندات در چهارچوب مجموعه برنامه های آفیس مطرح گردید. حوزه عملکرد تکنولوژی فوق بر روی مستندات (Documents) متمرکز بود. در ادامه شرکت مایکروسافت به این نکته پی برد که تکنولوژی فوق نباید صرفا متمرکز بر روی مستندات باشد و می تواند عملکردی جامع تر را تحت پوشش خود قرار دهد. بدین منظور نسخه شماره ۲، OLE در سال 1995 مطرح گردید و این نسخه در ادامه تمامی عناصر و اجزای موجود در محیط ویندوز را شامل گردید و بدین ترتیب COM مطرح شد.

در اوایل، تکنولوژی فوق در رابطه با عناصر و اجزای توزیع شده امکانات قابل توجه ای ارائه نکرده بود. شاید یکی از مهمترین دلایل آن عدم عرضه یک سیستم عامل شبکه ای از طرف مایکروسافت تا آن زمان بود. همزمان با عرضه ویندوز 95 و ویندوز NT در سال 1996 و مطرح شدن امکانات شبکه ای و ضرورت توزیع، اجرا و ارتباط بین عناصر توزیع شده تکنولوژی Distributed COM یا DCOM مطرح گردید. سرانجام در سال 1997 نسخه توسعه یافته این تکنولوژی با نام +COM توسط شرکت مایکروسافت ارائه گردید.

همزمان با گرایش بسمت طراحی و پیاده سازی نرم افزارهای متکی بر مدل Three Tire از یکطرف و نیاز شدید به پیاده سازی نرم افزار های متکی بر وب، ضرورت توجه و بازنگری در نحوه طراحی و پیاده سازی عناصر توزیع شده مورد اهتمام جدی شرکت های عظیم نرم افزاری قرار گرفت. شرکت مایکروسافت در این زمینه منادی تکنولوژی های COM/DCOM/COM+، Internet Explorer و ActiveX گردید. در مقابل شرکت های نرم افزاری دیگر، NetScape، Java/J2EE ( شرکت سان ) و CORBA را مطرح کردند.

اولین نسخه CORBA در سال 1992 توسط Object Management Group یا OMG که بالغ بر ششصد عضو دارد ارائه گردید. آخرین نسخه آن (نسخه شماره ۲) در سال 1996 عرضه شده است. عملکرد کلی تکنولوژی فوق نظیر COM است. بهرحال هدف اکثر تکنولوژی های فوق در این است که امکانات و استانداردهائی را برای تولید عناصر بگونه ای ارائه نمایند که با پیاده سازی آنها، قادر به اخذ سرویس و خدمات بصورت محلی و یا از را دور باشیم.

در این راستا شاید مناسب باشد که به عملکرد هر Tire در نرم افزارها از بعد سرویس دهی متمرکز شده و هر Tire را بعنوان مجموعه ای از سرویس ها در نظر بگیریم که مسئول ارائه سرویس به عناصر موجود در Tire خود و یا سایر Tire های مرتبط باشد. با این نگرش می توان گفت تمامی نرم افزارها خدمات و سرویس های خود را در سه بخش ارائه می نمایند:• User Sevices• Business Services• Data Services

در مدل Three Tire مسئولیت ارائه هر یک از سرویس های فوق به یک Tire واگذار می گردد. عناصر موجود و مسئول ارائه سرویس و خدمات در هر Tire قادر به ارتباط و درخواست سرویس از عناصر موجود در Tire خود و سایر Tire های موجود در بالا و یا پایین خود خواهند بود. نکته بسیار مهم در رابطه با وضعیت فوق این است که یک درخواست جهت اخذ سرویس نمی تواند یک Tire را حذف و خود مستقیما با Tire ثانویه ( بعدی) مرتبط و اصطلاحا یک Tire را دور بزند. مثلا عناصر موجود در لایه User Services نمی توانند مستقیما درخواست خود را برای لایه Data Services ارسال دارند. البته لایه فوق نیز چنین امکانی را نخواهد داشت. هر یک از سه بخش فوق مسئولیت های خاصی را برعهده گرفته و در زمانیکه یک بخش به خدمات یک بخش دیگر نیاز داشته باشد، درخواست خود را برای اخذ سرویس در اختیار بخش مورد نظر قرارداده و بخش مربوطه سرویس درخواستی را در قالب اجرای یک یا چندین عنصر انجام و ماحصل را در اختیار بخش مربوطه قرار خواهد داد.

مدل فوق که بر اساس همگرائی نوع سرویس ها و خدمات در یک نرم افزار ارائه شده است، صرفا یک مدل منطقی است و نشاندهنده یک مدل فیزیکی نیست. دراین راستا چهار مدل فیزیکی برای پیاده سازی نرم افزارهای Three Tire ارائه شده است:• Single Server• Business Server• Transaction Server• Web Server

Single Serverدر این مدل محل استقرار تمامی عناصر بین سرویس گیرنده و سرویس دهنده شبکه تقسیم می گردد. در مدل فوق تمامی عناصر مربوط به بانک های اطلاعاتی (Data Services) بر روی سرویس دهنده قرار می گیرد. عناصر مربوط به User Service در صورتیکه بگونه ای طراحی شده اند که ممکن است مورد استفاده چندین نرم افزار دیگر قرار بگیرند، می بایست آنها را بر روی سرویس دهنده شبکه نصب نمود. عناصر مربوط به Business Services که مسئولیت پیاده سازی سیاست ها و قوانین در یک نرم افزار را برعهده دارند، عمدتا بر روی سرویس دهنده شبکه نصب می گردنند مگر اینکه در رابطه با یک نرم افزار، اعمال یک سیاست بخصوص را می بایست در سطح لایه User Services پیاده سازی نمود ( بررسی صحت داده های ورودی، انجام برخی محاسبات خودکار با توجه به رفتار داده ها و ). در این حالت عنصر مجری سیاست فوق می بایست در لایه User Services و بصورت محلی و مختص به آن نصب و فعال گردد.

Bussines Server (Application)در مدل فوق یک سرویس دهنده اضافی با نام Application Server، استفاده می گردد. سرویس دهنده فوق مسئولیت استقرار تمامی عناصری را که می بایست به اشتراک گذاشته شوند، بر عهده خواهد گرفت. در این راستا در صورتیکه برخی از عناصر مربوط به لایه User Service باشند ولی بصورت مشترک مورد استفاده چندین نرم افزار قرار می گیرند نیز از این قاعده مستثنی نبوده و بهترین محل برای استقرار آنان، سرویس دهنده Application است. در مدل فوق تمامی عناصر مربوط به Data service بر روی سرویس دهنده Data قرار خواهند گرفت. ارتباط تمامی سرویس گیرندگان در ابتدا با Application Server آغاز خواهد گشت. سرویس گیرندگان خواسته خود را به لایه Application ارسال و لایه فوق مسئولیت ارتباط با لایه Data را بر عهده خواهد گرفت.

Transaction ServerTransaction واحد انجام یک فعالیت بوده که خود می تواند شامل چندین عملیات دیگر باشد. سلسله عملیات فوق می بایست تماما با موفقیت اجرا گردند. در مدل فوق سرویس دهنده Transaction مسئولیت مدیریت و ذخیره سازی عناصر لازم برای یک فعالیت Transaction را برعهده خواهد گرفت. در این مدل می توان از چندین سرویس دهنده دیگر بمنظور استقرار عناصر مربوطه استفاده کرد. استقرار عناصر بر روی سرویس دهنده ها می بایست پویا بوده و در صورت افزایش ترافیک، امکان جابجائی آنها بر روی سایر سرویس دهنده ها وجود داشته باشد. سرویس دهنده Transaction مسئولیت های نگهداری عناصر ActiveX، ارسال درخواست یک برنامه به یکی از سرویس دهنده ها، اتمام اجرای یک برنامه، بررسی صحت عملکرد یک عنصر را بر عهده خواهد گرفت.

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

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

بهرحال مدل فوق یک ایده جدید برای اجرای یک برنامه را مطرح کرده است. سرویس دهنده وب بسادگی و بصورت اتوماتیک قادر به نصب اجزای مورد نیاز یک سرویس گیرنده خواهد بود. بدین ترتیب از یکطرف ضرورت استقرار تمامی عناصر بر روی سرویس گیرنده از بین رفته و از طرف دیگر به سرویس گیرنده ها استقلال لازم داده شده و در صورت ضرورت می توان آنها را نیز در اجرای برخی از عناصر سهیم کرد.
نظرات 0 + ارسال نظر
برای نمایش آواتار خود در این وبلاگ در سایت Gravatar.com ثبت نام کنید. (راهنما)
ایمیل شما بعد از ثبت نمایش داده نخواهد شد