SOA describes any architecture that allows one component to request another component to do some operation. For an example let's say that you work for an online retailer and you've been asked to write something to allow different parts of the existing software system to generate several types of sales reports - one report for the marketing department, one for the shipping department, one for the tax collectors, etc. The underlying service that the solution is oriented around here is the generation of a report. Using web services for SOA you would write a web service that has a web method that clients can call to create reports. Any client can call the method, the method creates the report and does whatever it needs to do with it. You could also use a Windows Service. All you have to do is create a way for clients to request that the service generate the report that it wants and for this any form of IPC could be used. Sockets, MSMQ, Named Pipes, .Net Remoting or WCF would all allow other clients to get a message to the service to ask it to generate a report. The basic gist of SOA is [component A -> requests a service to be performed by -> component B]. What component A and B are aren't important and neither is how A requests B to do something. What makes it SOA is the design not what technologies are used.
:badger: