SOA (Service-Oriented Architecture) organizes business capabilities into services that multiple applications can share. Each service provides a clear function, such as checking stock or issuing an invoice, through an agreed interface.
For example, an online store and a staff application can call the same inventory service to check stock. Neither application needs to implement that business logic again or know how the warehouse software works internally.
Some systems use an ESB (Enterprise Service Bus) to route requests and translate data formats between applications. This is one integration option; SOA does not require an ESB or the SOAP protocol.
Consider a company with an online store, warehouse software, and accounting software. When a customer orders, the order workflow calls the inventory service to reserve stock, then calls the accounting service to create an invoice. Each service performs its operation in its own system and returns a result so the website can notify the customer.
The staff application can use those same two services to create orders in a physical store. Both sales channels share the inventory and accounting capabilities instead of maintaining separate implementations.
SOA suits organizations that need to connect multiple systems and share business capabilities, such as sales, inventory, accounting, and customer support. For a small application with little integration to do, it may add operational work without delivering much benefit.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate