This presentation is part of the Services and Connectors Self-Study Course.
Service Oriented Architecture (SOA) is an evolution of distributed computing and modular programming. The goal of SOA is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications that are built almost entirely from existing software services. Industry standard integration protocols are used in a SOA, such as web services (though not limited to web services). Integration becomes more like "plug and play".
For example, let's assume we integrated our enrollment system to the ERP solution via a web service. Your front-end solution is likely to be only slightly coupled with the ERP solution. If you want to use a different ERP vendor, fine. Just bring in the new vendor and modify some of the web service code. You should not have to rewrite the front-end solution from scratch.
Even better, a service oriented architecture is composed of an Enterprise Service Bus or ESB. This is software that manages the integration between applications. For example, if our front-end benefits enrollment system wants to communicate with a system of record to return a list of dependents, the front-end system will send its request to the ESB. The ESB will then determine the application that gets this request. This could be an Oracle application one day, SAP the next day, and a homegrown application the following day. As long as the type of operation, the inputs (e.g. employee id) and outputs (e.g. list of dependents) have not changed, the front-end application does not need to change. In an SOA, communication is always to the ESB, so you are never communicating directly with another application.
One of the prime benefits of an SOA is that legacy applications or portions of them can be reused across the enterprise. To allow for this reuse, adapters (software code) are created that turn legacy applications into services.
Implementations of SOA can even support the abstraction of database calls. For instance, you might communicate with an ESB via a web service, and the ESB translates the request to a SQL call via JDBC. Some data transformation may be necessary, and the SOA can perform this as well.
PRPC services may be created, and then called from an SOA. For instance, a SOA might string together a PRPC service, along with other applications, to form a composite application. Note that PRPC can also call services indirectly via a brokering component of an SOA.