فدراسیون نرم افزارها

نرم افزارهای تعامل ناپذیر

مستقل از سکو

تک سکو

اتصال سست

اتصال محکم

پیام محور

مولفه محور

د- پروتکل ها، استانداردها، وب سرویس ها، هم نواسازی و هم خوانی در معماری سرویس گرا
کم کردن مشکلات، همگن سازی، برقراری ارتباط بین سیستم های متفاوت و تغییرات نیازهای روزمره، نیازمند به یک معماری برای برنامه های کاربردی سرویس دهنده است که مشخصات اتصال سست^[۳۱]، ارتباطات شفاف^[۳۲] و وابسته به پرتکل های ارتباطی استاندارد^[۳۳] باشد.
(( اینجا فقط تکه ای از متن درج شده است. برای خرید متن کامل فایل پایان نامه با فرمت ورد می توانید به سایت nefo.ir مراجعه نمایید و کلمه کلیدی مورد نظرتان را جستجو نمایید. ))

زبان ها و تکنولوژی های شی گرا روشی قوی برای پیاده سازی اشیا بوده اند. یک مزیت فوق العاده ای که در توسعه مبتنی بر شی وجود داشت، بکارگیری مجدد اشیای موجود درلایه های متفاوت می باشد. برای تحقق یافتن راه حل سرویس گرا نیاز به یک لایه معماری نرم افزار دارد تا بتوان، به کار گیری مجدد سرویس ها را فراهم کرد.
پروتکل ها، استانداردها و وب سرویس ها:
وب سرویس ها یک تکنولوژی نسبتا جدید می باشند، از آنجا که وب سرویس ها یک مشی محاسباتی توزیع شده ^[۳۴] را برای فراهم کردن یکپارچگی برنامه های بشدت ناهمگن^[۳۵] بر روی بستر اینترنت فراهم می کنند، قابلیت پیاده سازی ویژگی های معماری سرویس گرا را دارا هستند. مشخصات وب سرویس ها کاملا متمایز و مستقل از زبان های برنامه نویسی، سیستم های عامل و سخت افزار ها بوده، و قابلیت اتصال سست را بین بکار گیرنده و ارائه دهنده آن فراهم می کنند. این تکنولوژی بر پایه تکنولوژی ها و استانداردهای باز ^{[۳۶] [۳۷]}XML، ^[۳۸]SOAP، ^[۳۹]UDDI، ^[۴۰]WSDL، BPEL^[41] و … می باشد
همانگونه که در شکل زیر نشان داده شده، استفاده از استاندارد های باز، همکاری^[۴۲] وسیعی را در میان محصولات و راه حل های شرکت های مختلف فراهم می آورد. این اصول بدین معناست که شرکت ها می توانند وب سرویس های خود را بدون نیاز به دانشی نسبت به وضعیت مشتری و برعکس آن پیاده سازی نمایند. این تسهیلات یکپارچگی را بدون نیاز به صرف زمانی خاص فراهم می کنند و به سازمان ها این امکان را می دهد، تا شرکت پذیری های جدیدی را به سادگی و به صورت پویا بنا نهند.
Web Services
SOA
شکل ۲-۱۰: ارتباط معماری سرویس گرا با وب سرویس ها
در این سبک(مدل) برنامه نویسی از استانداردهائی مانند SOAP)، UDDI،WSDL ، … ) و فناوری هائی نظیر سرویس های وب استفاده می کند و قابلیت تعامل پذیری بین مولفه های نرم افزاری را بدون توجه به سکو و فناوری پیاده سازی آنها پشتیبانی می کند. در زیر توضیح مختصری در مورد هر کدام از این استانداردها داده می شود:
XML که به شکل گسترده از آن پشتیبانی می شود، یک تکنولوژی باز بوده و به شرکت خاصی تعلق ندارد. اولین بار در کنسرسیوم W3C در سال ۱۹۹۶ به علت محدودیت های HTML(ضعف در توسعه پذیری همچون قابلیت اضافه و کم کردن خواص و ضعف توصیف داده های نگهداری شده در درون خود) برای ساده کردن انتقال داده ها ایجاد شد.
استقلال اطلاعات، یک مشخصه برای XML به حساب می آید. محتوای XML فقط یک داده را توصیف می کند و برنامه ای که XML برای آن قابل درک است، بدون توجه به زبان و سیستم عامل، قادر است به اطلاعات درون فایل XML ، هر گونه قالبی که مایل است بدهد. محتوای XML حاوی داده به شکل خاص است.
تمامی برنامه هایی که از XML استفاده می کنند قادر خواهند بود که XML ِ همدیگر را بفهمند. این سطح بالای تطابق بین برنامه ها باعث می شود که XML یک تکنولوژی مناسب برای وب سرویس باشد، چون بدون اینکه احتیاج به سیستم عامل و سخت افزار یکسان باشد می تواند اطلاعات را جابجا کند.
SOAP ساختاری برای تبادل پیام های در قالب XMLاست که بین سرویس های وب مبادله می شود و می تواند توسط پروتکل های انتقالی گوناگونی مانند HTTP، SMTP وFTP استفاده شود.
یک پیغام SOAP از سه بخش مهم پوشش^[۴۳]، سر پیام^[۴۴]، بدنه^[۴۵] تشکیل شده است. قسمت پوشش برای بسته بندی کردن کل پیغام به کار می رود . این بخش محتوای پیغام را توصیف و چگونگی پردازش پیغام آن را مشخص می کند. بخش بعدی سر پیام آن است که یک بخش اختیاری بوده و مطالبی مانند امنیت و مسیریابی را توضیح می دهد. بدنه پیغام SOAP بخشی است که دیتاهای مورد نظر در آن جای می گیرند. دیتاها بر مبنای XML هستند و از یک مدل خاص تبعیت می کنند. این الگو ها به گیرنده کمک می کنند تا متن را به درستی تفسیر کند. پیغام های SOAP توسط سرورها گرفته و تفسیر می شود تا در نتیجه آن، وب سرویس ها فعال شوند و کار خود را انجام دهند.
به وسیله قابلیت ضمیمه^[۴۶] SOAP می توان داده های non-XML را نظیر فایل های چند رسانه ای و .. به یک پیغام SOAP الصاق کرد.
WSDL شمای توافق شده ای است برای شرح اینکه، سرویس چه هست؟ چطور فراخوانی می شود؟ و چه داده هایی را سرویس برای اجرای درست آن نیاز دارد؟ یکی از خواص وب سرویس ها توصیف خود آنهاست به این معنی که وب سرویس دارای اطلاعاتی است که نحوه استفاده از آن را توضیح می دهد. این توضیحات در WSDL نوشته می شود، متنی مبتنی بر XML که به برنامه ها می گوید این وب سرویس چه اطلاعاتی لازم دارد و چه اطلاعاتی را بر می گرداند .
هر وب سرویسی که بر روی اینترنت قرار می گیرد دارای یک فایل WSDL است که مشخصات، مکان و نحوه استفاده از وب سرویس را توضیح می دهد. یک فایل WSDL نوع پیغام هایی که وب سرویس می فرستد و می گیرد را توضیح می دهد مانند پارامترهایی که برنامه صدا زننده برای کار با وب سرویس باید به آن بفرستد. در تئوری یک برنامه در وب برای یافتن وب سرویس مورد نظر خود از روی توضیحات WSDL ها جستجو می کند.
UDDI واسطی است برای انتشار و شناسایی سرویس های وب و شامل یک مخزن می شود که ارائه دهندگان به انتشار و تبلیغ سرویس خود می پردازند تا دیگران بتوانند آن را شناسایی کنند. از نظر مفهومی مخزن شامل صفحات سفید(اطلاعات سرویس ها)، صفحات زرد( دسته بندی صنعتی) و صفحات قرمز( اطلاعات فنی) خواهد بود.
BPELزبان اجرای فرایندهای کسب و کار گفته می شود. این زبان استاندارد مستقل از سکو و مبتنی بر XML و توصیف کننده فرایندهای کسب و کار به کمک سرویس ها می باشد.
معماری سرویس گرا سبکی از معماری است که از اتصال سست سرویس ها جهت انعطاف پذیری و تعامل پذیری با حرفه به وجود می آید. این نوع معماری از ترکیب مجموعه ای از سرویس های مبتنی بر حرفه تشکیل می شود. این سرویس ها انعطاف پذیری و پیکربندی پویا را برای فرآیندها محقق می کنند. از طرفی محصولات یا فرآیندهای جدید به سادگی توسط فناوری اطلاعات اجرا خواهند شد. سیستم های انعطاف پذیر دیگر مانعی بر سر تغییر و تکامل سریع فرآیندها نخواهند بود. در همین راستا دو واژه پر کاربرد در معماری سرویس گرا، هم نواسازی و هم خوانی بکار می رود.
هم نواسازی^[۴۷] و هم خوانی^[۴۸]: هم نواسازی در خصوص ترتیب اجرای سرویس ها در فرایند بحث می کند، ارکستر اصلی مجموعه ای از سرویس ها را فراخوانی می کند تا نتیجه مورد نظر حاصل شود و فرایند تکمیل گردد، ممکن است سرویس های خارج سازمان نیز در این راستا فراخوانی و استفاده شوند، این کار با کمک موتور فرایند محقق می شود. در عوض هم خوانی به فرآیندهایی گویند که بدون موتور فرآیندی(رهبر ارکستر) اقدام به تبادل پیام کرده و ترتیب و توالی پیامهای مبادلاتی را خود بازیگران ثبت و کنترل می کنند.
در واقع هم خوانی به معنای پردازش های توزیع شده بین چند فرایند است که بدون یک رهبر مرکزی با هم تعامل دارند یا چندین موتور فرآیندی که در کنار و هم سطح هم اجرا می شوند و با همکاری هم هدفی را محقق می سازند. نمونه این موضوع در پردازش های توزیع شده و یا فعالیت های بین سازمانی که هر دو طرف با مشارکت هم به دنبال یک هدف هستند دیده می شود.
هم نواسازی فرایند کسب و کار^[۴۹] در حقیقت مجموعه ای از ویژگی هایی است که امکان ترکیب، سازماندهی، اجرا و اداره فرایندهای مختلف کسب و کار را که به وسیله سرویس های متنوع در دسترس هستند به ما می دهد. یک فرایند از یک مجموعه سرویس هایی که با ارتباطی منطقی به یکدیگر متصل شده اند تشکیل شده است و هر سرویس یک واحد عملکرد می باشد. هم نواسازی این فرصت را به ما می دهد تا با مدل کردن تعاملات بین سرویس های قابل استفاده مجدد بتوانیم فرایندهای کسب و کاری خود را بسازیم]۱۱و۳۹و۴۰[.
شکل۲-۱۱: هماهنگ سازی فرایندهای کسب و کار
و- مدل های معماری سرویس گرا
با مطالعه مقالات، کتب و مطالب منتشره در اینترنت جستجو برای انواع مدل های معماری سرویس گرا صورت گرفت، در راستای پیاده سازی معماری سرویس گرا مدل های متفاوتی ارائه شده که تعدادی از این مدل ها فقط مدل مفهومی بوده، در اینجا سه نمونه مطرح مدل های سرویس گرا را شرح می دهیم:
مدل مرجع SOA
هدف مدل مرجع، تعریف ماهیت معماری سرویس گرا و درک و زبان مشترک از SOA می باشد که توسط انجمن ^[۵۰]OASIS تهیه گردیده است. مدل مرجع SOA بدون توجه به تحولات فناوری های مختلف و اجتناب ناپذیر موثر در SOA، یک مدل اصولی به عنوان مدل انتزاعی و قدرتمند ایجاد می کند.
شکل زیر نشان می دهد که یک مدل مرجع SOA چگونه با سایر سیستم های توزیع شده ارتباط برقرار می کند. مفاهیم و روابط تعریف شده توسط مدل مرجع به عنوان پایه ای برای توصیف مراجع معماری و الگوهای اصلی SOA در نظر گرفته شده است. معماری پایدار از ترکیبی از معماری های مرجع، الگوهای معماری، امکانات مورد نیاز، محیط های فن آوری موجود و جاری بوجود می آیند.
انتزاعی
مدل مرجع
دست آورد
کار معماری
معماری مرجع