معماری سرویس گرا (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

مترجم: امین ایزدپناه