پاورپوینت شناسایی و کشف سرویس در معماری سرویس گرا

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

این فایل به تشخیص سرویس ها و تعیین ویژگی های سرویس ها و عینیت بخشی به سرویس ها و ... می پردازد. این فایل برای ارائه ی دانشجویان در کلاس مهندسی نرم افزار پیشرفته بسیار مفید است.

معرفی معماری عامل گرا

اختصاصی از اینو دیدی معرفی معماری عامل گرا دانلود با لینک مستقیم و پر سرعت .

ارائه ای به صورت کامل و جامع درمورد معرفی معماری عامل گرا برای کارشناسی ارشد کامپیوتر دارای163 اسلاید می باشد که دران به معرفی عامل های هوشمندومعماری عامل وکابردهای آن و متدولوژی های مختلف و... می پردازد و این پاور مناسب برای ارائه درس مهندسی نرم افزار پیشرفته می باشد

دانلود مقاله معماری سرویس گرا

اختصاصی از اینو دیدی دانلود مقاله معماری سرویس گرا دانلود با لینک مستقیم و پر سرعت .

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

واژه های کلیدی
SOA = Service Oriented Architecture,
SOE = Service Oriented Enterprise,
SOI = Service Oriented Infrastructure,
MDA = Minimum Descent Altitude,
XML = Extensible Markup Language,
خوش تعریف = Well-defined,
WSDL = Web Service Description Language,
SGML = Standard Generalized Markup Language,
واحدهای نرم افزاری آماده در شبکه = Network-available Software Unit,
سرویس های سطح کسب و کار = Business-level services,

مقدمه
برای مدت های طولانی برنامه نویسان سعی می کردند تا، کدهای خود را بصورت modular( یک سیستم از بالا به پایین به زیر سیستم های کوچک و نسبتا مستقل تفکیک می شود ) بنویسند، تا بتوان از آن در تولید نرم افزارهای دیگر استفاده کرد. تفاوت نوشتن کد بصورت modular و بر اساس معماری سرویس گرا در حجم مخاطبان آن است. دوباره به همان مثال اول برمی گریم، وقتی شما کد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شکل modularمی نویسید مانند این است که، یک شبکه تلویزیون کابلی درون یک ساختمان خاص دارید و بنابراین فقط ساکنین آن ساختمان می توانند از آن بهره برداری کنند. در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد.
این معماری توسط دو شرکت IBM , Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویس های وب و عامل بسیاری از ابداعات جدید در حیطه ی سرویس های وب، مانند UDDI ,WSE بوده اند.
قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است MDA، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است. از نمونه های استفاده از این معماری در کشور خودمان، سازمان ثبت احوال کشور است که موظف شده تا پایگاه های اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد.

سرویس ها چه هستند؟
بسیاری از ما آنقدر با تکنولوژی های سرویس های وب آشنا هستیم که اغلب درباره این که خود سرویس ها واقعا چه هستند، فکر نمی کنیم. هر کس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تا ن را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تایید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل ونقل سرویستان را فراهم می کند و در نهایت کالای شما تحویلتان می شود.
در ادامه سه تعریف می آوریم که در کنار یکدیگر ماهیت یک سرویس راشرح می دهند:
۱- سرویس ها اجزاء مستقلی هستند که پیغام های XML با ساختار مشخص و خوش تعریف را پردازش می‏کنند.
• XML ساده ترین ورژن SGML استاندارد برای ایجاد و طراحی سند های HTML است(مناسب برای استفاده در سایت های اینتر نتی).
• SGML یک استاندارد مدیریت اطلاعات است که در سال 1986 به وسیله سازمان بین المللى استاندارد سازى (ISO) معرفى گردید و وسیله اى است براى ارائه اسناد مستقل از یک سیستم یا برنامه کاربردى خاص ضمن به کارگیرى اطلاعاتى چون قالب بندى، شاخص دهى و حفظ اطلاعات پیوندى در اسناد.
۲- سرویس ها دارای رابط های خوش تعریف هستند که به وسیله یک سند مبتنی بر XML که سند
WSDLخوانده می شود، به این سند گاهی قرارداد WSDL نیز گفته می شود، پردازش می شوند. محتویات این سند،‌ عملیاتی (متدهایی) که توسط سرویس ارائه می شود را شرح می دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرویس، جهت یافتن و ارتباط با عملیات سرویس وب.
۳- سرویس ها دارای نقاط انتهایی (Endpoint)هستند که استفاده کنندگان از سایر سرویس ها می‏توانند بر اساس آدرس سرویس (URL)معمولاً به آن ها متصل شوند. این همان چیزی است که ارتباط(جفت شدن) آزادانه خوانده می شود.
سرویس ها می توانند به دو شکل ساده و ترکیبی ارائه شوند. سرویس های ترکیبی، سرویس هایی هستند که بر اساس بکارگیری چند سرویس ساده ( یا ترکیبی) ایجاد می شوند. برای مثال، ممکن است سیستم توزیع شده ای بر اساس چند سرویس ساده صدور صورتحساب، ثبت سفارش، مدیریت روابط مشتری و... سرویس های ترکیبی گسترده تری در ارتباط با حرفه ای خاص ایجاد نماید.
پس می توان گفت: سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XML را پردازش و تبادل می کنند.

معماری سرویس
چندین مصرف‌کننده سرویس می‌توانند با ارسال پیام اقدام به فراخوانی سرویس‌ها نمایند. این پیام‌ها معمولا توسط یک گذرگاه سرویس تغییر شکل داده شده و به سوی سرویس مناسب هدایت می‌گردند. معماری سرویس می‌تواند یک موتور قواعد تجاری را فراهم سازد که امکان تلفیق قواعد تجاری در یک سرویس یا چندین سرویس را عملی سازد. معماری سرویس مزبور همچنین یک زیربنای مدیریت سرویس فراهم می‌آورد که سرویس‌ها و اعمالی از قبیل بازرسی، پرداخت صورتحساب، و واقعه‌نگاری (logging) را مدیریت می‌نماید. به علاوه، این معماری انعطاف‌پذیری ناشی از دارا بودن فرایندهای تجاری تغییر پذیر را به سازمان‌ها ارزانی می‌دارد، فرایندهایی که نیازمندی‌های تنظیمی همانند Sarbanes Oxley (SOX) را مد نظر قرار می‌دهند، و سرویس‌های اختصاصی را بدون تحت تاثیر قرار دادن سایر سرویس‌ها تغییر می‌دهند.

معرفی SOA و چند کار برد آن:
معماری سرویس‌گرا (SOA) شکل تکامل یافته محاسبه‌گری توزیع شده مبتنی بر فرضیه طراحی تقاضا/پاسخ برای برنامه‌های کاربردی همگام و ناهمگام است. منطق تجاری یا توابع اختصاصی یک برنامه کاربردی به صورت ماژولار در آمده‌اند و به عنوان سرویس‌هایی برای برنامه‌های کاربردی مصرف‌کننده/کلاینت ارائه گردیده‌اند. مهم‌ترین نکته‌ در مورد این سرویس ‌ها طبیعت اتصال آزادانه آنهاست؛ بدین معنی که رابط سرویس، مستقل از پیاده‌سازی است.
تعاریف گوناگونی از معماری سرویس گرا ارائه شده است که از جمله آنها می توان به تعاریف زیر اشاره کرد:
1. مجموعه قوانین، سیاست ها و چارچوب هایی که نرم افزارها را قادر می سازد تا عملکرد خود را از طریق مجموعه سرویس های مجزا و در عین حال مربوط به هم در اختیار سایر درخواست کنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابط های استاندارد و تعریف شده، این سرویس ها را پیدا کرده و فراخوانی نمایند.
2. روشی برای ساخت سیستم های توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویس ها قرار می گیرد.
3. از دیگرتعاریف ارائه شده می توان به "واحدهای نرم افزاری آماده در شبکه (Network-available Software Unit) " یا "سرویس های سطح کسب و کار (Business-level services) " اشاره کرد.
معماری‌های سرویس‌گرا دارای خصوصیات اصلی زیر هستند:
- سرویس ‌های SOA دارای رابط ‌های خود توصیف‌گر در اسناد XML مستقل از پلتفرم هستند. زبان توصیف سرویس‌های وب (WSDL) استاندارد به کار برده شده برای توصیف این سرویس‌ها می‌باشد.
- سرویس‌های SOA با پیام‌هایی که رسماً توسط مدل XML (که XSD نیز نامیده می‌شود) تعریف شده‌اند ارتباط برقرار می‌نمایند. ارتباط میان مصرف‌کنندگان و فراهم‌کنندگان یا سرویس‌ها معمولا در محیط‌های ناهمگن رخ می‌دهد، با دانش کم یا بدون هیچ دانشی در مورد فراهم‌کننده. پیام‌های مبادله شده میان سرویس‌ها را می‌توان به عنوان اسناد تجاری مهم پردازش شده در یک سازمان نگریست.
- سرویس‌های SOA توسط یک رجیستری که به عنوان یک فهرست دایرکتوری عمل می‌کند نگهداری می‌گردند. برنامه‌های کاربردی می‌توانند سرویس‌ها را درون رجیستری جستجو نمایند و سرویس را فراخوانی کنند. توصیف، تعریف، و یکپارچگی جهانی (UDDI) استانداردی است که برای رجیستری سرویس مورد استفاده قرار گرفته است.
هر سرویس SOA دارای یک کیفیت سرویس (QoS) مرتبط با خود است. برخی از عناصر اساسی QoS شامل نیازمندی‌های امنیتی، از قبیل احراز هویت و صدور مجوز، پیام‌رسانی قابل اطمینان، و خط‌مشی‌هایی در این زمینه که چه افرادی می‌توانند سرویس‌ها را فراخوانی نمایند، می‌باشد.
می توان گفت: معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Application است. با رویکرد سرویس گرا می توان راه حل هایی را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد(loosly coupled) ساخت که جریان یکنواخت و هماهنگ کار را تضمین کند.
نیاز به معماری سرویس گرا از جنبه ای دیگر نیز به نحوه بارزی در برنامه های کاربردی E-Commerce مشهود است. اگر مثلا جزء (componet) مربوط به پرداخت با کارت اعتباری offline و یا غیر فعال باشد،‌ قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند وعملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده،‌ SOA ساخت برنامه های کاربردی با استفاده اجزایی که در domainهای جدا از هم را قرار دارند را ممکن می سازد. SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند. با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزاداترانه ومستقل تر (loosely coupled) است. بعلاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند، نیز منحصر به فرد است. فاکتورهایی نظیر: قابلیت اطمینان سرویس،‌ جامعیت پیام، یکسانی تراکنش و امنیت پیام. در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند،‌ پردازش می کنند حساب کرد. در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد. با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یاعدم پاسخ به یک درخواست باشند.
علاوه بر آن نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف، متفاوت باشد. با وجود این،‌ هیچ کدام ازاین موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشه باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند، در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازی و اعلام شود. بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مر حله ای از جریان کار بسیار زیاد است. در SOA فرض بر این است که خطا وجود دارد و می تواند بیفتد، برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد، این معماری طوری طراحی شده است که مجدداً پیام را بفرستد. و اگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار انفاق بیفتد) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که منجر به قطع کامل در خواست سرویس می شود، ‌امکان پذیر نباشد. SOAقابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند.
در حال حاضر، تکنولوژی سرویس های وب(Web Services)و پیاده سازی نمونه های موفق از آن، نشان داده است که SOA می تواند به عنوان راه حلی عملی و دست یافتنی در طراحی سیستم های جدید و یکپارچه سازی سیستم های بزرگ موجود، مطرح گردد. البته ذکر تفاوت سرویس های وب و SOA در اینجا لازم به نظر می رسد:
سرویس های وب مجموعه ای از تکنولوژی هایی همچون XML,SOAP,WSDL و UDDI می باشد که امکان ارائه راه حل و برنامه نویسی جهت رفع مشکلی خاص را فراهم می نماید.
در حالی که SOA یک معماری است و از مجموعه مشخصی از تکنولوژی ها فراتر می باشد. اگرچه SOA بر اساس این تکنولوژی ها راه حل ارائه می نماید، اما در عین حال مستقل از هر یک از آنها است.
آنچه اهمیت دارد تعریف سرویس به عنوان مهمترین عنصر این معماری می باشد.
سرویس، رفتار قرادادی تعریف شده ایست که هر قطعه ای می تواند آن را جهت استفاده سایر قطعات در سیستم تهیه و پیاده سازی نماید.
در این معماری، همه توابع به عنوان سرویس تعریف می گردند. این توابع شامل توابع کسب و کار (Business functions) و تراکنش های حرفه‌ای (Business transactions) می باشند که تراکنش های حرفه ی خود شامل توابع سطح پایین (Low-level functions) و توابع سیستمی سرویس ها(System service functions) هستند.
سرویس ها بصورت مستقل طراحی و پیاده سازی شده و به عنوان جعبه سیاه عمل می نمایند. قطعات دیگر در خارج از این قطعه نیازی به دانستن نحوه انجام کار در این سرویس را ندارند و تنها به نتیجه آن نیازمندند.
قطعات، سرویس های خود را از طریق رابط ها (interface) در اختیار قطعات دیگر قرار می دهند که این رابط ها قابل دستیابی و فراخوانی هستند، بدون اینکه محل قرار گیری آنها اهمیت داشته باشد (رابط های محلی یا دور). در ضمن این رابط ها می توانند به همان نرم افزار کاربردی یا به آدرسی در محل دیگری از شبکه مرتبط باشند.
رابط ها به عنوان کلیدی در برقراری این ارتباط ها هستند و از طریق آنها نوع پارامترهای ورودی و نتایج (خروجی) مشخص می گردد.
مهمترین مفاهیم و اصول در نظر گرفته شده در طراحی سرویس گرا به شرح زیر می باشد:
1- کپسوله سازی سرویس (service encapsulation) تاکید بر متمرکز کردن عملیات وابسته به داده در یک واحد (کپسول) مشخص و پنهان کردن پیاده سازی و مکانیزم درون واحد نرم افزاری است.
2- اتصال آزاد بین سرویس ها (service loose coupling) تاکید بر استقلال سرویس ها و کاهش وابستگی سرویس ها به یکدیگر است فقط کافی است سرویس ها از وجود هم آگاه باشند.
3- قرارداد سرویس دهی (service contract) ارتباط بین سرویس ها بر اساس قرارداد تعریف شده ای است که در اسناد فنی بطور مشخص ذکر می شود.
4- مجرد ساختن سرویس (service abstraction) تاکید بر جدا کردن پیاده سازی از رابط (جهان خارج) و پنهان کردن مکانیزم و نحوه انجام کار در درون واحد ارائه دهنده ی سرویس می باشد.
5- استفاده مجدد و بازبکارگیری سرویس (service reusability) تاکید بر طراحی سرویس ها به نحوی است که بتوان آنها را در سامانه های مختلف بکار برد. با تاکید بیشتر بر استفاده مجدد.
6- قابلیت ترکیب سرویس (service composability) به معنی آنست که سرویس ها به نحوی طراحی شوند که با برخورداری از قابلیت ترکیب شدن ایجاد سرویس های مرکب (کامپوزیت) امکان پذیر باشد.
7- خودگردانی سرویس (service autonomy) عبارتست از قابلیت و قدرت سرویس در بکارگیری و مدیریت منابع خود بطور مستقل و همچنین کنترل کامل بر منطق پیاده سازی خود.
8- بدون حالت بودن سرویس (service statelessness) به این معنی است که سرویس باید در مورد فعالیت های گذشته (فراخوانی های گذشته) کمترین اطلاعات را نگهدارد و تاکید بر طراحی سرویس بنحوی است که حالت های وابسته به گذشته کمتری داشته باشد.
9- قابلیت کشف شدن سرویس (service discoverability) به این معنی است که سرویس باید در یک محیط شبکه با استفاده از سازوکارهای مناسب توسط برنامه های دیگر آشکار شود.
به بیان کلی،‌ SOA فرایندی تکامل یافته را ارائه می نماید و ازاین نظر می تواند آن را بلوغ سرویس های وب و تکنولوژی های یکپارچه سازی به حساب آورد. در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند، باید تضمین های خاصی را تامین نمایند. در این گونه سیستم ها باید این اطمینان وجود داشته باشد که در خواست های سرویس به طور صحیح مسیر دهی و هدایت می شوند، در زمان مناسب به آن ها پاسخ داده می شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام می کنند.

شکل 1- SOA کارها را تغییر می دهد

SOAP, WSDL, UDDI
WSDL، UDDI و SOAP قطعات اساسی زیربنای SOA هستند WSDL .برای توصیف سرویس به کار برده شده است؛UDDI، برای ثبت و جستجوی سرویس‌ها وSOAP، به عنوان یک لایه نقل و انتقال جهت ارسال پیام‌ها میان مصرف‌کننده سرویس و فراهم‌کننده سرویس. در حالی که SOAP ساز و کار پیش‌فرض برای سرویس‌های وب است، تکنولوژی‌های جایگزین، انواع دیگری از انقیادها (binding) را برای یک سرویس تحقق می‌بخشند. یک مصرف‌کننده می‌تواند به جستجوی یک سرویس در رجیستری UDDI بپردازد، WSDL را برای سرویسی که دارای توصیف است تهیه نماید، و سرویس را از طریق SOAP فراخوانی کند.

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

شکل 2 - مقایسه ی دو نوع معماری
SOA سرویس‌ وب نیست
آن گونه که به نظر می‌رسد در مورد ارتباط میان SOA و سرویس‌های وب نوعی سردرگمی عمومی وجود دارد. در یکی از گزارش‌های Gartner مورخ آوریل 2003، Yefim V. Natis این گونه تقاوت میان آنها را شرح می‌دهد: "سرویس‌های وب راجع به مشخصه‌های تکنولوژی هستند، در حالی که SOA یک قاعده‌ی طراحی نرم‌افزار است."شایان ذکر است که WSDL سرویس‌های وب یک استاندارد تعریف رابط مناسب SOA است: این نقطه‌ای است که سرویس‌های وب و SOA اساسا به یکدیگر پیوند می‌خورند. اساساً،SOA یک الگوی معماری است، در حالی که سرویس‌های وب سرویس‌های پیاده‌سازی شده توسط مجموعه‌ای از استانداردها می‌باشند؛ سرویس‌های وب یکی از روش‌هایی است که شما با استفاده از آن می‌توانید SOA را پیاده‌سازی نمایید. مزیت پیاده‌سازی SOA با سرویس‌های وب این است که شما به یک رویکرد بی‌طرفانه نسبت به پلات‌فرم به منظور دستیابی به سرویس‌ها و interoperability بهتر دست می‌یابید همچنان که فروشندگان بیشتر و بیشتری مشخصه‌های بیشتر و بیشتری از سرویس‌های وب را پشتیبانی می‌نمایند.

فرمت این مقاله به صورت Word و با قابلیت ویرایش میباشد

تعداد صفحات این مقاله 29   صفحه

پس از پرداخت ، میتوانید مقاله را به صورت انلاین دانلود کنید

پایان نامه معماری سرویس گرا

اختصاصی از اینو دیدی پایان نامه معماری سرویس گرا دانلود با لینک مستقیم و پر سرعت .

فایل:Word (قابل ویرایش و آماده پرینت) تعداد صفحه:127

پایان نامه معماری سرویس گرا

فهرست مطالب

عنوان                                  صفحه

پیش گفتار .......................................................................... A

چکیده..................................................................................... D

فصل 1 :

• مقدمه............................................................................ 2
  • - معماری سرویس گرا چیست؟...................................... 3

2-1-1- ویژگی های سیستم های مبتنی بر معماری سرویس گرا 9

3-1-1- آماده شدن برای معماری سرویس گرا..... 12

2-1- معرفی................................. 15

3-1- ویژگیهای سرویس و محاسبات سرویس گرا.... 17

4-1- نرم افزار به عنوان سرویس.............. 19

5-1- مفهوم معماری سرویس گرا................ 20

6-1- معماری سرویس گرای مقدماتی............. 23

7-1- معماری سرویس گرای توسعه یافته......... 25

8-1- نیازمندیهای معماری سرویس گرا.......... 29

فصل 2 : معماری سرویس گرا

• مقدمه................................. 32

2-2- محرک های تجاری در رویکردی جدید........ 32

3-2- معماری سرویس گرا به عنوان یک راه حل... 35

1-3-2- تجزیه و تحلیل و طراحی شی گرا........ 35

2-3-2- طراحی بر مبنای جزء.................. 36

3-3-2- طراحی سرویس گرا..................... 37

4-3-2- طراحی بر مبنای واسط................. 39

5-3-2- معماریهای برنامه های کاربردی لایه ای 41

4-2- نگاهی دقیق تر بر معماری سرویس گرا..... 42

1-4-2- جنبه های عملکردی.................... 43

2-4-2- جنبه های کیفیت سرویس................ 44

3-4-2- همکاری SOA......................... 45

4-4-2- نقش ها در معماری سرویس گرا.......... 45

5-4-2- عملیات در معماری سرویس گرا.......... 46

6-4-2- سرویس در بافت SOA.................. 48

7-4-2- سرویس در برابر اجزاء................ 49

5-2- مزایای معماری سرویس گرا............... 51

1-5-2- بالا بردن دارایی های موجود........... 51

2-5-2- مجتمع سازی و اداره کردن راحت تر پیچیدگی 52

3-5-2- پاسخگویی بیشتر و خرید و فروش سریعتر 52

4-5-2- کاهش هزینه و افزایش استفاده مجدد.... 52

5-5-2- آمادگی در برابر حوادث............... 53

فصل 3 : معماری سرویس وب

• مقدمه................................. 55

2-3- سرویس وب چیست؟........................ 56

3-3- مدل چند لایه مبتنی بر XML-Web service.... 56

1-2-3- برخی از ویژگیهای سرویس های وب....... 63

4-3- قابلیت عملکرد متقابل سرویس های وب..... 65

1-1-3-3- انگیزه های مالی برای معماری سرویس گرا 66

2-1-3-3- خصیصه های معماری سرویس وب......... 68

3-1-3-3- سازمان قابلیت عملکرد متقابل سرویس های وب   69

4-1-3-3- خصوصیات گزارش..................... 71

5-1-3-3- موارد کاربردی و سناریوی مورد استفاده 72

6-1-3-3- برنامه های کاربردی نمونه.......... 71

7-1-3-3- ابزارهای تست...................... 72

2-3-3- گزارش بر مبنای WS-I 1.0.............. 72

1-2-3-3- سناریوی مورد استفاده یک طرفه...... 73

2-2-3-3- سناریوی مورد استفاده تقاضا / پاسخ همزمان  73

3-2-3-3- سناریوی مورد استفاده تماس برگشتی اولیه ... 73

فصل 4 : انتخابهای تکنولوژی

• انتخابهای تکنولوژی.................... 76

2-4- مقدمه................................. 77

1-2-4- مزایای سرویس های وب................. 77

2-2-4- معایب سرویس های وب.................. 78

3-4- لایه های پشته معماری سرویس گرا......... 79

1-3-4- حمل و نقل........................... 79

2-3-4- پروتکل تبادل سرویس.................. 80

3-3-4- شرح سرویس........................... 81

4-3-4- سرویس............................... 82

1-4-3-4- سرویس وب و J2EE................... 82

2-4-3-4- چارچوب کاری احضار سرویس وب........ 83

3-4-3-4- برخی ملاکهای مؤثر در انتخاب چهارچوبها. 84

5-3-4- فرآیند تجاری........................ 92

6-3-4- بایگانی سرویس....................... 94

1-6-3-4- درخواست مستقیم.................... 94

2-6-3-4- انتشار جمعی ساده ................. 94

3-6-3-4- استفاده از دایرکتوری.............. 95

7-3-4- سیاست............................... 95

1-7-3-4- استانداردهای نوظهور برای سیاست.... 96

8-3-4- امنیت............................... 97

9-3-4- معاملات............................. 102

1-9-3-4- استانداردهای نوظهور برای معاملات.. 103

- WS-Coordination........................... 103

- WS-Transaction............................ 104

پشتیبانی نگهداری برای سرویس وب .......... 104  

10-3-3- مدیریت............................ 105

نتیجه گیری................................ 107

خلاصه ..................................... 108

پیوست..................................... 110

منابع..................................... 112

 مقدمه:

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

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

دوباره به همان مثال اول برمی گردیم، وقتی شما کد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شکل Modular می نویسید مانند این است که، یک شبکه تلویزیون کابلی درون یک ساختمان خاص دارید و بنابراین فقط ساکنین آن ساختمان می توانند از آ« بهره برداری کنند.

در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد. این معماری توسط دو شرکت IBM ، Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند WSE ، UDDI بوده اند. قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است (MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است.

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

• معماری سرویس گرا چیست؟

همان طور که در عنوان آن مشخص است، به مفهومی در سطح معماری، اشاره می کند و بنابراین در مورد چیزی پایه ای و اساسی در سطوح بالا است، که پایه و اساس آن تجربیات بدست آمده در تولید سیستم های نرم افزاری مبتنی بر CBD و دو اصل اساسی در صنعت مهندسی نرم افزار یعنی تولید نرم افزار بصورت با همبستگی زیاد و در عین حال با چسبندگی کم است. بنابراین ایده های برنامه نویسی سرویس گرا ایده ا جدید نیست و شما شاید قبلاً از آن استفاده کرده باشید. اما جمع آوری بهترین تجربیات از تولید چنین سیستمهایی بصورت مجتمع و ناظر به وضعیت تکنولوژیکی امروز بشر، که همان مفاهیم مطرح شده در معماری سرویس گرا است چیز جدیدی است. در زیر بصورت دقیق تر این بحث را ادامه می دهیم آیا تولید سیستم های سرویس گرا مفهوم جدیدی است؟ مهندسان نرم افزار، همیشه می گفتند و گفته اند که نرم افزار باید به شکلی نوشته شود که همبستگی زیاد ولی در عین حال اتصال کمی داشته باشد. شرکتهای بزرگ نرم افزاری هم در جهت گام برداشتن برای رسیدن به این دو اصل، تکنولوژی هایی را بوجود آورده اند که به برنامه نویسان اجازه دهد تا به این دو هدف در تولید نرم افزارهای خود تا حد زیادی دست یابند. برای مثال می توان به تکنولوژی هایی مانند CORBA ، COM+ و RMI و موارد دیگر، اشاره کرد. خوب پس مشاهده کردید که موضوع برنامه نویسی سرویس گرا، مفهوم جدیدی نیست و این معماری تلاشی دیگر در جهت تولید نرم افزارهای با همبستگی زیاد و در عین حال با چسبندگی و اتصال کم است. ممکن است بپرسید، پس چرا با وجود تکنولوژی های قدرتمندی چون RMI ، COM+ و CORBA چیز جدیدی بوجود آمد؟ مگر تکنولوژی های قبلی موفق نبودند؟ بله مهمترین اشکال در معماری های قدرتمندی چون موارد مذکور این بود که تولید کنندگان آنها سعی داشتند، که تکنولوژی خود را بر بازار غالب نمایند. رویایی که هرگز به حقیقت نمی پیوست . بنابراین با توجه به این موضوع که این تکنولوژیها قادر به تعامل مناسب با یکدیگر نبودند عملاً اصل همبستگی زیاد بصورت خود بخود رد می شد.

البته معماری های مذکور اشکالات دیگری هم داشتند که نسبت به موارد بالا از اهمیت کمتری برخوردار است که از جمله آنها می توان به عدم هماهنگی با اصول امنیتی مورد استفاده در اینترنت اشاره کرد. البته بعدها راه حل هایی هم برای این مشکل بوجود آمد (مانند Over HTTP RPC ) اما به این علت که از روز اول، در طراحی این تکنولوژی ها این امر در نظر گرفته نشده بود، از کارایی مناسبی برخوردار نبودند. مفهوم همبستگی زیاد و در عین حال با چسبندگی و اتصال کم، وقتی بخواهد در جهت ارزیابی یک سیستم نرم افزاری یا تکنولوژی، مورد استفاده قرار گیرد بسیار مبهم می شود. حتی کسی می تواند ایده های همبستگی و چسبندگی را با هم ترکیب کند! برای جلوگیری از چنین ابهاماتی، شما می توانید از ویژگی های معماری سرویس گرا به عنوان یک راه برای ارزیابی میزان همبستگی و چسبندگی و اتصال یک سیستم نرم افزاری یا یک تکنولوژی استفاده کنید. اگر چه مفاهیم مطرح شده در معماری سرویس گرا دقیقاً همان مفاهیم همبستگی زیاد و در عین حال چسبندگی کم نیستند، اما سیستمهایی که بر اساس معماری سرویس گرا طراحی و پیاده سازی شده اند، نشان داده اند که توانسته اند تا حد بسیار زیادی ویژگی های همبستگی زیاد و در عین حال چسبندگی کم را بخوبی در خود ایجاد و حفظ کنند.

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

هرکس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تان را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تأیید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل و نقل هماهنگ می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه های دیگر نیز به شکل بارزی در برنامه های کاربردی تجارت الکترونیکی مشهود است. اگر مثلاً جزء مربوط به پرداخت کارت اعتباری Offline و یا غیر فعال باشد، قرار نیست که فرآیند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند و عملیات پرداخت به وقت دیگری موکول شود.

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

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

خرید و دانلود پایان نامه کارشناسی کامپیوتر موضوع : معماری سرویس گرا

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

پایان نامه کارشناسی کامپیوتر(گرایش نرم افزار)

موضوع : معماری سرویس گرا

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

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

دوباره به همان مثال اول برمی گردیم، وقتی شما کد خود را به منظور قابل استفاده بودن توسط نرم افزارهای دیگر، به شکل Modular می نویسید مانند این است که، یک شبکه تلویزیون کابلی درون یک ساختمان خاص دارید و بنابراین فقط ساکنین آن ساختمان می توانند از آ« بهره برداری کنند.

در جهان امروز طیف مخاطبانی که بالقوه می توانند از سرویس شما استفاده کنند، کل کاربران روی شبکه اینترنت است. بنابراین باید مکانیزمی بوجود می آمد، که می توانست پاسخگوی این محیط جدید (اینترنت) و کاربران آن باشد و بنابراین معماری سرویس گرا بوجود آمد. این معماری توسط دو شرکت IBM ، Microsoft بوجود آمد، که هر دو شرکت طی سالهای اخیر از حامیان اصلی سرویسهای وب و عامل بسیاری از ابداعات جدید در حیطه سرویس های وب، مانند WSE ، UDDI بوده اند. قابل ذکر است، که در آخرین معماری در حال توسعه، در تولید نرم افزار که هنوز هم در مرحله تحقیقاتی است (MDA) ، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است.

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

این تحقیق در 5 فصل تنظیم شده که مباحث زیر را در بردارد :

فصل اول: معرفی معماری سرویس گرا

فصل دوم: معماری سرویس گراSOA  

فصل سوم :معماری سرویس وب

فصل چھارم: انتخابهای تکنولوژی

فصل پنجم:نتایج بحث و پیشنهاد

این فایل با فرمت word و در 127 ص تنظیم گشته است.