"توجه کنید که به سرویس ها اجازه دهید به طور مستقیم بتوانند سرویس های دیگر را فراخوانی کنند."
(یعنی هر سرویس خود مشتری سرویس دیگر هم باشد.)

به این عنوان محتوای در دسترس کسب و کار برای استفاده مجدد سرویس می تواند کاهش چشمگیری داشته باشد. گاهی اوقات به نظر می رسد لازم است یک سرویس را مشتری سرویس دیگر در اجرایش ساخت. با این کار مرحله ای از اتصال را تعریف می کنید که بعداً برایتان مسئله ساز می شود. اگر شما خودتان را در این موقعیت دیدید استفاده از یک تکنولوژی ارکستراسیون ( همنوازی ) مانند BPEL را به کار گیرید.
همچنین بدون قرارداد سطح سرویس (SLA) نظارت بر نرم افزار و متریک اینکه در هر مکان دنبال کنیم چه مقدار سرویس دریافت می شود؛ می تواند دشوار باشد. یک مشکل دیگر در زمینه احضار سرویس آن است که بدون اجازه دید دادن به ابزار به توپوگرافی شما پیچیدگی می افزاید. ابزارهای برای نشان دادن منابع در سرتاسر منابع مربوط به سرویس های ذخیره شده در مخزن در نزد فروشندگان بزرگ SOA وجود دارد. اما بسیار گران است.
راه حل معماری این مشکل آن است، زمانی که می خواهیم یک سرویس داشته باشیم که مستقیم دیگری را فراخوانی کند در نظر بگیریم می توانیم به جای آن، یک ارکستراسیون خلق کنیم.
همان طور که یک سرویس سیستم یا زیر سیستم راپوشش می دهد، یک ارکستراسیون مجموعه ای از سرویس ها را که با هم جریان دارند را پوشش می دهد. اما یک ارکستراسیون مانند یک سرویس عمل می کند به صورتی که برای مشتریان مانند سرویس های دیگر به نظر می رسد.
در هر سازمانی SOA ها متفاوت اند و بهتر است که هر سازمان با توجه به کسب و کار و عناصر و محدودیت های آن برای SOA معنای خاص خود را در نظر داشته باشد.