Yeah. The basic idea is fine. (Don't write huge monolithic software blobs!) But the term was effectively coopted to be about a lot of specific heavyweight proprietary software and the heavyweight specs associated with them.
I'm not disagreeing but the reason SOA is more complex is that it does a whole lot more than "REST" microservices. It encompasses standardized protocols for transactions, faults, asynchronous services, auth, and more, in addition to payload typing and state. Such QoS dimensions aren't either considered in naive "REST" services at all, or at least not in upfront design (because waterfall sucks right?). Hence they're implemented for each service in an ad-hoc fashion, if at all. Implementing ad-hoc security in Docker containers (a technology proud of cutting ties with established ways of keeping eg OpenSSL lib up-to-date) in the "REST architectural style" (appealing to junior devs) and without transactions sure sounds like calling for trouble and acrueing technical debt like there's no tomorrow.
And also not disagreeing. While not an expert (thankfully!), it was very prescriptive and theoretically suited to the development styles of the time. As you suggest, microservices is more ad hoc and puts a greater burden on good architectural and operations practices which are more informally enforced.
But, net net, I put SOA in the same general bucket as ITIL and other associated practices of the time. They meant well but for most purposes they involved too much process and were ultimately too tied to big vendors trying to sell stuff.
> I'm not disagreeing but the reason SOA is more complex is that it does a whole lot more than "REST" microservices. It encompasses standardized protocols for transactions, faults, asynchronous services, auth, and more, in addition to payload typing and state.
"REST" microservices also do that, but they aren't bound to quasi-proprietary protocols and tooling.
How does "REST" handle coordinated transaction rollback/compensation over multiple heterogenous service calls? How is SOAP, XML, WS-*, AMQP proprietary?
> How does "REST" handle coordinated transaction rollback/compensation over multiple heterogenous service calls?
By "REST" I assume you're referring to non-SOA distributed systems which might happen to use REST or RPC-over-HTTP interfaces, and not the architecture style.
Assuming that, "REST" handles all those features by integrating services that support coordinated transaction rollback/compensation over multiple heterogenous service calls.
> How is SOAP, XML, WS-*, AMQP proprietary?
If you read what I said you'll notice that I explicitly said "quasi-proprietary protocols and tooling".
