Service-oriented architecture: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Sposto l'elenco delle definizioni in fondo alla pagina |
Recupero di 1 fonte/i e segnalazione di 0 link interrotto/i.) #IABot (v2.0.9.5 |
||
(42 versioni intermedie di 17 utenti non mostrate) | |||
Riga 1:
Nell'ambito dell'[[informatica]], con la locuzione [[lingua inglese|inglese]] di '''Service-Oriented Architecture''' (SOA) si indica generalmente un'
[[File:SOA Elements.png|thumb|upright=1.4|Elementi di una SOA, di Dirk Krafzig, Karl Banke, e Dirk Slama. ''Enterprise SOA''. Prentice Hall, 2005]]
== Definizioni esistenti ==
Una ''Service-Oriented Architecture'' è progettata per il collegamento a richiesta di risorse computazionali (principalmente applicazioni e dati), per ottenere un dato risultato per gli utenti, che possono essere utenti finali o altri servizi. L'''Organization for the Advancement of Structured Information Standards'' (Organizzazione per lo sviluppo di standard sull'informazione strutturata) definisce la Service Oriented Architecture così:
{{citazione| Un paradigma per l'organizzazione
Nonostante il fatto che esistano molteplici definizioni di ''Service-Oriented Architecture'', solo il gruppo ''Organization for the Advancement of Structured Information Standards'' ha prodotto una definizione formale applicabile profondamente sia alla tecnologia che ai domini aziendali.
Sebbene molte definizioni di ''Service-Oriented Architecture'' si limitino alla tecnologia o solo ai Web
=== Il manifesto ===
Riga 28 ⟶ 27:
== Descrizione ==
Nell'ambito di un'architettura ''Service-Oriented Architecture'' è quindi possibile modificare, in maniera relativamente più semplice, le modalità di interazione tra i servizi, oppure la combinazione nella quale i servizi vengono utilizzati nel processo. Inoltre, risulta più agevole aggiungere nuovi servizi e modificare i processi per rispondere alle specifiche esigenze di business. Così facendo, il processo di business non è più vincolato da una specifica [[sistema (informatica)|piattaforma]] o da un'applicazione; ma può essere considerato come un componente di un processo più ampio e quindi riutilizzato o modificato.
Riga 35 ⟶ 33:
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.).
''Service-Oriented Architecture'' può supportare l'integrazione e la consolidazione di attività all'interno di complessi sistemi aziendali (sistemi di [[Enterprise Application Integration|EAI]]
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 46 ⟶ 44:
Tra le tecnologie che permettono di creare delle architetture orientate ai servizi, ci sono:
* le [[Rete informatica|reti di comunicazione]], senza le quali sarebbe impossibile far comunicare applicativi che si trovano su server diversi;
* i [[Web
* l'[[Enterprise Service Bus]] (ESB) che ha la funzionalità di coordinare, orchestrare i vari applicativi per svolgere le funzioni di business.
== Protocolli di comunicazione correlati ==
Il service oriented computing non è legato ad una specifica tecnologia. Può essere realizzato usando una vasta gamma di tecnologie, comprese:
* [[Representational State Transfer]] (REST), un linguaggio usato per la definizione del servizio è Web Application Description Language;
* [[
* [[Distributed Component Object Model]] (DCOM), definiti mediante [[Interface Description Language]];
* [[Common Object Request Broker Architecture]] (CORBA), definiti mediante [[Interface Description Language]].
* [[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 ==
Riga 66 ⟶ 62:
* '''Standard aperti''': per poter operare in ambienti multipiattaforma è necessario, o quantomeno consigliabile, utilizzare esclusivamente standard aperti quali [[XML]], [[Web Services Description Language|WSDL]] e [[WS-Security]] (WSS).
* '''Modularità''': bisogna trovare il giusto equilibrio tra i servizi erogati da ogni singolo componente, creando un insieme bilanciato di piccoli servizi riutilizzabili per le funzioni comuni e servizi più grandi per processi specifici. Tale aspetto viene mutuato dal [[Component-based software engineering]]<ref>
* '''Contratti di servizio''': [[Web Services Description Language
▲* '''Modularità''': bisogna trovare il giusto equilibrio tra i servizi erogati da ogni singolo componente, creando un insieme bilanciato di piccoli servizi riutilizzabili per le funzioni comuni e servizi più grandi per processi specifici. Tale aspetto viene mutuato dal Component-based software engineering<ref>[http://petritsch.co.at/download/SOA_vs_component_based.pdf Service-Oriented Architecture (SOA) vs. Component Based Architecture]</ref>.
* '''Framework di integrazione''': implementano i pattern di integrazione<ref>[http://www.pearsoned.co.uk/bookshop/detail.asp?WT.oss=enterprise%20integration%20patterns&WT.oss_r=1&item=100000000041627 pattern di integrazione]</ref> e permettono una gestione più ordinata dell'orchestrazione dei servizi.▼
▲* '''Contratti di servizio''': [[Web Services Description Language|WSDL]] (Web Services Description Language) è la specifica standard per la creazione di contratti di Web Services, un contratto definito avrà come conseguenza servizi più flessibili.
▲* '''Framework di integrazione''': implementano i [http://www.pearsoned.co.uk/bookshop/detail.asp?WT.oss=enterprise%20integration%20patterns&WT.oss_r=1&item=100000000041627 pattern di integrazione] e permettono una gestione più ordinata dell'orchestrazione dei servizi.
* '''Enterprise Service Bus''': La dorsale di pubblicazione dei servizi ed abilitazione delle applicazioni per accedervi. Inoltre include caratteristiche quali adattatori per i [[sistema legacy|sistemi legacy]], capacità di orchestrazione dei servizi, autorizzazione e autenticazione lato sicurezza, trasformazione dei dati, supporto per regole di business e capacità di monitorare i [[service level agreement]].
== Critiche ==
==
I
Il tentativo di nascondere la complessità dell'integrazione all'interno degli Enterprise Service Bus
Scrive
{{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.
Riga 90 ⟶ 82:
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. |
== Note ==
Riga 96 ⟶ 88:
==Bibliografia==
* {{Cita libro | cognome=Barry | nome=Douglas K. | titolo= Web Services and Service-Oriented Architectures: The Savvy Manager's Guide | url=https://archive.org/details/webservicesservi0000barr | editore= Morgan Kaufmann Publishers | anno=2003 | città=San Francisco | isbn=1-55860-906-7 }}▼
▲* {{Cita libro | cognome=Barry | nome=Douglas K. | titolo= Web Services and Service-Oriented Architectures: The Savvy Manager's Guide | editore= Morgan Kaufmann Publishers | anno=2003 | città=San Francisco | isbn=1-55860-906-7 }}
* {{Cita libro | cognome=Bieberstein | nome=Norbert | coautori= Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah | titolo= Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap | editore= IBM Press| anno=2005 | città=Upper Saddle River | isbn=0-13-187002-5 }}
* {{Cita libro | cognome=Bloomberg| nome=Jason| coautori= Ronald Schmelzer | titolo= Service- orient or Be Doomed| url=https://archive.org/details/serviceorientorb00bloo| editore= WILEY | anno=2006 | città=Hoboken, New Jersey| isbn=0-13-187002-5}}
* {{Cita libro | cognome=Erl | nome=Thomas | titolo= Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services | url=https://archive.org/details/serviceorienteda0000erlt_f1c5 | editore= Prentice Hall PTR | anno=2004 | città=Upper Saddle River | isbn=0-13-142898-5 }}
* {{Cita libro | cognome=Erl | nome=Thomas | titolo= Service-Oriented Architecture: Concepts, Technology, and Design | url=https://archive.org/details/serviceorienteda0000erlt_f1c5 | editore= Prentice Hall PTR | anno=2005 | città=Upper Saddle River | isbn=0-13-185858-0 }}
* {{Cita libro | cognome=Hurwitz | nome=Judith | coautori=Robin Bloor, Carol Baroudi, Marcia Kaufman | titolo= Service Oriented Architecture for Dummies | editore= Wiley | anno=2006 | città=Hoboken | isbn=0-470-05435-2 }}
* {{Cita web | cognome = Shan | nome = Tony | coautori = Hua, Winnie | anno = 2006 | url = http://www.irma-international.org/viewtitle/3073/ | titolo = A Service-Oriented Solution Framework for Internet Banking | formato = PDF | editore= International Journal of Web Services Research, Vol. 3, Issue 1, pp 29-48 }}
* {{Cita web
Riga 123 ⟶ 113:
}}
* {{Cita libro | cognome=Pulier | nome=Eric | coautori=Hugh Taylor | titolo= Understanding Enterprise SOA | editore= Manning Publications | anno=2005 | città=Greenwich | isbn=1-932394-59-1 }}
* {{Cita web
| cognome = SOA Reference Model Technical Committee
Riga 136 ⟶ 125:
| nome =
| anno = 2006
| url =
| titolo = The Emergence of Grid and Service-Oriented IT: An Industry Vision for Business Success
| tipo = Paperback| editore= Tabor Communications, Inc.
}}
* {{Cita web
|
|
|
|
|
|
|
| |urlmorto = sì
|urlarchivio = https://web.archive.org/web/20070128091802/http://dssg.cs.umb.edu/projects/soa.html
|dataarchivio = 28 gennaio 2007
}}
* {{Cita web
|
|
|
|
|
|
|
| |urlmorto = sì
|urlarchivio = https://web.archive.org/web/20070128091802/http://dssg.cs.umb.edu/projects/soa.html
|dataarchivio = 28 gennaio 2007
}}
== Voci correlate ==▼
* [[Enterprise Service Bus]]▼
* [[Enterprise Application Integration]]▼
* [[XML]]▼
* [[Representational State Transfer]]▼
▲* [[Data Distribution Service]]
== Altri progetti ==
{{interprogetto|
== Collegamenti esterni ==
*{{en}} Consorzio OASIS: [http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm Modello di riferimento per le SOA]
*{{en}} InfoWorld: [https://web.archive.org/web/20060204060647/http://infoworld.com/techindex/portal/soa.html SOA News] Articoli sulle SOA
*{{
*{{en}} [https://web.archive.org/web/20060212051921/http://weblogs.java.net/blog/johnreynolds/archive/2005/01/the_soa_elevato.html La definizione di SOA di John Reynolds in due frasi] Articolo
*{{
*{{en}} [https://web.archive.org/web/20170915191919/http://soa-zone.com/ SOA Zone] Blog molto consultato a livello industriale
*{{
=== Definizioni di Service-Oriented Architecture ===
* {{
* {{
* {{
* {{
* {{
* {{
* {{
* {{
▲== Voci correlate ==
▲* [[Enterprise Service Bus]]
▲* [[Enterprise Application Integration]]
▲* [[XML]]
▲* [[Representational State Transfer]]
{{Controllo di autorità}}
{{Portale|internet}}
[[Categoria:Web service]]
|