|
== Critiche ==
L'architettura di tipo SOA è stata criticata da Martin Fowler<ref>[http://martinfowler.com/articles/microservices.html Microservices]</ref> e da Jim Webber<ref>[http://www.infoq.com/interviews/jim-webber-qcon-london Jim Webber on "Guerilla SOA"]</ref>. La critica riguarda la complessità del coordinamento tra i vari Web service che vengono chiamati. Solitamente per tale compito viene usato un prodotto proprietario di tipo Enterprise Service Bus. Tale prodotto proprietario nasconde all'interno di sé la complessità del coordinamento delle varie componenti. Con il tempo, modificare le configurazioni dell'ESB diventa sempre più difficile e si tende a non usare più l'ESB, ma a fare in modo che i componenti si chiamino l'uno con l'altro direttamente, ripresentando i problemi che l'ESB si era proposto di risolvere.
== Microservice ==
I microservice hanno uno stretto legame con l'architettura orientata ai servizi, infatti lo stile di sviluppo dei microservice è molto simile a quello promosso da chi sostiene SOA. La differenza sta nel fatto che spesso venivano usati degli Enterprise Service Bus per integrare delle applicazioni monolitiche.
Il tentativo di nascondere la complessità dell'integrazione all'interno degli Enterprise Service Bus, secondo Martin Fowler, ha portato a progetti che sono durati diversi anni e che sono costati milioni di dollari ma che non hanno prodotto alcun valore. Ancor peggio, hanno portato a modelli di conduzione centralizzata che hanno inibito i cambiamenti e reso difficile notare questi problemi.
Scrive Martin Fowler:
{{citazione| When we've talked about microservices a common question is whether this is just Service Oriented Architecture (SOA) that we saw a decade ago. There is merit to this point, because the microservice style is very similar to what some advocates of SOA have been in favor of. The problem, however, is that SOA means too many different things, and that most of the time that we come across something called "SOA" it's significantly different to the style we're describing here, usually due to a focus on ESBs used to integrate monolithic applications.
In particular we have seen so many botched implementations of service orientation - from the tendency to hide complexity away in ESB's, to failed multi-year initiatives that cost millions and deliver no value, to centralised governance models that actively inhibit change, that it is sometimes difficult to see past these problems.
Certainly, many of the techniques in use in the microservice community have grown from the experiences of developers integrating services in large organisations. The Tolerant Reader pattern is an example of this. Efforts to use the web have contributed, using simple protocols is another approach derived from these experiences - a reaction away from central standards that have reached a complexity that is, frankly, breathtaking. (Any time you need an ontology to manage your ontologies you know you are in deep trouble.)
This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA, perhaps service orientation done right. Either way, the fact that SOA means such different things means it's valuable to have a term that more crisply defines this architectural style. |Martin Fowler, [http://martinfowler.com/articles/microservices.html Microservices]}}
== Note ==
| 