معماری خدمت گرا در تولید نرم افزار – Service Oriented Architecture

در این مقاله یکی از آخرین معماری ها در تولید نرم افزارها با نام معماری خدمت گرا معرفی می گردد.Service Oriented Architecture

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

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

برای مدتهای طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت 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.rar
Service Oriented Architecture.doc
SOA.doc سوال یکی از خوانندگان و پاسخ آن

علی کاظمی مقدم، نیما شریفی مهر ali.kazemi@takfa.ir nima@nebrasinfo.com

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

اجرا شده توسط: همیار وردپرس