پایان نامه معماری مبتنی بر سرویس گرایی در تجارت الکترونیک

فهرست مطالب

هدف  پروژه۸

فصل اول

۱-۱تعریف، مزایاو ادبیات موضوع معماری سرویس گرا ۹

۲-۱نتیجه گیری   ۱۱

فصل دوم

۱-۲ سرویس  مولفه  و مشخصه ها ی سرویس وب   ۱۳

۲-۲ نتیجه گیری   ۱۹

فصل سوم

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

۳-۱ مقدمه  ۲۱

۳-۳ سرویس های ارکسترال و کاریوگرافی  ۲۵

۳-۴ نتیجه گیری   ۲۷

فصل چهارم

مفاهیم اصلی و چرخه حیات درمعماری سرویس گرا

۴-۱ مقدمه  ۲۸

۴-۲ مولفه های اصلی در معماری مبتنی بر سرویس   ۲۹

۴-۳ خصوصیات مدل داده ای مرتبط  ۳۱

۴-۳-۱ اصطلاحات رایج در معماری مبتنی بر سرویس   ۳۲

۴-۳-۲  نقشه مفهومی  ۳۲

۴-۳-۳  مفاهیم اختیاری و زیرساخت های معماری سرویس گرا  اشتراکی  ۳۳

۴-۳-۴  الگوهای معماری سرویس گرا ۳۵

۴-۳-۵  چرخه حیات معماری سرویس گرا ۳۵

۴-۳-۵-۱  فاز ۱- مرحله مدل سازی   ۳۶

۴-۳-۵-۲  فاز۲- مرحله گردآوری   ۳۶

۴-۳-۵-۳  فاز۳- مرحله نصب   ۳۷

۴-۳-۵-۴ فاز۴- مرحله مدیریت   ۳۷

۴-۳-۵-۵  فاز۵ – مرحله حاکمیت و فرایندها ۳۷

۴-۴  خصوصیات اساسی جهت استفاده بهینه از سرویس ها ۳۸

۴-۴-۱  مقیاس پذیری از طریق رفتار آسنکرون و صف بندی   ۳۹

۴-۵ ویژگیهای سرویس و محاسبات سرویس گرا ۴۲

۴-۷ نتیجه گیری   ۴۴

فصل پنجم

۱-۵طراحی نرم افزار سرویس گرا ۴۸

۵-۲ معماری سرویس گرای توسعه یافته  ۴۹

۵-۳ ويژگي هاي سيستم هاي نرم افزاري مبتني بر معماري سرویس گرا ۵۴

۵-۴ نتیجه گیری   ۵۸

فصل ششم

سرويس‌های مبتنی بر رويداد در معماری سرویس گرا

۶-۱ مقدمه  ۵۹

۶-۲ معماري مبتني بر رويداد ۶۰

۶-۳ مزاياي طراحي و توسعه مبتني‌ بر رويداد ۶۱

۶-۴ تلفیقEDA  ومعماری سرویس گرا ۶۱

۶-۴-۱ طبقه‌بندي و علت رويداد ۶۲

۶-۴-۲ معرفي مول (Mule) 64

۶-۴-۲-۱ معماري مول  ۶۴

۶-۴-۲-۲  مدل مول: ۶۷

۶-۴-۲-۳ مدير مول: ۶۸

۶-۴-۲-۴ رويدادهاي مول  ۶۹

۶-۴-۲-۵ پردازش رويداد در مول  ۷۱

۶-۴-۲-۶ يك چارچوب ساده با استفاده از مول  ۷۲

۶-۵ نتیجه گیری   ۸۸

فصل هفتم

کاربرد معماری سرویس گرا در لایه های معماری شهر الکترونیک

۱-۷ مقدمه  ۹۰

۷-۲ الزامات و نیازمندی های شهر الکترونیک    ۹۱

۷-۳ معماری شهر الکترونیک    ۹۲

۷-۳-۱  نیازمندی های لایه های معماری شهر الکترونیک    ۹۳

۷-۴ معماری سرویس گرا ۹۴

۷-۴-۱ طبقه بندی سرویس از نگاه معماری سازمانی  ۹۷

۷-۵  کاربرد معماری سرویس گرا در شهر الکترونیک    ۹۹

۷-۶  اصول سرویس های الکترونیک در معماری سرویس گرا ۱۰۱

۷-۶-۱  قابلیت استفاده مجدد ۱۰۱

۷-۶-۲  قرارداد رسمی برای تعامل  ۱۰۱

۷-۶-۳  اتصال سست سرویس ها ۱۰۲

۷-۶-۴  پنهان سازی پیاده سازی داخلی  ۱۰۲

۷-۶-۵  قابلیت ترکیب پذیری   ۱۰۲

۷-۶-۶  خود مختاری سرویس ها ۱۰۲

۷-۶-۷  بی وضعیتی ( حالت ) سرویس ها ۱۰۳

۷-۶-۸  قابلیت شناسایی و کشف   ۱۰۳

۷-۷نتیجه  گیری   ۱۰۳

فصل  هشتم

چالش یكپارچه سازی سیستم های سازمانی(EAI) و تعامل پذیری بین سازمانی(B2B)

۸-۱ یکپارچه سازی اطلاعات و فرایندهای سازمانی  ۱۰۵

۸-۳ یكپارچه سازی سیستم های  سازمان و تعامل پذیری بین سازمانی به كمك معماری سرویس گرا ۱۰۷

۸-۳-۱  یکپارچه سازی سیستم های اطلاعاتی  ۱۰۷

۸-۳-۲  یکپارچگی اتوماسیون فرایندهای سازمان در قالب ارکستریشن  ۱۰۹

۸-۳-۳  تعامل پذیری بین سازمانی  ۱۱۱

۸-۴  نتیجه گیری   ۱۱۲

منابع و مراجع۱۱۳

فهرست اشکال

فصل  سوم

شکل ۳-۱ : وجود یا عدم وجود هدایت کننده مرکزی تفاوت میان ارکستریشن و کاریگرافی                              ۲۱

فصل  چهارم

شکل۴-۱  مثالی از نقشه مفهومی                                                                                                       ۲۷

شکل۴-۲  مدل مرجع معماری مبتنی بر سرویس پایه                                                                              ۲۸

شکل ۴-۳مفاهیم اختیاری برای معماری سرویس گرا  و نمایش تعامل آنها با مفاهیم پایه این معماری                   ۲۸

شکل ۴-۴الگوی پایه برای معماری مبتنی بر سرویس                                                                             ۲۹

شکل۴-۵ چرخه حیات معماری مبتنی بر سرویس                                                                                  ۳۰

شکل ۴-۶  تاکید بر درشت دانه بودن در سرویس ها                                                                              ۳۳

شکل ۴-۷ طراحی مبتنی بر واسط در معماری سرویس گرا                                                                                 ۳۳

شکل۴-۸  روش سنکرون در مقابل روش آسنکرون                                                                               ۳۴

فصل  پنجم

شکل ۵-۱- سه نوع ارتباط در سرویس گرائی                                                                                       ۴۱

شکل ۵-۲  – مولفه های سرویس گرا                                                                                                  ۴۳

فصل  ششم

شکل ۶-۱- رویداد ها و لایه های معماری                   ۵۳

شكل ۶-۲ ، نماي سطح بالايي از جريان پیام   را براي معماري                                                                ۵۹

فصل  هفتم

شکل ۷-۱ مدل مفهومی شهر الکترونیک                                                                                             ۷۸

شکل ۷-۲ لایه های معماری شهر الکترونیک                                                                                       ۷۹

شکل ۷-۳  لایه های معماری سازمانی فناوری اطلاعات                                                                         ۸۳

شکل ۷-۴ تاثیر معماری سرویس گرا بر لایه های شهر الکترونیک                                                                       ۸۵

فصل  هشتم

شکل ۸-۱ : رویکرد اتصال نقطه به نقطه برای ارتباط بین سیستم های اطلاعاتی سازمان                                            ۹۲

شکل ۸-۲ : رویکرد مترجم مرکزی برای ارتباط بین سیستم های اطلاعاتی سازمان                                                     ۹۳

شکل ۸-۳ : پیاده سازی فرایندهای کسب و کار به کمک موتور فرایندی(BizTalk) مبتنی بر معماری سرویس گرا                        ۹۴

شکل ۸-۴ : تعامل پذیری بین سازمانی/کشوری به کمک وب سرویس های مبتنی بر معماری سرویس گرا                      ۹۵

  فهرست جداول

فصل سوم

جدول۳-۱٫مقایسه میان ویژگیهای معماری سرویس گرا و رویکرد های گذشته                                                          ۱۹

فصل  هفتم

جدول۷-۱ : مقایسه میان ویژگی های معماری سرویس گرا با رویکردهای گذشته                                           ۸۲

هدف  پروژه

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

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

تعریف، مزایا و ادبیات موضوع معماری سرویس گرا

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

براي مدتهاي طولاني برنامه نويسان سعي مي كردند تا، كدهاي خود را بصورت ماژولار[۲] بنويسند، تا بتوان از آن در توليد نرم افزارهاي ديگر استفاده كرد. تفاوت نوشتن كد بصورت ماژولار  بر اساس معماري سرویس گرا در حجم مخاطبان آن است. دوباره به همان مثال اول برمي گرديم، وقتي شما كد خود را به منظور قابل استفاده بودن توسط نرم افزارهاي ديگر، به شكل ماژولار مي نويسيد مانند اين است كه، يك شبكه تلويزيون كابلي درون يك ساختمان خاص داريد و بنابراين فقط ساكنين آن ساختمان مي توانند از آن بهره برداري كنند. در جهان امروز طيف مخاطباني كه بالقوه مي توانند از سرویس شما استفاده كنند، كل كاربران روي شبكه اينترنت است. بنابراين بايد مكانيزمي بوجود مي آمد، كه مي توانست پاسخگوي اين محيط جديد (اينترنت) و كاربران آن باشد و به همین دلیل معماري سرویس گرا بوجود آمد. اين معماري توسط افراد و موسسات و دانشگاه های مختلفی توسعه یافته و توسط شرکت های نرم افزاری بزرگی همانند شركت  مایکروسافت، ای بی ام و امثالهم حمایت شد. این دو شرکت نام برده شده دو شركت طي سالهاي اخير از حاميان اصلي سرویس هاي وب و عامل بسياري از ابداعات جديد در حيطه سرویس هاي وب هماننددابلیو اس ای[۳] و دی دی ای[۴]  بوده اند.  از نمونه هاي استفاده از اين معماري در كشور خودمان، سازمان ثبت احوال كشور است كه موظف شده تا پايگاه هاي اطلاعاتي خود را بصورت سرویس وب و مبتني بر اين معماري به ساير نهادها مانند نيروي انتظامي و ساير دستگاه ها ارائه دهد.

معماري سرويس گرا  یا به اختصار SOA روشي جديد و در حال تكامل براي ساخت برنامه هاي توزيع شده[۵]    است. سرويس ها  مولفه های توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پیام   هاي به زبان  XML را پردازش وتبادل مي كنند.  با رويكرد سرويس گرا مي توان راه حل هاي را ارائه داد كه به مرز دامنه هاي سازمان، شركت يا دپارتمان محدود نيستند. با استفاده از  معماری سرویس گرا مي توان در شركتي كه داراي سيستم ها و برنامه هاي كاربردي مختلف بر روي سکو[۶] هاي متفاوت است، يك راه حل يك پارچه سازي با استقلال زياد  [۷]را توسعه داده بطوریکه  جريانی يكنواخت و ناهماهنگ كار را تضمين كند. هر كس كه از سايت هاي تجارت الكترونيكي به صورت برخط خريد كرده باشد، با مفهوم سرويس ها آشنا است. وقتي كه سفارش خود را می دهید، بايد اطلاعات كارت اعتباري خود  را ارايه داده كه به طور معمول توسط يك فراهم كننده سرويس ثانويه، تاييد و شارژ  شود. وقتي كه سفارش پذيرفته شد، شركت سفارش گيرنده با يك شركت فراهم كننده سرويس حمل ونقل هماهنگ کرده و در نهايت كالاي شما تحويل   مي شود. نياز به معماري سرويس گرا از جنبه اي ديگر نيز به نحوه بارزي در برنامه هاي كاربردي تجارت الکترونیکی[۸] مشهود است. اگر مثلا مولفه[۹] مربوط به پرداخت با كارت اعتباري  غیربرخط و يا غير فعال باشد،‌قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوند وعمليات پرداخت به وقت ديگري موكول شود.

همانند ساير معماري هاي توزيع شده،‌ سرویس گرا ئی توسعه برنامه هاي كاربردي را با استفاده از مولفه هائی  كه در دامنه هاي جدا از هم  قرار دارند را ممكن مي سازد . معماری سرویس گرا از سرويس هاي وب به عنوان نقاط ورود برنامه كاربردي استفاده مي كند كه از لحاظ مفهومي معادل همان  مولفه های پراکسی  [۱۰] و استاب[۱۱]   در سيستم هاي توزيع شده سنتي مبتني بر مولفه هستند . با اين تفاوت كه در اين جا ارتباط بين سرويس وب و استفاده كننده خيلي آزاداترانه ومستقل تر   است .به علاوه معماری سرویس گرا  به خاطر در بر داشتن فاكتورهايي نظير  قابليت اطمينان سرويس،‌ جامعيت پيام، يكساني تراكنش و امنيت پيام اهميتی حياتي در تجارت الکترونیکی داشته و از این حیث منحصر به فرد است. در امور تجاري واقعي نمي توان روي سرويس هايي كه فقط يك درخواست را به خاطر اين كه فهمیده شود پردازش کرد. و بطور معمول به قطعيت و اطمينان بيشتري نياز است. واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلف متفاوت باشد . با وجود اين هيچكدام از اين موارد نبايد دلیلی براي كنار گذاشتن ياعدم پاسخ به يك درخواست باشند. علاوه بر آن نبايد هيچ ابهامي در نحوه فراخواني يك سرويس وجود داشه باشد. اگر سيستمي توانايي هاي خود را در قالب سرويس  وب ارائه كند. در آن صورت نحوه فراخواني آن سرويس بايد به طور واضح مستند سازي و اعلام شود . بسياري از مسائل دسترس پذيري و مقياس پذيري برنامه هاي كاربردي امروزي در معماری سرویس گرا  حل شده اند كه احتمال نقض آن ها در هر مر حله اي از جريان كار بسيار زياد است. در معماری سرویس گرا  فرض بر اين است كه خطا وجود دارد و مي تواند مهار شود،  بنابراين براي مثال اگر يك سرويس نتواند يك پیام را در مرحله اول بپذيرد . اين معماري طوري طراحي شده است كه پيام مجددا می تواند فرستاده شود. واگر يك سرويس به طور كامل قابل دسترس نباشد، (كه هرگز نبايد در يك سيستم معماری سرویس گرا ی پايدار[۱۲] انفاق بيفتد ) آن وقت معماري طوري طراحي شده است كه روي دادن خطاهايي كه  منجر به قطع كامل در خواست سرويس مي شود،‌امكان پذير نیست و چون خطاهاي موقت در بخشي از جريان كار نمي توانند كل فرايند تجاري را از كار بياندازند بنابراین معماری سرویس گرا  قابليت اطمينان را افزايش مي دهد.

  ۲-۱نتیجه گیری

معماري سرويس گرا  یا به اختصار SOA روشي جديد و در حال تكامل براي ساخت برنامه هاي توزيع شده[۱۳]  است. سرويس ها  مولفه های توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پیام هاي به زبان  XML را پردازش وتبادل مي كنند. در حالت کلی، معماری سرویس گرا  فرايندي تكامل يافته را ارائه مي نمايد و ازاين منظر مي توان آن را بلوغ سرويس هاي وب و فناوری هاي يكپارچه سازي به حساب آورد. در معماری سرویس گرا  به اين امر توجه شده است كه سيستم هاي با اهميت حياتي كه بر مبناي فناوری هاي توزيع شده ساخته مي شوند، بايد تضمين هاي خاصي را تامين نمايند. در اين گونه سيستم ها بايد اين اطمينان وجود داشته باشد كه در خواست هاي سرويس به طور صحيح مسير دهي و هدايت مي شوند، در زمان مناسب به آن ها پاسخ داده مي شود، و اين سرويس ها به طور واضح و دقيق سياست هاي ارتباطي و رابط هاي خود را اعلام مي كنند.

[۱] Metaphore

[۲] Modular

[۳] USE

[۴] UDDI

[۵] Application Distributed

[۶] Platform

[۷] loosly coupled

[۸] Ecommerce

[۹] Component

[۱۰] proxy

[۱۱] stub

[۱۲] Stable

[۱۳] Application Distributed

۱۲۰ صفحه Word

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