فرمت فایل: ورد –Word و قابل ویرایش تعداد صفحات: 118     فهرست مطالب عنوان صفحه پیش گفتار A چکیدهD فصل 1 : 1-1- مقدمه2 1-1-1- معماری سرویس گرا چیست؟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 : معماری سرویس گرا 1-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- همکاری SOA45 4-4-2- نقش ها در معماری سرویس گرا45 5-4-2- عملیات در معماری سرویس گرا46 6-4-2- سرویس در بافت SOA48 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 : معماری سرویس وب 1-3- مقدمه55 2-3- سرویس وب چیست؟56 3-3- مدل چند لایه مبتنی بر XML-Web service56 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.072 1-2-3-3- سناریوی مورد استفاده یک طرفه73 2-2-3-3- سناریوی مورد استفاده تقاضا / پاسخ همزمان73 3-2-3-3- سناریوی مورد استفاده تماس برگشتی اولیه 73 فصل 4 : انتخابهای تکنولوژی 1-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- سرویس وب و J2EE82 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-Coordination103 - WS-Transaction104 پشتیبانی نگهداری برای سرویس وب 104 10-3-3- مدیریت105 نتیجه گیری107 خلاصه 108 پیوست110 منابع112   چکیده یک معماری سرویس گرا اساساً یک مجموعه از سرویس ها است که این سرویس ها با هم ارتباط و تعامل دارند. این ارتباط می تواند به صورت ارتباط از طریق پیغام باشد یا اینکه دو یا چند سرویس با همکاری هم، کاری را انجام دهند. معماری سرویس گرا چیز جدیدی نمی باشد. در این پروژه به بررسی معماری سرویس گرا، به عنوان یکی از آخرین دستاوردهای صنعت مهندسی نرم افزار و تکنولوژیهایی قابل استفاده در این معماری، پرداخته می شود.     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 و یا غیر فعال باشد، قرار نیست که فرآیند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند و عملیات پرداخت به وقت دیگری موکول شود.