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

معماری سرویس‌گرا (SOA) شکل تکامل یافته محاسبه‌گری توزیع شده مبتنی بر فرضیه طراحی تقاضا/پاسخ برای برنامه‌های کاربردی همگام و ناهمگام است. منطق تجاری یا توابع اختصاصی یک برنامه کاربردی به صورت ماژولار در آمده‌اند و به عنوان سرویس‌هایی برای برنامه‌های کاربردی مصرف‌کننده/کلاینت ارائه گردیده‌اند. مهم‌ترین نکته‌ در مورد این سرویس‌ها طبیعت اتصال آزادانه آنهاست؛ بدین معنی که رابط سرویس، مستقل از پیاده‌سازی است. توسعه‌دهندگان برنامه‌های کاربردی یا گردآورندگان سیستم‌ها می‌توانند با ساختن یک یا چند سرویس بدون آگاهی از پیاده‌سازی‌های زیرین سرویس‌ها اقدام به ایجاد برنامه‌های کاربردی نمایند. برای مثال، یک سرویس می‌تواند در .Net یا J۲EE پیاده‌سازی گردد، و برنامه کاربردی استفاده کننده از سرویس می‌تواند بر روی یک پلات‌فرم یا زبان متفاوت قرار داشته باشد.
▪ معماری‌های سرویس‌گرا دارای خصوصیات اصلی زیر هستند:
- سرویس‌های SOA دارای رابط‌های خود-توصیف‌گر در اسناد XML مستقل از پلاتفرم هستند. زبان توصیف سرویس‌های وب (WSDL) استاندارد به کار برده شده برای توصیف این سرویس‌ها می‌باشد.
- سرویس‌های SOA با پیام‌هایی که رسما توسط شمای XML (که XSD نیز نامیده می‌شود) تعریف شده‌اند ارتباط برقرار می‌نمایند. ارتباط میان مصرف‌کنندگان و فراهم‌کنندگان یا سرویس‌ها معمولا در محیط‌های ناهمگن رخ می‌دهد، با دانش کم یا بدون هیچ دانشی در مورد فراهم‌کننده. پیام‌های مبادله شده میان سرویس‌ها را می‌توان به عنوان اسناد تجاری مهم پردازش شده در یک سازمان نگریست.
- سرویس‌های SOA توسط یک رجیستری که به عنوان یک فهرست دایرکتوری عمل می‌کند نگهداری می‌گردند. برنامه‌های کاربردی می‌توانند سرویس‌ها را درون رجیستری جستجو نمایند و سرویس را فراخوانی کنند. توصیف، تعریف، و یکپارچگی جهانی (UDDI) استانداردی است که برای رجیستری سرویس مورد استفاده قرار گرفته است.
هر سرویس SOA دارای یک کیفیت سرویس (QoS) مرتبط با خود است. برخی از عناصر اساسی QoS شامل نیازمندی‌های امنیتی، از قبیل احراز هویت و صدور مجوز، پیام‌رسانی قابل اطمینان، و خط‌مشی‌هایی در این زمینه که چه افرادی می‌توانند سرویس‌ها را فراخوانی نمایند، می‌باشد.
● چرا SOA؟
واقعیت موجود در سازمان‌های IT این است که زیربنا در میان سیستم‌های عامل، برنامه‌های کاربردی، نرم‌افزارهای سیستمی، و زیربنای کاربردی به صورت ناهمگن است. برخی برنامه‌های کاربردی موجود برای اجرای فرایندهای فعلی تجارت مورد استفاده قرار گرفته‌اند، بنابراین آغاز از صفر برای ساختن زیربنای جدید یک رویکرد قابل انتخاب محسوب نمی‌گردد. سازمان‌ها باید به شکلی سریع به تغییرات تجاری واکنش نشان دهند؛ از سرمایه‌های موجود در برنامه‌های کاربردی و زیربنای کاربردی به منظور تمرکز بر روی نیازمندی‌های تجاری جدیدتر استفاده نمایند؛ کانال‌های جدید تعامل با مشتریان، شرکا، و تامین‌کنندگان را پشتیبانی کنند؛ و یک معماری که تجارت ارگانیک را پشتیبانی نماید به کار گیرند. SOA با طبیعت اتصال آزادانه خود به سازمان‌ها امکان بهره‌گیری از سرویس‌های جدید یا ارتقای سرویس‌های موجود را به شیوه‌ای قطعه‌ قطعه به منظور تمرکز بر نیازمندی‌های تجاری فراهم می‌آورد، امکانی را برای قابل استفاده نمودن سرویس‌ها در کانال‌های متفاوت فراهم می‌سازد، و سازمان موجود و برنامه‌های کاربردی نسل قبل را به عنوان سرویس‌ها ارائه می‌کند، در نتیجه سرمایه‌های زیربنای IT موجود را حراست می‌نماید.
یک سازمان استفاده کننده از SOA می‌تواند یک برنامه کاربردی مرکب زنجیره تامین را با استفاده از مجموعه‌ای از برنامه‌های کاربردی موجود که کارکرد خود را از طریق رابط‌های استاندارد ارائه می‌دهند، ایجاد نماید.
● معماری سرویس
چندین مصرف‌کننده سرویس می‌توانند با ارسال پیام اقدام به فراخوانی سرویس‌ها نمایند. این پیام‌ها معمولا توسط یک گذرگاه سرویس تغییر شکل داده شده و به سوی یک پیاده‌سازی سرویس مناسب هدایت می‌گردند. این معماری سرویس می‌تواند یک موتور قواعد تجاری را فراهم سازد که امکان تلفیق قواعد تجاری در یک سرویس یا چندین سرویس را عملی سازد. معماری سرویس مزبور همچنین یک زیربنای مدیریت سرویس فراهم می‌آورد که سرویس‌ها و اعمالی از قبیل بازرسی، پرداخت صورتحساب، و واقعه‌نگاری (logging) را مدیریت می‌نماید. به علاوه، این معماری انعطاف‌پذیری ناشی از دارا بودن فرایندهای تجاری تغییر پذیر را به سازمان‌ها ارزانی می‌دارد، فرایندهایی که نیازمندی‌های تنظیمی همانند Sarbanes Oxley (SOX)i را مد نظر قرار می‌دهند، و سرویس‌های اختصاصی را بدون تحت تاثیر قرار دادن سایر سرویس‌ها تغییر می‌دهند.
● زیربنای SOA
برای اجرا و مدیریت برنامه‌های کاربردی SOA، سازمان‌ها نیازمند یک زیربنای SOA هستند که بخشی از پلات‌فرم SOA محسوب می‌گردد. یک زیربنای SOA باید تمامی استانداردهای مرتبط و ظرف‌های (container) مورد نیاز زمان اجرا را پشتیبانی کند. یک زیربنای SOA معمولی چیزی شبیه شکل ۳ است. بخش‌هایی که در ادامه این مقاله مشاهده می‌نمایید قطعات اختصاصی این زیربنا را مورد بحث قرار می‌دهند.
● SOAP, WSDL, UDDI
WSDL، UDDI، و SOAP قطعات اساسی زیربنای SOA هستند. WSDL برای توصیف سرویس به کار برده شده است؛ UDDI، برای ثبت و جستجوی سرویس‌ها؛ و SOAP، به عنوان یک لایه نقل و انتقال جهت ارسال پیام‌ها میان مصرف‌کننده سرویس و فراهم‌کننده سرویس. در حالی که SOAP ساز و کار پیش‌فرض برای سرویس‌های وب است، تکنولوژی‌های جایگزین، انواع دیگری از انقیادها (binding) را برای یک سرویس تحقق می‌بخشند. یک مصرف‌کننده می‌تواند به جستجوی یک سرویس در رجیستری UDDI بپردازد، WSDL را برای سرویسی که دارای توصیف است تهیه نماید، و سرویس را از طریق SOAP فراخوانی کند.
● WS-I Basic Profile
WS-I Basic Profile، که از سوی Web services Interoperability Organization فراهم شده است، یکی دیگر از قطعات اساسی مورد نیاز برای تست و interoperability (قابلیت کار با سایر اجزای سیستم) سرویس است. فراهم‌کنندگان سرویس می‌توانند از مجموعه‌های تست Basic Profile برای تست نمودن interoperability سرویس در میان پلات‌فرم‌ها و تکنولوژی‌های متفاوت استفاده کنند.
● J۲EE و .Net
اگر چه پلات‌فرم‌های J۲EE و .Net برای برنامه‌های کاربردی SOA پلاتفرم‌های توسعه غالب به شمار می‌روند، اما SOA به هیچ عنوان به این پلات‌فرم‌ها محدود نیست. پلات‌فرم‌هایی از قبیل J۲EE نه تنها یک framework را برای توسعه‌دهندگان جهت سهیم شدن در SOA فراهم می‌آورند، بلکه با طبیعت ذاتی خود، یک زیربنای کامل و مورد تایید از لحاظ بسط‌پذیری، قابلیت اطمینان، دسترس‌پذیری، و کارآیی را برای دنیای SOA به ارمغان می‌آورند. مشخصه‌های جدیدی از قبیل JAXB (Java API for XML Binding)، که کاربرد آن در نگاشت اسناد XML به کلاس‌های جاوا است، JAXR (Java API for XML Registry)، که کاربرد آن در تعامل با رجیستری‌های UDDI به یک شیوه استاندارد است، و XML-RPC (Java API for XML-based Remote Procedure Call)، که کاربرد آن در فراخوانی سرویس‌های راه دور در J۲EE ۱.۴ است توسعه و گسترش سرویس‌های وبی که در میان ظرف‌های استاندارد J۲EE قابل انتقال هستند را تسهیل می‌نمایند، ضمن این که به شکل همزمان به کار با سرویس‌های موجود در پلات‌فرم‌های دیگری از قبیل .Net می‌پردازند.
● کیفیت سرویس‌ها
سیستم‌های حیاتی موجود در سازمان‌ها نیازمندی‌های پیشرفته‌ای از قبیل امنیت، قابلیت اطمینان، و تراکنش‌ها را مد نظر قرار می‌دهند. همچنان که سازمان‌ها شروع به پذیرش معماری سرویس به عنوان ابزاری برای توسعه و گسترش برنامه‌های کاربردی می‌نمایند، مشخصه‌های بنیادین وب از قبیل WSDL، SOAP، و UDDI قادر به برآورده ساختن این نیازمندی‌های پیشرفته نیستند. همچنان که قبلا گفته شد، این نیازمندی‌ها، همچنین تحت عنوان کیفیت سرویس‌ها شناخته می‌شوند. تعداد بیشماری از مشخصه‌های مرتبط با QoS در هیئت‌های برخی استانداردها همچون W۳C (World Wide Web Consortium) و OASIS (Organization for the Advancement of Structured Information Standards) مطرح گردیده‌اند. بخش‌هایی که در ادامه آمده است برخی از اثرات QoS و استانداردهای مرتبط را مورد بحث قرار داده‌اند.
● امنیت
مشخصه Web Services Security امنیت پیام را مد نظر دارد. این مشخصه بر روی تبادل اعتبارنامه، یکپارچگی پیام، و محرمانگی پیام متمرکز گردیده است. نکته جذاب در مورد این مشخصه این است که آن از استانداردهای امنیتی موجود، از قبیل SAML (Security Assertion Markup Language)، بهره می‌گیرد و امکان استفاده از این استانداردها را به منظور ایمن‌سازی پیام‌های سرویس‌های وب فراهم می‌سازد. Web Services Security یک تلاش مداوم و در حال رشد از سوی OASIS است.
● قابلیت اطمینان
در یک محیط SOA معمولی، اسناد متعددی میان استفاده‌کنندگان از سرویس و فراهم‌کنندگان سرویس مبادله می‌گردد. تحویل پیام‌ها با خصوصیاتی همچون تحویل یکباره و فقط یکباره، تحویل حداکثر یکباره، حذف دوباره‌ای پیام، تحویل تضمین شده پیام، و تصدیق در سیستم‌های حیاتی که از معماری سرویس استفاده می‌کنند از اهمیت بالایی برخوردار می‌گردد. WS-Reliability و WS-ReliableMessaging دو استانداردی هستند که مسائل مربوط به پیام‌رسانی قابل اطمینان را مد نظر قرار می‌دهند. هر دوی این استانداردها اکنون بخشی از OASIS می‌باشند.
● خط‌مشی
فراهم‌کنندگان سرویس در برخی موارد استفاده‌کنندگان از سرویس را ملزم به مراوده با خط‌مشی‌های معین می‌نمایند. به عنوان یک مثال، یک فراهم‌کننده سرویس ممکن است یک نشانه امنیتی Kerberos را برای دستیابی به سرویس الزامی نماید. این استلزام‌ها به عنوان اظهارنامه‌های خط‌مشی تعریف گردیده‌اند. یک خط‌مشی ممکن است شامل چندین اظهارنامه باشد. WS-Policy نحوه مورد مراوده قرار گرفتن خط‌مشی‌ها میان استفاده‌کنندگان از سرویس و فراهم‌کنندگان سرویس را به شکل استاندارد در می‌آورند.
● هماهنگ‌سازی
همچنان که سازمان‌ها به معماری سرویس روی می‌آورند، سرویس‌ها می‌توانند برای یکپارچه‌سازی مخازن داده، برنامه‌های کاربردی، و کامپوننت‌ها مورد استفاده قرار گیرند. یکپارچه‌سازی برنامه‌های کاربردی بدان معنی است که نیازمندی‌های پردازش، از قبیل ارتباط ناهمگام، پردازش موازی، تبدیل داده‌ها، و تصحیح، باید استانداردسازی گردند. BPEL۴WS یا WSBPEL (Web Services Business Process Execution Language) یک مشخصه OASIS است که هماهنگ‌سازی سرویس را مد نظر دارد، جایی که فرایندهای تجاری با استفاده از مجموعه‌ای از سرویس‌های گسسته ایجاد گردیده‌ باشند. WSBPEL اکنون بخشی از OASIS می‌باشد.
● مدیریت
همچنان که تعداد سرویس‌ها و فرایندهای تجاری ارائه شده به عنوان سرویس در سازمان افزایش می‌یابد، یک زیربنای مدیریت که امکان مدیریت سرویس‌های در حال اجرا در یک محیط ناهمگن را به مدیران سیستم می‌دهد از اهمیت بالایی برخوردار می‌گردد. WSDM (Web Services for Distributed Management) بیانگر آن خواهد بود که هر سرویس پیاده‌سازی شده بر اساس WSDM توسط یک راهکار مدیریت سازگار با WSDM قابل مدیریت خواهد بود. سایر صفت‌های QoS از قبیل هماهنگی میان شرکا و تراکنش‌ها که در بر دارنده چندین سرویس هستند به ترتیب در مشخصه‌های WS-Coordination و WS-Transaction (که باز هم جزو تلاش‌های OASIS محسوب می‌گردند) مد نظر قرار گرفته‌اند.
● SOA سرویس‌ وب نیست
آن گونه که به نظر می‌رسد در مورد ارتباط میان SOA و سرویس‌های وب نوعی سردرگمی عمومی وجود دارد. در یکی از گزارش‌های Gartner مورخ آوریل ۲۰۰۳، Yefim V. Natis این گونه تقاوت میان آنها را شرح می‌دهد: ”سرویس‌های وب راجع به مشخصه‌های تکنولوژی هستند، در حالی که SOA یک قاعده‌ی طراحی نرم‌افزار است. شایان ذکر است که WSDL سرویس‌های وب یک استاندارد تعریف رابط مناسب SOA است: این نقطه‌ای است که سرویس‌های وب و SOA اساسا به یکدیگر پیوند می‌خورند.“ اساسا، SOA یک الگوی معماری است، در حالی که سرویس‌های وب سرویس‌های پیاده‌سازی شده توسط مجموعه‌ای از استانداردها می‌باشند؛ سرویس‌های وب یکی از روش‌هایی است که شما با استفاده از آن می‌توانید SOA را پیاده‌سازی نمایید. مزیت پیاده‌سازی SOA با سرویس‌های وب این است که شما به یک رویکرد بی‌طرفانه نسبت به پلات‌فرم به منظور دستیابی به سرویس‌ها و interoperability بهتر دست می‌یابید همچنان که فروشندگان بیشتر و بیشتری مشخصه‌های بیشتر و بیشتری از سرویس‌های وب را پشتیبانی می‌نمایند.
● مزایای SOA
در حالی که مفهوم SOA اساسا جدید نیست، SOA با تکنولوژی‌های توزیع‌شده موجود متفاوت است به گونه‌ای که اغلب فروشندگان آن را پذیرفته و دارای یک مجموعه پلات‌فرم یا برنامه کاربردی هستند که دارای قابلیت SOA می‌باشند. SOA، با یک مجموعه از استانداردهایی که همه جا در دسترس هستند، قابلیت استفاده مجدد از سرمایه‌ها و دارایی‌های موجود در سازمان را بهبود می‌بخشد و به شما امکان ایجاد برنامه‌های کاربردی که می‌توانند بر فراز برنامه‌های کاربردی موجود و جدید ساخته شوند، می‌دهد. SOA امکان ایجاد تغییر در برنامه‌های کاربردی در شرایطی که کلاینت‌ها یا استفاده‌کنندگان از سرویس جدای از تغییرات صورت گرفته در پیاده‌سازی سرویس حفظ شوند، فراهم می‌آورد. SOA امکان ارتقای استفاده‌کنندگان از سرویس یا سرویس‌های اختصاصی را فراهم می‌سازد؛ بازنویسی کامل یک برنامه کاربردی یا حفظ یک سیستم موجود که دیگر نیازمندی‌های جدید تجاری را مد نظر قرار نمی‌دهد لازم نیست.نهایتا، SOA انعطاف‌پذیری بیشتری را برای سازمان‌ها در ساختن برنامه‌های کاربردی و فرایندهای تجاری به شیوه‌ای سریع‌تر با بهره‌گیری از زیربنای برنامه‌ی کاربردی موجود به منظور تولید سرویس‌های جدید فراهم می‌نماید.

نویسنده: Raghu R. Kodali
مترجم: امین ایزدپناه

منبع : علم الکترونیک و کامپیوتر