صفحه محصول - مقاله معماری سرویس گرا 33 ص

مقاله معماری سرویس گرا 33 ص (docx) 32 صفحه

دسته بندی : تحقیق

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

تعداد صفحات: 32 صفحه

قسمتی از متن Word (.docx) :

معماری سرویس گرا بسم الله الرحمن الرحیم فهرست مطالب چکیده فهرست شکل ها و جداول چکیده معماري سرویس گرا به عنوان يكي از آخرين دستاوردها در توليد نرم افزار، به نظر مي رسد، در سالهاي آتي معماري غالب صنعت فناوري اطلاعات و ارتباطات باشد. علت بوجود آمدن اين معماري، ايده اي بود كه در ذهن تعدادي از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس، شما نرم افزار خود را بگونه اي طراحي مي كنيد كه قابل استفاده توسط سيستم هاي ديگر باشد يعني ديگران مي توانند براي استفاده از سرویس شما ثبت نام كنند و هر موقع كه لازم داشتند از خدمات آن بهره ببرند، همانند حالتي كه در مورد شبكه هاي تلويزيون كابلي وجود دارد. تا زماني كه شما به سرویس متصل هستيد، مي توانيد هر لحظه كه خواستيد از سرویس استفاده كنيد. واژه های کلیدی 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) شكل تكامل يافته محاسبه‌گري توزيع شده مبتني بر فرضيه طراحي تقاضا/پاسخ براي برنامه‌هاي كاربردي همگام و ناهمگام است. منطق تجاري يا توابع اختصاصي يك برنامه كاربردي به صورت ماژولار در آمده‌اند و به عنوان سرويس‌هايي براي برنامه‌هاي كاربردي مصرف‌كننده/كلاينت ارائه گرديده‌اند. مهم‌ترين نكته‌ در مورد اين سرويس ‌ها طبيعت اتصال آزادانه آنهاست؛ بدين معني كه رابط سرويس، مستقل از پياده‌سازي است. تعاریف گوناگونی از معماری سرویس گرا ارائه شده است كه از جمله آنها می توان به تعاریف زیر اشاره كرد: مجموعه قوانین، سیاست ها و چارچوب هایی كه نرم افزارها را قادر می سازد تا عملكرد خود را از طریق مجموعه سرویس های مجزا و در عین حال مربوط به هم در اختیار سایر درخواست كنندگان قرار دهند تا بتوانند بدون اطلاع از نحوه پیاده سازی و تنها از طریق رابط های استاندارد و تعریف شده، این سرویس ها را پیدا كرده و فراخوانی نمایند. روشی برای ساخت سیستم های توزیع شده ای است که در آنها عملکرد سیستم بصورت سرویس در اختیار کاربران و یا سایر سرویس ها قرار می گیرد. از دیگرتعاریف ارائه شده می توان به "واحدهای نرم افزاری آماده در شبكه (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 بهتر دست مي‌يابيد همچنان كه فروشندگان بيشتر و بيشتري مشخصه‌هاي بيشتر و بيشتري از سرويس‌هاي وب را پشتيباني مي‌نمايند. معرفي WS-IBasic Profile سازمان (WS-I)Web Services Interoperability يك هدف اصلي دارد و آن را ارائه مشخصه هاي استانداردي است كه سرويس هاي وب بتوانند با استفاده از آن روي پلتفرم هاي مختلف با هم تعامل داشته باشند. به بيان ديگر، هدف اين سازمان اين است كه سرويس هاي وب بتوانند با هم كار كنند، ‌بدون توجه به اين كه تحت چه سكوي كاري عمل مي كنند و يا با استفاده از چه ابزارهايي ايجاد شده اند. اين مشخصه هاي سرويس هاي وب زمينه هاي گسترده اي را پوشش مي دهند، از پروتكل هاي نقل و انتقال داده تا امنيت كه مجموعه آن ها تحت عنوان پروفايل پايه WS-I جمع آوري شده اند. مشخصه هاي سرويس هاي وب به طور عمده در گروه هاي زير دسته بندي مي شوند: نقل و انتقال (Tranport ) اين گروه از مشخصه ها، پروتكل هاي ارتباطي براي انتقال داده هاي خام بين سرويس هاي وب را تعريف مي كنند و پروتكل هاي HTTP،HTTPS و SMTP را شامل مي شوند. پيغام رساني (Messaging) اين گروه از مشخصه ها تعيين مي كنند كه پيغام هاي XMIL كه سرويس هاي وب تبادل مي كنند، چه فرمتي بايد داشته باشند. اين گروه مشخصه هاي SOAP براي نحوه رمز گذاري پيغام و مشخصه هاي XMIL و XSD براي كلمات كليدي پيغام، (vocablury)را شامل مي شود. مشخصه هاي آدرس دهي سرويس هاي وب نيز در اين گروه قرار دارد. اين مشخصه ها اطلاعات مقصد پيغام را از پروتكل نقل و انتقال داده ها، مستقل مي سازد. براي مثال مي توان با استفاده از مشخصه هاي آدرس دهي سرويس هاي وب، چندين مقصد براي يك پيغام XMIL تعريف كرد. تشريح (Description) اين گروه شامل مشخصه هايي براي تشريح و توضيح يك سرويس وب است. مشخصه هاي اصلي اين گروه WSDL (براي قرارداد سرويس ) و XSD (براي تعريف شماهاي نوع داده) هستند. اين گروه همچنين مشخصه سياست گذاري سرويس وب(WS-Policy) را شامل مي شود كه سياست گذاري هايي كه يك سرويس وب به هنگام ارتباط با يك سرويس گيرنده (كلاينت) اعمال مي كند و تشريح مي كند. براي مثال يك سرويس ممكن است شرايط خاصي براي فراخواني عملياتش داشته باشد. مشخصه WS-Policy به سرويس وب اين امكان مي دهد كه به سرويس گيرنده هاي احتمالي بگويد براي اجراي يك درخواست سرويس موفق بايد از چه قوانيني تبعيت كنند. نهايتاً،‌ در اين گروه مشخصه UDDI براي يافتن (description) سرويس هاي وب گنجانده شده است. ضمانت هاي سرويس (Service Assurances) سرويس هاي وب نبايد فقط به سادگي پيغام هاي XMIL را رد و بدل كنند. اين سرويس ها بايد تضميني براي سرويس گيرنده داشته باشند كه اولاً پيغام به نحوي ايمن منتقل خواهد شد، ثانياً اين كه سرويس گيرنده بايد حتما پاسخي دريافت كند، حتي اگر در نقطه اي از جريان كار، نقصي پيش آمده باشد. اين گروه از مشخصه ها شامل مشخصه ی امنيت سرويس وب ( براي تضمين رسيدن پيغام ها) مشخصه ی پيغام رساني مطمئن سرويس وب ( براي تضمين رسيدن پيغام ها در شبكه هاي ناپايدار و بدون قابليت اطمينان) و تعداد زيادي از مشخصه هاي مربوط به تراكنش است. تركيب سرويس (Service Composition) مجموعه گسترده مشخصه هاي WS-I Basic Profile را نمي توان به طور كامل در هر سرويس وب پياده كرد. به همين خاطر، توسعه دهندگان بايد مشخصه هايي كه براي يك سرويس خاص مهم و مناسب هستند را انتخاب و در آن سرويس پياده كنند. براي تامين اين هدف،‌ سرويس ها داراي ويژگي تركيب سرويس هستند. كه به توسعه دهندگان اجازه مي دهد مشخصه هاي مختلف را براي هر سرويس انتخاب كنند و آن ها را در سند WSDL گرد آوري و ثبت كنند. در ادامه بحث، تعدادي از مهمترين مشخصه هاي سرويس هاي وب و اهداف آن را بيان مي كنيم: (WS-Seccurity) امنيت سرويس وب: مشخصه اي جامع كه مجموعه اي از تكنولوژي هاي متداول امنيتي را تحت پوشش دارد، از جمله امضاهاي ديجيتال و رمز گذاري مبتني بر نشانه هاي امنيتي،شامل گواهي هاي X.509 WS-Policy)) سياست گذاري سرويس وب: به سرويس هاي وب امكان مي دهد نيازها،) ترجيحاً(‌preferences و توانايي هاي خود را براساس مجموعه اي از فاكتورها بيان و مستند سازي مي كند كنند. البته تمركز بيشتر با فاكتورهاي امنيتي است. براي مثال سياستگذاري يك سرويس وب مي تواند شامل نيازهاي امنيتي آن، نظير رمز گذاري و امضاي ديجيتال بر اساس يك گواهي X.509 باشد. (WS-Adressing)آدرس دهي سرويس وب: نقاط انتهايي سرويس را در يك پيغام مشخص مي كندو امكان update شدن اين نقاط انتهايي را در مواردي كه پيغام بين دو يا چند سرويس منتقل مي شود، فراهم مي سازد. اين مشخصه به طور گسترده در حال جايگزيني مشخصه قديمي تر( WS-Routing) مسير دهي سرويس وب است. (WS-Messaging)پيام رساني سرويس وب: امكان پشتيباني از ساير پروتكل هاي كانال ارتباطي، نظير TCP، را در كنار HTTP براي سرويس وب فراهم مي سازد. اين مشخصه ساخت و توسعه نرم افزارهاي پيغام رساني، از جمله برنامه هاي كاربردي غير همزمان كه با استفاده از SOAP روي HTTP ارتباط برقرار مي كنند، را تسهيل مي كند. (WS-Secure Conversation) مكالمه ايمن سرويس وب: با استفاده از نشانه هاي امنيتي (Security tokens) ارتباطات مورد اعتماد براي جلسات كاري فراهم مي كند. (WS-Reliable Messaging)پيغام رساني مطمئن سرويس وب: مكانيسم هايي براي تضمين اطمينان از رسيدن پيغام، حتي در صورتي كه يك يا چند سرويس در زنجيره سرويس ها قابل دسترس نباشند، را فراهم مي سازد. اين مشخصه شامل روش هايي براي اعلام رسيدن پيغام است، به طوري كه فرستنده بتواند بفهمد كه آيا گيرنده در دريافت پيغام موفق بوده است يا نه. با معرفي و ثبت مشخصه هاي جديد و بهبود مشخصه هاي قبلي، مشخصه هاي سرويس هاي وب دائما ًدر حال تكامل هستند. البته، مجموعه مشخصه هاي پايه اي كه در این مقاله بيان شد، احتمالاً براي مدتي به عنوان زير بناي اصلي مشخصه هاي سرويس هاي وب باقي خواهند ماند،‌ چرا كه اين مشخصه ها نيازهاي اصلي و بنيادي برنامه هاي كاربردي سرويس گرا را پوشش مي دهند. معرفي.NET for Web Services Enhancements 2.0 Web Services Enhancements (WSE) 2.0 مجموعه اي از ابزارهاي مديريت شده تحتNET . را جهت پياده سازي مشخصه هاي سرويس هاي وب براي توسعه دهندگان فراهم آورده است WSE .جهت فراهم آوردن پشتيباني بيشتر زيرساختي، فراتر از آنچه كه در حال حاضر به وسيله چارچوب كاري دات نت تامين مي شود، ‌براي راه حل ها ي SOA ارايه شده است. به كمك WSE همچنين زير ساخت پردازشي براي ميزباني سرويس هاي وبي كه WS-Specification را پياده سازس مي كنند، فراهم مي آورد. براي مثال، WSEبه شما امكان مي دهد كه به آساني سرويس هاي وبي بسازيد كه رمز گذاري و امضاهاي ديجيتال را روي درخواست ها و پاسخ هاي سرويس وب اعمال مي كنند. در نهايت،‌WSE يك ابزار بهره وري است كه براي هدايت توسعه دهندگان دات نت به سمت نسخه آينده Indigo طراحي شده است. Indigo از محصولات آينده مايكروسافت است كه پشتيباني يك پارچه براي برنامه هاي كاربردي پيغام رساني و سرويس گرا را هم فراهم مي آورد. معماری سرویس گرای مقدماتی SOA شیوه ای منطقی برای طراحی سیستم های نرم افزاری است که از طریق آن سرویس هایی جهت ارائه به کاربران یا سایر سرویس های توزیع شده بر روی شبکه ایجاد می شود و این سرویس ها از طریق رابطهای تعریف شده در دسترس می باشند. معماری سرویس گرای مقدماتی، راهی برای تبادل اطلاعات بین عامل های نرم افزاری بوسیله پیغام تعریف می نماید. این عامل ها، درخواست کننده سرویس (مشتری) و یا تهیه کننده سرویس می باشند. علاوه بر این دو، عامل دیگری بعنوان عامل کشف سرویس نیز وجود دارد. در معماری سرویس گرا معرفی سرویس ها و همچنین نحوه ارتباط این سه شرکت کننده نیز اهمیت دارد. این ارتباطات عبارتند از: منتشر کردن سرویس، پیدا کردن سرویس و متصل شدن به سرویس. شکل 3 - معماری سرویس گرای مقدماتی در یک سناریو بر پایه سرویس، تهیه کننده، سرویس را پیاده سازی کرده و از طریق شبکه به ارائه توضیحات آن سرویس برای درخواست کننده یا عامل کشف سرویس می پردازد. در خواست کننده معمولا درخواست پیدا کردن سرویس را به عامل کشف سرویس می دهد تا از طریق آن به توضیحات ارائه شده سرویس و محل آن دسترسی پیدا کند. سپس با بکارگیری این اطلاعات به تهیه کننده سرویس متصل شده و از سرویس ارائه شده استفاده می نماید. بدین ترتیب، سرویس بعنوان قطعه نرم افزاری پیاده سازی شده ای که توسط یک رابط تعریف شده مستند گردیده است و نه تنها بوسیله خود تهیه کننده بلکه توسط سایر عواملی که از نحوه پیاده سازی آن خبر ندارند، نیز قابل استفاده و فراخوانی است. این ویژگی جعبه سیاه بودن سرویس از اصل ماژولاریتی در مهندسی نرم افزار به ارث رسیده است. البته سرویس با تعاریفی مانند ماژول، قطعه نرم افزاری یا شی تفاوت دارد، زیرا نه تنها در سطح برنامه ها و نرم افزارهای کاربردی، بلکه در سطح حرفه و حتی مابین سازمان ها نیز قابل بكارگیری و استفاده مجدد می باشد. در واقع سرویس ها، نمایش عملکرد معنی داری از حرفه هستند که می توانند بنا به نیاز مشتری در سرویس ها و توابع بزرگتر یا جدید بکار گرفته شوند. رابط ها به سادگی مکانیزمی جهت برقراری ارتباط بین سرویس و نرم افزارها یا سایر سرویس ها ایجاد می نمایند. از لحاظ تکنیکی، رابط سرویس ها، توضیحاتی در مورد نام و امضاء متدهای یک سرویس هستند که توسط درخواست کننده، قابل فراخوانی می باشند. معماری سرویس گرای توسعه یافته معماری سرویس گرای مقدماتی به برخی از مسائل موجود در یک معماری مبتنی بر سرویس نمی پردازد. از جمله این مسائل، مدیریت، هماهنگ سازی سرویس ها، متناسب کردن آنها، امنیت، مدیریت تراکنش ها و... می باشد. این نکات که در شکل 2 نمایش داده شده است، در معماری سرویس گرای توسعه یافته در نظر گرفته شده است. شکل 4 - معماری سرویس گرای توسعه یافته معماری مقدماتی در لایه پایینی این معماری لایه ای قرار گرفته است. لایه ترکیب سرویس در معماری توسعه یافته، شامل توابع و نقشهای لازم برای یکپارچه کردن چند سرویس به عنوان سرویس ترکیبی می باشد. سرویس ترکیبی بدست آمده، توسط Service Aggregator بعنوان یک سرویس مقدماتی استفاده می گردد و یا توسط درخواست کنندگان سرویس بکارگرفته می شود. Service Aggregator تهیه کننده سرویسی است که سرویس های ارائه شده توسط سایر تهیه کنندگان را یکپارچه می نماید تا از آنها سرویس های جدید بسازد، همچنین مشخصات و کدهایی را تهیه می کند تا در مورد سرویس های ترکیبی عملیات زیر را انجام دهد: - متناسب کردن: کنترل اجرای سرویس های ترکیب شده و مدیریت گردش داده ها در بین آنها و انتقال آن به خروجی.- کنترل کردن: مجوز دادن به رخدادها و اطلاعات تولید شده توسط سرویس های ترکیبی جهت به اشتراک گذاشتن و منتشر کردن رخدادهای ترکیبی سطح بالاتر ( برای مثال از طریق فیلتر کردن و خلاصه سازی). - مطابقت دادن: حصول اطمینان از حفظ جامعیت سرویس های ترکیبی از طریق تطبیق دادن محدودیت ها و نوع پارامترهای سرویس های بکار رفته. - ترکیب خواص سرویس ها: بکارگیری، مجتمع سازی و دسته بندی ویژگی های سرویس های ترکیب شده جهت بدست آوردن خواص ترکیبی جدید که دربردارنده کارایی، هزینه، امنیت، جامعیت، قیاس پذیری، در دسترس بودن و قابلیت اطمینان می باشد. استانداردهای جدید ارائه شده با عنوان زبان اجرای پردازشهای حرفه برای سرویس های وب، تلاشی است که بر اساس XML، تعریف سرویس های وب جدید را که از ترکیب سرویس های موجود بدست می آیند، ارائه دهد. یک پردازش BPEL بصورت انتزاعی با ارجاع و اتصال به portTypeهای تعیین شده در WSDL ای ایجاد می شود كه در سرویسهای وب موجود در یک پردازش، تعریف شده است. مدیریت نرم افزارهای کاربردی مهم و بحرانی تجارت الکترونیک، می بایست نظارت عمیق و جامعی در محیط های توزیع شده داشته باشد. خارج از دسترس بودن یک عنصر کلیدی در سیستم های توزیع شده، تاثیر منفی زیادی بر کل چرخه گذاشته و باعث بیرون رانده شدن ارائه کننده سرویس از بازار می شود. برای رویارویی با چنین موقعیت هایی، سازمان ها نیاز به کنترل دائم سرویس و حصول اطمینان از سلامتی سیستم دارند. کارایی می بایست همیشه، در هر شرایطی و با هر بار کاری، در سطح قابل قبولی باشد. برای مدیریت قسمتهای مهم و بحرانی و سرویس های ویژه، معماری توسعه یافته، در لایه مدیریت سرویس بعنوان بالاترین سطح، سرویس های مدیریت شده را ارائه کرده است. این لایه شامل دو قسمت مدیریت عملکرد و مدیریت بازار می باشد. کارکرد مدیریت عملکرد بدین صورت است که قسمتهای مهم سیستم را پشتیبانی می نماید. این لایه جزئیاتی از کارایی سیستم را جهت ارزیابی آن ارائه می دهد و بدین صورت سازمان را قادر می سازد تا بر اساس وضعیت نرم افزار و تکمیل شدن تراکنش های حرفه، تصمیم گیری نماید. اپراتور سرویس، مسئول انجام امور مربوط به این واحد است. مدیریت عملکرد، قابلیت بسیار مهم و کلیدی است که می تواند صحت و کارایی کلی سیستم را کنترل نماید و بدین ترتیب از بروز مشکلات شدید و خطا در سرویس ها جلوگیری کند. این خطاها ممکن است بر اثر اجتماع و هماهنگ سازی سرویس ها و بخاطر عدم رعایت توافق های در سطح سرویس (SLA) اتفاق بی افتد. مدیریت و کنترل های مناسب باعث کاهش احتمال بروز چنین خطاهایی می شود؛ بدین ترتیب که صحت، پایداری و همچنین مناسب بودن ارتباط بین توابع بکار رفته در سرویس های ورودی و خروجی را بررسی و کنترل می نماید. قسمت دیگر در لایه مدیریت، مدیریت بازار می باشد. مسئولیت این واحد ارائه پروتکل ها و قوانین استاندارد در سطح حرفه می باشد تا از این طریق امکان استفاده از سرویسهای تعبیه شده در بازارهای مختلف بوجود آید. در ضمن برخی از تسهیلات و سرویسهای پایه برای امور مالی، تضمین کیفیت و... در این لایه قرار می گیرد تا از این طریق بازارهای مختلف بتوانند در کمترین زمان به سرویس ها دسترسی یابند. این قسمت از لایه مدیریت، توسط سازندگان بازار که کنسرسیومی از شرکت های فعال در این عرصه هستند، کنترل و نگهداری می گردد. می توان معماری سرویس گرا را روشی در جهت بهبود طراحی و استفاده از سیستم های نرم افزاری دانست، اگرچه مشكلات و چالش های پیش روی آن همچنان نیازمند بررسی تجارب گذشته و نیز ارائه راه حل مناسب پیرامون مسائل مطرح در این معماری می باشند. معماري سرويس گرا در توليد نرم افزار همان طور كه در عنوان آن مشخص است، به مفهومي در سطح معماري، اشاره مي كند و بنابراين در مورد چيزي پايه اي و اساسي در سطوح بالا است، كه پايه و اساس آن تجربيات بدست آمده در توليد سيستم هاي نرم افزاري مبتني بر CBD و دو اصل اساسي در صنعت مهندسي نرم افزار يعني توليد نرم افزار بصورت با همبستگي زياد و در عين حال با چسبندگي كم است. بنابراين ايده هاي برنامه نويسي سرویس گرا ايده اي جديد نيست و شما شايد قبلا از آن استفاده كرده باشيد. اما جمع آوري بهترين تجربيات از توليد چنين سيستم هايي بصورت مجتمع و ناظر به وضعيت تكنولوژيكي امروز بشر، كه همان مفاهيم مطرح شده در معماري سرویس گرا است چيز جديدي است. مهندسان نرم افزار، هميشه گفته اند كه نرم افزار بايد به شكلي نوشته شود كه همبستگي زياد ولي در عين حال اتصال كمي داشته باشد. شركت هاي بزرگ نرم افزاري هم در جهت گام برداشتن براي رسيدن به اين دو اصل، تكنولوژي هايي را بوجود آوردند كه به برنامه نويسان اجازه دهد تا به اين دو هدف در توليد نرم افزارهاي خود تا حد زيادي دست يابند. براي مثال مي توان به تكنولوژي هايي مانند COM+ , CORBA و RMI و موارد ديگر، اشاره كرد. مشاهده كرديد كه موضوع برنامه نويسي سرویس گرا، مفهموم جديدي نيست و اين معماري تلاشي ديگر در جهت توليد نرم افزارهاي با همبستگي زياد و در عين حال با چسبندگي و اتصال كم است. ممكن است بپرسيد، پس چرا با وجود تكنولوژي هاي قدرتمندي چون CORBA ,COM+ ,RMI چيز جديدي بوجود آمد؟ مگر تكنولوژي هاي قبلي موفق نبودند؟ بله مهمترين اشكال در معماري هاي قدرتمندي چون موارد مذكور اين بود كه توليد كنندگان آنها سعي داشتند، كه تكنولوژي خود را بر بازار غالب نمايند. رويايي كه هرگز به حقيقت نمي پيوست. بنابراين با توجه به اين موضوع كه اين تكنولوژي ها قادر به تعامل مناسب با يكديگر نبودند عملاً اصل همبستگي زياد بصورت خود بخود رد مي شد. البته معماري هاي مذكور اشكالات ديگري هم داشتند كه نسبت به مورد بالا از اهميت كمتري برخوردار است كه از جمله آنها مي توان به عدم هماهنگي با اصول امنيتي مورد استفاده در اينترنت اشاره كرد. البته بعدها راه حل هايي هم براي اين مشكل بوجود آمد) مانند (RPC Over HTTP اما به اين علت كه از روز اول، در طراحي اين تكنولوژي ها اين امر در نظر گرفته نشده بود، از كارايي مناسبي برخوردار نبودند. مفهموم همبستگي زياد و در عين حال با چسبندگي و اتصال كم، وقتي بخواهد در جهت ارزيابي يك سيستم نرم افزاري يا تكنولوژي، مورد استفاده قرار گيرد بسيار مبهم مي شود. حتي كسي مي تواند ايده هاي همبستگي و چسبندگي را باهم تركيب كند!. براي جلوگيري از چنين ابهاماتي، شما مي تواند از ويژگي هاي معماري سرویس گرا به عنوان يك راه براي ارزيابي ميزان همبستگي و چسبندگي و اتصال يك سيستم نرم افزاري يا يك تكنولوژي استفاده كنيد. اگرچه مفاهيم مطرح شده در معماري سرویس گرا دقيقاً همان مفاهيم همبستگي زياد و در عين حال چسبندگي كم نيستند، اما سيستم هايي كه بر اساس معماري سرویس گرا طراحي و پياده سازي شده اند، نشان داده اند كه توانسته اند تا حد بسيار زيادي ويژگي هاي همبستگي زياد و در عين حال چسبندگي كم را بخوبي در خود ايجاد و حفظ كنند. در چهار دهه اخیر، پیچیدگی نرم افزارها روز به روز بیشتر شده و تقاضا برای نرم افزارهای قدرتمندتر افزایش یافته است. در این میان، به نظر می رسد که روش های قدیمی جوابگوی نیازهای در حال رشد کنونی نیستند و نیاز به ایجاد و بکارگیری روش هایی است که بوسیله آنها بتوان بر این پیچیدگی ها در زمان هایی کوتاه تر غلبه کرد. از طرفی امكان كنار گذاشتن سیستم های نرم افزاری موجود که تا به حال مشغول سرویس دهی به مشتریان بوده اند، وجود ندارد و می بایست سیستم های جدید را بصورت یکپارچه و در کنار همین سیستم ها بوجود آورد. معماری سرویس گرا، با تکیه بر محاسبات توزیع شده و بر پایه شبکه ها و لایه های میانی و همچنین زبان هایی که تولید نرم افزارهای توزیع شده را فراهم می كنند، بعنوان راه حلی مناسب جهت از میان برداشتن مشکلات و مسائل مذكور مطرح گردیده است. در روش فوق هدف فقط اینکه سیستمی داشته باشیم که بتواند سرویس بدهد نیست بگونه ای دیگر در این روش طراح مثلا به حسابداری به عنوان یک سیستم خاص نباید نگاه کند که به دیگرسیستم ها سرویس می دهد و کار حسابداری انجام می دهد بلکه باید به این شکل نگاه شود که مجوعه سرویس هایی آماده شود براساس فرآیند های سیستم حسابداری که این سرویسها در presentation layer ای می توانند توسط یک نرم افزار یا بصورت سناریو های مختلف در جاهای مختلف فرآخوانی شده و یک فرآیند یا بخشی از فرآیند مربوط به حسابداری راانجام دهند که می توانند هر بخشی از این فرآیند مربوط به یک کار یا سیستم باشد مثلا در سیستم های ERP درسازمانها می توان فرآیند درخواست جنس از یک مجتمع تولیدی را توسط مشتری در نظر بگیریم می توان سناریوئی چید تا درخواست مشتری بررسی, درصورت عدم وجود جنس درخواست مواداولیه ازانبار و درنهایت تامین خواسته مشتری با صدور یک سند در حسابداری پایان یابد که هرکدام ازاین گام های سناریو می توانند در سیستم گردش کاری یا در پشت صحنه توسط نرم افزار هدایت شده ودرنهایت با فراخوانی سرویسهای مختلف از سیتم های مختلف و اثر گذاری هریک این سناریو اجرا شود. البته در هر حال سرویس های وب از این نظر كه طیف كاربران بالقوه آنها اینترنت است بسیار مورد توجه هستند. در حال حاضر هم در اكثر سازمانها برای تمامی نرم افزار ها یك واسط بصورت وب سرویس جهت فراهم كردن استفاده از آن برای سازمانهای همكار فراهم می شود و یا حتی در داخل سازمان و در مواردی كه استفاده از نرم افزار مذبور در داخل سازمان بسیار استفاده شود، با توجه به مشكلات كارایی سرویس های وب، یك واسط بصورت یكی از تكنولوژی های برنامه نویسی مبتنی بر Component مانند COM+ و یا CORBA برای نرم افزار ایجاد می شود. آماده شدن برای معماری سرویس گرا: همانطوری كه ذكر شد، با وجود اینكه تعدادی نكات منفی در استفاده از سرویسهای وب به عنوان پایه معماری سرویس گرا وجود دارد اما این موارد قابل حل هستند. برای مثال در مورد بحث كارایی، می توان از پردازنده ای قدرتمند تر استفاده كرد و یا مشكل امنیت را می توان با استفاده از زیرساختهای مبتنی بر رمزنگاری های نامتقارن حل كرد. در هر حال اگر شما تا بحال برای معماری سرویس گرا آماده نشده اید، در هر حال لازم است تا به این سمت پیش روید زیرا همانطور كه در ابتدای این مقاله اشاره شد، نرم افزارهای مبتنی بر این معماری، نسل غالب سال های آینده خواهند بود. بدین منظور باید اندكی تفكر خود را در مورد طراحی نرم افزار، تغییر دهید. در زیر به مهمترین آنها اشاره می شود: - سعی كنید با سرویس دهنده های خود از طریق واسط های چاق ارتباط برقرار كنید و از استفاده از واسط های پرحرف بپرهیزید. به عبارت دیگر سعی كنید عملیاتی كه شامل چندین فراخوانی است از طریق یك فراخوانی انجام دهید. هر بایت اطلاعاتی كه شما روی اینترنت می فرستید محسوس است زیرا روی اینترنت اولاً پهنای باند محدود است و همچنین در مورد هر انتقال باید عملیات تحلیل نام و مسیریابی انجام شود. - سعی كنید حتی الامكان اطلاعات مربوط به وضعیت را در سمت سرویس دهنده نگهداری نكنید. سعی كنید این كار را به استفاده كنندگان واگذار كنید. برای مثال اگر شما یك سازمان باشید كه تعداد زیادی مراجعه كننده دارد و شما نیاز به اطلاعات مراجعه كننده ها دارید، اگر بخواهید خودتان تمام اطلاعات مربوط به مراجعه كنندگان خود را نگهداری كنید به یك انبار بسیار بزرگ نیاز خواهید داشت. بهتر است از مراجعه كنندگان خود بخواهید كه اطلاعات خودشان را نگهداری كنند، نه خود سازمان شما بخواهد آنها را نگهداری كند. - سعی كنید از واسط های بسیار خوش تعریف برای سرویس های خود استفاده كنید زیرا وقتی شما پایه خود را بر سرویس های وب بنا نهادید، لازم دارید این واسط ها را در اختیار استفاده كنندگان از سرویس خود قرار دهید. (از طریق WSDLسرویس وب خود) - سعی كنید به سمت استفاده از روش های غیرهمزمان برای فراخوانی های خود پیش روید زیرا بسیاری از سرویس ها به استفاده كنندگان خود بصورت غیرهمزمان سرویس می دهند(مانند سرویس های وب) بنابراین برای سرویس گیرندگان بهتر است از این روش تبعیت كنند. این روش مناسبی نیست كه سرویس گیرنده به علت اینكه سرویس دهنده هنوز پردازش را شروع نكرده است، بلاك شود. به عبارت دیگر سعی كنید دید خود را از حالت درخواست/پاسخ (مطرح در معماری Client/Server) به دید مبتنی بر پیام تغییر دهید؛ یعنی وقتی كه سرویس گیرنده یك پیام را برای سرویس دهنده ارسال كرد سرویس دهنده بعد از مدتی از طریق یك پیام به سرویس گیرنده پاسخ خواهد داد. - برای تصدیق هویت و كنترل دسترسی به روشهای دیگر فكر كنید. مكانیزهای امنیتی در مورد سرویس های وب متفاوت است. در مورد مكانیزهای امنیتی مورد استفاده از روش های خاص یك پلتفرم استفاده نكنید زیرا قابلیت تعامل سیستم شما را با سایر سرویس ها بخطر می اندازد(مانند (Integrated Windows Authentication)اخیرا هم یك گسترش در مشخصات سرویس های وب با نام ws-security بوجود آمده است كه از آن جهت پیاده سازی امنیت در سروی های وب استفاده می شود. - از پلتفرمی استفاده كنید كه به شما اجازه دهد بطور همزمان چندین نسخه از یك سرویس را در كنار هم نگه دارید (مراجعه كنید به قابلیتهای سیستم های نرم افزاری مبتنی بر معماری سرویس گرا) همچنین به یاد داشته باشید تكنولوژیهایی مانند COM+,CORBA,RMI در حیطه خود فنآوری های موفقی بوده و هستند و تعداد بسیار زیاد سیستم هایی كه از این معماری ها استفاده می كنند این موضوع را نشان می دهد. سرویس های وب شامل مفاهیمی هستند كه در مورد این تكنولوژی ها وجود ندارد، اما این به این معنی نیست كه سرویس های وب در زمانی كوتاه جایگزین این فنآوری ها خواهند بود؛ و بنابراین سعی كنید در كنار این تكنولوژی ها از سرویس های وب بهره جویید. با توجه به بوجود آمدن شركت های چند ملیتی، ظهور خدمات الكترونیك و پیچیده شدن امور گوناگون و مخصوصا مجتمع سازی سیستم های نرم افزاری گوناگون EAI، این معماری توانسته بخوبی از عهده این پدیده های نوین بر آید. ويژگي هاي سيستم هاي نرم افزاري مبتني بر معماري سرویس گرا استفاده كننده از سرویس هيچ لزومي ندارد از جرئيات پياده سازي سرویس در سمت سرویس دهنده مطلع باشد - محل سرویس دهنده بايد از نظر استفاده كننده از سرویس پنهان باشد(در انجام امور مرتبط با استفاده از سرویس ) و تنها در زمان اجرا سرویس گيرنده از مكان سرویس دهنده آگاه خواهد شد. - نرم افزار مبتني بر معماري سرویس گرا بايد بتواند با نرم افزارهاي موجود روي ساير پلتفرم ها تعامل داشته باشد. - چندين نسخه از سرویس بايد بصورت همزمان در كنار هم فعاليت كنند زيرا با توجه به طيف گسترده استفده كنندگان در صورت بروزرساني سرویس در سمت سرویس دهنده، به سرعت امكان بروزرساني استفاده كنندگان سرویس وجود ندارد همچنين تعدادي از ويژگي هايي كه هر نرم افزار، اعم از اينكه مبتني بر اين معماري باشد يا نباشد، بايد داشته باشد به شرح زير است: -كارايي زياد. – امنيت بالا (تضمين محرمانگي، صحت اطلاعات و هميشه در دسترس بودن) و همچنين كنترل دسترسي. - قابليت اطمينان بالا بخصوص وقتي سر و كار با تراكنش هاي چند مرحله اي است. سرویس هاي وب به عنوان پايه معماري سرویس گرا سير تكامل و رشد XML، با پيدايش سرویس هاي وب همراه بود. يك سرویس وب بهترين راه حل براي پياده سازي معماري سرویس گرا است، مخصوصا وقتي ديدگاه استفاده از كل كاربران اينترنت به عنوان كاربران بالقوه سرویس مطرح باشد. شما پايه كار خود را بر پروتكل HTTP بنا مي نهيد، پروتكلي كه از همه پروتكل هاي ديگر روي اينترنت قابل دسترس تر است. با نگاه به قابلتهاي سيستم هاي نرم افزاري مبتني بر معماري سرویس گرا، شما متوجه خواهيد شد كه سرویس هاي وب بسياري از موارد مطرح شده در بالا را رعايت مي كنند اما تعدادي از اصول مطرح شده را هم زير پا مي گذارند كه آن را بررسي مي كنيم: - كارايي: XML كه عنصر اصلي سازنده سرویسهاي وب است، نسبت به ساير مكانيزم هاي انتقال اطلاعات (binary) از سربار بسيآر زيادي برخودار است. - قابليت اطمينان در تراكنش ها: اگر شما در يك تراكنش از يك سرویس وب استفاده كنيد، چگونه مي توانيد صحت تراكنش را تضمين كنيد در حالي كه تمام كارهاي شما مبتني بر اينترنت و پروتكل HTTP است؟ - امنيت: شما چگونه مي توانيد كاربران سرویس خود را تصديق هويت كنيد تا بعد از آن بتواند صلاحيت آنها را در استفاده از سرویس تان مورد بررسي قرار دهيد؟ همچنين يك نكته منفي ديگر در مورد سرویس هاي وب در حال حاضر، عدم پشتيباني اكثر محيط هاي توليد نرم افزار (IDE) براي توليد و استفاده از آنها است و در عين حال فراهم كردن قابلت هايي مانند كمك به برنامه نويس در استفاده از متدها و غيره يا پيدا كردن خطاها در زمان كامپايل و نه زمان اجرا. بنابراين، مگر اينكه موارد فوق به نحوي حل نگردد، ممكن است استفاده از سرویس هاي وب به عنوان پايه معماري سرویس گرا مورد سوال قرار گيرد. البته در هر حال سرویس هاي وب از اين نظر كه طيف كاربران بالقوه آنها اينترنت است بسيار مورد توجه هستند. در حال حاضر هم در اكثر سازمان ها براي تمامي نرم افزار ها يك واسط بصورت وب سرویس جهت فراهم كردن استفاده از آن براي سازمانهاي همكار فراهم مي شود و يا حتي در داخل سازمان و در مواردي كه استفاده از نرم افزار مذبور در داخل سازمان بسيار استفاده شود، با توجه به مشكلات كارايي سرویس هاي وب، يك واسط بصورت يكي از تكنولوژي هاي برنامه نويسي مبتني بر Component مانند COM و يا CORBA براي نرم افزار ايجاد مي شود. ویژگی های سرویس و محاسبات سرویس گرا محاسبات سرویس گرا (SOC)، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پايه سرویس به عنوان عنصر اساسی، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستم های توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند. از آنجا که سرویس ها از طریق سازمان ها و شرکت های گوناگون تهیه می شوند و جهت دسترسي كاربران مختلف می بایست همواره در دسترس باشند، رعایت ویژگیهای زیر ضروری می باشد: - مستقل از تکنولوژی باشند؛ به این معنا که بکارگیری و مکانیزم فراخوانی و پیدا کردن سرویس ها به راحتی و از تمام محیط ها ( سیستم های عامل مختلف و زبانهای برنامه سازی گوناگون ) میسر بوده و وابسته به پلتفرم خاصی نباشد. - وابستگی بسیار پایینی بین درخواست کننده و ارائه دهنده سرویس وجود داشته باشد و یا بعبارتی Loosly Coupled باشد. به این معنا که درخواست کننده نباید هیچ نیازی به دانستن ساختار داخلی و نحوه پیاده سازی سرویس داشته باشد. برای این منظور، فراخوانی سرویس از طریق بکار گیری مکانیزم پیغام (Message) بجای فراخوانی API انجام می گردد. - درخواست کننده نباید نیازی به دانستن محل قرارگیری سرویس داشته باشد و بعبارتی معماری سرویس گرا می بایست Location Transparency  را پشتیبانی نماید. به این ترتیب که محل قرارگیری سرویس و مشخصات آن در مخزنی (Repository) قرار می گیرد و درخواست کننده، محل و اطلاعات لازم را از طریق بازیابی آن از این مخزن بدست می آورد. سیستم های ساخته شده بر اساس سرویس، ترکیبی از سرویس های مستقل هستند که عملکردهای خود را از طریق رابطهای تعریف شده ای در اختیار کاربران (بالقوه ) خود  قرار میدهند.  (Web Service Description Language)WSDL از جمله راه هایی است که بطور گسترده برای تعریف این رابط ها بکار می رود تا بوسیله آن جزئیات لازم برای اتصال درخواست کننده به ارائه دهنده سرویس تعریف شود. نرم افزار به‌عنوان سرویس اصل ارائه شده " نرم افزار- بعنوان- سرویس" از محاسبات سرویس گرا، بر اساس مدل ASP مطرح گشته است. ASP هویت سوم شخصیست که بكارگيري سرويس هاي نرم افزاري و دسترسی مشتری را به بسته نرم افزاری از طریق شبكه، مدیریت و میزبانی می نماید. به‌عبارتی ASP ها راهی برای رفع نیازهای IT شرکت ها از طریق واگذاری بخشي از این نيازها یا تمامی آنها به بیرون از سازمان می باشند. برای این منظور ASP با استفاده از زیر ساخت های خود، ارتباط بین مشتری و نرم افزار ارائه شده را برقرار کرده و دسترسی وی به داده ها و توابع موجود را بصورت در دسترس (online)، مدیریت می نماید. اگرچه نظریه "نرم افزار بعنوان سرویس" اولین بار توسط ASP ارائه شد، اما مشكلات این روش باعث ایجاد کدهایی می شد که معمولا قابل استفاده مجدد نبوده و محدود به مشتری خاص می بود، بعبارتی وابستگی زیادی بین سرویس ارائه شده و سیستم استفاده کننده بوجود می آمد. معماری سرویس گرا اجازه می دهد تا نظریه "نرم افزار بعنوان سرویس"، گسترش یافته تا از طریق آن بتوان پردازش ها و تراکنش های پیچیده را بعنوان سرویس هايی با قابلیت استفاده مجدد ارائه کرد و به این ترتیب سیستم ها را مستقل از سرویس ها طراحی و تولید نمود. معماري سرويس گرا سبكي از سيستم هاي اطلاعاتي است كه بر اتصال سست، قابليت استفاده مجدد، تركيب پذيري، پنهان سازي پياده سازي داخلي و... تاكيد داشته و شامل استانداردهاي soap, wsdl, bpel, uddi مي شود. از طرف ديگر چگونگي تغيير و تاثير جنبه هاي سازمانی (فرايندها، بانك هاي اطلاعاتي، زيرساخت) در مواجه با معماري سرويس گرا نياز به توجه بيشتر دارد. چگونگي ارتباط معماري سرويس گرا با کسب و کار سازمان (خصوصا فرايندها) و تاثیر متقابل آنها جزو موضوعات جذاب و پرطرفدار سال هاي اخير بوده و ده ها كتاب و تز دانشگاهي و صدها مستند فني نيز به اين موضوع پرداخته اند كه هركدام از زاويه اي قصد داشته اند ويژگي ها و قالبي براي "معماري سرويس گرا سازماني" ارائه كنند. تقريباً اكثر این منابع تاثير SOA بر جنبه های دیگر سازمان(فرایندها، زیرساخت) را ناچیز دانسته و SOA را غالباً موضوعي "نرم افزاري" به حساب آورده اند. به عبارت واضح تر از ديدگاه آنان، "معماري سرويس گرا" بیشتر از حيث نتايج در لايه نرم افزاري نسبت به سبک های قبلی متفاوت بوده است. اين برداشت در طول سالهاي 2004 تا 2007 غالب بود و همان گونه كه گفته شد اكثر كتب و مستندات معتبر منتشر شده بر اين ديدگاه اعتقاد داشتند‍‌‌. اما در كنار ديدگاه اول، به تدريج ديدگاه جديدتر و كامل تري نيز رشد يافت و در يكي- دو سال اخير بالغ  شد كه معتقد بود "معماري سرويس گرا" بخشي از پارادايم سرويس گرائي (Service-Orientation) است و اين پارادايم همانطور كه در لايه نرم افزارهاي كاربردي منجر به سبك "معماري سرويس گرا"(SOA) مي شود، در كسب و كار سازمان نيز مي تواند اثر بخش بوده و "سازمان سرويس گرا" (SOE) را تعريف كند، همچنين در لايه زيرساخت منجر به "زيرساخت سرويس گرا"(SOI) شود. با اين تعريف جديد، پارادايم سرويس گرائي به سه شكل خود را نشان مي دهد: جنبه سازماني: سازمان سرويس گرا SOE: (Service Oriented Enterprise) جنبه معماري نرم افزار: معماري سرويس گرا SOA: (Service Oriented Architecture) جنبه زيرساخت: زيرساخت سرويس گرا SOI: (Service Oriented Infrastructure) اين ديدگاه جديد و جامع همانطور كه گفته شد طي دو سال اخير مباني خود را ارائه نمود، اما نتوانسته بود به ديدگاه غالب بدل شود و نيز منابع و مراجع معتبر جهاني در تائيد خود نداشت تا اينكه سرانجام در نيمه دوم سال 2008، شوراي مديران ارشد اطلاعاتي(CIO Council) دولت ايالات متحده آمريكا نتايج مطالعات و بررسي هاي چند ساله خود در تائید این دیدگاه جدید را با عنوان "راهنماي كاربردي براي معماري سرويس گرا فدرال" (A Practical "Guide to Federal Service Oriented Architecture) منتشر نمود. راهنماي كاربردي براي معماري سرويس گرا فدرال" به عنوان جديدترين مستند منتشر شده اين شورا، در بردارنده مباني جديدي در حوزه سازمان سرويس گرا مي باشد و نشان دهنده يك جهش فني و بنيادي در اين صنعت است. رابطه بین BPM , SOA و EA معماری سرویس گرا رابطه تنگاتنگی با رهیافت های معماری سازمانی (EA) و مدیریت فرایندهای حرفه (BPM) دارد. بررسی ارتباط و چگونگی تعامل این رهیافت ها می تواند موضوع جالبی برای پایان نامه ها و تحقیقات علمی باشد!!!. در فضای کاری و پروژه های اجرائی نیز ارتباط بین این سه رهیافت مطرح بوده و هست: در این راستا برخی سازمانها، پروژه های تلفیقی تعریف و اجرا می کنند که معماری سازمانی را با BPM همراه نموده تا بتوانند از مدل های معماری در پروژه BPM استفاده کنند. برخی دیگر شرکت ها نیز معماری سازمانی را با SOA همراه کرده اند و می خواهند در طی فرایند معماری سازمانی، مدل های مرتبط با سرویس های حرفه شناسائی و استخراج شوند تا در مرحله بعد، این مدل ها توسط پروژه های SOA به سرویس های سیستمی تبدیل شده و سیستم های سرویس گرا طراحی شوند، جالب اینکه پروژه های تحت عنوان معماری سازمانی سرویس گرا کم کم دارند جای پروژه های کلاسیک معماری سازمانی را می گیرند. حالت ترکیب  BPM و SOA به مراتب مرسوم تر بوده و زمینه های زیادی برای یکپارچگی دارند، اکثر سیستم های مدیریت فرایندهای کسب و کار(BPMS) که در دنیا رایج هستند از فناوری های مبتنی بر معماری سرویس گرا استفاده می کنند و از طرف دیگر محیط های یکپارچه طراحی و پیاده سازی سرویس گرا (Oracle SOA Suite, Microsoft BizTalk Server, IBM WebSphere) جایگاه ویژه ای برای BPM در نظر گرفته اند. باید به این نکته اشاره کرد که دامنه کاربرد و جایگاه سه رهیافت EA، BPM و SOA دارای نقاط مشترک فراوانی است و می تواند منشاء بهبود و تکامل هر یک از این رهیافت ها باشد. شرکت ها  و سازمانها نیز بصورت غیر رسمی(برنامه ریزی نشده) به تلفیق این رهیافت ها علاقه مند شده اند، لذا متخصصان این حوزه ها باید مطالعات و تمرینهای بیشتری بر روی نقاط اشتراک و چگونگی تلفیق این رهیافت ها انجام دهند. EAI with SOA راه حل معماری سرویس گرا برای یکپارچه سازی سیستم های اطلاعاتی(EAI), ارتباط بین سیستم های اطلاعاتی به کمک وب سرویس است. از اواخر دهه 90 برای چالش تعامل پذیری سیستم های اطلاعاتی رهیافت هایی ارائه شده که معروفترین آنها اتصال نقطه به نقطه (Peer-to-Peer) و یکپارچگی مبتنی بر یک مترجم مرکزی بوده است. در حالت نقطه به نقطه برای هر تعامل بین دو سیستم اطلاعاتی در سازمان لازم است که استاندارد و مسیر ارتباطی مربوطه تعریف و فراهم گردد. طبیعی است که چنین رهیافتی بسیار هزینه بر و دست و پا گیر خواهد بود. در حالت مترجم مرکزی نیز میان افزاری (Middle-Ware) به عنوان مترجم بین همه سیستم های اطلاعاتی عمل می کرد به گونه ای که مانند یک هاب مرکزی تمامی پیام های ارسالی به این واسط ارجاع می شد و پس از ترجمه به پروتکل و فناوری سامانه مقصد، ارسال می گشت. این گزینه نیز با دشواری هایی همراه بود که مهمترین آنها وجود انواع پروتکل های ناهمجور و عدم جامعیت بود. اما در معماری سرویس گرا اصل بر این است که همه سیستم های اطلاعاتی با یک واسط استاندارد و مورد توافق جهانی تعامل داشته باشند. این واسط وب سرویس(Web Service) نام دارد و پروتکل های مورد استفاده ان نیز شامل SOAP,WSDL,UDDI می شود، همه این پروتکل ها بسطی از XML هستند که استانداردی جهانی و مورد توافق همه سکوها، فناوری ها و سازندگان است. در حقیقت معماری سرویس گرا اجازه می دهد تا سیستم های اطلاعاتی سازمان دارای فناوری و پیاده سازی مختص به خود باشند به شرطی که برای ارائه و دریافت سرویس با دیگر سیستم ها از یک استاندارد پذیرفته شده تبعیت کنند، مفهوم "سرویس " نیز بیانگیر همین موضوع است. سرویس مانند یک جعبه سیاه است که از داخل آن اطلاعی در دسترس نیست اما درگاه هائی برای ارائه تعدادی Function ارائه نموده است. چرا معماری سرویس گرا (SOA) ؟! در حالي كه مفهوم SOA اساسا جديد نيست، SOA با تكنولوژي‌هاي توزيع‌شده موجود متفاوت است به گونه‌اي كه اغلب فروشندگان آن را پذيرفته و داراي يك مجموعه پلت‌فرم يا برنامه كاربردي هستند كه داراي قابليت SOA مي‌باشند. SOA با يك مجموعه از استانداردهايي كه همه جا در دسترس هستند، قابليت استفاده مجدد از سرمايه‌ها و دارايي‌هاي موجود در سازمان را بهبود مي‌بخشد و به شما امكان ايجاد برنامه‌هاي كاربردي كه مي‌توانند بر فراز برنامه‌هاي كاربردي موجود و جديد ساخته شوند، مي‌دهد. SOA امكان ايجاد تغيير در برنامه‌هاي كاربردي در شرايطي كه كلاينت‌ها يا استفاده‌كنندگان از سرويس جداي از تغييرات صورت گرفته در پياده‌سازي سرويس حفظ شوند، فراهم مي‌آورد. SOA امكان ارتقاي استفاده‌كنندگان از سرويس يا سرويس‌هاي اختصاصي را فراهم مي‌سازد؛ بازنويسي كامل يك برنامه كاربردي يا حفظ يك سيستم موجود كه ديگر نيازمندي‌هاي جديد تجاري را مد نظر قرار نمي‌دهد لازم نيست. نهايتا، SOA انعطاف‌پذيري بيشتري را براي سازمان‌ها در ساختن برنامه‌هاي كاربردي و فرايندهاي تجاري به شيوه‌اي سريع‌تر با بهره‌گيري از زيربناي برنامه‌ي كاربردي موجود به منظور توليد سرويس‌هاي جديد فراهم مي‌نمايد. برای آن دسته از تصمیم گیران و مدیران فناوری اطلاعات که هنوز در انتخاب این سبک از معماری کمترین تردیدی دارند این مطلب را نوشته ام: برای ارزیابی محبوبیت و بی رقیب بودن معماری سرویس گرا به سراغ موتور جستجویGoogle بروید و چندین واژه رایج و پرکاربرد در حوزه تحلیل و طراحی سیستم ها را انتخاب کنید. برای مثال: UML: زبان مرسوم و بی رقیب مدلسازی RUP: متد معروف تحلیل و طراحی نرم افزار BPM: رهیافت مدیریت فرایندهای کسب و کار OOP: رهیافت بی رقیب برنامه نویسی شیء گرا این واژه گان را در گوگل جستجو کنید و تعداد نتایج یافته شده را یاداشت نمائید، سپس همین کار را برای واژه SOA نیز انجام دهید. بصورت پیش فرض برداشت شما این خواهد بود که نتایج یافته شده برای واژه های قدیمی و معرفی چون UML, RUP, OOP باید به مراتب بیشتر از واژهSOA (با توجه به جدید بودن آن) باشد. خوب حال با این پیش فرض ذهنی نتایج جستجو را در جدول زیر ببینید! یافته ها در Google (میلیون)عبارت جستجو5RUP20UML21BPM14OOP34SOA جدول 1 – مقایسه ی یافته ها بله خیلی جالب است! تعداد مقالات و صفحاتی که طی 5 الی 6 سال اخیر در زمینه معماری سرویس گرا ایجاد و در وب قرار داده شده از تعداد مطالبی که در طول بیش از دو دهه در خصوص رهیافتهای مشابه تهیه شده بوده، بیشتر است!! اگر هنوز به اندازه سر سوزنی در ایمانتان به معماری سرویس گرا شبه وجود دارد و شک کرده اید که شاید SOA بخاطر معادل بودن با مخفف دیگر کلمات به این نتایج رسیده است، یکبار دیگر جستجو را با واژگان کامل تکرار کنید: یافته ها در Google (میلیون)عبارت جستجو0.4“Rational Unified Process"1"Unified Modeling Language"5"Business Process Management"4"Object oriented Programming"6.5"Service Oriented Architecture" جدول 2 – مقایسه ی مجدد همانطور که مشاهد می شود، با جستجوی عبارات کامل داخل گیومه تعداد یافته ها برای واژگان کاهش پیدا کرد ولی باز هم معماری سرویس گرا بیشترین آمار را دارد! قصد نوشتن این پست مقایسه بین این مفاهیم نبوده و این مفاهیم اصلا در یک سطح نیستند. همچنین قصد نداشتم مشخصات و مزایای معماری سرویس گرا را بیان کنم ( هدف این بخش نشان دادن سرعت رشد و همه گیر شدن معماری سرویس گرا بوده و برای اینکه این سرعت نشان داده شود از چند مفهوم پرکاربرد و رایج(ونه الزاماً یکسان) برای مقایسه استفاده شده است. نتیجه گیری توسعه‌دهندگان برنامه‌هاي كاربردي يا گردآورندگان سيستم‌ها مي‌توانند با ساختن يك يا چند سرويس بدون آگاهي از پياده‌سازي‌هاي زيرين سرويس‌ها اقدام به ايجاد برنامه‌هاي كاربردي نمايند. براي مثال، يك سرويس مي‌تواند در .Net يا J2EE پياده‌سازي گردد، و برنامه كاربردي استفاده كننده از سرويس مي‌تواند بر روي يك پلت‌فرم يا زبان متفاوت قرار داشته باشد. معماري سرويس گرا از جنبه اي ديگر نيز به نحوه بارزي در برنامه هاي كاربردي E-Commerce مشهود است. اگر مثلا جزء (componet) مربوط به پرداخت با كارت اعتباري offline و يا غير فعال باشد،‌ قرار نيست كه فرايند فروش متوقف شود. بلكه سفارش ها بايستي پذيرفته شوند وعمليات پرداخت به وقت ديگري موكول شود. با ایجاد قابلیت توزیع شدگی به شكلی مناسب و بدون وابستگی زیاد، می توان سرویس ها را در قسمت های مختلف شبکه و بصورت بعضاً تکراری (مخصوصاً برای سرویس های مهم) قرار داد تا این سرویس ها همیشه در دسترس بوده و در صورت زیاد شدن درخواست ها بتوان با استفاده از تکنیک های Load Balancing به تمامی آنها به ‌خوبی پاسخ داد. براي اجرا و مديريت برنامه‌هاي كاربرديSOA، سازمان‌ها نيازمند يك زيربناي SOA هستند كه بخشي از پلت‌فرم SOA محسوب مي‌گردد. يك زيربناي SOA بايد تمامي استانداردهاي مرتبط و ظرف‌هاي (container) مورد نياز زمان اجرا را پشتيباني كند. سرويس‌هاي وب راجع به مشخصه‌هاي تكنولوژي هستند، در حالي كه SOA يك قاعده‌ي طراحي نرم‌افزار است. در حالي كه مفهوم SOA اساسا جديد نيست، SOA با تكنولوژي‌هاي توزيع‌شده موجود متفاوت است به گونه‌اي كه اغلب فروشندگان آن را پذيرفته و داراي يك مجموعه پلت‌فرم يا برنامه كاربردي هستند كه داراي قابليت SOA مي‌باشند. SOA با يك مجموعه از استانداردهايي كه همه جا در دسترس هستند، قابليت استفاده مجدد از سرمايه‌ها و دارايي‌هاي موجود در سازمان را بهبود مي‌بخشد و به شما امكان ايجاد برنامه‌هاي كاربردي كه مي‌توانند بر فراز برنامه‌هاي كاربردي موجود و جديد ساخته شوند، مي‌دهد. نهايتا، SOA انعطاف‌پذيري بيشتري را براي سازمان‌ها در ساختن برنامه‌هاي كاربردي و فرايندهاي تجاري به شيوه‌اي سريع‌تر با بهره‌گيري از زيربناي برنامه‌ي كاربردي موجود به منظور توليد سرويس‌هاي جديد فراهم مي‌نمايد.