معماری سرویس گرا در تولید نرم افزار
تکفا - در این مقاله یکی از آخرین معماری ها در تولید نرم افزارها با نام معماری سرویس گرا معرفی می گردد.
Service Oriented Architecture علی کاظمی مقدم، نیما شریفی مهر ali.kazemi@takfa.ir nima@nebrasinfo.com چکیده مقاله: در این مقاله به بررسی معماری سرویس گرا در تولید نرم افزار، به عنوان یکی از آخرین دستاوردهای صنعت مهندسی نرم افزار، پرداخته می شود. کلمات کلیدی: سرویس های وب، Web Services، معماری سرویس گرا، Service Oriented Architecture، SOA مقدمه: معماری سرویس گرا به عنوان یکی از آخرین دستآوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود که در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس شما نرم افزار خود را بگونه ای طراحی می کنید که قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام کنند و هر موقع که لازم داشتند از خدمات آن بهره ببرند، همانند حالتی که در مورد شبکه های تلویزیون کابلی وجود دارد. تا زمانی که شما به سرویس متصل هستید، شما می توانید هر لحظه که خواستید از سرویس استفاده کنید. برای مدتهای طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت 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، این معماری توانسته بخوبی از عهده این پدیده های نوین بر آید. منابع: 1 –Mehran Nikoo, Service-Oriented Architecture, Where do we stand? , 2003 2 –Alan Brown, Simon Johnston, Kevin Kelly, Using Service-Oriented Architecture and Component-Based Development to Build Web Services Application, 2002
- ۸۴/۰۲/۱۵
