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

در این مقاله به بررسی معماری سرویس گرا در تولید نرم افزار، به عنوان یكی از آخرین دستاوردهای صنعت مهندسی نرم افزار، پرداخته می شود.
معماری سرویس گرا به عنوان یكی از آخرین دستآوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود كه در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس شما نرم افزار خود را بگونه ای طراحی می كنید كه قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام كنند و هر موقع كه لازم داشتند از خدمات آن بهره ببرند، همانند حالتی كه در مورد شبكه های تلویزیون كابلی وجود دارد. تا زمانی كه شما به سرویس متصل هستید، شما می توانید هر لحظه كه خواستید از سرویس استفاده كنید. برای مدتهای طولانی برنامه نویسان سعی می كردند تا، كدهای خود را بصورت modular بنویسند، تا بتوان از آن در تولید نرم افزارهای دیگر استفاده كرد. تفاوت نوشتن كد بصورت modular و بر اساس معماری سرویس گرا در حجم مخاطبان آن است. دوباره به همان مثال اول برمی گریم، وقتی شما كد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شكل modular می نویسید مانند این است كه، یك شبكه تلویزیون كابلی درون یك ساختمان خاص دارید و بنابراین فقط ساكنین آن ساختمان می توانند از آن بهره برداری كنند. در جهان امروز طیف مخاطبانی كه بالقوه می توانند از سرویس شما استفاده كنند، كل كاربران روی شبكه اینترنت است. بنابراین باید مكانیزمی بوجود می آمد، كه می توانست پاسخگوی این محیط جدید (اینترنت) و كاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد.
این معماری توسط دو شركت IBM, Microsoft بوجود آمد، كه هر دو شركت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند UDDI ,WSE بوده اند. قابل ذكر است، كه در آخرین معماری در حال توسعه، در تولید نرم افزار كه هنوز هم در مرحله تحقیقاتی است ( MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است. از نمونه های استفاده از این معماری در كشور خودمان، سازمان ثبت احوال كشور است كه موظف شده تا پایگاه های اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد. معماری سرویس گرا چیست؟ همان طور كه در عنوان آن مشخص است، به مفهومی در سطح معماری، اشاره می كند و بنابراین در مورد چیزی پایه ای و اساسی در سطوح بالا است، كه پایه و اساس آن تجربیات بدست آمده در تولید سیستم های نرم افزاری مبتنی بر CBD و دو اصل اساسی در صنعت مهندسی نرم افزار یعنی تولید نرم افزار بصورت با همبستگی زیاد و در عین حال با چسبندگی كم است. بنابراین ایده های برنامه نویسی سرویس گرا ایده ای جدید نیست و شما شاید قبلا از آن استفاده كرده باشید.
اما جمع آوری بهترین تجربیات از تولید چنین سیستمهایی بصورت مجتمع و ناظر به وضعیت تكنولوژیكی امروز بشر، كه همان مفاهیم مطرح شده در معماری سرویس گرا است چیز جدیدی است. در زیر بصورت دقیق تر این بحث را ادامه می دهیم آیا تولید سیستم های سرویس گرا مفهوم جدیدی است؟ مهندسان نرم افزار، همیشه می گفتند و گفته اند كه نرم افزار باید به شكلی نوشته شود كه همبستگی زیاد ولی در عین حال اتصال كمی داشته باشد. شركتهای بزرگ نرم افزاری هم در جهت گام برداشتن برای رسیدن به این دو اصل، تكنولوژی هایی را بوجود آوردند كه به برنامه نویسان اجازه دهد تا به این دو هدف در تولید نرم افزارهای خود تا حد زیادی دست یابند. برای مثال می توان به تكنولوژی هایی مانند COM+ , CORBA و RMI و موارد دیگر، اشاره كرد. خوب پس مشاده كردید كه موضوع برنامه نویسی سرویس گرا، مفهموم جدیدی نیست و این معماری تلاشی دیگر در جهت تولید نرم افزارهای با همبستگی زیاد و در عین حال با چسبندگی و اتصال كم است. ممكن است بپرسید، پس چرا با وجود تكنولوژی های قدرتمندی چون CORBA,COM+,RMI چیز جدیدی بوجود آمد؟ مگر تكنولوژی های قبلی موفق نبودند؟ بله مهمترین اشكال در معماری های قدرتمندی چون موارد مذكور این بود كه تولید كنندگان آنها سعی داشتند، كه تكنولوژی خود را بر بازار غالب نمایند. رویایی كه هرگز به حقیقت نمی پیوست. بنابراین با توجه به این موضوع كه این تكنولوژیها قادر به تعامل مناسب با یكدیگر نبودند عملا اصل همبستگی زیاد بصورت خود بخود رد می شد.
البته معماری های مذكور اشكالات دیگری هم داشتند كه نسبت به مورد بالا از اهمیت كمتری برخوردار است كه از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره كرد. البته بعدها راه حل هایی هم برای این مشكل بوجود آمد (مانند RPC Over HTTP) اما به این علت كه از روز اول، در طراحی این تكنولوژی ها این امر در نظر گرفته نشده بود، از كارایی مناسبی برخوردار نبودند. مفهموم همبستگی زیاد و در عین حال با چسبندگی و اتصال كم، وقتی بخواهد در جهت ارزیابی یك سیستم نرم افزاری یا تكنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی كسی می تواند ایده های همبستگی و چسبندگی را باهم تركیب كند!. برای جلوگیری از چنین ابهاماتی، شما می تواند از ویژگی های معماری سرویس گرا به عنوان یك راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یك سیستم نرم افزاری یا یك تكنولوژی استفاده كنید. اگرچه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی كم نیستند، اما سیستمهایی كه بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند كه توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی كم را بخوبی در خود ایجاد و حفظ كنند.
ویژگی های سیستم های نرم افزاری مبتنی بر معماری سرویس گرا: - استفاده كننده از سرویس هیچ لزومی ندارد از جرئیات پیاده سازی سرویس در سمت سرویس دهنده مطلع باشد - محل سرویس دهنده باید از نظر استفاده كننده از سرویس پنهان باشد (در انجام امور مرتبط با استفاده از سرویس ) و تنها در زمان اجرا سرویس گیرنده از مكان سرویس دهنده آگاه خواهد شد. - نرم افزار مبتنی بر معماری سرویس گرا باید بتواند با نرم افزارهای موجود روی سایر پلتفرم ها تعامل داشته باشد. - چندین نسخه از سرویس باید بصورت همزمان در كنار هم فعالیت كنند زیرا با توجه به طیف گسترده استفده كنندگان در صورت بروزرسانی سرویس در سمت سرویس دهنده، به سرعت امكان بروزرسانی استفاده كنندگان سرویس وجود ندارد همچنین تعدادی از ویژگی هایی كه هر نرم افزار، اعم از اینكه مبتنی بر این معماری باشد یا نباشد، باید داشته باشد به شرح زیر است: - كارایی زیاد - امنیت بالا (تضمین محرمانگی، صحت اطلاعات و همیشه در دسترس بودن) و همچنین كنترل دسترسی - قابلیت اطمینان بالا بخصوص وقتی سر و كار با تراكنش های چند مرحله ای است.
سرویسهای وب به عنوان پایه معماری سرویس گرا: سیر تكامل و رشد XML، با پیدایش سرویس های وب همراه بود. یك سرویس وب بهترین راه حل برای پیاده سازی معماری سرویس گرا است، مخصوصا وقتی دیدگاه استفاده از كل كاربران اینترنت به عنوان كاربران بالقوه سرویس مطرح باشد. شما پایه كار خود را بر پروتكل HTTP بنا می نهید، پروتكلی كه از همه پروتكل های دیگر روی اینترنت قابل دسترس تر است. با نگاه به قابلتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا، شما متوجه خواهید شد كه سرویس های وب بسیاری از موارد مطرح شده در بالا را رعایت می كنند اما تعدادی از اصول مطرح شده را هم زیر پا می گذارند كه آن را بررسی می كنیم: - كارایی: XML كه عنصر اصلی سازنده سرویسهای وب است، نسبت به سایر مكانیزم های انتقال اطلاعات (binary) از سربار بسیآر زیادی برخودار است. - قابلیت اطمینان در تراكنش ها: اگر شما در یك تراكنش از یك سرویس وب استفاده كنید، چگونه می توانید صحت تراكنش را تضمین كنید در حالی كه تمام كارهای شما مبتنی بر اینترنت و پروتكل HTTP است؟ - امنیت: شما چگونه می توانید كاربران سرویس خود را تصدیق هویت كنید تا بعد از آن بتواند صلاحیت آنها را در استفاده از سرویس تان مورد بررسی قرار دهید؟ همچنین یك نكته منفی دیگر در مورد سرویس های وب در حال حاضر، عدم پشتیبانی اكثر محیط های تولید نرم افزار (IDE) برای تولید و استفاده از آنها است و در عین حال فراهم كردن قابلتهایی مانند كمك به برنامه نویس در استفاده از متدها و غیره یا پیدا كردن خطاها در زمان كامپایل و نه زمان اجرا. بنابراین، مگر اینكه موارد فوق به نحوی حل نگردد، ممكن است استفاده از سرویس های وب به عنوان پایه معماری سرویس گرا مورد سوال قرار گیرد.البته در هر حال سرویس های وب از این نظر كه طیف كاربران بالقوه آنها اینترنت است بسیار مورد توجه هستند. در حال حاضر هم در اكثر سازمانها برای تمامی نرم افزار ها یك واسط بصورت وب سرویس جهت فراهم كردن استفاده از آن برای سازمانهای همكار فراهم می شود و یا حتی در داخل سازمان و در مواردی كه استفاده از نرم افزار مذبور در داخل سازمان بسیار استفاده شود، با توجه به مشكلات كارایی سرویس های وب، یك واسط بصورت یكی از تكنولوژی های برنامه نویسی مبتنی بر Component مانند COM+ و یا CORBA برای نرم افزار ایجاد می شود. آماده شدن برای معماری سرویس گرا: همانطوری كه ذكر شد، با وجود اینكه تعدادی نكات منفی در استفاده از سرویسهای وب به عنوان پایه معماری سرویس گرا وجود دارد اما این موارد قابل حل هستند.
برای مثال در مورد بحث كارایی، می توان از پردازنده ای قدرتمند تر استفاده كرد و یا مشكل امنیت را می توان با استفاده از زیرساختهای مبتنی بر رمزنگاری های نامتقارن حل كرد. در هر حال اگر شما تا بحال برای معماری سرویس گرا آماده نشده اید، در هر حال لازم است تا به این سمت پیش روید زیرا همانطور كه در ابتدای این مقاله اشاره شد، نرم افزارهای مبتنی بر این معماری، نسل غالب سالهای آینده خواهند بود. بدین منظور باید اندكی تفكر خود را در مورد طراحی نرم افزار، تغییر دهید. در زیر به مهمترین آنها اشاره می شود: - سعی كنید با سرویس دهنده های خود از طریق واسط های چاق ارتباط برقرار كنید و از استفاده از واسط های پرحرف بپرهیزید. به عبارت دیگر سعی كنید عملیاتی كه شامل چندین فراخوانی است از طریق یك فراخوانی انجام دهید. هر بایت اطلاعاتی كه شما روی اینترنت می فرستید محسوس است زیرا روی اینترنت اولا پهنای باند محدود است و همچنین در مورد هر انتقال باید عملیات تحلیل نام و مسیریابی انجام شود. - سعی كنید حتی الامكان اطلاعات مربوط به وضعیت را در سمت سرویس دهنده نگهداری نكنید. سعی كنید این كار را به استفاده كنندگان واگذار كنید.
برای مثال اگر شما یك سازمان باشید كه تعداد زیادی مراجعه كننده دارد و شما نیاز به اطلاعات مراجعه كننده ها دارید، اگر بخواهید خودتان تمام اطلاعات مربوط به مراجعه كنندگان خود را نگهداری كنید به یك انبار بسیار بزرگ نیاز خواهید داشت . بهتر است از مراجعه كنندگان خود بخواهید كه اطلاعات خودشان را نگهداری كنند، نه خود سازمان شما بخواهد آنها را نگهداری كند. - سعی كنید از واسط های بسیار خوش تعریف برای سرویس های خود استفاده كنید زیرا وقتی شما پایه خود را بر سرویسهای وب بنا نهادید شما لازم دارید این واسط ها را در اختیار استفاده كنندگان از سرویس خود قرار دهید. (از طریق WSDLسرویس وب خود) - سعی كنید به سمت استفاده از روشهای غیرهمزمان برای فراخوانی های خود پیش روید زیرا بسیاری از سرویس ها به استفاده كنندگان خود بصورت غیرهمزمان سرویس می دهند(مانند سرویس های وب) بنابراین برای سرویس گیرندگان بهتر است از این روش تبعیت كنند. این روش مناسبی نیست كه سرویس گیرنده به علت اینكه سرویس دهنده هنوز پردازش را شروع نكرده است ، بلاك شود. به عبارت دیگر سعی كنید دید خود را از حالت درخواست/پاسخ (مطرح در معماری Client/Server) به دید مبتنی بر پیام تغییر دهید؛ یعنی وقتی كه سرویس گیرنده یك پیام را برای سرویس دهنده ارسال كرد سرویس دهنده بعد از مدتی از طریق یك پیام به سرویس گیرنده پاسخ خواهد داد. - برای تصدیق هویت و كنترل دسترسی به روشهای دیگر فكر كنید.
مكانیزهای امنیتی در مورد سرویس های وب متفاوت است. در مورد مكانیزهای امنیتی مورد استفاده از روشهای خاص یك پلتفرم استفاده نكنید زیرا قابلیت تعامل سیستم شما را با سایر سرویس ها بخطر می اندازد(مانند Integrated Windows Authentication) اخیرا هم یك گسترش در مشخصات سرویس های وب با نام ws-security بوجود آمده است كه از آن جهت پیاده سازی امنیت در سروی های وب استفاده می شود. - از پلتفرمی استفاده كنید كه به شما اجازه دهد بطور همزمان چندین نسخه از یك سرویس را در كنار هم نگه دارید (مراجعه كنید به قابلیتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا) همچنین به یاد داشته باشید تكنولوژیهایی مانند COM+,CORBA,RMI در حیطه خود فنآوری های موفقی بوده و هستند و تعداد بسیار زیاد سیستمهایی كه از این معماری ها استفاده می كنند این موضوع را نشان می دهد. سرویس های وب شامل مفاهیمی هستند كه در مورد این تكنولوژی ها وجود ندارد، اما این به این معنی نیست كه سرویس های وب در زمانی كوتاه جایگزین این فنآوری ها خواهند بود؛ و بنابراین سعی كنید در كنار این تكنولوژی ها از سرویس های وب بهره جویید. نتیجه گیری: معماری سرویس گرا از آخرین فن آوری های بوجود آمده در تولید نرم افزار است، كه علاوه بر رعایت دو اصل همبستگی زیاد و چسبندگی كم نیازهای تكنولوژیكی امروز بشر را برآورده می سازد.
با توجه به بوجود آمدن شركتهای چند ملیتی، ظهور خدمات الكترونیك و پیچیده شدن امور گوناگون و مخصوصا مجتمع سازی سیستم های نرم افزاری گوناگون EAI، این معماری توانسته بخوبی از عهده این پدیده های نوین بر آید. منابع: ۱ –Mehran Nikoo, Service-Oriented Architecture, Where do we stand? , ۲۰۰۳ ۲ –Alan Brown, Simon Johnston, Kevin Kelly, Using Service-Oriented Architecture and Component-Based Development to Build Web Services Application, ۲۰۰۲

علی كاظمی مقدم
نیما شریفی مهر

منبع : پایگاه اطلاع رسانی ITanalyze