Service-oriented architecture: differenze tra le versioni

Versione delle 11:08, 11 apr 2015

Versione delle 11:41, 11 apr 2015

Riga 44:

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.

non ha chiaro il vero valore e l'intrinseco significato delle ''Service-Oriented Architecture'': nessuna di queste tecnologie è infatti capace di implementare entità che descrivano se stesse come è possibile fare usando i [[Web service]] mediante il linguaggio di definizione dei servizi [[Web Services Description Language]]. Piuttosto tali tecnologie sono utilizzate nell'ambito Service-Oriented Computing, ma non Service-Oriented Architecture. Infatti applicazioni di test che a run-time capiscano la semantica di un servizio e lo invochino senza "conoscere" nulla del servizio stesso "a priori", non esistono per nessuna delle tecnologie citate.}} 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.

{{citazione necessaria|Non è affatto vero che un'architettura orientata ai servizi non sia legata ad una specifica tecnologia. Chi dice che può essere realizzata usando una vasta gamma di tecnologie, comprese:

* [[Representational State Transfer]],

* [[Chiamata di procedura remota]],

* [[Distributed Component Object Model]],

* [[Common Object Request Broker Architecture]],

* [[Message-oriented middleware]],

* [[Data Distribution Service]]

non ha chiaro il vero valore e l'intrinseco significato delle ''Service-Oriented Architecture'': nessuna di queste tecnologie è infatti capace di implementare entità che descrivano se stesse come è possibile fare usando i [[Web service]] mediante il linguaggio di definizione dei servizi [[Web Services Description Language]]. Piuttosto tali tecnologie sono utilizzate nell'ambito Service-Oriented Computing, ma non Service-Oriented Architecture. Infatti applicazioni di test che a run-time capiscano la semantica di un servizio e lo invochino senza "conoscere" nulla del servizio stesso "a priori", non esistono per nessuna delle tecnologie citate.}} 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). I servizi, per esempio, 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à.

Line 64 ⟶ 57:

* i [[Web Service]] che permettono di definire le modalità di comunicazione dei vari applicativi;

* l'[[Enterprise Service Bus]] che ha la funzionalità di coordinare, orchestrare i vari applicativi per svolgere le funzioni di business.

== Protocolli di comunicazione correlati ==

{{citazioneIl necessaria|Nonservice èoriented affatto vero che un'architettura orientata ai servizicomputing non siaè legatalegato ad una specifica tecnologia. Chi dice che puòPuò essere realizzatarealizzato usando una vasta gamma di tecnologie, comprese:

* [[Representational State Transfer]],

* [[Chiamata di procedura remota]],

* [[Distributed Component Object Model]],

* [[Common Object Request Broker Architecture]],

* [[Message-oriented middleware]],

* [[Data Distribution Service]]

Bisogna sottolineare il fatto che, perché una architettura possa essere definita ''orientata ai servizi'', il protocollo di comunicazione deve permettere anche di definire i servizi, i parametri in ingresso ed in uscita, come viene fatto, ad esempio con il [[Web Services Description Language]].

Diversi dei protocolli elencati sopra sono antecedenti alla definizione dell'architettura orientata ai servizi e sono associati al component-based software engineering. Quando sono state introdotte delle tecnologie legate all'eXtensible Markup Language, è diventato più semplice e proficuo realizzare architetture di questo tipo.

== Aspetti dello sviluppo ==

Line 169 ⟶ 175:

*{{en}} [http://soa-zone.com SOA Zone] Blog molto consultato a livello industriale

*{{en}} [http://www.customers.com/articles/Service-Oriented-World-Cheat-Sheet/ "Service-Oriented World" di Patricia Seybold]

{{Controllo di autorità}}

{{Portale|internet}}

== Voci correlate ==

* [[Enterprise Service Bus]]

{{Controllo di autorità}}

{{Portale|internet}}

[[Categoria:Web service]]