مقاله در مورد معماري سرويس گرا

 nx دارای 29 صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است فایل ورد nx  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد. این پروژه توسط مرکز nx2 آماده و تنظیم شده است توجه : در صورت  مشاهده  بهم ريختگي احتمالي در متون زير ،دليل ان کپي کردن اين مطالب از داخل فایل ورد مي باشد و در فايل اصلي nx،به هيچ وجه بهم ريختگي وجود ندارد بخشی از متن nx : معماری سرویس گرا معماری سرویس گرا به عنوان یكی از آخرین دستاوردها در تولید نرم افزار، به نظر می رسد، در سالهای آتی معماری غالب صنعت فناوری اطلاعات و ارتباطات باشد. علت بوجود آمدن این معماری، ایده ای بود كه در ذهن تعدادی از معماران آن وجود داشت و آن نرم افزار به عنوان سرویس بود. در مدل نرم افزار به عنوان سرویس، شما نرم افزار خود را بگونه ای طراحی می كنید كه قابل استفاده توسط سیستم های دیگر باشد یعنی دیگران می توانند برای استفاده از سرویس شما ثبت نام كنند و هر موقع كه لازم داشتند از خدمات آن بهره ببرند، همانند حالتی كه در مورد شبكه های تلویزیون كابلی وجود دارد. تا زمانی كه شما به سرویس متصل هستید، می توانید هر لحظه كه خواستید از سرویس استفاده كنید. واژه های کلیدی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، تدابیری جهت هماهنگی با معماری سرویس گرا در نظر گرفته شده است. از نمونه های استفاده از این معماری در كشور خودمان، سازمان ثبت احوال كشور است كه موظف شده تا پایگاه های اطلاعاتی خود را بصورت سرویس وب و مبتنی بر این معماری به سایر نهادها مانند نیروی انتظامی و سایر دستگاه ها ارائه دهد. سرویس ها چه هستند؟ بسیاری از ما آنقدر با تكنولوژی های سرویس های وب آشنا هستیم كه اغلب درباره این كه خود سرویس ها واقعا چه هستند، فكر نمی كنیم. هر كس كه از سایت های تجارت الكترونیكی به صورت آنلاین خرید كرده باشد، با مفهوم سرویس ها آشنا است. وقتی كه سفارش تا ن را دادید، باید اطلاعات كارت اعتباری تان را ارایه كنید كه به طور معمول توسط یك فراهم كننده سرویس ثانویه، تایید و شارژ می شود. وقتی كه سفارش پذیرفته شد، شركت سفارش گیرنده با یك شركت فراهم كننده سرویس حمل ونقل سرویستان را فراهم می كند و در نهایت كالای شما تحویلتان می شود.در ادامه سه تعریف می آوریم كه در كنار یكدیگر ماهیت یك سرویس راشرح می دهند: 1- سرویس ها اجزاء مستقلی هستند كه پیغام های XML با ساختار مشخص و خوش تعریف را پردازش می‏كنند.• XML ساده ترین ورژن SGML استاندارد برای ایجاد و طراحی سند های HTML است(مناسب برای استفاده در سایت های اینتر نتی).• SGML یك استاندارد مدیریت اطلاعات است كه در سال 1986 به وسیله سازمان بین المللى استاندارد سازى (ISO) معرفى گردید و وسیله اى است براى ارائه اسناد مستقل از یك سیستم یا برنامه كاربردى خاص ضمن به كارگیرى اطلاعاتى چون قالب بندى، شاخص دهى و حفظ اطلاعات پیوندى در اسناد. 2- سرویس ها دارای رابط های خوش تعریف هستند كه به وسیله یك سند مبتنی بر XML كه سند WSDLخوانده می شود، به این سند گاهی قرارداد WSDL نیز گفته می شود، پردازش می شوند. محتویات این سند،‌ عملیاتی (متدهایی) كه توسط سرویس ارائه می شود را شرح می دهد. از جمله اطلاعات مربوط به انواع داده، اطلاعات نحوه اتصال به سرویس، جهت یافتن و ارتباط با عملیات سرویس وب.3- سرویس ها دارای نقاط انتهایی (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 بهتر دست می‌یابید همچنان كه فروشندگان بیشتر و بیشتری مشخصه‌های بیشتر و بیشتری از سرویس‌های وب را پشتیبانی می‌نمایند. معرفی 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)پیغام رسانی مطمئن سرویس وب: مكانیسم هایی برای تضمین اطمینان از رسیدن پیغام، حتی در صورتی كه یك یا چند سرویس در زنجیره سرویس ها قابل دسترس نباشند، را فراهم می سازد. این مشخصه شامل روش هایی برای اعلام رسیدن پیغام است، به طوری كه فرستنده بتواند بفهمد كه آیا گیرنده در دریافت پیغام موفق بوده است یا نه .با معرفی و ثبت مشخصه های جدید و بهبود مشخصه های قبلی، مشخصه های سرویس های وب دائما ًدر حال تكامل هستند. البته، مجموعه مشخصه های پایه ای كه در این مقاله بیان شد، احتمالاً برای مدتی به عنوان زیر بنای اصلی مشخصه های سرویس های وب باقی خواهند ماند،‌ چرا كه این مشخصه ها نیازهای اصلی و بنیادی برنامه های كاربردی سرویس گرا را پوشش می دهند. 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 درسازمانها می توان فرآیند درخواست جنس از یک مجتمع تولیدی را توسط مشتری در نظر بگیریم می توان سناریوئی چید تا درخواست مشتری بررسی, درصورت عدم وجود جنس درخواست مواداولیه ازانبار و درنهایت تامین خواسته مشتری با صدور یک سند در حسابداری پایان یابد که هرکدام ازاین گام های سناریو می توانند در سیستم گردش کاری یا در پشت صحنه توسط نرم افزار هدایت شده ودرنهایت با فراخوانی سرویسهای مختلف از سیتم های مختلف و اثر گذاری هریک این سناریو اجرا شود. ادامه خواندن مقاله در مورد معماري سرويس گرا

نوشته مقاله در مورد معماري سرويس گرا اولین بار در دانلود رایگان پدیدار شد.