WSDL and SOAP generally suffer from the same problem CORBA and DCOM do: contract versioning is a nightmare. This isn't as much of a problem in the degnerate case where you have full control of all clients and servers, but it gets ugly when you begin federating systems, more so when you go inter-enterprise.
At that point you're almost forced to some sort of event driven architecture approach instead of the typical SOAP-as-RPC model of interactions. This doesn't have to mean using ESBs, but viewing the connections between enterprises as connections among ESBs is very useful.
Even then relying on SOAP as a transport gets ugly. Not only do you need to accomodate bidirectional interaction using opposed Web Services, you're still stuch with the versioning problem. Often the SOAP methods dengerate to trivial wrappers around "blobs" defined otherwise (separate XML schemas for example).
There are answers but they're never simple. Best practices for Web services versioning discusses a couple of them.
But SOA does not imply anything async at all. It's just the smart way to implement SOA. SOAs are about loose coupling. The EDA subset of SOAs is about de-coupling, which goes further.
