ايتنا - معماری سرویس گرا (Service-Oriented Architecture)

به عنوان مقدمه‌ای از معماری سرویس گرا (SOA)، ابتدا به بیان دو مفهوم می‌پردازیم.
مفهوم منطق کسب‌وکار(Business Logic) و زیرساخت (Plumbing):

اولین مسئله‌ای که برای ساخت برنامه کاربردی باید در نظر گرفته شود، این است که شما از ابزار چه انتظاری دارید؟ و اینکه کامپیوتر چگونه آن را انجام می‌دهد؟

برنامه‌های کاربردی کسب‌وکار شامل مجموعه‌ای از کدهای برنامه‌نویسی هستند که کارهایی که کامپیوتر باید انجام دهد را به آن دیکته می‌کنند.

برخی از این کدها برطرف‌کننده‌ی نیاز منطق کسب‌وکار هستند (مانند اضافه کردن یک کالا به درخواست) و برخی دیگر زیرساختی می‌باشند (مرتبط با لایه‌ی کامپیوترها، مانند چک کردن در دسترس بودن پرینتر)؛ وجود هر دوی آنها الزامی است.

اگر شما فعالیت‌های برنامه‌ی کاربردی را در کسب‌وکار توصیف نکنید (به طور مثال ثبت سفارش، محصولات، مشتری‌ها، حساب کاربری و...) به سرعت آن خروجی را که از ابزار انتظار داشته‌اید، فراموش می‌کنید و اگر شما عملیات های کامپیوتر را توصیف نکنید عملاً کامپیوتر چگونه بتواند به وظایف خود عمل کند؟

و مواردی از این دست باعث می‌شوند نرم‌افزار نتواند عملیاتی شود. یکی از بزرگ‌ترین مشکلاتی که در برنامه‌نویسی‌های گذشته وجود داشت این بود که در حال نوشتن ابزار به سختی می‌توانستید لایه منطق کسب‌وکار را از لایه زیرساختی جدا کنید، بدین علت که شما باید هر دوی آنها را به طور همزمان کنترل می‌کردید.

در حین اینکه این دو لایه به هم مرتبط هستند، می‌توانند جدای از هم نیز در نظر گرفته شوند.

معماری SOA این مفهوم را با خود به همراه می‌آورد، کافی است از نرم‌افزارها و قواعد درست برنامه‌نویسی استفاده کنیم تا اطمینان یابیم این دو لایه از یکدیگر تفکیک شده‌اند.

در صورت تفکیک درست این دو لایه، اگر شما بخواهید تغییراتی در نحوه سفارش دهید (به طور مثال یک برنامه کاربردی را در مرحله‌ای از فرآیند فراخوانی کنید) این تغییر در معماری SOA بسیار ساده و کم هزینه خواهد بود درحالی‌که اگر تفکیک لایه‌های ذکرشده رعایت نشود(به همان سبک سنتی) این تغییرات بسیار پرهزینه، زمان‌بر، پیچیده، و نیازمند تست می‌باشد.
-------------------------------------------------
منبع: پایگاه دانش BPM رایورز