One of the criticisms of SOA is that the addition of XML layers introduces XML parsing and composition. In the absence of native or binary forms of Remote Procedure Calls (RPCs) applications may run slower and require more processing power, which increases costs.
Another criticism of SOA is that the services are just stateless. According to www.xml.com, Stateful service is difficult to avoid in a number of situations. One situation is to establish a session between a consumer and a provider. A session is typically established for efficiency reasons. For example, sending a security certificate with each request is a serious burden for both any consumer and provider. It is much quicker to replace the certificate with a token shared just between the consumer and provider. Another situation is to provide customized service.
Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. The drawback of this constraint is that it may reduce the overall scalability of the service provider because it may need to remember the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult.
Another concern is that WS* standards and products are still evolving (e.g., transaction, security), and SOA can thus introduce risk unless properly managed and estimated with additional budget and contingency for additional Proof of Concept work.
An informal survey by Network Computing placed SOA as the most despised buzzword (November 2006).
Some critics feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).
Lamentablemente, la Wikipedia no publica los nombres de los colaboradores que intervienen en cada artículo. En este caso, hubiera sido conveniente.