I've been reading quite a lot of things recently attacking SOA as heavyweight and unwieldy, but these articles are actually attacking SOAP and various WS-* standards. The point is that these are not the same thing as SOA, in fact I tend to agree that when compared to REST, say, a lot of Web Service standards certainly look rather complex and heavyweight.
Half the problem is that various vendors jumped on Service Oriented Architecture as a way to sell products, they contributed the blurring of the term. I happen to think SOA contains some concepts that can actually really help when building distributed systems - I'd hate those ideas get thrown out with the bathwater, so to speak.
For me SOA is about a way of viewing a distributed system or integration problem, seeing things not as a series of applications to be plumbed together but rather as business units that interact by providing or consuming services.
Processing a customer order might involve a 'warehouse stock check' service, a 'credit check' service, a 'payment service' and a 'schedule delivery' service. Maybe these services all live on the same system, or 4 different systems - what's important is that there are 4 distinct services involved. By talking about these things at the service level we can verify with the business both our understanding and the value those services offer. If we jump straight into technical detail we lose the business involvement and usually end up with integration points between systems that can never be reused with all to often no one remembering why they were built. I see this happening with web services - just recreating the same old problems with new technology.
So what features would we like our services to have?
We want to be able to consume a service without being dependent on the underlying implementation (decoupling) so we can change implementations without disrupting consumers. The change in implementation might be as simple as adding a database column or as complex as replacing a whole legacy system. Exposing a database table via a web service is coupling the user of that web service to the structure of the table - it's not really a service at all, just another api straight into the database.
We want to be able to discover and use services, this implies some kind of service defintion - this doesn't need to be anything complicated, a
sequence diagram and message schema will do just fine, nobody needs to start creating WSDL. Discovery can just be manually checking a web page with a list of available services on it, as relationships between business units tends to be long lived fancy automated discovery rarely (in my experience) adds much value.
We also want to understand the quality of service we need, retrying a stock check might be fine but retrying a payment request without knowing the status of the previous attempt is probably a bad thing, customers don't like to be charged twice. We need to make a choice here, we could use guaranteed delivery for payment requests but reliable for stock check, or it could be we capture the behaviour in the semantics of the service itself i.e. with duplicate payment requests containing the same order number, say, always being rejected.
Finally we might take the 'customer order' service and offer that up as a service in it's own right, i.e. we can compose services together to create new services. Again no one needs any complex tool to do this, it could just be as simple as an application which processes customers orders (by consuming other services) offering that service up for reuse.
There is a lot more to think about but the point is no web services, no distributed transactions, no expensive orchestration engine. I was involved in building systems like this using simple messaging middleware over 6 years ago - SOA is not heavyweight and complex in of itself, many things which claim to deliver SOA are.
