SOA is not necessarily ‘Web Services’.
A service oriented architecture could be implemented in many different ways. One implementation might be a client-server application, where services are independently deployed to the SOA platform and accessed by client programs. Think of 20 cash register operators at Wal-Mart (the client programs) and a server running a set of cashier related services in the back room somewhere. This might all be implemented in Java.
Another implementation of a service oriented architecture might involve traditional ‘Web Services’ implemented using SOAP (Simple Object Access Protocol) and WSDL (Web Service Description Language). Imagine Amazon.com providing software services to their business partners and UPS providing services to Amazon.com. In this scenario, Amazon.com might have implemented their system using Java, whereas UPS implemented their system in .NET. This is the value of ‘Web Services’ – SOAP and WSDL enable these heterogeneous systems to communicate with one another. The SOA part of this scenario lies in the fact that new services can be deployed and consumed independent of the existing services currently deployed. SOA enables this loose coupling which is quite valuable from a business standpoint, as I discussed before.
So service oriented architecture is not necessarily coupled to ‘Web Services’. It’s more of an architectural style.