معماری سرویس گرا (SOA) چیست؟

[fahimeh.kheyrkhah]

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

 [FONT=Tahoma,sans-serif]معماري سرويس   [FONT=Tahoma,sans-serif](SOA)  [FONT=Tahoma,sans-serif]روشي جديد و در حال تكامل براي ساخت برنامه هاي توزيع شده   [FONT=Tahoma,sans-serif]Distributed  [FONT=Tahoma,sans-serif]است. سرويس ها اجزاي توزيع شده با رابط هاي تعريف شده و مشخص هستند كه پيغام   [FONT=Tahoma,sans-serif]XMIL  [FONT=Tahoma,sans-serif]را پردازش وتبادل مي كنند. با رويكرد سرويس گرا مي توان راه حل هايرا ارائه داد كه به مرز دامنه هاي سازمان، شركت يا دپارتمان محدود نيستند. بااستفاده   [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]مي توان در شركتي كه داراي سيستم ها و برنامه هاي كاربردي مختلف رويپلتفرم هاي متفاوت است، يك راه حل يك پارچه سازي با استقلال   [FONT=Tahoma,sans-serif](loosly coupled)  [FONT=Tahoma,sans-serif]ساخت كه جريان يكنواخت و ناهماهنگ كار را تضمين  [FONT=Tahoma,sans-serif].   [FONT=Tahoma,sans-serif]
   [FONT=Tahoma,sans-serif]   [FONT=Tahoma,sans-serif] [FONT=Tahoma,sans-serif]هر كس كه از سايت هاي تجارت الكترونيكي به صورت آنلاين خريد كرده باشد، با مفهوم  [FONT=Tahoma,sans-serif]سرويس ها آشنا است. وقتي كه سفارش تا ن را داديد، بايد اطلاعات كارت اعتباري تان راارايه كنيد كه به طور معمول توسط يك فراهم كننده سرويس ثانويه، تاييد و شارژ ميشود. وقتي كه سفارش پذيرفته شد، شركت سفارش گيرنده با يك شركت فراهم كننده سرويسحمل ونقل فراهم مي كند و در نهايت كالاي شما تحويلتان مي شود. نياز به معماري سرويسگرا از جنبه اي ديگر نيز به نحوه بارزي در برنامه هاي  [FONT=Tahoma,sans-serif] [FONT=Tahoma,sans-serif]مشهود  [FONT=Tahoma,sans-serif]
.  [FONT=Tahoma,sans-serif]اگر مثلا جزء  [FONT=Tahoma,sans-serif](componet)  [FONT=Tahoma,sans-serif]مربوط به پرداخت با كارت اعتباري  [FONT=Tahoma,sans-serif]offline  [FONT=Tahoma,sans-serif]و يا غير فعالباشد،‌قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوندوعمليات پرداخت به وقت ديگري موكول  [FONT=Tahoma,sans-serif].  
 [FONT=Tahoma,sans-serif]   
[FONT=Tahoma,sans-serif] [FONT=Tahoma,sans-serif]مثل ساير معماري هاي توزيع شده،‌  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]ساخت برنامه هاي كاربردي با استفاده اجزايي  [FONT=Tahoma,sans-serif]در  [FONT=Tahoma,sans-serif] [FONT=Tahoma,sans-serif]هاي جدا از هم را قرار دارند را ممكن مي سازد  [FONT=Tahoma,sans-serif]SOA.  [FONT=Tahoma,sans-serif]از سرويس هاي وب به  [FONT=Tahoma,sans-serif]عنوان نقاط ورود برنامه كاربردي استفاده مي كند كه از لحاظ مفهومي معادل همان اجزاي  [FONT=Tahoma,sans-serif]Pr o _x y  [FONT=Tahoma,sans-serif]و  [FONT=Tahoma,sans-serif]stub  [FONT=Tahoma,sans-serif]در سيستم هاي توزيع شده سنتي مبتني بر اجزاء هستند . با اين تفاوت كه  [FONT=Tahoma,sans-serif]در اين جا ارتباط بين سرويس وب و استفاده كننده خيلي آزاداترانه ومستقل تر  [FONT=Tahoma,sans-serif](loosely coupled)  [FONT=Tahoma,sans-serif]است .به علاوه  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]به خاطر در بر داشتن فاكتورهايي كه اهميت حياتي درتجارت دارند ، نيز منحصر به فرد است . فاكتورهايي نظير: قابليت اطمينان سرويس،‌جامعيت پيام ، يكساني تراكنش و امنيت پيام . در امور تجاري واقعي نمي توان رويسرويس هايي كه يك درخواست را فقط به خاطر اين كه بتوانند بفهمند،‌ پردازش مي كنندحساب كرد . در امور تجاري به قطعيت و اطمينان بيشتري نياز است. واضح است كه سيستمهاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها در دفعات مختلفمتفاوت باشد . با وجود اين هيچكدام از اين موارد نبايد براي كنار گذاشتن ياعدم پاسخبه يك درخواست  
[FONT=Tahoma,sans-serif]  بر آن نبايد دليلي براي كنار گذاشتن يا عدم پاسخ به يك درخواست باشند واضح است كه سيستم هاي مختلف ممكن است بعضي اوقات غير فعال باشند و يا پاسخگويي آن ها دردفعات مختلف ، متفاوت باشد. با وجود اين ،‌هيچ كدام ازاين موارد نبايد دليلي برايكنار گذاشتن يا عدم پاسخ به يك درخواست باشند. علاوه بر آن نبايد هيچ ابهامي درنحوه فراخواني يك سرويس وجود داشه باشد. اگر سيستمي توانايي هاي خود را در قالبسرويسي روي وب ارائه كند. در آن صورت نحوه فراخواني آن سرويس بايد به طور واضحمستند سازي و اعلام شود . بسياري از مسائل دسترس پذيري و مقياس پذيري برنامه هايكاربردي امروزي در [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]حل شده است كه احتمال نقض آن در هر مر حله اي از جريان كاربسيار زياد است.در  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]فرض بر اين است كه خطا وجود دارد و مي تواند بيفتد ،بنابراين استراتژي هايي براي مثال اگر يك سرويس نتواند يك پيغام را در مرحله اولبپذيرد . اين معماري طوري طراحي شده است كه مجددا پيام را بفرستد . واگر يك سرويسبه طور كامل قابل دسترس نباشد، (كه هرگز نبايد در يك سيستم  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]پايدار انفاق  [FONT=Tahoma,sans-serif])  [FONT=Tahoma,sans-serif]آن وقت معماري طوري طراحي شده است كه روي دادن خطاهايي كه ممنجر به قطع كامل درخواست سرويس مي شود،‌امكان پذير  [FONT=Tahoma,sans-serif]. SOA  [FONT=Tahoma,sans-serif]قابليت اطمينان را افزايش مي دهد، چون خطاهاي موقت در بخشي از جريان كار نمي توانند كل فرايند تجاري را از كار    [FONT=Tahoma,sans-serif]به بيان كلي،‌  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]فرايندي تكامل يافته را ارائه مي نمايد و ازاين نظر مي تواند انرا بلوغ سريس هاي وب و تكنولوژي هاي يكپارچه سازي به حساب آورد .  [FONT=Tahoma,sans-serif]SOA  [FONT=Tahoma,sans-serif]به اين امرتوجه شده است كه سيستم هاي با اهميت حياتي كه بر مبناي تكنولوژي هاي توزيع شدهساخته مي شوند. بايد تضمين هاي خاصي را تامين نمايند . در اين گونه سيستم ها بايداين اطمينان وجود داشته باشد كه در خواست هاي سرويس به طور صحيح مسير دهي و هدايتمي شوند، در زمان مناسب به آن ها پاسخ داده مي شود، و اين سرويس ها به طور واضح ودقيق سياست هاي ارتباطي و رابط هاي خود را اعلام مي  
   

[fahimeh.kheyrkhah]

سلام از تمامی شما عزیزان متشکرم.موفق باشین.