معاری سرویس گرا (SOA) روشی جدید و در حال تکامل برای ساخت برنامه های توزیع شده با Distributed Applicationاست. سرویس ها اجزای توزیع شده با رابط های تعریف شده و مشخص هستند که پیغام های XMIL را پردازش وتبادل می کنند. با رویکرد سرویس گرا می توان راه حل های را ارائه داد که به مرز دامنه های سازمان، شرکت یا دپارتمان محدود نیستند. با استفاده از SOA می توان در شرکتی که دارای سیستم ها و برنامه های کاربردی مختلف روی پلتفرم های متفاوت است، یک راه حل یک پارچه سازی با استقلال زیاد(loosly coupled) ساخت که جریان یکنواخت و ناهماهنگ کار را تضمین کند.
هر کس که از سایت های تجارت الکترونیکی به صورت آنلاین خرید کرده باشد، با مفهوم سرویس ها آشنا است. وقتی که سفارش تا ن را دادید، باید اطلاعات کارت اعتباری تان را ارایه کنید که به طور معمول توسط یک فراهم کننده سرویس ثانویه، تایید و شارژ می شود. وقتی که سفارش پذیرفته شد، شرکت سفارش گیرنده با یک شرکت فراهم کننده سرویس حمل ونقل فراهم می کند و در نهایت کالای شما تحویلتان می شود. نیاز به معماری سرویس گرا از جنبه ای دیگر نیز به نحوه بارزی در برنامه های کاربردیeCommerce مشهود است. اگر مثلا جزء(componet) مربوط به پرداخت با کارت اعتباری offline و یا غیر فعال باشد،‌قرار نیست که فرایند فروش متوقف شود. بلکه سفارش ها بایستی پذیرفته شوند وعملیات پرداخت به وقت دیگری موکول شود.
مثل سایر معماری های توزیع شده،‌ SOA ساخت برنامه های کاربردی با استفاده اجزایی که در domainهای جدا از هم را قرار دارند را ممکن می سازد . SOA از سرویس های وب به عنوان نقاط ورود برنامه کاربردی استفاده می کند که از لحاظ مفهومی معادل همان اجزای proxy و stub در سیستم های توزیع شده سنتی مبتنی بر اجزاء هستند . با این تفاوت که در این جا ارتباط بین سرویس وب و استفاده کننده خیلی آزاداترانه ومستقل تر (loosely coupled) است .به علاوه SOA به خاطر در بر داشتن فاکتورهایی که اهمیت حیاتی در تجارت دارند ، نیز منحصر به فرد است . فاکتورهایی نظیر: قابلیت اطمینان سرویس،‌ جامعیت پیام ، یکسانی تراکنش و امنیت پیام . در امور تجاری واقعی نمی توان روی سرویس هایی که یک درخواست را فقط به خاطر این که بتوانند بفهمند،‌ پردازش می کنند حساب کرد . در امور تجاری به قطعیت و اطمینان بیشتری نیاز است. واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف متفاوت باشد . با وجود این هیچکدام از این موارد نباید برای کنار گذاشتن یاعدم پاسخ به یک درخواست باشند.
علاوه بر آن نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند واضح است که سیستم های مختلف ممکن است بعضی اوقات غیر فعال باشند و یا پاسخگویی آن ها در دفعات مختلف ، متفاوت باشد. با وجود این ،‌هیچ کدام ازاین موارد نباید دلیلی برای کنار گذاشتن یا عدم پاسخ به یک درخواست باشند. علاوه بر آن نباید هیچ ابهامی در نحوه فراخوانی یک سرویس وجود داشه باشد. اگر سیستمی توانایی های خود را در قالب سرویسی روی وب ارائه کند. در آن صورت نحوه فراخوانی آن سرویس باید به طور واضح مستند سازی و اعلام شود . بسیاری از مسائل دسترس پذیری و مقیاس پذیری برنامه های کاربردی امروزی در SOA حل شده است که احتمال نقض آن در هر مر حله ای از جریان کار بسیار زیاد است.در SOA فرض بر این است که خطا وجود دارد و می تواند بیفتد ، بنابراین استراتژی هایی برای مثال اگر یک سرویس نتواند یک پیغام را در مرحله اول بپذیرد . این معماری طوری طراحی شده است که مجددا پیام را بفرستد . واگر یک سرویس به طور کامل قابل دسترس نباشد، (که هرگز نباید در یک سیستم SOA پایدار انفاق بیفتد ) آن وقت معماری طوری طراحی شده است که روی دادن خطاهایی که ممنجر به قطع کامل در خواست سرویس می شود،‌امکان پذیر نباشد. SOA قابلیت اطمینان را افزایش می دهد، چون خطاهای موقت در بخشی از جریان کار نمی توانند کل فرایند تجاری را از کار بیاندازند .
به بیان کلی،‌ SOA فرایندی تکامل یافته را ارائه می نماید و ازاین نظر می تواند ان را بلوغ سریس های وب و تکنولوژی های یکپارچه سازی به حساب آورد . در SOA به این امر توجه شده است که سیستم های با اهمیت حیاتی که بر مبنای تکنولوژی های توزیع شده ساخته می شوند. باید تضمین های خاصی را تامین نمایند . در این گونه سیستم ها باید این اطمینان وجود داشته باشد که در خواست های سرویس به طور صحیح مسیر دهی و هدایت می شوند، در زمان مناسب به آن ها پاسخ داده می شود، و این سرویس ها به طور واضح و دقیق سیاست های ارتباطی و رابط های خود را اعلام می کنند.