مقاله معماری سرویس گرا در word دارای 123 صفحه می باشد و دارای تنظیمات و فهرست کامل در microsoft word می باشد و آماده پرینت یا چاپ است
فایل ورد مقاله معماری سرویس گرا در word کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه و مراکز دولتی می باشد.
این پروژه توسط مرکز مرکز پروژه های دانشجویی آماده و تنظیم شده است
توجه : توضیحات زیر بخشی از متن اصلی می باشد که بدون قالب و فرمت بندی کپی شده است
بخشی از فهرست مطالب پروژه مقاله معماری سرویس گرا در word
فصل
1-1- مقدمه
1-1-1 – معماری سرویس گرا چیست؟
2-1-1- ویژگی های سیستم های مبتنی بر معماری سرویس گرا
3-1-1- آماده شدن برای معماری سرویس گرا
2-1- معرفی
3-1- ویژگیهای سرویس و محاسبات سرویس گرا
4-1- نرم افزار به عنوان سرویس
5-1- مفهوم معماری سرویس گرا
6-1- معماری سرویس گرای مقدماتی
7-1- معماری سرویس گرای توسعه یافته
8-1- نیازمندیهای معماری سرویس گرا
فصل 2 : معماری سرویس گرا
1-2- مقدمه
2-2- محرک های تجاری در رویکردی جدید
3-2- معماری سرویس گرا به عنوان یک راه حل
1-3-2- تجزیه و تحلیل و طراحی شی گرا
2-3-2- طراحی بر مبنای جزء
3-3-2- طراحی سرویس گرا
4-3-2- طراحی بر مبنای واسط
5-3-2- معماریهای برنامه های کاربردی لایه ای
4-2- نگاهی دقیق تر بر معماری سرویس گرا
1-4-2- جنبه های عملکردی
2-4-2- جنبه های کیفیت سرویس
3-4-2- همکاری SOA
4-4-2- نقش ها در معماری سرویس گرا
5-4-2- عملیات در معماری سرویس گرا
6-4-2- سرویس در بافت SOA
7-4-2- سرویس در برابر اجزاء
5-2- مزایای معماری سرویس گرا
1-5-2- بالا بردن دارایی های موجود
2-5-2- مجتمع سازی و اداره کردن راحت تر پیچیدگی
3-5-2- پاسخگویی بیشتر و خرید و فروش سریعتر
4-5-2- کاهش هزینه و افزایش استفاده مجدد
5-5-2- آمادگی در برابر حوادث
فصل 3 : معماری سرویس وب
1-3- مقدمه
2-3- سرویس وب چیست؟
3-3- مدل چند لایه مبتنی بر XML-Web service
1-2-3- برخی از ویژگیهای سرویس های وب
4-3- قابلیت عملکرد متقابل سرویس های وب
1-1-3-3- انگیزه های مالی برای معماری سرویس گرا
2-1-3-3- خصیصه های معماری سرویس وب
3-1-3-3- سازمان قابلیت عملکرد متقابل سرویس های وب
4-1-3-3- خصوصیات گزارش
5-1-3-3- موارد کاربردی و سناریوی مورد استفاده
6-1-3-3- برنامه های کاربردی نمونه
7-1-3-3- ابزارهای تست
2-3-3- گزارش بر مبنای WS-I 1.0
1-2-3-3- سناریوی مورد استفاده یک طرفه
2-2-3-3- سناریوی مورد استفاده تقاضا / پاسخ همزمان
3-2-3-3- سناریوی مورد استفاده تماس برگشتی اولیه
فصل 4 : انتخابهای تکنولوژی
1-4- انتخابهای تکنولوژی
2-4- مقدمه
1-2-4- مزایای سرویس های وب
2-2-4- معایب سرویس های وب
3-4- لایه های پشته معماری سرویس گرا
1-3-4- حمل و نقل
2-3-4- پروتکل تبادل سرویس
3-3-4- شرح سرویس
4-3-4- سرویس
1-4-3-4- سرویس وب و J2EE
2-4-3-4- چارچوب کاری احضار سرویس وب
3-4-3-4- برخی ملاکهای مؤثر در انتخاب چهارچوبها
5-3-4- فرآیند تجاری
6-3-4- بایگانی سرویس
1-6-3-4- درخواست مستقیم
2-6-3-4- انتشار جمعی ساده
3-6-3-4- استفاده از دایرکتوری
7-3-4- سیاست
1-7-3-4- استانداردهای نوظهور برای سیاست
8-3-4- امنیت
9-3-4- معاملات
1-9-3-4- استانداردهای نوظهور برای معاملات
- WS-Coordination
- WS-Transaction
پشتیبانی نگهداری برای سرویس وب
10-3-3- مدیریت
نتیجه گیری
خلاصه
منابع
1-1- مقدمه
معماری سرویس گرا به عنوان یکی از آخرین دستاوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود که در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس شما نرم افزار خود را بگونه ای طراحی می کنید که قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام کنند و هر موقع که لازم داشتند از خدمات آن بهره ببرند، همانند حالتی که در مورد شبکه های تلویزیون کابلی وجود دارد. تا زمانی که شما به سرویس متصل هستید، شما می توانید هر لحظه که خواستید از سرویس استفاده کنید
برای مدتهای طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت modular بنویسند، تا بتوان از آن در تولید نرم افزارهای دیگر استفاده کرد. تفاوت نوشتن کد بصورت modular و بر اساس معماری سرویس گرا در حجم مخاطبان آن است
دوباره به همان مثال اول برمی گردیم، وقتی شما کد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شکل Modular می نویسید مانند این است که، یک شبکه تلویزیون کابلی درون یک ساختمان خاص دارید و بنابراین فقط ساکنین آن ساختمان می توانند از آ« بهره برداری کنند
در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد. این معماری توسط دو شرکت IBM ، Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند WSE ، UDDI بوده اند. قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است (MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است
از نمونه های استفاده از این معماری در کشور خودمان، سازمان ثبت احوال کشور است که موظف شده تا پایگاه اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد
1-1-1- معماری سرویس گرا چیست؟
همان طور که در عنوان آن مشخص است، به مفهومی در سطح معماری، اشاره می کند و بنابراین در مورد چیزی پایه ای و اساسی در سطوح بالا است، که پایه و اساس آن تجربیات بدست آمده در تولید سیستم های نرم افزاری مبتنی بر CBD و دو اصل اساسی در صنعت مهندسی نرم افزار یعنی تولید نرم افزار بصورت با همبستگی زیاد و در عین حال با چسبندگی کم است. بنابراین ایده های برنامه نویسی سرویس گرا ایده ا جدید نیست و شما شاید قبلاً از آن استفاده کرده باشید. اما جمع آوری بهترین تجربیات از تولید چنین سیستمهایی بصورت مجتمع و ناظر به وضعیت تکنولوژیکی امروز بشر، که همان مفاهیم مطرح شده در معماری سرویس گرا است چیز جدیدی است. در زیر بصورت دقیق تر این بحث را ادامه می دهیم آیا تولید سیستم های سرویس گرا مفهوم جدیدی است؟ مهندسان نرم افزار، همیشه می گفتند و گفته اند که نرم افزار باید به شکلی نوشته شود که همبستگی زیاد ولی در عین حال اتصال کمی داشته باشد. شرکتهای بزرگ نرم افزاری هم در جهت گام برداشتن برای رسیدن به این دو اصل، تکنولوژی هایی را بوجود آورده اند که به برنامه نویسان اجازه دهد تا به این دو هدف در تولید نرم افزارهای خود تا حد زیادی دست یابند. برای مثال می توان به تکنولوژی هایی مانند CORBA ، COM+ و RMI و موارد دیگر، اشاره کرد. خوب پس مشاهده کردید که موضوع برنامه نویسی سرویس گرا، مفهوم جدیدی نیست و این معماری تلاشی دیگر در جهت تولید نرم افزارهای با همبستگی زیاد و در عین حال با چسبندگی و اتصال کم است. ممکن است بپرسید، پس چرا با وجود تکنولوژی های قدرتمندی چون RMI ، COM+ و CORBA چیز جدیدی بوجود آمد؟ مگر تکنولوژی های قبلی موفق نبودند؟ بله مهمترین اشکال در معماری های قدرتمندی چون موارد مذکور این بود که تولید کنندگان آنها سعی داشتند، که تکنولوژی خود را بر بازار غالب نمایند. رویایی که هرگز به حقیقت نمی پیوست . بنابراین با توجه به این موضوع که این تکنولوژیها قادر به تعامل مناسب با یکدیگر نبودند عملاً اصل همبستگی زیاد بصورت خود بخود رد می شد
البته معماری های مذکور اشکالات دیگری هم داشتند که نسبت به موارد بالا از اهمیت کمتری برخوردار است که از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره کرد. البته بعدها راه حل هایی هم برای این مشکل بوجود آمد (مانند Over HTTP RPC ) اما به این علت که از روز اول، در طراحی این تکنولوژی ها این امر در نظر گرفته نشده بود، از کارایی مناسبی برخوردار نبودند. مفهوم همبستگی زیاد و در عین حال با چسبندگی و اتصال کم، وقتی بخواهد در جهت ارزیابی یک سیستم نرم افزاری یا تکنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی کسی می تواند ایده های همبستگی و چسبندگی را با هم ترکیب کند! برای جلوگیری از چنین ابهاماتی، شما می توانید از ویژگی های معماری سرویس گرا به عنوان یک راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یک سیستم نرم افزاری یا یک تکنولوژی استفاده کنید. اگر چه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی کم نیستند، اما سیستمهایی که بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند که توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی کم را بخوبی در خود ایجاد و حفظ کنند
معماری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده است. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XMIL را پردازش و تبادل می کنند. با رویکرد سرویس گرا می توان راه حل هایی را ارائه داد که به مرز دامنه های سازمان یا شرکت محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی ایستگاه های کاری متفاوت است، یک راه حل یکپارچه سازی با استقلال زیاد ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند
هرکس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تان را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تأیید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل و نقل هماهنگ می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه های دیگر نیز به شکل بارزی در برنامه های کاربردی تجارت الکترونیکی مشهود است. اگر مثلاً جزء مربوط به پرداخت کارت اعتباری Offline و یا غیر فعال باشد، قرار نیست که فرآیند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند و عملیات پرداخت به وقت دیگری موکول شود
مثل سایر معماری های توزیع شده، SOA ساخت برنامه های کاربردی با استفاده از اجزایی که در دامنه های جدا از هم قرار دارند را ممکن می سازد. SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای Proxy و Stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند. با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزادانه تر و مستقل تر است. به علاوه SOA به خاطر در برداشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند، نیز منحصر به فرد است. فاکتورهایی نظیر: قابلیت اطمینان سرویس، جامعیت پیام، یکسانی تراکنش و امنیت پیام. در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری خاطر این که بتوانند بفهمند، پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد. با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند
واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف، متفاوت باشد. با وجود این، هیچ کدام از این موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشته باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند، در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستندسازی و اعلام شود. بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مرحله ای از جریان کار بسیار زیاد است. در SOA فرض بر این است که خطا وجود دارد و می تواند اتفاق بیفتد، بنابراین استراتژی هایی برای برخورد با این خطاها در نظر گرفته است. به عنوان مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد، این معماری طوری طراحی شده است که مجدداً پیام را بفرستد
و اگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار اتفاق بیفتد) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که منجر به قطع کامل در خواست سرویس می شود، امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرآیند تجاری را از کار بیاندازند
به بیان کلی، SOA فرآیندی تکامل یافته را ارائه می نماید و از این نظر می توان آن را بلوغ سرویس های وب و تکنولوژی های یکپارچه سازی به حساب آورد. در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند، باید تضمین های خاصی را تأمین نمایند. در این گونه سیستم ها باید این اطمینان وجود داشته باشد که درخواست های سرویس به طور صحیح مسیر دهی و هدایت شوند، در زمان مناسب به آن ها پاسخ داده شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام کنند
2-1-1- ویژگی های سیستم های مبتنی بر معماری سرویس گرا
- استفاده کنندگان از سرویس هیچ لزومی ندارد از جزئیات پیاده سازی سرویس در سمت سرویس دهنده مطلع باشد
- محل سرویس دهنده باید از نظر استفاده کننده از سرویس پنهان باشد (در انجام امور مرتبط با استفاده از سرویس) و تنها در زمان اجرای سرویس گیرنده از مکان سرویس دهنده آگاه خواهد شد
- نرم افزار مبتنی بر معماری سرویس گرا باید بتواند با نرم افزارهای موجود روی سایر پلتفرم ها تعامل داشته باشد
- چندین نسخه از سرویس باید بصورت همزمان در کنار هم فعالیت کنند زیرا با توجه به طیف گسترده استفاده کنندگان در صورت بروز رسانی سرویس در سمت سرویس دهنده ، به سرعت امکان بروز رسانی استفاده کنندگان سرویس وجود ندارد
همچنین تعدادی از ویژگی هایی که هر نرم افزار، اعم از اینکه مبتنی بر این معماری باشد یا نباشد، باید داشته باشد به شرح زیر است
کارآیی زیاد
امنیت بالا ( تضمین محرمانگی، صحت اطلاعات و همیشه در دسترس بودن) و همچنین کنترل دسترسی
قابلیت اطمینان بالا بخصوص وقتی سروکار با تراکنش های چند مرحله ای است
سرویس های وب به عنوان پایه معماری سرویس گرا : سیر تکامل و رشد XML، با پیدایش سرویس های وب همراه بود. یک سرویس وب بهترین راه حل برای پیاده سازی معماری سرویس گرا است، مخصوصاً وقتی دیدگاه استفاده از کل کاربران اینترنت به عنوان کاربران بالقوه سرویس مطرح باشد. شما پایه کار خود را بر پروتکل HTTP بنا می نهید، پروتکلی که از همه پروتکل های دیگر روی اینترنت قابل دسترس تر است. با نگاه به قابلیتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا، شما متوجه خواهید شد که سرویس های وب بسیاری از موارد مطرح شده در بالا را رعایت می کنند اما تعدادی از اصول مطرح شده را هم زیر پا می گذارند که آن را بررسی می کنیم
کارآیی : XML که عنصر اصلی سازنده سرویسهای وب است، نسبت به سایر مکانیزم های انتقال اطلاعات (binary) از سربار بسیار زیادی برخوردار است
قابلیت اطمینان در تراکنش ها : اگر شما در یک تراکنش از یک سرویس وب استفاده کنید، چگونه می توانید صحت تراکنش را تضمین کنید در حالی که تمام کارهای شما مبتنی بر اینترنت و پروتکل HTTP است؟
امنیت : شما چگونه می توانید کاربران سرویس خود را تصدیق هویت کنید تا بعد از آن بتواند صلاحیت آنها را در استفاده از سرویس تان مورد بررسی قرار دهید؟
همچنین یک نکته منفی دیگر در مورد سرویس های وب در حال حاضر، عدم پشتیبانی اکثر محیط های نرم افزار (IDE) برای تولید و استفاده از آنها است و در عین حال فراهم کردن قابلیتهایی مانند کمک به برنامه نویس در استفاده از متدها و غیره یا پیدا کردن خطاها در زمان کامپایل و نه زمان اجرا
بنابراین، مگر اینکه موارد فوق به نحوی حل نگردد، ممکن است استفاده از سرویس های وب به عنوان پایه معماری سرویس گرا مورد سوال قرار گیرد. البته در هر حال سرویس های وب از این نظر که طیف کاربران بالقوه آنها اینترنت است بسیار مورد توجه هستند. در حال حاضر هم در اکثر سازمانها برای تمامی نرم افزارها یک واسط بصورت وب سرویس جهت فراهم کردن استفاده از آن برای سازمانهای همکار فراهم می شود و یا حتی در داخل سازمان و در مواردی که استفاده از نرم افزار مذبور در داخل سازمان بسیار استفاده شود، با توجه به مشکلات کارایی سرویس های وب، یک واسط بصورت یکی از تکنولوژی های برنامه نویسی مبتنی بر Component مانند +Com و یا CORBA برای نرم افزار ایجاد می شود
3-1-1- آماده شدن برای معماری سرویس گرا
همانطوری که ذکر شد، با وجود اینکه تعداد نکات منفی در استفاده از سرویس های وب به عنوان پایه معماری سرویس گرا وجود دارد اما این موارد قابل حل هستند. برای مثال در مورد بحث کارایی، می توان از پردازنده ای قدرتمندتر استفاده کرد و یا مشکل امنیت را می توان با استفاده از زیرساختهای مبتنی بر رمزنگاری های نامتقارن حل کرد
در هر حال اگر شما تا بحال برای معماری سرویس گرا آماده نشده اید، لازم است تا به این سمت پیش روید زیرا همانطور که در ابتدای این مقاله اشاره شد، نرم افزارهای مبتنی بر این معماری، نسل غالب سالهای آینده خواهند بود. بدین منظور باید اندکی تفکر خود را در مورد طراحی نرم افزار ، تغییر دهید
در زیر به مهمترین آنها اشاره می شود
سعی کنید با سرویس دهنده های خود از طریق واسط های چاق ارتباط برقرار کنید و از استفاده از واسط های پرحرف بپرهیزید. به عبارت دیگر سعی کنید عملیاتی که شامل چندین فراخوانی است از طریق یک فراخوانی انجام دهید
- هر بایت اطلاعاتی که شما روی اینترنت می فرستید محسوس است زیرا روی اینترنت اولاً پهنای باند محدود است و همچنین در مورد هر انتقال باید عملیات تحلیل نام و مسیریابی انجام شود
- سعی کنید حتی الامکان اطلاعات مربوط به وضعیت را در سمت سرویس دهنده نگهداری نکنید. سعی کنید این کار را به استفاده کنندگان واگذار کنید. برای مثال اگر شما یک سازمان باشید که تعداد زیادی مراجعه کننده دارد و شما نیاز به اطلاعات مراجعه کننده ها دارید، اگر بخواهید خودتان تمام اطلاعات مربوط به مراجعه کنندگان خود را نگهداری کنید به یک انبار بسیار بزرگ نیاز خواهید داشت. بهتر است از مراجعه کنندگان خود بخواهید که اطلاعات خودشان را نگهداری کنند، نه خود سازمان شما بخواهد آنها را نگهداری کند
- سعی کنید از واسط های بسیار خوش تعریف برای سرویس های خود استفاده کنید زیرا وقتی شما پایه خود را بر سرویسهای وب بنا نهادید شما لازم دارید این واسط ها را در اختیار استفاده کنندگان از سرویس خود قرار دهید. (از طریق WSDL سرویس وب خود)
- سعی کنید به سمت استفاده از روشهای غیر همزمان برای فراخوانی های خود پیش روید زیرا بسیاری از سرویس ها به استفاده کنندگان خود بصورت غیر همزمان سرویس می دهند (مانند سرویس های وب) بنابراین برای سرویس گیرندگان بهتر است از این روش تبعیت کنند. این روش مناسبی نیست که سرویس گیرنده به علت اینکه سرویس دهنده هنوز پردازش را شروع نکرده است، بلاک شود. به عبارت دیگر سعی کنید دید خود را از حالت درخواست / پاسخ (مطرح در معماری Client / Server ) به دید مبتنی بر پیام تغییر دهید، یعنی وقتی که سرویس گیرنده یک پیام را برای سرویس دهنده ارسال کرد سرویس دهنده بعد از مدتی از طریق یک پیام به سرویس گیرنده پاسخ خواهد داد
- برای تصدیق هویت و کنترل دسترسی به روشهای دیگر فکر کنید مکانیزم های امنیتی در مورد سرویس های وب متفاوت است. در مورد مکانیزم های امنیتی مورد استفاده از روشهای خاص یک پلتفرم استفاده نکنید زیرا قابلیت تعامل سیستم شما را با سایر سرویس ها بخطر می اندازد (مانند Intergrated Windows Authentication ) اخیرا هم یک گسترش در مشخصات سرویس های وب با نام Ws – security بوجود آمده است که از آن جهت پیاده سازی امنیت در سرور های وب استفاده می شود
- از پلتفرمی استفاده کنید که به شما اجازه دهد بطور همزمان چندین نسخه از یک سرویس را در کنار هم نگه دارید (مراجعه کنید به قابلیتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا )
- همچنین به یاد داشته باشید تکنولوژیهایی مانند RMI ، CORBA ،COM+ در حیطه خود فناوری های موفقی بوده و هستند و تعداد بسیار زیاد سیستمهایی که از این معماری ها استفاده می کنند این موضوع را نشان می دهد. سرویس های وب شامل مفاهیمی هستند که در مورد این تکنولوژی ها وجود ندارد، اما این به این معنی نیست که سرویس های وب در زمانی کوتاه جایگزین این فناوری ها خواهند بود، و بنابراین سعی کنید در کنار این تکنولوژی ها از سرویس های وب بهره جویید
2-1- معرفی
تعاریف گوناگونی از معماری سرویس گرا ارائه شده است که از جمله آنها می توان به تعاریف زیر اشاره کرد
مجموعه قوانین ، سیاستها و چهارچوبهایی که نرم افزارها را قادر می سازد تا عملکرد خود را از طریق مجموعه سرویسهای مجزا و در عین حال مربوط به هم در اختیار سایر درخواست کنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابطهای استاندارد وتعریف شده، این سرویسها را پیدا کرده و فراخوانی نمایند. و یا معماری سرویس گرا روشی برای ساخت سیستمهای توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویس ها قرار می گیرد
از دیگر تعاریف ارائه شده می توان به واحدهای نرم افزاری آماد ه در شبکه (Network-available Software Unit) یا سرویسهای سطح حرفه(Business Servives level) اشاره کرد
در حال حاضر، تکنولوژی سرویسهای وب (Web Services) و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستمهای جدید و یکپارچه سازی سیستمهای بزرگ موجود، مطرح گردد. البته ذکر تفاوت سرویسهای وب و SOA در اینجا لازم به نظر می رسید. سرویسهای وب مجموعه ای از تکنولوژیهای همچون UDDI,XML,SOAP , WSDL می باشد که امکان ارائه راه حل و برنامه نویسی جهت رفع مشکلی خاص را فراهم می نماید
در حالی که SOA یک معماریست و از مجموعه مشخصی از تکنولوژیها فراتر می باشد . اگر چه SOA بر اساس این تکنولوژیها راه حل ارائه می نماید، اما در عین حال مستقل از هریک از آنها است
آنچه اهمیت دارد تعریف سرویس به عنوان مهمترین عنصر این معماری می باشد. سرویس، رفتار قراردادی تعریف شده ایست که هر قطعه ای می تواند آنرا جهت استفاده سایر قطعات در سیستم تهیه و پیاده سازی نماید
در این معماری، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع حرفه (Business function) و تراکنشهای حرفه ای (Business transactions ) می باشند که تراکنشهای حرفه خود شامل توابع سطح پایین (Low – level function) و توابع سیستمی سرویسها (System service functions ) هستند
سرویسها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند
قطعات، سرویسهای خود را از طریق رابطها (interface) در اختیار قطعات دیگر قرار میدهند که این رابطها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرارگیری آنها اهمیت داشته باشد (رابطهای محلی یا دور) . در ضمن این رابطها می توانند به همان نرم افزار کاربردی یا به آدرسی در محل دیگری از شبکه مرتبط باشند. رابطها به عنوان کلیدی در برقراری این ارتباطها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد
بعلاوه، با ایجاد قابلیت توزیع شدگی به شکلی مناسب و بدون وابستگی زیاد، می توان سرویسها را در قسمتهای مختلف شبکه و بصورت بعضا تکراری (مخصوصاً برای سرویسهای مهم) قرار داد تا این سرویسها همیشه در دسترس بوده و در صورت زیاد شدن درخواستها بتوان با استفاده از تکنیکهای Load Balancing به تمامی آنها به خوبی پاسخ داد
3-1- ویژگیهای سرویس و محاسبات سرویس گرا
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پایه سرویس به عنوان عنصر اساسی، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می سازند تا توابع خود را از طریق زبانها و پروتکلها برپایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند
از آنجا که سرویسها از طریق سازمانها و شرکتهای گوناگون تهیه می شوند و جهت دسترسی کاربران مختلف می بایست همواره در دسترس باشند، رعایت ویژگیهای زیر ضروری می باشد
مستقل از تکنولوژی باشند : به این معنا که بکارگیری و مکانیزم فراخوانی و پیدا کردن سرویسها به راحتی و از تمام محیطها (سیستمهای عامل مختلف و زبانهای برنامه سازی گوناگون) میسر بوده و وابسته به پلتفرم خاصی نباشد. وابستگی بسیار پایینی بین درخواست کننده و ارائه دهنده سرویس وجود داشته باشد و یا بعبارتی Loosly Coupled باشد. به این معنا که درخواست کننده نباید هیچ نیازی به دانستن ساختار داخلی و نحوه پیاده سازی سرویس داشته باشد. برای این منظور، فراخوانی سرویس از طریق بکارگیری مکانیزم پیغام (Message) بجای فراخوانی API انجام می گردد
درخواست کننده نباید نیازی به دانستن محل قرارگیری سرویس داشته باشد و بعبارتی معماری سرویس گرا می بایست Location Transparency را پشتیبانی نماید. به این ترتیب که محل قرارگیری سرویس و مشخصات آن در مخزنی (Repository) قرار می گیرد و درخواست کننده، محل و اطلاعات لازم را از طریق بازیابی آن از این مخزن بدست می آورد
سرویس ها می توانند به دو شکل ساده و ترکیبی ارائه شوند. سرویس های ترکیبی، سرویس هایی هستند که بر اساس بکارگیری چند سرویس ساده (یا ترکیبی) ایجاد می شوند. برای مثال، ممکن است سیستم توزیع شده ای بر اساس چند سرویس ساده صدور صورتحساب، ثبت سفارش، مدیریت روابط مشتری و ; سرویسهای ترکیبی گسترده تری در ارتباط با حرفه ای خاص ایجاد نماید
سیستم های ساخته شده بر اساس سرویس، ترکیبی از سرویس های مستقل هستند که عملکردهای خود را از طریق رابطهای تعریف شده ای در اختیار کاربران (بالقوه) خود قرار میدهند . Web Service Description Language WSDL از جمله راههایی است که بطور گسترده برای تعریف این رابطها بکار می رود تا بوسیله آن جزئیات لازم برای اتصال درخواست کننده به ارائه دهنده سرویس تعریف شود
4-1- نرم افزار به عنوان سرویس
اصل ارائه شده «نرم افزار – بعنوان – سرویس» از محاسبات سرویس گرا، بر اساس مدل ASP مطرح گشته است. ASP هویت سوم شخصیست که بگارگیری سرویسهای نرم افزاری و دسترسی مشتری را به بسته نرم افزاری از طریق شبکه، مدیریت و میزبانی می نماید. به عبارتی ASP ها راهی برای رفع نیازهای IT شرکتها از طریق واگذاری بخشی از این نیازها یا تمامی آنها به بیرون از سازمان می باشند. برای این منظور ASP با استفاده از زیرساختهای خود، ارتباط بین مشتری و نرم افزار ارائه شده را برقرار کرده و دسترسی وی به داده ها و توابع موجود را بصورت در دسترس (online) ، مدیریت می نماید
اگر چه نظریه، نرم افزار بعنوان سرویس اولین بار توسط ASP ارائه شد، اما مشکلات این روش باعث ایجاد کدهایی می شد که معمولاً قابل استفاده مجدد نبوده و محدود به مشتری خاص می بود، بعبارتی وابستگی زیادی بین سرویس ارائه شده و سیستم استفاده کننده بوجود می آمد
معماری سرویس گرا اجازه میدهد تا نظریه نرم افزار بعنوان سرویس، گسترش یافته تا از طریق آن بتوان پردازشها و تراکنشهای پیچیده را بعنوان سرویسهایی با قابلیت استفاده مجدد ارائه کرد و به این ترتیب سیستمها را مستقل از سرویسها طراحی و تولید نمود
5-1- مفهوم معماری سرویس گرا
هریک از اجزای معماری سرویس گرا می تواند حداقل یکی از نقش های زیر را داشته باشد
فراهم کننده سرویس
واسط سرویس
درخواست کننده سرویس
که عملیاتی را که در شکل 1-3 نشان داده شده است را انجام می دهند
1- فراهم کننده سرویس : سرویس وب را می سازد و تا حد امکان رابط و اطلاعات مربوط به دسترسی به آن را در ثبت خانه سرویس ها قرار می دهد . هر فراهم کننده می بایست راجع به اینکه چه سرویسی را ارائه دهد، چگونه بین امنیت و سهولت دسترسی تعادل برقرار کند، چگونه بین امنیت و سهولت دسترسی تعادل برقرار کند، چگونه روی سرویسها قیمت بگذارند ( و یا اگر رایگان هستند، چگونه منابع مصرف شده را جبران نماید) ، همچنین در مورد اینکه چه دسته ای از سرویسها می بایست در لیست واسط قرار بگیرند و چه نوع قراردادهای شریک تجاری برای استفاده از سرویس نیاز هستند، باید تصمیم گیری کند
2- واسط سرویس : که به آن ثبت خانه سرویس هم گفته می شود. مسئول ساختن رابط سرویس وب و پیاده سازی آن برای دسترسی تقاضا کنندگان سرویس به اطلاعات موجود می باشد. سازنده های واسط می بایست راجع به محدوده واسطه تصمیم گیری کنند. واسط های عمومی در کل اینترنت در دسترس هستند. در حالیکه واسطهای اختصاصی تنها برای کاربران (مشتریان) خاصی در دسترس اند که به عنوان مثال می توان به کاربران شرکتی که دارای یک شبکه وسیع اینترانت است، اشاره کرد. علاوه بر آن می بایست راجع به وسعت اطلاعاتی که عرضه می شود نیز تصمیم گیری کند. چه بسا برخی از واسطها از نظر تعداد مخاطبان خود محدود شده اند. برخی دیگر نیز سرویسها را با امنیت بسیار بالا عرضه می کنند، برخی بخش وسیعی از سرویسها را پوشش می دهند و بعضی روی صنعت خاصی تمرکز می کنند. در هر حال بسته به مدل تجاری، واسط سعی می کند جستجوی درخواستها، تعداد و دقت یافته های خود را به حداکثر برساند
3- درخواست کننده سرویس : ورودی ها را با استفاده از روشهای مختلف جتسجو در ثبت خانه واسط قرار می دهد و سپس به منظور فراخوانی یکی از سرویسهای وب به فراهم کننده سرویس مقید می کند.
یک مسئله مهم برای کاربران سرویسها، اهمیت سرویسهای ایستا که از طریق طراحان انتخاب می شوند. در مقایسه با سرویسهای پویاست که در زمان اجرا انتخاب می شوند. اگر چه قسمت اعظم کاربردهای اولیه را سرویسهای ایستا تشکیل می دهند. ولی سرویسهای پویا امکاناتی را به کاربر می دهند که بهترین فراهم کننده سرویس را انتخاب کنند و کیفیت سرویس را تشخیص دهند
6-1- معماری سرویس گرای مقدماتی
