جمعه, ۵ بهمن, ۱۴۰۳ / 24 January, 2025
مجله ویستا

معماری سرویس گرا در تولید نرم افزار


معماری سرویس گرا در تولید نرم افزار

معماری سرویس گرا به عنوان یكی از آخرین دستآوردها در تولید نرم افزار, به نظر می رسد, در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد علت بوجود آمدن این معماری, ایده ای بود كه در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود در مدل نرم افزار به عنوان سرویس شما نرم افزار خود را بگونه ای طراحی می كنید كه قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام كنند و هر موقع كه لازم داشتند از خدمات آن بهره ببرند, همانند حالتی كه در مورد شبكه های تلویزیون كابلی وجود دارد

در این مقاله به بررسی معماری سرویس گرا در تولید نرم افزار، به عنوان یكی از آخرین دستاوردهای صنعت مهندسی نرم افزار، پرداخته می شود.

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

این معماری توسط دو شركت IBM, Microsoft بوجود آمد، كه هر دو شركت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند UDDI ,WSE بوده اند. قابل ذكر است، كه در آخرین معماری در حال توسعه، در تولید نرم افزار كه هنوز هم در مرحله تحقیقاتی است ( MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است. از نمونه های استفاده از این معماری در كشور خودمان، سازمان ثبت احوال كشور است كه موظف شده تا پایگاه های اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد. معماری سرویس گرا چیست؟ همان طور كه در عنوان آن مشخص است، به مفهومی در سطح معماری، اشاره می كند و بنابراین در مورد چیزی پایه ای و اساسی در سطوح بالا است، كه پایه و اساس آن تجربیات بدست آمده در تولید سیستم های نرم افزاری مبتنی بر CBD و دو اصل اساسی در صنعت مهندسی نرم افزار یعنی تولید نرم افزار بصورت با همبستگی زیاد و در عین حال با چسبندگی كم است. بنابراین ایده های برنامه نویسی سرویس گرا ایده ای جدید نیست و شما شاید قبلا از آن استفاده كرده باشید.

اما جمع آوری بهترین تجربیات از تولید چنین سیستمهایی بصورت مجتمع و ناظر به وضعیت تكنولوژیكی امروز بشر، كه همان مفاهیم مطرح شده در معماری سرویس گرا است چیز جدیدی است. در زیر بصورت دقیق تر این بحث را ادامه می دهیم آیا تولید سیستم های سرویس گرا مفهوم جدیدی است؟ مهندسان نرم افزار، همیشه می گفتند و گفته اند كه نرم افزار باید به شكلی نوشته شود كه همبستگی زیاد ولی در عین حال اتصال كمی داشته باشد. شركتهای بزرگ نرم افزاری هم در جهت گام برداشتن برای رسیدن به این دو اصل، تكنولوژی هایی را بوجود آوردند كه به برنامه نویسان اجازه دهد تا به این دو هدف در تولید نرم افزارهای خود تا حد زیادی دست یابند. برای مثال می توان به تكنولوژی هایی مانند COM+ , CORBA و RMI و موارد دیگر، اشاره كرد. خوب پس مشاده كردید كه موضوع برنامه نویسی سرویس گرا، مفهموم جدیدی نیست و این معماری تلاشی دیگر در جهت تولید نرم افزارهای با همبستگی زیاد و در عین حال با چسبندگی و اتصال كم است. ممكن است بپرسید، پس چرا با وجود تكنولوژی های قدرتمندی چون CORBA,COM+,RMI چیز جدیدی بوجود آمد؟ مگر تكنولوژی های قبلی موفق نبودند؟ بله مهمترین اشكال در معماری های قدرتمندی چون موارد مذكور این بود كه تولید كنندگان آنها سعی داشتند، كه تكنولوژی خود را بر بازار غالب نمایند. رویایی كه هرگز به حقیقت نمی پیوست. بنابراین با توجه به این موضوع كه این تكنولوژیها قادر به تعامل مناسب با یكدیگر نبودند عملا اصل همبستگی زیاد بصورت خود بخود رد می شد.

البته معماری های مذكور اشكالات دیگری هم داشتند كه نسبت به مورد بالا از اهمیت كمتری برخوردار است كه از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره كرد. البته بعدها راه حل هایی هم برای این مشكل بوجود آمد (مانند RPC Over HTTP) اما به این علت كه از روز اول، در طراحی این تكنولوژی ها این امر در نظر گرفته نشده بود، از كارایی مناسبی برخوردار نبودند. مفهموم همبستگی زیاد و در عین حال با چسبندگی و اتصال كم، وقتی بخواهد در جهت ارزیابی یك سیستم نرم افزاری یا تكنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی كسی می تواند ایده های همبستگی و چسبندگی را باهم تركیب كند!. برای جلوگیری از چنین ابهاماتی، شما می تواند از ویژگی های معماری سرویس گرا به عنوان یك راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یك سیستم نرم افزاری یا یك تكنولوژی استفاده كنید. اگرچه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی كم نیستند، اما سیستمهایی كه بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند كه توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی كم را بخوبی در خود ایجاد و حفظ كنند.

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

سرویسهای وب به عنوان پایه معماری سرویس گرا: سیر تكامل و رشد XML، با پیدایش سرویس های وب همراه بود. یك سرویس وب بهترین راه حل برای پیاده سازی معماری سرویس گرا است، مخصوصا وقتی دیدگاه استفاده از كل كاربران اینترنت به عنوان كاربران بالقوه سرویس مطرح باشد. شما پایه كار خود را بر پروتكل HTTP بنا می نهید، پروتكلی كه از همه پروتكل های دیگر روی اینترنت قابل دسترس تر است. با نگاه به قابلتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا، شما متوجه خواهید شد كه سرویس های وب بسیاری از موارد مطرح شده در بالا را رعایت می كنند اما تعدادی از اصول مطرح شده را هم زیر پا می گذارند كه آن را بررسی می كنیم: - كارایی: XML كه عنصر اصلی سازنده سرویسهای وب است، نسبت به سایر مكانیزم های انتقال اطلاعات (binary) از سربار بسیآر زیادی برخودار است. - قابلیت اطمینان در تراكنش ها: اگر شما در یك تراكنش از یك سرویس وب استفاده كنید، چگونه می توانید صحت تراكنش را تضمین كنید در حالی كه تمام كارهای شما مبتنی بر اینترنت و پروتكل HTTP است؟ - امنیت: شما چگونه می توانید كاربران سرویس خود را تصدیق هویت كنید تا بعد از آن بتواند صلاحیت آنها را در استفاده از سرویس تان مورد بررسی قرار دهید؟ همچنین یك نكته منفی دیگر در مورد سرویس های وب در حال حاضر، عدم پشتیبانی اكثر محیط های تولید نرم افزار (IDE) برای تولید و استفاده از آنها است و در عین حال فراهم كردن قابلتهایی مانند كمك به برنامه نویس در استفاده از متدها و غیره یا پیدا كردن خطاها در زمان كامپایل و نه زمان اجرا. بنابراین، مگر اینكه موارد فوق به نحوی حل نگردد، ممكن است استفاده از سرویس های وب به عنوان پایه معماری سرویس گرا مورد سوال قرار گیرد.


شما در حال مطالعه صفحه 1 از یک مقاله 2 صفحه ای هستید. لطفا صفحات دیگر این مقاله را نیز مطالعه فرمایید.