Service-oriented architecture: differenze tra le versioni

Versione delle 00:42, 10 gen 2016

Versione delle 22:40, 21 apr 2016

Riga 35:

Benché molte aziende offrano prodotti che possono formare la base di una ''Service-Oriented Architecture'' va sottolineato che la ''Service-Oriented Architecture'' non è un prodotto.

La chiave sta nella totale assenza di business logic sul client SOA, il quale è totalmente agnostico rispetto alla piattaforma di implementazione, riguardo ai protocolli, al binding, al tipo di dati, alle policy con cui il servizio produrrà l'informazione richiesta. Tutto a beneficio dell'indipendenza dei servizi, che possono essere chiamati per eseguire i propri compiti in un modo standard, senza che il servizio abbia conoscenza dell'applicazione chiamante e senza che l'applicazione abbia conoscenza, o necessiti di averne, del servizio che effettivamente eseguirà l'operazione.

''Service-Oriented Architecture'' può anche essere vista come uno stile dell'architettura dei [[sistema informatico|sistemi informatici]] che permetta la creazione delle applicazioni sviluppate, combinando servizi debolmente accoppiati e interoperabilità degli stessi. Questi servizi interagiscono secondo una definizione formale, detta protocollo o contratto, come per i [[Web Services Description Language]] indipendente dalla piattaforma sottostante e dalle tecnologie di sviluppo (come Java, .NET, ecc.). IPer serviziesempio, peri esempio,servizi scritti in Java usando la piattaforma Java EE e quelli in C# con .NET possono essere utilizzati dall'applicazione sovrastante. Le applicazioni in esecuzione su una piattaforma possono anche utilizzare servizi in esecuzione su altre, come con i Web services, facilitando quindi la riusabilità.

''Service-Oriented Architecture'' può supportare l'integrazione e la consolidazione di attività all'interno di complessi sistemi aziendali (sistemi di [[Enterprise Application Integration|EAI]],) ma non specifica o fornisce la metodologia o il framework per documentare capacità e potenzialità dei servizi.

I linguaggi di alto livello come [[Business Process Execution Language]] e le specifiche come ''Web Services Choreography Description Language'' e ''WS-Coordination'' estendono il concetto di servizio, fornendo un metodo per definire e supportare la coordinazione dei servizi di rifinitura con quelli maggiori, che, di conseguenza, possono essere inclusi in flussi di controllo e processi aziendali implementati con applicazioni composte o portali.

Riga 70:

== Critiche ==

Tale 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 ==