مقاله:استاندارد خدمات وب برای رایانش ابری

web services standards for Cloud

چکیده

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

فصل اول:مقدمه ای بر استاندارد های ابری

مقدمه ای بر استاندارد های ابری

استاندارد ها برای محیط های رایانش ابری اهمیت زیادی دارند و امکان اتصال به ابر، توسعه و ارائه محتوا را فراهم می کند. رایانش ابری و SOA هردو یک سازمان با یک فرصت مناسب برای انتخاب استانداردهای رایج و مشترک برای قابلیتهای در دسترس شبکه را فراهم میکنند. SOA یک مجموعه نسبتا بالغ شده ای از مجموعه استاندارد هایی که با سرویسهای نرم افزار پیاده سازی ، مانند REST ، SOAP ، و WSDL در میان بسیاری دیگر را داراست. رایانش ابری بالغ نیست (کامل نیست) ، و بسیاری از اینترفیسهای ارائه شده به یک فروشنده خاص منحصربفرد (یونیک) هستند ، درنتیجه خطر ابتلا به فروشنده قفل (vendor lock-in) افزایش میابد. سیمون واردلی مینویسد : توانایی سوییچ بین ارائه دهندگان، بزرگترین نگرانیهای ناشی از استفاده مثل ارائه دهندگان سرویس ، عدم یافتن منابع گزینه های دوم و ترس از فروشنده قفل در (vendor lock-in) برتری میابد (و نقاط ضعف متعاقب آن در کنترل استراتژیک و عدم رقابت قیمت گذاری) . این احتمال وجود دارد که در طول زمان ارائه ها (Offerings) در هر لایه در پشته همگن تر شود. واردلی در ادامه مینویسد : محاسبات پشته ، از برنامه هایی که ما مینویسیم ، به پلتفرم هایی که ما ایجاد میکنیم ، برای سیستم عامل هایی که ما استفاده میکنیم درحال حاضر از یک محصول به اقتصاد مبتنی بر سرویس حرکت میکند. این شیفت (تغییر – انتقال) به سمت سرویسهایی که به استانداردسازی سفارشات کمتر (lower orders) از محاسبات پشته اجزای ارائه دهنده اینترنت، رهبری میشود.

تلاش ها و فعالیت های انجام شده در حوزه استانداردهای رایانش ابری

بسیاری از پروژه های ابری که وجود دارد شاید بیش از حد هستند. برخی از این پروژه ها در بخشهای استانداردسازی از یک سولوشن رایانش ابری مانند حجم کار (workloads) ، احراز هویت و دسترسی به داده ها تمرکز میکنند. تلاشهای دیگر در چگونگی استاندارد سازی قسمت هایی که باید باهم بعنوان یک راه حل کار کنند، تمرکز میکنند. استانداردهای ابر هماهنگ Wiki یک لیستی از این پروژه ها را حفظ میکنند.

1. HTML/XML 2. WSDL/SOAP 3. SAML/XACML 4. OAuth/OpenID 5. OData 6. OVF 7. OpenStack 8. CAMP 9. CIMI 10. ODCA – SuoM 11. SCAP 12. ISO 27001 13. ITIL 14. SOC 15. Tier Certification 16. CSA CCM

درحالیکه این لیست کامل نیست ، نشانه هایی از تنوع ، تعداد و همپوشانی از پروژه های مربوط فعلی با استانداردها را برای ایجاد قابلیت همکاری رایانش ابری فراهم میکند.

استاندارد سازی برای کاهش پیچیدگی

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

= چهار دسته کلی استاندارد ها

در این بخش، دسته بندی کلی و رایجی که در زمینه استاندارد های رایانش ابری مورد استفاده قرار می گیرد را بررسی می کنیم.

ارتباطات

رایانه ها نیاز به روشی دارند که بتوانند با همدیگر صحبت کنند. ارتباطات را می توانید همانند صحبت کردن از طریق تلفن با یک شخص دیگری که فارسی صحبت نمی کند و شما متوجه زبان آن نمی شوید در نظر بگیرید. بنابراین راهی برای فهمیدن همدیگر ندارید. شاید بتوانید بعضی کلمات را حدس بزنید، اما در کل مکالمه پیش نمی رود. در رایانه ها هم موضوع از همین قرار است. البته اگر زبان آنها مشترک نباشد، حتی یک کلمه را هم نمی توانند تشخیص دهند. بنابراین بدون زبان مشترک، ارتباط برقرار نمی شود. • Hypertext Transfer Protocol, HTTP: برای دریافت یک صفحه وب از سرویس دهنده ابری، معمولا از پروتکل HTTP استفاده می شود که یک مکانیزم برای انتقال داده بین ابر و سازمان شماست. • Extensible Messaging and Presence Protocol, XMPP: این پروتکل یکی از رویدادهای بزرگ در خصوص رایانش ابری می باشد. پروتکل XMPP امکان ارتباط دو طرفه را فراهم کرده و نیاز به عملیات Polling را بر طرف کرده است.

امنیت

امن کردن session های ابر از آن جهت مهم است که بسیاری از شرکت ها علاقمند شده اند تا وارد ابر شوند. امن کردن session های ابر می توانند از طریق رمز نگاری و احراز هویت انجام شود. روش های رمز نگاری رایج در همه مرورگرها بصورت استاندارد انجام می شود. احراز هویت موضوع دیگری است که گزینه های مختلفی در پیش روی شماست. • Secure Sockets Layer, SSL: ssl تکنولوژی امنیتی استاندارد برای برقراری یک اتصال رمز شده بین یک سرور وب و مرورگر است. به کمک آن می توان اطمینان حاصل کرد که داده های ارسال شده بین مرورگر و سرور وب، امن باقی می ماند. و از این روش به طور گسترده برای رمزنگاری مورد استفاده قرار می گیرد. • OpenID: Openid یک راه حل کد متن باز برای مشکل نیاز به نام کاربری و کامه عبور واحد دسترسی به سایت های مختلف است، بنابرای پیمایش در وب را تسهیل می کند. و یکی از روش های احراز هویت می باشد.

زیر ساخت

مجازی سازی راهی برای ایجاد زیرساخت در محیط رایانش ابری است. در نتیجه تلاش های VMware و دیگر شرکای صنعت مجازی سازی، یک استاندارد به نام Open Virtualization Format, OVF توسعه داده شد. OVF تعیین می کند که چگونه ابزار های مجازی بتوانند در یک فرمت مستقل از فروشنده قرار بگیرند تا در هر فوق ناظری اجرا شوند. این یک فرمت مستقل از یکو، قابل توسعه و باز برای بسته بندی و توزیع ابزار های مجازی است که از یک یا چند ماشین مجازی تشکیل شده است. OVF به مشتریان و توسعه دهندگان امکان انتخاب هر فوق ناظری را بر اساس قیمت، ترجیحات یا کارآیی می دهد و از قفل شدن در یک فروشنده جلوگیری می کندو این استاندارد بسته بندی و توزیع برای ابزار های مجازی در افزایش سرعت پذیری ابزار های مجازی نقش مهمی ایفا می کند.

سرویس

یک سرویس وب، طبق تعریف W3C ، یک سیستم نرم افزاری است که برای پشتیبانی از تعامل های متقابل ماشین به ماشین در شبکه طراحی شده است. در رایانش ابری نیز اجزای مختلف می توانند از طریق سرویس های وب در دسترس قرار بگیرند. سرویس های وب معمولا API های وبی هستند که از طریق شبکه هایی نظیر اینترنت قابل دسترسی هستند و روی یک سیستم راه دور که میزبان سرویس های درخواست شده است، اجرا می شوند. در این بخش در خصوص چند نمونه از سرویس های وب رایج نظیر REST، SOAP، JSON صحبت می کنیم. داده: داده می تواند با استفاده از مکانیزم ها و ساختارهای مختلفی مورد استفاده قرار بگیرد. دو نمونه از رایج ترین آنها JSON و XML می باشد. هر دوی این ها بر اساس استاندارد های پیش رو در صنعت –HTML و جاوااسکریپت- هستند که برای کمک به ارائه و استفاده از داده مورد استفاده قرار می گیرند. • JavaScript Object Notation, JSON یک قالب سبک رایانه ای برای تبادل داده ها است. از این فرمت برای ارسال داده های ساخت یافته در شبکه استفاده می شود. این فرمت معمولا می تواند به عنوان یک روش دیگر مشابه با XML مورد استفاده قرار بگیرد. اصول JSON یک فرمت مستقل از زبان است و کد های مورد نیاز برای تحلیل و تولید آن در چندین زبان برنامه نویسی مختلف موجود است. همین موضوع باعث شده است که وقتی در تبادل داده با جاوا اسکریپت در گیر هستیم، بتوان آن را به عنوان یک جایگزین خوب بجای XML استفاده کرد.

• Extensible Markup Language, XML یک زبان استاندارد و روشی خود تعریف برای کد کردن متن و داده است به طوری که محتوا با کمترین تعامل انسانی قابل دسترسی و قابل مبادله در بین طیف مختلف سخت افزارها، سیستم عامل و برنامه های کاربردی باشد. XML روشی استاندارد برای ارایه متن و داده در فرمتی که بتواند مستقل از پلت فرم استفاده شود، فراهم آورده است. همچنین می تواند با طیف گسترده ای از ابزار های توسعه و برنامه نویسی و ابزار های دیگر مورد استفاده قرار بگیرد. سرویس های وب تعیین می کنند که داده چگونه از ایر به کلاینت ارسال شود. پروتکل های مختلفی در این رابطه وجود دارند که تعدادی از آنها را بررسی خواهیم کرد. به طور کلی SOAP و REST بهترین گزینه ها برای نیاز های ابری هستند.

فصل دوم: معماری سرویس های وب و نحوه همپوشانی آن با رایانش ابری

معماری سرویس های وب و نحوه همپوشانی آن با رایانش ابری

تعریف رایانش ابری

درحالی که رایانش ابری در حال حاضر یک اصطلاح بدون یک اجماع معنا در بازار است که یک حرکت گسترده به سمت استفاده از شبکه های گسترده را توصیف میکند ، مانند اینترنت که برای تعامل بین ارائه دهندگان انواع بسیار سرویس IT و مصرف کنندگان است. ارائه دهندگان سرویس، خدمات در حال عرضه خود را شامل تمام پشته سنتی آی تی ، از سخت افزار و پلتفرم ها گرفته تا اجزای نرم افزار ، سرویسهای نرم افزار و کل برنامه های کاربردی را گسترش میدهند ، همانطور که در شکل 1 نشان داده شده است. نخ مشترک در تمام سطوح از پشته ارائه های رایانش ابری رابطه مصرف کننده/ارائه دهنده و یک وابستگی بر روی شبکه برای اتصال دوطرف میباشد. بازار تجاری ابر یک طیف گسترده ای از خدمات ابری که در پیچیدگی و ارزش متفاوت است را ارائه می دهد. شکل 1 سازماندهی این بازار را به صورت مجموعه ای کلی از دسته های لایه بندی شده خدمات ، در یک پشته متصورشده ، با ارائه های اساسی به سمت بالا و پیچیدگی بسیار به سمت پایین را ارائه می دهد.

• Cloud Infrastructure:

در پایین پشته ابر ، ساختار ابر اجزای فیزیکی چند سایت توزیع شده را برای پشتیبانی رایانش ابری مانند ذخیره سازی و پردازش منابع فراهم می آورد. این لایه به زیرساخت ارائه دهنده اجازه جزییات انتزاعی مانند سخت افزار دقیق برنامه ای که در حال استفاده است و کدام دیتاسنتر برنامه در حال اجرا هست را میدهد. پیشرفت در فن آوری های مجازی سازی سرور برآمده از این لایه از پشته بسیار کارآمد تر از سالهای گذشته اجازه استفاده بیشتر از پردازش منابع از آنچه قبلا عملی شده است را میدهد. مفاهیم ماشین مجازی نیز به جدایی مفید از جزییات پیاده سازی سخت افزاری اصولی از نظر توسعه دهندگان ، و توانایی بخشیدن به سرعت بیشتر مقیاس پذیری منابع سرور در پاسخ به تغییر تقاضا (changing demand) را فراهم می آورد.

• Cloud Storage—Storage as a service:

ساخت بر روی زیرساخت ابر ، این لایه از پشته ابر بر روی اجاره افزایشی از ذخیره سازی بر روی اینترنت ، که قبلا رایانش همگانی نام گذاری شده تمرکز دارد. بسیاری از ارائه ها در این زمینه نیز با پیشرفتهای اساسی در مجازی سازی سرور روبرو شده است. در مقیاس بزرگتر مبتنی بر شبکه ذخیره سازی در تقاضا مانند این لایه از رایانش ابری میباشد. برخی از ارائه ها فراتر از این و ارائه پلتفرمها برای ارائه دهندگان سرویس شامل ذخیره سازی ، امنیت ، مدیریت هویت و دیگر عملکردها میشود. یک مثال خوب از این نوع ارائه Amazon Simple Storage Service (Amazon S3) سرویس ذخیره سازی ساده آمازون میباشد. Amazon S3 ذخیره سازی برای اینترنت را ارائه میدهد که برای محاسبات آسانتر در مقیاس وب برای توسعه دهندگان نرم افزار طراحی شده است. Amazon S3 یک اینترفیس وب سرویس که میتواند برای ذخیره و بازیابی داده در هر زمان از هر جا بر روی وب استفاده شود را ارائه میدهند. S3 دسترسی به مقیاس پذیری و ذخیره سازی قابل اعتماد داده ها را برای یک هزینه میدهد. S3 در پیاده سازی ، آستانه تحمل و ساخت از یک مجموعه ای از اینترفیسهای ساده و بسیار granular غیرمتمرکز است.

• Cloud Platform—Platform as a service:

ارائه دهندگان پلتفرم زیرساختی برای توسعه و اجرای نرم افزار برنامه های مبتنی بر وب را فراهم میکنند. مثالها عبارتند از امکانات برای طراحی برنامه ، توسعه برنامه ، تست ، استقرار و هاستینگ و همچنین سرویسهای برنامه مانند همکاری تیم ، امنیت ، نسخه گذاری برنامه و ابزار برنامه میباشد. تیم توسعه دهنده اغلب از طریق مرورگر خود با ورود به پلتفرم مجازی ابر ، باهم کار میکنند. سرورهای مجازی در حال اجرا در ابر میتوانند شامل وب سرویسها ، برنامه های سرورها و موتورهای دیتابیس ها باشند. برای برخی از ارائه دهندگان ، اینترفیسهای برنامه نویسی نرم افزار (API ها) به عملکردهای مبتنی بر وب از پیش تعریف شده ارائه شده اند. ProgrammableWeb.com لیست بیش از 600 API که بر روی اینترنت در سال 2008 با گوگل مپ ، فلیکر ، آمازون ، و یوتیوب را که بزرگترین سهم بازار از Calls را به اشتراک گذاشته است. ارائه دهندگان پلتفرم بطور کلی بخشی از یک معماری چند مستاجره که در آن بسیاری از سازمانهای نامربوط ممکن است توسط برخی از همان زیرساخت پلتفرم پشتیبانی شوند را متصور میشوند. پلتفرم ها میتوانند بوسیله اضافه کردن پردازش و ذخیره سازی منابع بصورت پویا از رشد در خواسته های عملیاتی برای یک وب اپلیکیشن مشتری خاص پشتیبانی کرده و مقایس پذیر شوند. بعنوان مثال از یک ارائه پلتفرم Force.com است که بعنوان یک نرم افزار ارائه دهنده پشتیبانی از SalesForce.com آغاز کرده است. API ها و ابزارهای توسعه برای پشتیبانی از برنامه SalesForce بیشتر ابزارهای کلی پلتفرم را برای هر مشتری ارائه دهنده نرم افزار مبتنی بر اینترنت فراهم میکند.

• Cloud Services—Components as a service:

این لایه از پشته رایانش ابری شامل تعریفی از اجزای نرم افزار ، اجرای آن در یک مد توزیع شده ، سراسر اینترنت تجاری میباشد. این تعریف بیشتر شبیه SOA است که زیر مورد بحث ، با اینترفیسهای سرویس تعریف شده بعنوان پایه ای برای یکپارچه سازی سیستم به سیستم میباشد.

• Cloud Applications—Soft ware as a service(SaaS):

این تعریف مبتنی بر ابر برای دسترسی به آنچه که بطور سنتی در محل دسکتاپ نرم افزار است ، خواهد بود. بعنوان مثال ادوب فتوشاپ ، یک برنامه برای دستکاری تصاویر ، به کاربران نهایی بر روی سی دی ها برای سالهای سال توزیع شده بود. امروزه ، شما همچنان میتوانید یک نسخه از فتوشاپ را از دیسک نصبی آن ، نصب کنید ، یا شما میتوانید به یک نسخه کاملا آنلاین از برنامه مشابه ، تحت عنوان اکسپرس (Express) بروید. در اکسپرس آنلاین ، شما میتوانید عکسهایتان را در یک فایل محیطی هاست آپلود کرده و کار بر روی تصاویر با برخی فیلترها و قابلیتهایی که در نسخه نرم افزار سنتی آن است ، را انجام دهید. اکسپرس بعنوان مثالی از SaaS است ، اگرچه این تنها شکل به طول کشیدن (can take) SaaS نیست. برای مثال ، ارائه دهندگان برنامه های وب گوگل ، مانند جی میل ، تقویم گوگل ، تالک ، داکز و سایتها ، با عملکرد مشابه نرم افزارهای سنتی اداری است. یکی از مزایای این روش این است که برنامه را میتوان بصورت مداوم بوسیله ارائه دهنده نرم افزار بدون مشکلی و خرید دیسکهای نصبی ، بروزرسانی کرد. هربار که کاربر به سایت لاگ کرد ، کاربر آخرین نسخه از برنامه را خواهد گرفت. همچنین ارائه دهنده نرم افزار نیز یک وب اپلیکیشن بسیار مقیاس پذیر با استفاده از یک معماری چند لایه وب ، بر روی زیرساختهای قابل توجه پیاده سازی میکند. معایب آن شامل وابستگی کامل بر روی شبکه های زیربنایی برای دسترسی به برنامه میباشد. هنگامی که شبکه دان (پایین) است ، کاربر نمیتواند کاری با برنامه مبتنی بر شبکه انجام دهد. در مقابل نسخه دسکتاپ از نرم افزار نیاز به اتصال شبکه برای کار تولیدی ندارد. Software as a Servis (SaaS) یک مدل از توسعه نرم افزار است که در آن نرم افزار بعنوان یک سرویس هاست شده (hosted) به مشتریان در سراسر اینترنت ارائه میشود. با برطرف نمودن نیاز به نصب و اجرای برنامه بر روی کامپیوتر شخصی مشتریان ، SaaS بار مشتریان (فشار روی مشتری ناشی از ) را از تعمیر و نگهداری نرم افزار ، عملیات در حال انجام (ongoing) و پشتیبانی را کاهش میدهد. در مقابل ، مشتریان کنترل نسخه نرم افزار یا تغییرات لازم را واگذار میکنند. علاوه بر این ، هزینه های استفاده از سرویس به یک هزینه مستمر بجای هزینه تنها در زمان خرید تبدیل میشود. (ارجاع به SaaS در ویکیپدیا) با SaaS به مقدار قابل توجهی از پردازش در اینترنت "ابر" در دیتا سنترهای از راه دور و نه بر لوکال دسکتاپ رخ میدهد. لوکال دسکتاپ در درجه اول یک layer device (لایه دستگاه) در این سناریو ارائه میدهد. با استفاده از بسیاری از برنامه های نرم افزاری آنلاین ، کاربر پردازشهای در حال توزیع از طرف آنها در سراسر پردازنده ی ابر بوسیله نرم افزار ارائه سرویس پراکنده میشود. بعنوان مثال ، در پایگاه ویکیپدیا ، رایانش ابری یک سبک از محاسبات مربوط به قابلیتهای آی تی است که یک سرویس را به کاربران اجازه میدهد برای دسترسی به خدمات فناوری فعال از اینترنت (در ابر) بدون دانشی از تخصص و یا کنترل بر زیرساختهای فناوری که آنها پشتیبانی میکنند را ارائه میدهد.

سرویس های وب و رایانش ابری

مدل های سرویس رایانش ابری

با این حال ، ارائه دهندگان ابر از انواع مختلف مدلهای سرویس و برخی از مدلهای سرویس پایدار به سود بیشتر از استانداردسازی از دیگران استفاده میکنند. بر اساس سرویس هایی که ابر فراهم میکنند ، سه نوع مدل رایانش ابری وجود دارد. زیرساختی از یک سرویس IaaS، پلت فرمی از یک سرویس PaaS، و نرم افزاری از یک سرویس SaaS. ادامه این بخش به چگونگی بهرمند شدن از استانداردسازی IaaS , PaaS و SaaS میپردازد.

Infrastructure as a Service (IaaS) : IaaS یک مدل سرویس است که بیشترین سود از استانداردسازی را میبرد زیرا بلوکهای ساختمان اصلی IaaS بعنوان نماینده حجم کاری (work-load)از تصاویر ماشین مجازی و واحدهای ذخیره ای که متفاوت از data-typed از داده های خام باشد. برای انتقال حجم کار ، تلاشهای استانداردها مانند OVF و VHD به کاربران اجازه میدهد تا یک تصویر را از یک ارائه دهنده استخراج کرده و آن را درارائه دهنده دیگری آپلود نماید. با توجه به اینکه اکثر ارائه دهندگان IaaS به مشتریان اجازه نصب و اجرای هر پلتفرمی را میدهند ، یک manual (راهنمای) بیشتر و زمان گیر از انتقالی که برای بازیابی عکس از ارائه دهنده فعلی میخواهند ، یک عکس جدید در ارائه دهنده جدید ایجاد و نرم افزار مجدد نصب میگردد. این manual (راهنمای) انتقال نبایستی نیازمندی استانداردها را تازمانی که راهی برای بازیابی جایگاه برنامه (بعنوان مثال داده برنامه ها ، فایلها ، پردازشهای در حال اجرا) از عکس منبع و حرکت به یک عکس جدید را انجام دهد. برای انتقال داده ، تلاشهای استانداردها مانند CDMI و API آمازون S3 ، که پشتیبانی ارائه دهندگان متعدد را دارد ، کاربران را برای استخراج داده از یک ارائه دهنده و بارگذاری آن در یک ارائه دهنده متفاوت قادرمیسازد. اگر یک ارائه دهنده این رابط استانداردها را با استفاده از SOAP – یا پروتکل های مبتنی بر REST پیاده سازی کند ، ابر مزایای استفاده از سهولت توسعه و در دسترس بودن ابزار را ارائه خواهد داد. با این حال ، این استانداردها بیشتر برای داده های خام که not typed (تایپ شده نیستند) مفید است (بعنوان مثال عکسهای ماشین مجازی ، فایلها ، blobs (حبابها) ) زیرا منبع ابر در این مورد صرفا بعنوان یک ظرف عمل کرده و معمولا نیازی به انتقال داده ندارد. برای داده های تایپ شده (typed data) ، انتقال داده مشابه هر انتقال داده دیگری رخ میدهد وظیفه: کاربران باید داده را از منبع اصلی استخراج کرده ، و بازگزاری کنند در منبع هدف ، که میتواند یک فرآیند پیچیده باشد. تلاش موردنیاز برای تحول نیز بستگی دارد به عواملی مانند شباهت بین اهداف و منابع تکنولوژیهای ذخیره سازی داده (بعنوان مثال ، انتقال از یک دیتابیس سازگار با SQL به دیگری آسانتر از آبجکت دیتابیس به یک پایگاه داده رابطه ای یا بعلکس خواهد بود) و مشابه اینترفیس عملیاتها (بعنوان مثال ، دو اینترفیس مبتنی بر SOAP میتوانند عملیات کاملا متفاوتی را داشته باشند). IaaS زیرساخت بعنوان یک سرویس عمدتا شامل زیرساخت های در دسترس محاسباتی بر روی اینترنت مانند چرخه محاسبه و ذخیره سازی میشود. IaaS به سازمانها و توسعه دهندگان اجازه میدهد تا به گسترش تقاضاهای زیرساخت های فناوری اطلاعات بپردازد. نمونه هایی از ارائه های IaaS به ترتیب حروف الفبا عبارتند از : Amazon Elastic Compute Cloud (EC2) : ماشین های ویژه مجازی ، بنام ماشین عکسهای آمازون AMI ، که میتواند بر روی زیرساختهای EC2 توسعه یافته و اجرا شود. Amazon Simple Storage Solution (S3) : منابع ذخیره سازی بصورت مقیاس پذیری پویا Amazon’s other data-related offerings : ذخیره سازی الاستیک بلوک ، که حجم ذخیره سازی در سطح بلوک را برای استفاده با موارد EC2 آمازون فراهم میکند ، SimpleDB که یک منبع داده های غیررابطه ای است ، و منبع داده های ارتباطی که یک منبع داده رابطه ایست. GoGrid Cloud Servers : محاسبات مقیاس پذیر به صورت پویا و ذخیره سازی منابع Rackspace Cloud Servers : محاسبات بصورت پویا مقیاس پذیر ، ذخیره سازی و منابع موازنه بار PaaS بر روی پلتفرمهای توسعه یافته نرم افزار است که اجازه استفاده از منابع خارجی برای ساخت و برنامه های میزبان (هاست) را می دهد. نمونه هایی از ارائه های PaaS به ترتیب حروف الفبا عبارتند از : CloudBees : پلتفرمی برای ساخت ، استقرار و مدیریت برنامه های جاوا Engine Yard : پلتفرمی برای ساخت و گسترش برنامه های Ruby و Php که میتوانند با افزودنی ها گسترش یابند. Google App Engine : پلتفرمی برای توسعه و اجرای جاوا ، Python و برنامه های Go که بر روی زیرساختهای گوگل است. Heroku : پلتفرمی برای استقرار برنامه های جاوا ، Ruby ، پایتون ، Clojure ، Node.js و Scala که میتوانند با افزودن (add-ons) به منابع گسترش یابد. Microsoft Windows Azure : بر روی تقاضای محاسبه و ذخیره سازی سرویسها و همچنین بعنوان یک توسعه و استقرار پلتفرم برای برنامه هایی که در ویندوز اجرا میشوند. Salesforce Force.com : پلتفرمی برای ساخت و اجرای برنامه ها و قطعات خریداری شده از AppExchange یا برنامه های سفارشی SaaS یک مدل از استقرار و بکارگیری نرم افزار است که در آن شخص سوم نرم افزار به مشتریان برای استفاده از یک سرویس مبتنی بر تقاضا را فراهم میکند. نمونه هایی از ارائه های SaaS به ترتیب حروف الفبا عبارتند از : Google Apps : ایمیل وب بیس ، تقویم ، مدیریت اسناد و ایجاد و مدیریت وب سایتهای مبتنی بر وب Microsoft Office 365 : ایمیل تقویم ، برنامه های مبتنی بر وب آفیس ، وب کنفرانس و اشتراک فایل NetSuite : برنامه های نرم افزاری مدیریت کسب و کار که شامل حسابداری ، برنامه ریزی منابع سازمانی ERP ، مدیریت موجودی ، مدیریت ارتباط با مشتری CRM و تجارت الکترونیکی Salesforce : نرم افزار برنامه های CRM SurveyTool : پلتفرم نظرسنجی مبتنی بر وب برای جمع آوری بازخورد از کارکنان ، مشتریان ، گروه تمرکز یا هر کاربر فعال پایگاه Zoho : مجموعه زیادی از برنامه های مبتنی بر وب ، بیشتر برای استفاده شرکتها

Platform as a Service (PaaS) : فواید مدل سرویس PaaS از استانداردسازی IaaS کمتر است. سازمان هایی که PaaS را خریده اند برای مزایای درک شده از پلت فرم توسعه انجام داده اند. این پلتفرم قابلیت های بسیاری در خارج از باکس ، مانند محیطهای مدیریت برنامه ، احرازهویت کاربر ، ذخیره سازی داده ، پیامهای قابل اعتماد ، و دیگر قابلیتهایی که در مقابل کتابخانه هایی که میتواند برنامه ها را یکپارچه کند ارائه میدهد. این قابلیت به یک زبان خاص و زمان اجرای محیط گره خورده است. برای مثال موتور برنامه های گوگل پشتیبانی میکنند از برنامه هایی که در محیطهای جاوا ، پایتون و گو نوشته شده است. مایکروسافت Azure پشتیبانی میکند از برنامه هایی که در محیط دات نت و بیشتر برنامه هایی که در محیط جاوا ، پی اچ پی و نود دات جی اس نوشته شده است. انگیزه ها برای اتخاذ PaaS در درجه اول توسعه سریع و استقرار و پتانسیل برای این برنامه هایی که به تعداد بیشتری از مشتریان خدمات میدهند ، میباشد. درخواست خرید به یک ارائه دهنده Paas به معنای خرید از یک پلتفرمی در همان راهی است که سازمان ها به طور سنتی دارند ، مبتنی بر ارزش افزوده ، مهارتها ، و هر معیار دیگری است. ارائه دهندگان میتوانند برنامه ها را با انتخاب پلتفرم هایی که از ابزارها و زبانهای بیشتر استاندارد شده پشتیبانی میکنند ، مانند آنهایی که مبتنی بر زبانهای جاوا یا اینترفیس های دسترسی به داده استاندارد ، شامل اتصال به پایگاه داده جاوا (JDBC) ، اتصال به پایگاه داده باز (ODBC) و SQL ، را سازگارتر کنند. با این حال ، حتی در میان ارائه دهندگانی که از همان زبانهای برنامه نویسی پشتیبانی میکنند ، اینترفیس هایی وجود دارد بر پایه سرویسهایی مانند احرازهویت ، فایلها ، صف ها ، توابع هش ، و وظایف ، که ممکن است سازگار نباشند. علاوه بر این ، گزینه های بومی ممکن از قویتر از گزینه های استاندارد شده باشند. (بعنوان مثال ، سود بیشتری که اتخاذ یک تصمیم میتواند ایجاد انگیزه کند). برای مثال ، داده ها به طور پیشفرض در موتور برنامه گوگل ذخیره میشوند که تکرار بالایی در انبارداده دارند که به طور خودکار تکرار همه داده های دیتاسنترها را ارائه میدهند. یک کاربر میتواند به منبع داده با یک API استاندارد یا یک API سطح پایین دسترسی داشته باشد. این مبادله ایست که API استاندارد در بیشتر برنامه های پرتابل مهیا میسازد اما کنترل کمتر و ارزش افزوده ارائه دهنده خاص کمتر ویژگیهایست که API سطح پایین ، و در نتیجه پایینترین مخرج مشترک برای ویژگیها را ارائه میدهد.

Software as a Service (SaaS): SaaS یک مدل تا حدودی متفاوت از IaaS و PaaS میباشد زیرا یک موافقت نامه صدور مجوز به نرم افزار شخص ثالث بجای یک مدل استقرار متفاوت برای منابع موجود در محدوده ای از ذخیره سازی داده تا برنامه ها است. مزایای استانداردسازی برای SaaS حتی محدودتر از PaaS میباشد. برای SaaS ارائه هایی مانند Salesforce.com CRM میشود ، کاربر ، کاربرنهایی (end user) است. با این حال ، دیگر ارائه های SaaS مانند نقشه های گوگل یا یاهو اجتماعی (Yahoo Social) که در آن کاربر میتواند به یک توسعه دهنده که ادغام قابلیتها از این سرویسها به دیگر برنامه ها را پیدا کند ، وجود دارد. در مورد دوم ، APIهای استاندارد شده مفید هستند زیرا آنها فرآیند توسعه را تسهیل میبخشند. با این حال ، مگر اینکه APIها از دیدگاه عملکردی یکسان هستند ، این استانداردسازی کمی به انتقال کمک میکند. انتقال برای این مورد هنگامی است که کاربر SaaS کاربرنهایی بوده باشد در همان راهی که با هر انتقال نرم افزار رخ میدهد زیرا هر ارائه دهنده SaaS منطق پردازش خود را دارد ؛ این به سادگی یک راه مختلف برای مجوز نرم افزار است. در این مورد ، تنها منطقه ای که SaaS از استاندارد سازی مفید میباشد ذخیره سازی داده است زیرا مهمترین نگرانی برای مصرف کنندگان SaaS ، خصوصا برای شرکت نرم افزاری SaaS مانند CRM یا منابع انسانی ، چگونگی استخراج داده های خود است. در یک حادثه که بطور گسترده به اطلاع عموم رسید ، سرویس ذخیره سازی آنلاین شات دان شد و یک ارائه دهنده SaaS 45% از داده های مشتری خود را از دست داد. در این مورد ، مصرف کننده مجبور به استخراج داده های خود از ارائه دهنده SaaS شد ، ارسال منطقی داده های متحول شده و سپس بارگزاری داده ها به یک ارائه دهنده SaaS جدید ، انجام شد. APIهای استاندارد شده میتوانند بطور بالقوه این کار را آسانتر کنند.

مقایسه رایانش ابری و SOA

نمودار ون زیر روابط بین وب سرویسها ، ساختار سرویس-اورینتد (SOA) و رایانش ابری را نشان میدهد. وب سرویس معرف رایانش ابری در این نمودار است زیرا رایانش ابری از وب سرویس برای اتصال به شبکه استفاده میکند. ( ممکن است شما استثنا پیدا کنید اما آنها بسیار نادر هستند.) این امکان وجود دارد ، با این حال ، وب سرویس ها در شرایط دیگری از رایانش ابری استفاده میشوند. این قبیل استفاده از وب سرویس ها ممکن است بخشی از یک ساختار سرویس-اورینتد باشد ، اما این ممکن نیست. وب سرویس ها میتوانند به سادگی یک کانکشن باشند. نهایتا ممکن است یک معماری سرویس-اورینتد و نه استفاده وب سرویسها برای ارتباطات را داشته باشید.

رایانش ابری و SOA در نگرانی ها و ملاحظات مشترک تداخل و همپوشانی دارند ، همانطور که در شکل 4 نشان داده شده است. مهمترین همپوشانی در نزدیکی بالای پشته رایانش ابری رخ میدهد ، در این منطقه از سرویسهای ابری شبکه، در دسترس اجزای برنامه و سرویسهای نرم افزاری میباشد ، مانند وب سرویسهای معاصر.

تعامل با وب سرویس

کشف سرویسهایی که از استانداردهای تکنولوژی موجود استفاده میکنند عمدتا وظیفه جستجو بر اساس کلیدواژه را در شرح سرویس پیچیده کمتر یا بیشتر را دارد. این فراتر از محدوده این مقاله به اظهارنظر در تمام مشکلاتی که هنگام تلاش برای کشف سرویسها برای کاربر رخ میدهد میباشد. امروزه تکنیکهای مورد استفاده کاربر بعنوان مثال استفاده از عبارات دقیق و شناخت کامل آن، توسط استانداردهایی مانند WSDL ارائه شده است. ارتقای این وضعیت بوسیله چند روش تکنیکهای موجود برای تطبیق شناخت کامل و یا گسترش توسط اصطلاحنامه مناسب داده شده است. در ادامه ما با انتخاب task سرویسهای مناسب برخورد خواهیم کرد که پس از کشف یک سرویس مطابق task یک کاربر علاقمند ، به همراه خواهد داشت.

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

به کارگیری سرویس وب پویا در یک محیط ابری

برای استفاده از سرویس های وب، نیاز به استقرار آن ها می باشد. فقط تصاویر سرور ها در فضای کاری ابر آپلود می شوند، و مشخصات جریان کاری که برای آنها ایجاد شده است، توانایی برقرای ارتباط با مراحل مختلف فرآیند اجرایی را دارا می باشند. برای فرآیند مذکور، دو نوع استقرار مورد استفاده قرار می گیرد. تصویر TAVERNA به عنوان یک سرور اختصاصی و TICCLOPS و تصویر FROG، به عنوان سرویس های وب پویا به کار گرفته شده اند. به منظور دستیابی به سناریوی استقرار پویا، سرویس های مورد نظر فقط در زمان نیاز به آن ها درخواست و در قسمتی از جریان کاری استفاده می شوند. این دو سرویس، برای مدیریت پیکربندی جریان کاری و مدیریت بکارگیری تصاویر و فرآیند تخریب، ایجاد شده است. زمانی که یک جریان کاری به سمت سرویس اول ارسال می شود، ارزیابی می شود که آیا هر یک از سرویس های مندرج در فرآیند جریان کاری، ماهیت پویا دارد یا خیر.

فصل سوم:استاندارد های سرویس های وب در جهت تامین نیازمندی های ابری

= استاندارد های سرویس های وب در جهت تامین نیازمندی های ابری

نقش استاندارد در محیط های رایانش ابری

کاربران ابر تمایل ویژه ای به استقبال از استانداردهایی که به انتقال حجم کار (work-load) و انتقال یوزکیس های داده میپردازند، دارند؛ چون چنین استانداردهایی نگرانی قفل فروشنده (vendor lock-in) را کاهش میدهد. این امر استانداردسازی مستلزم فرمتهای فایل تصویر ماشین مجازی و API هایی برای ذخیره ابر میباشد. استانداردسازی برای احرازهویت کاربر Use case این مزیت را دارد که شناسایی کاربر بر اساس OpenID یا احرازهویت پروتکلهای مبتنی بر Oauth صورت میگیرد ، برای مثال ، میتوان در تمام چندین ارائه دهنده سرویسی که از این استانداردها پیشتیبانی میکنند استقاده کرد. بطور مشابه ، استانداردسازی به پشتیبانی از یوزکیس مدیریت حجم کاری (workload-management) جهت هرگونه تلاش های مربوط موجود در ایجاد کلاینت های مدیریت حجم کاری و اسکریپتهایی که میتوانند در سرتاسر چندین ارائه دهنده استفاده شوند ، میپردازد.

انتقال و مدیریت داده ها

Use Case ها برای انتقال و مدیریت داده های مربوط ، داده را از یک ارائه دهنده ابری به دیگری انتقال میدهند. همانطور که با انتقال حجم کار ، به استخراج داده از یک محیط ابری و آپلود داده در محیط دیگر ابری نیاز است. علاوه بر این ، در زمینه ایجاد قابلیت همکاری ، داده ها یکبار به ارائه دهنده جدید انتقال داده میشوند ، هر برنامه ای که اجرا میشود ، ساخت ، بازیابی ، بروزرسانی یا حذف (CRUD) عملیات بر روی داده در ارائه دهنده ابر اصلی باید تا کار در ارائه دهنده ابر جدید ادامه یابد. دو نوع ذخیره سازی ابر وجود دارد. کارهای ذخیره سازی Typed-data بطور مشابه سازگار با پایگاه داده SQL میباشد و قادر است عملیات های CRUD بر روی جدول تعریف شده کاربر انجام دهد. ذخیره سازی Object عملیات های CRUD بر آبجکتهای عمومی که رنجی از آیتم های داده (مشابه به یک ردیف از جدول) ، به فایلها ، به تصاویر ماشین مجازی ، انجام میدهد. برخی از استانداردهایی که از این Use case ها پشتیبانی میکنند ، بخصوص برای Object Storage عبارتند از : Cloud Data Management Interface (CDMI) : CDMI یک استاندارد پشتیبانی شده بوسیله انجمن Storage Networking Industry (SNIA) میباشد. CDMI یک API برای عناصر داده CRUD از یک محیط ذخیره سازی ابری تعریف میکند. همچنین این API برای کشف قابلیت ذخیره سازی و مدیریت ظروف داده تعریف شده است. SOAP : حتی اگر SOAP یک یک استاندارد خاص داده نباشد ، چندین ارائه دهنده ذخیره سازی ابری و اینترفیس مدیریت ذخیره سازی هستند که از پروتکل SOAP استفاده میکنند. SOAP یک مشخصه ای از W3C است که یک چارچوب برای ساخت پیغامهای XML-based در محیط شبکه شده غیرمتمرکز را تعریف میکند. نسخه فعلی 1.2 است و HTTP مکانیزم انتقال اولیه است. آمازون S3 یک اینترفیس SOAP-based ارائه میدهد که در دیگر محیطهای ذخیره سازی ابر شامل Eucalyptus و نیز OpenStack پشتیبانی میشود. Representational State Transfer (REST) : Rest با یک استانداردهای data-specific نیست اما چندین ارائه دهنده ذخیره سازی ابری از رابط RESTful کاملا پشتیبانی میکنند. REST بعنوان یک معماری درنظرگرفته شده و نه یک پروتکل. در پیاده سازی یک REST ، هر موجودیتی که میتواند نام گذاری شود ، شناسایی شود ، آدرس دهی شود یا هندل شود یک منبع درنظر گرفته میشود. هر یک از منابع که قابل آدرس دهی باشند از طریق شناسه منابع جهانی و برخی اینترفیس های ارائه دهندگان توسط HTTP: GET,POST,PUT,DELETE ، تعریف میشوند. آمازون S3 یک رابط RESTful که از Eucalyptus و نیز Open Stack پشتیبانی کنند را ارائه میدهد. ارائه دهندگان دیگر با رابط RESTful برای مدیریت داده ها شامل Salesforce.com’s forsce.com , Microsoft Windows Azure (Windows Azure Storage) , Open Stack (Object Storage) و Rackspace (Cloud Files) استفاده میکنند. این API بوسیله CDMI که رابط یک RESTful است تعریف شده است.

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

دو استاندارد سرویس وب شامل WSSecureConversationو WS-Federationمی باشند. با گذشت زمان، زبان های مختلف، مکانیسم ها و ابزار ها روی نرم افزار های مختلف و پلت فرم های سخت افزاری برای تعیین و اجرای انواع مکانیسم های امنیتی مانند رمز نگاری و کنترل دسترسی، توسعه داده شدند. در تنظیمات سرویس های وب، مکانیزم های امنیتی از محرمانگی و تمامیت داده ها در حالت انتقال و یا استراحت آن ها، محافظت می کنند. علاوه بر این، حفاظت از اطلاعات نباید فقط دو راه ساده تعاملات کلاینت-سروری در نظر گرفته شود بلکه، گسترش تعاملات پیچیده تر، به عنوان نمونه ای از فرآیند کسب و کار، از طریق خدمات وب چندگانه اجرا شده است. نیاز به فراهم کردن امنیت end to end از طریق مکانیزم های امنیت توزیع شده و ناهمگن، برای توسعه استانداردهای امنیت سرویس های وب ، با هدف نهایی از ایجاد پیاده سازی های مختلف سازگار با همان توابع امنیتی نام گذاری شده اند. تکنولوژی سرویس های وب، با قابلیت عملکرد متقابل پیاده سازی معماری سرویس گرا، مورد استفاده گسترده صنعت قرار گرفته اند(SOAs). این تکنولوژی شامل مجموعه های در حال تکامل از استانداردهای مرتبط که هدف آن در مقابله با اهداف SOA و چالش های آن می باشد. سازمان ها به دنبال کاهش هزینه های توسعه و نگهداری سیستم های خود، درحالی که ماندن انعطاف پذیری بیشتری از نظر قابلیت، استاندارد های سرویس های وب را به عنوان یک راه حل ممکن در نظر بگیرید. یک دلیل بزرگ، پشت تصویب استاندادرهای سرویس های وب، ویژگی های کلیدی کیفی آنها مانند قابلیت همکاری، توسعه و اصلاح است. بسیاری از سازمان ها برای ایجاد استاندارد های باز کار میکنند اما، سه سازمان کلیدی عبارتند از: سازمانی برای پیشبرد استاندارد های اطلاعاتی ساخت یافته(OASIS)، که برای زیرسازی و اجرای استاندارد های خدمات وب ایجاد شده است. کنسرسیوم جهای وب W3C، مسئول (HTTP) XML، SOAP، و استاندارد های دیگر می باشد. W3C شامل کمیته های بسیاری با هدف ساخت و حفظ استاندارد های وب می باشد. سازمان متقابل خدمات وب (WS-I) راهنمایی های عملی، بهترین شیوه و منابع برای توسعه سازگار راه حل های خدمات وب فراهم می کند. استاندارد های خدمات وب دارای تعداد قابل توجهی از شرکت های فناوری از جمله مایکروسافت، آی بی ام، اوراکل، BEA و غیره می باشند. این شرکت ها به مشارکت در استاندارد های وب، حمایت کامل از آنها، و ایجاد اجزای نرم افزاری ساخته شده روی استاندارد های سازگار و ادغام اجزای آنها درون محصولات، فعال هستند. در نهایت، هدف از استفاده از استاندارد های وب سرویس، تولید یک سیستم توسط نصب و راه اندازی محصولات توسعه داده شده توسط شرکت های مختلف می باشد که اجازه می دهد آن دسته از محصولان به صورت یکپارچه با هم کار کنند. یکی از اهداف استاندارد های خدمات وب، حمایت از دستگاه سازگار و تعامل دستگاه بر روی یک شبکه می باشد. این بر اساس فناوری پیام های مبتنی بر استفاده از XML انجام می شود و شامل: زبان توصیف خدمات وب(WSDL)، پروتکل دسترسی شی ساده(SOAP)، و توصیف، کشف و ادغام جهانی(UDDL) .این ها علاوه بر هر استاندارد جدید اضافی، توسط موسسات استاندارد های مختلف و اشخاص مدیریت می شوند. استاندارد های امنیتی سرویس های وب ابتدا توسط IBM و فریم ورک مایکروسافت نوشته شد. بررسی کلی، برای استاندارد های خدمات وب صورت گرفت و 60 استاندارد در 12 دسته منتشر شد. استاندارد های خدمات وب به عنوان یک راه حل کامل امن، پیاده سازی و ارائه شد که شامل ویژگی های زیر می باشد: •* مستقل: از زیر لایه های اجرایی فناوری و برنامه های کاربردی پلت فرم محسوب می شود. • *توسعه پذیر: برای رسیدگی به نیازهای جدی و / یا بهره برداری از فن آوری های امنیتی جدید. • *قابل استفاده مجدد: سرویس های وبی که با ایتفاده از اتاندارد های سرویس وب ساخته شده اند برای استفاده مجدد مناسب در سایر سرویس ها بسیار آسان هستند. • *انعطاف پذیر: مکانیزم های ناهمگن موجود که شامل الگوریتم های رمزنگاری مختلف، مکانیزم های کنترل دسترسی مختلف و غیره هستند قابل تطبیق خواهند بود.. • *قابل ترکیب: پشتیبانی از برنامه های کاربری مرکب مانند گردش فرآیند کسب و کار.

چندین کمیته مانند W3Cو OASIS در حال توسعه استاندارد های سرویس وب هستند.

در ابتدا، وب سرویس هایی که از SOAP ، REST و JSON استفاده میکنند بحث شده است. این بخش بدنبال اینست که با سابقه از وب سرویس هایی که به توصیف زبانهای وب سرویس WSDL و Universal Description,Discovery,Integration UDDI را پوشش دهد بپردازد.

مشخصات وب سرویس ها

سه مشخصه برای وب سرویسهایی که در این بخش نشان داده شده : SOAP ، REST و JSON Simple object access protocol, SOAP: SOAP در اصل بخشی از خصوصیاتی که شامل زبان توصیف وب سرویس WSDL و شرح یونیورسال ، کشف و یکپارچه سازی UDDI میباشد. درحال حاضر بدون WSDL و UDDI استفاده میشود. در عوض از فرآیند کشف شرح داده شده در قسمت پایین تاریخچه مشخصات وب سرویسها ، پیامهای SOAP بدون استفاده از یک مخزن، سخت رمز شده یا تولید شده اند. این تعامل در شکل زیر نشان داده شده است. مشخصات SOAP : • *بخوبی برای محیط های محاسباتی توزیع شده کاربرد دارد. • پروتکل و middleware های زیادی برای راه اندازی ارتباط لازم است. • *محتوای پیغام ردوبدل شده مشخص کننده سرویس فراخوانی شده می باشد. • *کاملا قابل اطمینان است. • *حجم اطلاعات منتقل شده باید منطبق با SOAP schema باشد. • *از استانداردهای فراوانی برای مباحث امنیت، قابلیت اعتماد و تراکنش ها پشتیبانی می کند. • *هر دو پرتکل SMTP و HTTP بعنوان پروتکل لایه application قابل استفاده هستند. • *مکانیزم error handling ندارد. • *پیچدگی بالا در پیاده سازی.

REST, Representational states transfer protocol: REST تجدیدنظر به توسعه دهندگان است زیرا یک سبک مشابه باعث میشود استفاده آن را آسانتر از SOAP کند. این نیز کمتر پرگو است (کوتاهتر است) به طوری که حجم کمتر هنگام برقراری ارتباط ارسال میشود. این تعامل در شکل زیر نشان داده شده است. یک معماری جدید وب سرویس هست که از پروتکل http برای ارتباط بین دو سیستم(client-server) استفاده میکند و ساده تر ازمعماری‌های پیچیده مانند RPC ،‌CORBA و SOAP است و اکثر وب سایت ها نظیر گوگل از Rest به جای معماری های پیچیده ای مثل SOAP در طراحی وب سایت استفاده می کنند. REST شش قید الزامی برای معماری برنامه‌های شبکه تعریف می‌کند: •* کلاینت سرور (client-server) باشد. • *بدون حالت (stateless) باشد. •* قابلیت cache داشته باشد. (cacheable) • *سیستم لایه‌بندی شده (layered system) داشته باشد. • *واسط یکنواخت (uniform interface) داشته باشد. • *دارای قابلیت کد در صورت نیاز (code on demand) باشد.

• به سیستمی که این قیود را رعایت نماید، RESTful می‌گویند.

برنامه هایی بر پایه این معماری، با نام RESTful application خوانده میشوند و فقط با Request های CRUD پروتکل واسط، با هدف تعامل برقرار می کنند. از لحاظ رويكرد برنامه نويسي REST جايگزيني ساده براي سرويس‌هاي وب است. توسعه‌پذيري در تعاملات ميان اجزا، عموميت واسط ها، توسعه مستقل اجزا و استفاده از واسطه ها از كليدي ترين اهداف معماري REST مي‌باشد و همچنين استفاده از معماري REST در برنامه‌نويسي كارايي، سادگي، انعطاف‌پذيري، امكان مشاهده و نظارت، قابليت حمل و قابليت اطمينان را افزايش مي دهد. مشخصات REST : • *برای ارتباطات مدل نقطه به نقطه (point-to-point) طراحی شده است و برای محیط های توزیع شده قابل استفاده نیست. • *برای راه اندازی ارتباط احتیاج به پرتکل یا middleware خاصی نیست و فقط پروتکل HTTP کفایت می کند. •* بطور معمول URL در سرویس های REST بیانگر سرویس های سیستم می باشد. • *قابل اطمینان نیست. برای مثال ممکن است یک دستور HTTP DELETE وضعیت OK برگرداند در حالی که عملیات حذف در سرور انجام نشده است. • *محدودیتی در حجم اطلاعات منتقل شده وجود ندارد. •* فقط از استاندارد های مشهور مانند HTTP, SSL پشتیبانی می کند. •* با مدل HTTP transport ارتباط تنگاتنگی دارد. • *مکانیزم error handling بصورت توکار دارد. • *سادگی در پیاده سازی.

جاوا اسکریپت نشانه گذاری شی JSON: درحالیکه هردو SOAP و REST ازXML برای تبادل استفاده میکنند ، JSON از زیرمجموعه ای از جاوا اسکریپت استفاده میکند ، این در شکل زیر نشان داده شده است

مقایسه SOAP در مقابل REST

SOAP : مشخصات تکنولوژی • فرمت پیام • اتصالات پروتکل • شرح خدمات ... Rest : سبک معماری • مجموعه ای از محدودیت های معماری • اهرم استانداردهای وب • خواص مورد انتظار از سیستم را معرفی میکند.

در نهایت شایان ذکر است روش SOAP بیشتر برای پیاده سازی سرویس های میانی مورد استفاده قرار می گیرد و روش REST بیشتر در مواردی کاربرد دارد که نیازی به سرویس میانی وجود ندارد و اصطلاحا ارتباط point-to-point است.

پروتکل های استاندارد شده وب سرویس ها برای رایانش ابری

زبان توصیف وب سرویسها WSDL ؛ توضیحات یونیورسال، کشف و یکپارچه سازی UDDI ؛ و SOAP تشکیل دهنده مشخصات اصلی وب سرویسها هستند. این بخش تاریخچه ای فراهم کرده است.

Web Services Description Language, WSDL: WSDL واژه نامه XML است ، به شدت با UDDI بعنوان طرحی برای شناسایی مرز وب سرویسهای رجیسترشده با یک مخزن UDDI همراه است. WSDL تلاش در جهت خدمات جدا از فرمت سوابق ملموس و روش مورد استفاده برای کارها را دارد. این نتیجه یک فرمت مورد نیاز بین شرح خدمات مفهومی و عملکرد صریح خود را نشان میدهد. ارتباط بین تعمیم خدمات در سطوح نسبتا پایین از نظر فکری از اهمیت رفتار کد ، اتصالات سرویس و announcement harbour. WSDL یک درک از انواع مشارکت و بهره وری است اما ، مثل UDDI ، به معنای حفظ خدمات نیست.

زبان توصیف وب سرویسها WSDL فرمی اساسی برای مشخصات اصلی وب سرویسها است. شکل زیر استفاده از WSDL را نشان میدهد. در سمت چپ ارائه دهنده سرویس و در سمت راست یک مشتری سرویس است. مراحل مربوط به تهیه و مصرف سرویسها عبارتند از : 1. یک ارائه دهنده برای توصیف خدمات از WSDL استفاده میکند. این تعریف به یک مخزن (repository) از سرویسها منتشرشده است. انبار میتواند از توضیحات یونیورسال ، کشف ، و یکپارچه سازی UDDI استفاده کند و انواع دیگری از دایرکتوری ها نیز میتواند مورد استفاده قرار گیرد. 2. یک مصرف کننده سرویس مسائل یک یا چند کوئری به مخزن محل یک سرویس و تعیین نحوه چگونگی ارتباط با آن سرویس را دارد. 3. بخشی از WSDL ارائه شده توسط ارائه دهنده سرویس به مصرف کننده منتقل میشود. این مصرف کننده سرویس چه درخواست کننده باشد و چه پاسخگو برای ارائه سرویس گفته میشود. 4. مصرف کننده سرویس برای ارسال یک درخواست به ارائه دهنده سرویس از WSDL استفاده میکند. 5. ارائه دهنده سرویس پاسخی را که از مصرف کننده سرویس انتظار میرود را فراهم میکند.

Universal Description, Discovery and Integration, UDDI: UDDI سرمایه گذاری رجیستری ارائه شده توسط مایکروسافت ، IBM ، Amazon و Ariba در راستای گسترش یک الگو برای رجیستری آنلاین از خدمات وب سرویس ها است. UDDI به گردش و نوآوری خلاقانه از تنظیم سرویسها و اختصاص دهی آن به توسعه دهندگان برای ارائه سرویس های محلی جهت عدم انحراف یا جذب خدمات جدید چندجانبه، کمک میکند. همکاران وب سرویس پک تجاری خود را در کنار واژه های کلیدی تگها ضبط و نگهداری میکنند. کاربران آینده نگر سرویس پک صنعتی از اساس رجیستری روی جستجوی کلیدواژه ها را برمیگردانند. این سواستفاده و همکاری در استفاده از سپردن مشابه کلیدواژه ها برای توصیف سرویس قابل درک است. دستگاه جستجوی متکی بر پیشتعریف، به برچسب زدن کلیدواژه و نه انتقال آن میپردازد. مخزن نشان داده شده در شکل بالا میتواند رجیستری UDDI باشد. رجیستری UDDI درنظرگرفته شده که درنهایت بعنوان وسیله ای با معنی "کشف" شرح وب سرویس با استفاده از WSDL است . ایده اینست که رجیستری UDDI میتواند به روشهای مختلف برای بدست آوردن اطلاعات تماس و وب سرویسهای در دسترس برای سازمانهای مختلف جستجو گردد. اینکه چقدر "کشف" تاکنون مورد استفاده قرار گرفته است بحثی گسترده است. با این وجود حتی بدون بخش کشف ، رجیستری UDDI یک راه برای بروز نگهداشتن بر روی وب سرویسهای سازماندهی شده ای است که در حال حاضر استفاده میکنید. این را میتوان در زمان طراحی استفاده کرد. یک جایگزین برای UDDI رجیستری ebXML است. SOAP, Simple object access protocol: همه پیامهای نشان داده شده در شکل بالا با استفاده از SOAP ارسال میشود. (SOAP در یک زمان برای پروتکل SOAP ایستاد. درحال حاضر ، حروف مخفف معنای خاصی ندارد.) SOAP اصل پاکت را برای ارسال پیام وب سرویس فراهم میکند. SOAP بطور کلی از HTTP استفاده میکند ، اما به معنای دیگر از اتصال ممکن است استفاده کند. استفاده از HTTP یک اتصال آشنا برای همه ما در اینترنت است. در واقع ؛ فراگیرندگی ارتباطات HTTP که به هدایت اتخاذ وب سرویسها کمک خواهد کرد.

SOAP یک پادمان مبتنی بر XML است، که برای رد و بدل کردن اطلاعات بین برنامه ها مورد استفاده قرار میگیرد. اطلاعات در SOAP به صورت پیام (Message) و از طریق پادمان‏های موجود در اینترنت مانند HTTP منتقل می‏شود (SOAP در سایر پادمان ها، مانند SMTP یا MIME نیز قابل استفاده است). به زبان ساده‏تر، SOAP یک پادمان برای دستیابی به یک سرویس ارایه شده در وب میباشد. آخرین نسخه SOAP، نسخه 1.2 می‏باشد. ویژگی های SOAP 1. یک پادمان ارتباطی است. 2. برای ارسال پیام استفاده می‏شود. 3. برای محیط اینترنت و شبکه طراحی شده است. 4. وابسته به محیط پیاده سازی و اجرا نیست. (Platform Independent) 5. مبتنی بر XML است. 6. از دیوارهای آتش (Firewall) گذر می‏کند ودیوارهای آتش مانع آنها نمی شوند (Block) نمی‏شوند. یکی از مسایلی که در دهه اخیر از اهمیت خاصی برخوردار بوده، چگونگی ارتباط برنامه‏ های تحت اینترنت با یکدیگر بوده است. همانطور که می‏دانید برنامه‏ های عادی از RPC (Remote Procedure Call) برای فراخوانی اشیاء DCOM یا CORBA، استفاده می‏کنند. اما مشکلی که در این نوع فراخوانی‏ها در بستر اینترنت وجود دارد، مسدود شدن این نوع ترافیک‏ها در Proxy Server ها و دیوارهای آتش (Firewall) ها است. در صورت استفاده از SOAP با این مشکل روبرو نخواهید بود SOAP .به راحتی شما را قادر خواهد کرد تا بین برنامه‏ هایی که در بسترهای متفاوت طراحی شده اند و در بسترهای متفاوتی در حال سرویس ‏دهی هستند، ارتباط برقرار کنید.

ساختار SOAP پیام ها (Message) ها در SOAP یک فایل XML هستند که از ساختار زیر پیروی می‏کنند: 1. یک بخش ضروری که به آن (Envelope)پاکت نامه گفته می‏شود که مشخص می‏کند که این XML یک پیام SOAP است. 2. قسمت سرآیند (Header)که اختیاری است. این بخش شامل اطلاعاتی در مورد خود برنامه است. در صورتی که از سرآیند استفاده شود، باید اولین عنصر در ساختار Envelope باشد. 3. قسمت بدنه که ضروری است و شامل Call یا Response است. در واقع مشخص کننده درخواستِ برنامه‏ی سرویس‏ گیرنده یا پاسخ برنامه سرویس‏ دهنده است. 4. قسمت Fault که قسمت خطا است و اختیاری است و اطلاعاتی درباره خطاهای بوجود آمده در هنگام پردازش پیام در خود دارد. قوانین مهم در ساختار پیام 1. پیام حتماً باید در قالب XML باشد. 2. باید از Namespace تعریف شده در Envelope پیروی کند. 3. فقط باید از نوع داده‏ های تعریف شده و مجاز استفاده کند. 4. در قالب پیام، نباید از DTD استفاده شود. DTD برای یک XML ، مانند Design View یک جدول در Database است و مشخص می‏کند که فیلدهای آمده در XML از چه نوع هستند و با چه ترتیبی می‏آیند. برای مثال: <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> 5. نباید شامل دستورات پردازشی باشد. قالب کلی پیام قالب پیام به صورت زیر است: <?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

   <soap:Header>
         ...
   </soap:Header>
   <soap:Body>
         ...
         <soap:Fault>
         ...
         </soap:Fault>
   </soap:Body>

</soap:Envelope>

برای مشاهده جزئیات بیشتر و ساختار کامل پیام آدرس زیر را کلیک کنید.

http://www.w3.org/2001/12/soap-envelope نوع داده های مجاز را نیز در آدرس زیر می‏توانید مشاهده کنید:

http://www.w3.org/2001/12/soap-encoding توجه: encodingStyle مشخص کننده قالب نامه است که به طور استاندارد مقدار مشخص شده در مثال را دارد. یک درخواست و پاسخ آن با SOAP هنگام استفاده از پادمان HTTP، در هر درخواست باید Content-Type و Content-Length مشخص شود. که برای SOAP، موارد ارسالی در مثال زیر، به طور معمول مورد استفاده قرار می‏گیرند. در این مثال ، درخواست قیمت سیب و پاسخ آن آورده شده است. مشتری (Client) یک XML را به کارگزار می فرستد که در آن قالب مشخص شده توسط برنامه کارگزار (Server) رعایت شده است و درخواست مشتری در آن قرار دارد. در این مثال، قیمت سیب، موردنظر است که در برچسب m:GetPrice ، آمده است. در صورتی که قالب تعیین شده توسط سرور این اجازه را به شما بدهد که چند مورد را در یک در خواست بفرستید، می توانید این کار را انجام دهید. برنامه کارگزار نیز، با استفاده از یک فایل XML پاسخ مشتری را می دهد و قیمت را در یک برچسب با عنوان m:GetPriceResponse به مشتری تحویل می دهد. POST /InStock HTTP/1.1 Host: www.stock.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn

<?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

   <soap:Body>
         <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
               <m:Item>Apples</m:Item>
         </m:GetPrice>
   </soap:Body>

</soap:Envelope> HTTP/1.1 200 OK Content-Type: application/soap; charset=utf-8 Content-Length: nnn <?xml version="1.0" ?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

   <soap:Body>
         <m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
               <m:Price>1.90</m:Price>
         </m:GetPriceResponse>
   </soap:Body>

</soap:Envelope>

معایب SOAP همانطور که می‏د‏انید اولین حرف از حروف تشکیل دهنده ‏یSOAP ، S است که حرف اول Simple است. همین مورد، باعث شده است تا سادگی بر هرچیز در این سیستم، مقدم باشد. برای همین در SOAP بسیاری از کاستی ‏ها دیده می‏شود، که یکی از مهمترین آنها امنیت و قابلیت اعتماد پایین در SOAP است. همین کاستی باعث شده است که تولیدکنندگان نرم‏افزار به این فکر بیفتند تا SOAP را توسعه دهند و استانداردهای جدیدتری با امکانات بیشتری تولید کنند. استاندارد تولید شده توسط مایکروسافت با نام GXA (Global XML Web Services Architecture) ارایه شد. که یک پیاده‏سازی ازآن WSE (Web Services Enhancements) است. WSE یک ابزار قدرتمند است که شما با استفاده از DotNet Framework و WSE می توانید وب سرویس های امن و قدرتمند بنویسید. به بیان ساده‏تر WSE ابزار شما برای طراحی و ساخت وب سرویس ها با .NET می باشد.

شکل بعدی جزئیات بیشتری در پیامهای ارسال شده با استفاده از وب سرویسها را فراهم میکند. در سمت چپ شکل ، یک قطعه از WSDL فرستاده شده به مخزن است. این درخواست اطلاعات مشتری را نشان میدهد که نیازمند آبجکت حساب مشتری است. همچنین پاسخ اطلاعات مشتری که فراهم میکند یک سری از آیتم های مشتری شامل نام ، تلفن و آیتم های آدرس را نشان میدهد. در سمت راست این شکل ، یک قطعه از WSDL به مصرف کننده خدمات ارسال میشود. این قطعه را همان ارائه دهنده خدمات به انبار فرستاده است. مصرف کننده خدمات با استفاده از این WSDL برای ایجاد درخواست خدمات نشان داده میشود ، فلش اتصال از مصرف کننده خدمات به ارائه دهنده خدمات میباشد. پس از دریافت درخواست ، ارائه دهنده خدمات ، یک پیغام با استفاده از فرمت شرح داده شده در WSDL اصلی برمیگرداند. این پیغام در پایین شکل به نظر میرسد. XML برای تعریف پیام استفاده میشود. XML دارای فرمت پیغامهای تگ شده است. شما میتوانید این را در مثالهای SOAP و REST در بخش اول و بالای شکل ببینید. در هریک از نمونه ها ، تک <city> دارای ارزش برنزویل است. و </city> تگ پایان دادن است که نشان پایان ارزش city است. هر دو ارائه دهنده خدمات و خدمات مصرف کننده از این تگ ها استفاده میکنند. در حقیقت ، ارائه دهنده خدمات میتواند ارسال داده در پایین این عکس را درهر سفارش نشان دهد. مصرف کننده خدمات از تگها و نه دستوری از داده های مقادیر داده شده استفاده میکند.

علاوه بر موارد مذکور، در ادامه به معرفی پروتکل های دیگر استاندارد های سرویس وب در رایانش ابری نگاه کوتاهی خواهیم داشت. E-Speak را یک شرکت توسط Hewlett-Packard برای فعال کردن کشف سرویس پیشرفته هدایت میکند. E-Speak و UDDI اهداف مشابهی در تسهیل کردن تبلیغات و کشف خدمات دارند. E-Speak در مقایسه با WSDL در اینست پشتیبانی از شرح خدمات و انواع اطلاعات و و ویژگیهای یک سرویس مربوطه که درخواست خدمات متعادل با استعاره سرویس را دارد. این تا حد زیادی بر اساس ورودی-خروجی و نوع خدمات هماهنگ آماده شده است. E-Speak خدمات را بعنوان مجموعه ای از مشخصات در اصطلاح متفاوت متعدد که سپرده مشخصات جهانی به یک گروه منسجم از سرویسها نشان میدهد. تحقیقات موردنیاز درکنار استعاره سرویس ها با اعتماد به نفس این تمایز هماهنگ شده است. در حال حاضر ، هیچ اهمیت معنایی مرتبط به هر یک از این ویژگیها وجود ندارد. هر نتیجه که موقعیت آن طول بکشد برای آماده سازی بیش از کلیدواژه های استعاری سرویس ، بین هر زیرگروه اضافی تبعیضی قائل نیست. DAMIL-S تکامل مبتنی بر شناخت کامل در به تصویر کشیدن از وب سرویسهای مسکونی! بعنوان بخشی از DARPA ابزار برنامه سبک نشانه گذاری است. هدف DAMIL-S در زمانی که بعنوان یک شناخت کامل جهانی سرویسها بوسیله پژوهش های قبلی در حوزه ای که به اصطلاح وب معنایی نامیده میشود که شامل مشکلات مستعمره وب با معانی قانع و سرویسهای به رسمیت شناخته شده تحریک شده است. در بالای DAMIL+OIL ایجاد ، طراحی DAMIL-S بدنبال پیشرفت encrusted به زبانهای معنادار نشانه گذاری وب میباشد. هدف نهایی از DAMIL-s در این ارائه شناخت کامل است که اجازه معیار انتقال و آزاردهنده به تشخیص ، بالابردن و ترتیب وب سرویسها را میدهد. درحال حاضر ساختار شناخت کامل DAMIL-S سه برابر و شامل یک پروفایل سرویس برای ترویج و کشف سرویسها ، یک مدل روشمند که توضیح جامعی از روش یک سرویس میدهد و یک دستور سرویس که استطاعت چیزهای بی اهمیت درباره چگونگی همکاری با یک سرویس از طریق جایگزین های ارتباطی را دارد. ebXML در درجه اول توسط OASIS و سازمان ملل متحد توسعه یافته است. این رفتار روش های استعاری سرویس از ادراک کاری میباشد. ebXML از دو دیدگاه برای نشان دادن مبادلات کسب و کار ، یک نمایش عملکرد کسب و کار BVF و یک نمایش مشخصات سرویس FSV استفاده میکند. در ebXML ، BOV با معانی معاملات داده کسب و کار بین ارائه دهندگان وب سرویس میپردازد. FSV به سرویس های موردپسند خود یعنی شایستگی و روش و مرز خود می پردازد. این درک از انجمن طرح روش که اجازه میدهد تا یک همکار ترافیک به بیان حفظ پیشرفت شرکت و کسب و کار سرویس درخواستهای لبه خودرا با دیگر ebXML های همکار عمل کند. یک پیشرفت تولید مجموعه ای از فعل و انفعالات تولید بین همکاران ترافیک است. این مانع فهرست صنعت ، تماس در دنباله ، حفظ پیشرفت کسب و کار ، درخواست رابط و غیره است. آنها کاتالوگی در رجیستری ebXML هستند که به کشف دیگر همکار اشتغال و حمایت از توسعه کسب و کار آنها کمک میکند. در این رابطه ebXML برخی از مکاتبات با UDDI را دارد. WSMF (Web Service Modelling Framework) استطاعت درک بنیادین اضافی در تکنولوژی معنایی وب برای وب سرویسهای جنینی و بازگویی و ترکیب آنها را دارد. WSMFصلاحیت و پس شرایط سرویسهای همراه با یک نماینده خدمات را نشان میدهد. هدف WSMF در sturdily جفت پذیری ترکیبی از دستگاههاست که به عمل قرار دادن یک برنامه وب سرویس درحالیکه در همان زمان به شرطی که مقدار حداکثری از مذاکرات اتصال دستگاههای مختلف میپردازد. WSFM یک شناخت کامل مانند DAMIL-s و مفهوم در دسترس بودن مخازن آسپیراتیون و واسطه ها برای حل خواسته سرویس کامپوزیت را ایجاد میکند.

جمع بندی

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

مراجع

1. Cloud Computing and SOA pdf, Geoffrey Raines 2. Dynamic web service deployment in a cloud environment pdf, Marc Kemps-Snijders, Jan Pieter Kunst, Matthijs Brouwer, Tom Visser 3. The Role of Standards in Cloud-Computing Interoperability pdf, Grace A. Lewis

4. Cloud Computing Models, Eugene Gorelik, Working Paper CISL# 2013-01, January 2013

5. PERSONALIZED WEB SERVICE SELECTION, Shailesh Khapre and D. Chandramohan, ,Department of Computer Science, Pondicherry University, Pondicherry, India, April 2011

6. Cloud Standards and Security pdf, enisa, Au gust 2014

7. When To Use SOAP And When REST, JAZOON, June 2011

8. MODELING AND ANALYSIS OF SECURITY STANDARDS FOR WEB SERVICES AND CLOUD COMPUTING pdf, Ola Ajaj 2013

9. http://www.service-architecture.com

10. http://www.w3.org

11. کتاب رایانش ابری، محمدکاظم اکبری، مرتضی سرگلزایی جوان، آزمایشگاه و مرکز تحقیقات رایانش ابری دانشگاه صنعتی امیرکبیر، بهار 1389

تهیه کننده

مهرناز روزبهان عضو کارگروه تاکسونومی و استاندارد سازی مرکز تحقیقات رایانش ابری دانشگاه صنعتی امیر کبیر

لینک های مرتبط

• صفحه رسمی کارگروه در سایت جامعه آزاد رایانش ابری ایران
• کارگروه تاکسونومی و استانداردسازی
• http://www.cloud-standards.ir
• بررسی استانداردهای رایانش ابری
• استانداردسازی رایانش ابری
• http://www.cloud-standards.ir