Il termine "architettura orientata ai servizi" è diventato un gergo insignificante? [chiuso]

Oggi mi è stato chiesto se avevo esperienza con "Service Oriented Architecture" e anche se penso di sì. Il concetto, per me, sembra così confuso che non so più come rispondere onestamente a questa domanda.

Ho fatto ricorso a Google per cercare il termine nel tentativo di ottenere una definizione concisa del concetto e di come differisce dalle altre architetture. Dopo aver letto una serie di articoli su di esso, l'unico thread comune che sembra essere in grado di trovare è un sistema con più componenti che dialogano tra loro su una sorta di interfaccia, con forse una leggera preferenza per XML / SOAP.

Sembra che quasi ogni applicazione possa essere definita come SOA, in particolare un'applicazione web. Questo termine è caduto nella trappola del "Web 2.0" e diventa un termine che significa qualunque cosa tu voglia che significhi?

Sono lontano dalla base qui? Quando ascoltate il termine, significa qualcosa di specifico per voi? Se è così, mi piacerebbe una definizione concisa che dimostri chiaramente cosa sia e cosa NON sia SOA.

Credo che il significato originale di SOA fosse basato su servizi con interfacce ben definite che possono essere consumate a livello di programmazione . L'attenzione era focalizzata sulle interfacce di servizio piuttosto che su terminali, comunicazioni o database dell'interfaccia utente. La parte chiave erano i servizi che consumavano altri servizi. Il servizio A può chiamare il servizio B, ottenere il risultato e chiamare il servizio C o D. È possibile disporre di una serie di servizi specializzati e progettarne una soluzione combinandoli in modo da risolvere il problema del cliente.

La SOA viene spesso confusa con SaaS (software as a service), che si riferisce al modello di prezzo in cui l'utente paga per l'utilizzo del servizio a cui si è abbonato, piuttosto che acquistare una licenza per una copia del prodotto software. Per rispondere al terzo paragrafo della tua domanda, un'applicazione Web probabilmente non è SOA, ma può essere SaaS.

Il termine ha sicuramente perso parte del suo significato. Nell'organizzazione in cui lavoro, il termine SOA viene spesso utilizzato in modo intercambiabile con SaaS e si riferisce a un team di professionisti IT ( tecnologia dell'informazione anziché sviluppo di prodotti software ) che configura server e router e installa prodotti software per eseguirli. Alcuni di essi hanno titoli come "SOA Architect", ma nessuno di essi ha a che fare con l'architettura, la progettazione, l'implementazione o il test del software.

Ho fatto la stessa cosa su Google SOA per vedere cosa è veramente, e sì, è stato abusato un po '. Quando penso alla SOA penso a quanto segue:

1. Un programma senza testa rilevabile ...
2. Che utilizza la connettività senza stato (ala HTTP) ...
3. Comunicazione in formati indipendenti dalla piattaforma

La SOA può essere contrastata con l'architettura Client-Server (un'architettura di servizio stateful) e le librerie, che sono moduli collegati ai programmi tramite un linker.

Quindi, quando la gente ne parla, generalmente lo prendo con un granello di sale. Tendo anche a chiamarlo semplicemente "servizi web". Con i servizi web l'architettura è implicita.

Le rigorose definizioni di SOA sono ben oltre la linea di costo / beneficio da essere teoriche in molti casi.

A meno che il tuo prodotto non sia il servizio stesso, spesso hai bisogno di un diverso punto di vista.

Una definizione USABLE di SOA significa che la tua architettura complessiva è di facile manutenzione. Un sistema costruito completamente da servizi atomici di solito non è il piano giusto e alcuni servizi si organizzeranno funzionalmente mentre altri saranno la sola responsabilità. Potrei avere scatole nere, potrei avere processi offline, ma se ci sono una raccolta di servizi rilevabile attraverso la quale posso fare una quantità significativa di lavoro, questa è la mia definizione minima.

A parte il dibattito su cosa significhi effettivamente, il concetto (qualunque cosa significhi) ha sofferto in molti ambienti essendo applicato a luoghi in cui semplicemente non rientrava.

Ad esempio, se sto costruendo qualcosa che dovrebbe essere un processo di black box e scala attraverso il parallelismo, non la segmentazione e la distribuzione, potrei avere un servizio per esporre / parlare con la black box, ma alcune persone continuano a provare a mettere i servizi all'interno del scatola.

Come definizione tecnica rigorosa è sempre stata indefinita, ma l'idea non è priva di merito dove si adatta.

Ho avuto la fortuna di lavorare su un paio di sistemi aziendali in cui la gestione è stata venduta su SOA. Come sviluppatore guardo i sistemi e vedo un mucchio di software dietro un servizio web che fa cose. Avrebbe potuto essere scritto in una varietà di lingue e architetture, nessuna delle quali avrebbe importanza o sarebbe rilevante per i clienti che chiamavano i servizi e non di cui effettivamente avesse l'acronimo "SOA" ovunque nella loro documentazione.

Ma la direzione vuole "SOA" !!! Quindi hanno acquistato server molto costosi da una certa grande azienda che ha applicato adesivi "SOA" sopra i precedenti adesivi "Web Service" che sono stati applicati sopra i precedenti adesivi "JEE" che sono stati applicati sopra .... hai avuto l'idea. E di conseguenza, noi sviluppatori siamo seduti a trascinare e rilasciare icone bituminose attorno allo schermo per creare "COMPONENTI" "SOA" che funzionano a metà e se lo avessimo fatto con qualcosa di semplice come fagioli EBJ3, componenti a molla ecc. .

Quindi il mio consiglio è se ti viene chiesto della SOA, dì "Sì, ho fatto la SOA, ho scritto molti sistemi che fanno uso di un'architettura orientata al servizio per fare le cose. Di quale tecnologia SOA stai chiedendo?". E se iniziano a parlare con occhi luminosi e sguardi malinconici su un SOA COMPONENTS, DRAG AND DROP, e su come lo sviluppo sia più semplice. Allontanati lentamente ed evita il contatto visivo!

Penso che potrebbe avere un senso un po ': una cosa è quando hai moduli "slave" chiamati quando necessario, e un'altra cosa è quando hai processi di servizio / demone che funzionano in modo indipendente e rispondono alle tue richieste, possibilmente parlando l'uno con l'altro, vivendo il loro la propria vita in altre parole. Con questo approccio puoi avere un sistema enorme, scalabile e distribuito fisicamente. Ne ho visti alcuni nel settore della telefonia mobile, ad esempio. Ma questa è solo una supposizione.

(Ora vediamo cosa dice Wikipedia su SOA ... Whoa.)