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

Credo che il significato originale di SOA fosse basato su servizi con interfacce ben definite che possono essere consumati a livello di codice . L'attenzione era rivolta alle interfacce di servizio piuttosto che ai terminali UI, alle comunicazioni o ai database. La parte fondamentale 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 progettare una soluzione combinandola in un modo che risolva 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 è iscritto, piuttosto che acquistare una licenza per una copia del prodotto software. Per rispondere al terzo paragrafo della 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 è spesso usato in modo intercambiabile con SaaS e si riferisce a un team di professionisti IT ( tecnologia dell'informazione al contrario di sviluppo prodotto software ) che configura server e router e installare prodotti software da eseguire su di essi. Alcuni di loro hanno titoli come "SOA Architect", ma nessuno di loro ha nulla 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 sia veramente, e sì è abusato un bel po '. Quando penso a SOA, penso a quanto segue:

1. Un programma headless individuabile ...
2. Questo sfrutta la connettività senza stato (ala HTTP) ...
3. Comunicazione in formati indipendenti dalla piattaforma

Le SOA possono essere confrontate con l'architettura Client-Server (un'architettura di servizio stateful) e le librerie, che sono moduli collegati ai programmi attraverso un linker.

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

Le rigide definizioni di SOA sono ben oltre la linea di costo / beneficio in quanto teoriche in molti casi.

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

Una definizione USBLE di SOA significa che l'architettura generale è 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 considerati una singola responsabilità. Potrei avere scatole nere, potrei avere processi offline, ma se ci sono una raccolta di servizi individuabili attraverso cui posso ottenere una quantità significativa di lavoro che è la mia definizione minima.

A prescindere dal dibattito su cosa significhi realmente, il concetto (qualunque cosa significhi) ha sofferto in molti ambienti applicandosi a luoghi che semplicemente non si adattano.

Per 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 alla scatola nera, ma alcune persone continuano a provare a mettere servizi all'interno della scatola.

Come definizione tecnica rigorosa è sempre stato indefinito, ma l'idea non è priva di valore 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. Potrebbe essere stato scritto in una varietà di linguaggi e architetture, non di cui sarebbe importante o rilevante per i client che chiamano i servizi e di cui non esiste l'acronimo "SOA" in nessuna parte della documentazione.

Ma la direzione vuole "SOA" !!! Così hanno acquistato server molto costosi da una certa grande azienda che ha applicato adesivi "SOA" sopra ai precedenti adesivi "Web Service" che sono stati applicati sopra i precedenti adesivi "JEE" che sono stati applicati sopra .... hai capito l'idea Di conseguenza, mentre gli sviluppatori siedono attorno a trascinare e rilasciare icone itty-bitty attorno a uno schermo per creare "COMPONENTI" "SOA" che funzionano a metà, come se lo avessimo fatto con qualcosa di semplice come bean EBJ3, componenti primaverili ecc. .

Quindi il mio consiglio è che se ti viene chiesto di SOA, dì "Sì, ho fatto SOA, ho scritto molti sistemi che fanno uso di un'architettura orientata ai servizi per fare cose. Di quale tecnologia SOA stai chiedendo?" . E se iniziano a parlare con gli occhi luminosi e gli sguardi malinconici di un COMPONENTE SOA, DRAG E GOCCIA, e come lo facilita lo sviluppo. Torna indietro lentamente ed evita di stabilire un contatto visivo!

Penso che potrebbe avere un senso un po ': una cosa è quando i moduli "slave" vengono chiamati quando necessario, e un'altra cosa è quando si hanno processi di servizio / demone in esecuzione autonomamente e rispondono alle richieste, magari parlando tra loro , vivendo la propria vita in altre parole. Con questo approccio puoi avere un sistema enorme, scalabile e distribuito fisicamente. Ho visto alcuni nel settore della telefonia mobile, per esempio. Ma questa è solo una supposizione.

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