Cos'è SOA "in inglese semplice"? [chiuso]

Qualcuno può spiegare in un inglese semplice che cos'è SOA ? Sento SOA qui, SOA là ma non riesco a capire esattamente cosa sia e per cosa venga usato. Era un concetto semplice e successivamente si è evoluto in qualcosa di enorme o cosa?

Tutti i documenti, incluso il wiki, sono un po 'astratti o forse sono un idiota e non capisco. C'è una guida idiota su questo?

Cosa c'è esattamente dietro queste tre lettere?

Potresti trovare utile questo articolo (Cos'è SOA? - Spiegazione SOA e Web Services) .

Un piccolo teaser:

• SOA è uno stile di architettura delle applicazioni in modo tale che siano composte da agenti software discreti che hanno interfacce semplici e ben definite e sono orchestrati attraverso un accoppiamento libero per eseguire una funzione richiesta.

• Ci sono 2 ruoli in SOA: un fornitore di servizi e un consumatore di servizi. Un agente software può svolgere entrambi i ruoli. SOA non è un concetto completamente nuovo, tuttavia, questo articolo si concentra principalmente sulla SOA implementata con i servizi web.

SOA è un nuovo badge per alcune idee molto vecchie:

• Dividi il tuo codice in moduli riutilizzabili.

• Incapsula in un modulo qualsiasi decisione di progettazione che potrebbe cambiare.

• Progetta i tuoi moduli in modo tale che possano essere combinati in diversi modi utili (a volte chiamati "famiglia" o "linea di prodotti").

Questi sono tutti i principi fondamentali dello sviluppo del software, molti dei quali articolati per la prima volta da David Parnas.

Cosa c'è di nuovo in SOA è

• Lo stai facendo su una rete.

• I moduli comunicano inviandosi messaggi l'un l'altro sulla rete, piuttosto che tramite meccanismi di linguaggio di programmazione più tradizionali come le chiamate di procedura. In particolare, in un'architettura orientata ai servizi le parti generalmente non condividono lo stato mutabile (variabili globali in un programma tradizionale). Oppure, se condividono lo stato, quello stato viene accuratamente rinchiuso in un database che è esso stesso un agente e che può gestire facilmente più client simultanei.

Vedo molte risposte che spiegano un'architettura SOA (Service Oriented Architecture) utilizzando parole e termini tecnici ancora più avanzati. Vorrei provare a spiegarlo per i profani, usando un'analogia in un inglese semplice.

Ma prima una descrizione di una SOA
SOA potrebbe essere descritta in tre strati come si vede nella figura sotto. Da una parte abbiamo il Provider e dall'altra abbiamo il Consumatore , separato da un Bridge dove comunicano le due parti.

Il consumatore utilizza una serie di applicazioni necessarie per la sua attività e il fornitore utilizza componenti che forniscono informazioni a queste applicazioni. Comunicano attraverso una serie di servizi utilizzando un'architettura comune.

L'analogia
Immagina una casa in campagna, che per molti versi fa parte di una comunità più ampia, come una città o un paese. La città ha i propri sistemi complessi per la fornitura di acqua ed elettricità, la gestione dei servizi igienici, la fornitura di trasporti e altri servizi. La casa è il consumatore in questo modello, la città (o la comunità) è il fornitore e le condutture, le fognature, le linee elettriche, le fibre ottiche, ecc. Sono l' infrastruttura in cui comunicano.

Questo modello potrebbe essere vagamente paragonato a una SOA. Le persone in casa utilizzano una serie di diverse "applicazioni" come radiatori, computer, servizi igienici, lampade, riscaldamento a pavimento, vasche da bagno ecc. Queste applicazioni non si preoccupano di come la città genera l'acqua, crea elettricità o gestisce i rifiuti finché come funziona. I componenti della città sono i generatori, le pompe dell'acqua e le aree igieniche. Fornisce alla casa tutte queste esigenze, ma spetta alla casa usarlo nel modo che ritiene opportuno.

Spero che questo abbia dato almeno a qualcuno un'immagine migliore di una SOA.

Supponiamo che tu abbia quattro cuochi. In SOA, presumi che si odino a vicenda, quindi ti sforzi di lasciare che debbano parlare tra loro il meno possibile.

Come si fa a farlo? Bene, prima definirai i ruoli e l'interfaccia: il cuoco 1 farà l'insalata, il cuoco 2 farà la zuppa, il cuoco 3 farà la bistecca, ecc. Quindi posizionerai i piatti ben organizzati sulla tavola (quindi questi sono i interfacce) e dite: "Per favore, mettete tutti la vostra creazione nei vostri piatti assegnati. Non preoccupatevi di nessun altro".

In questo modo, i quattro cuochi devono parlare tra di loro il meno possibile, il che è molto buono nello sviluppo del software, non necessariamente perché si odiano a vicenda, ma per altri motivi come la posizione fisica, l'efficienza nel prendere decisioni ecc.

Significa anche che puoi ricombinare i piatti (servizi) come preferisci. Ad esempio, potresti semplicemente usare il dessert per servire un bar, o semplicemente prendere la zuppa e combinarla con un pane che hai acquistato da un'altra azienda per fornire un menu più economico, o lasciare che altri ristoranti usino le tue insalate per combinare con i loro piatti, ecc. .

Una delle implementazioni di maggior successo di SOA è stata in Amazon. A causa del loro design, potrebbero reimballare l'intera infrastruttura e venderla come Amazon Web Service.

* Questo è solo un aspetto della SOA.

SOA è uno stile architettonico ma anche una visione su come sviluppare e integrare un'applicazione eterogenea. Lo scopo principale della SOA è quello di abbandonare le applicazioni monolitiche e avere invece una serie di servizi riutilizzabili che possono essere composti per creare applicazioni.

IMHO, SOA ha senso solo a livello aziendale e non significa nulla per una singola applicazione.

In molte aziende, ogni reparto aveva il proprio set di applicazioni aziendali che implicavano

1. Funzionalità simili sono state implementate più volte

2. I dati (ad esempio i dati dei clienti o dei dipendenti) devono essere condivisi tra diverse applicazioni

3. Le applicazioni erano incentrate sul reparto.

Con SOA, l'idea è di rendere disponibili servizi riutilizzabili a livello aziendale, in modo che l'applicazione possa essere costruita e composta da essi. Le promesse di SOA sono

1. Non è necessario reimplementare funzioni simili più e più volte (ad esempio fornire un servizio clienti o dipendenti)

2. Facilita l'integrazione delle applicazioni insieme e l'accesso a dati o funzionalità comuni

3. Sforzo di sviluppo incentrato sull'impresa.

La visione SOA richiede un cambiamento tecnologico oltre che un cambiamento organizzativo . Mentre risolve alcuni problemi, ne introduce anche altri, ad esempio la sicurezza è molto più difficile con SOA che con l'applicazione monolitica. Pertanto SOA è oggetto di discussione sul fatto che funzioni o meno.

Questa è la vista di 1000 piedi di SOA. Tuttavia non si ferma qui. Ci sono altri concetti che integrano SOA come l'orchestrazione dei processi aziendali (BPM), bus di servizi aziendali (ESB), elaborazione di eventi complessi (CEP), ecc. Tutti affrontano il problema dell'allineamento IT / business , ovvero come disporre dell'IT essere in grado di supportare efficacemente l'attività.

SOA è l'acronimo di Service Oriented Architecture.

SOA progetta e scrive applicazioni software in modo tale che moduli software distinti possano essere integrati perfettamente con un alto grado di riutilizzabilità.

La maggior parte delle persone limita la SOA scrivendo servizi web software client / server. Ma è un contesto troppo piccolo di SOA. La SOA è molto più ampia di così e negli ultimi anni i servizi web sono stati il ​​mezzo di comunicazione principale, il che è probabilmente il motivo per cui le persone pensano alla SOA come servizi web in generale che limitano i confini e il significato di SOA.

Puoi pensare di scrivere un modulo di accesso al database che sia così indipendente da poter funzionare da solo senza dipendenze. Questo modulo può esporre classi che possono essere utilizzate da qualsiasi software host che necessita dell'accesso al database. Non esiste una configurazione di avvio nell'applicazione host. Tutto ciò che è necessario o richiesto viene comunicato tramite le classi esposte dal modulo di accesso al database. Possiamo chiamare queste classi come servizi e considerare il modulo come abilitato ai servizi.

Praticare SOA offre un alto grado di riutilizzabilità imponendo DRY [Non ripetere te stesso] che si traduce in un software altamente manutenibile. La manutenibilità è la prima cosa a cui pensa un'architettura software: SOA te lo offre.

Per quanto ho capito, il concetto di base è quello di creare piccoli "servizi" che forniscono qualcosa di utile ad altri sistemi ed evitare di costruire grandi sistemi che tendono a fare tutto all'interno del sistema.

Quindi definisci un protocollo che utilizzerai per l'interazione (ad esempio, potrebbe essere servizi web SOAP) e lascia che il tuo "sistema-che-fa-lavoro-funzioni" interagisca con i piccoli servizi per raggiungere il tuo "grande obiettivo" .

Ti suggerirei di leggere articoli di Thomas Erl e Roger Sessions, questo ti darà una solida conoscenza di cosa sia SOA. Queste sono anche buone risorse, guarda la SOA spiegata per il tuo capo per una spiegazione laica

Costruire una SOA

Modello di progettazione SOA

Raggiungere l'integrità in una SOA

Perché il tuo SOA dovrebbe essere come un Maggiolino VW

SOA spiegato per il tuo capo

Prestazioni del servizio WCF

quello che tende ad accadere nelle grandi organizzazioni è che nel tempo tutto è monolitico o sistemi disparati ovunque o un po 'entrambi. Qualcuno alla fine arriva e dice che abbiamo un pasticcio. Ora, si vuole ridisegnare (soldi a qualcuno) tutto per essere orientato in una sorta di monotolitico dipende da chi si paga paradigma ma allo stesso tempo poter aggiungere pezzi e parti indipendentemente dal master / monolite.

Quindi acquisti SOA di Oracle e Oracle diventa il capo di tutte le tue parti. Tutti gli altri giocatori che entrano devono lavorare con SOA tramite un servizio (servizio web o qualunque cosa abbia). Il monolite Oracle si prende cura di tutto (monolite non è da intendersi dispregiativo). Oh sì, hai ASP.NET MVC sulla parte anteriore o qualcos'altro.

la cosa principale è spostare le cose dentro e fuori dal sistema senza alcun impatto e mantenere il fornitore Oracle SOA, Microsoft WCF, come il cervello di tutto. tutto è tutto fluido, fluido, cose che entrano ed escono con un impatto minimo o nullo, anche i servizi umani, non solo i computer.

Per me significa solo un mucchio di servizi web (o come li chiameremo in futuro) con un buon front-end. E se possiedi il database, accedi al database e smetti di preoccuparti delle parole d'ordine. va bene.

Un solo suggerimento: -

Leggi Concetti, tecnologia e design SOA di Thomas Erl.

Ha fornito in modo molto bello i dettagli sulla SOA in un inglese semplice e con casi di studio.

Bene, vedi .. SOA sta per Service Oriented Architecture .... In parole più semplici, scrivi un pezzo di codice che è molto generico, cioè fa qualcosa che può essere usato in molte applicazioni ... può essere qualcosa di simile una rubrica o può essere una calcolatrice. e lanci questo codice su IIS. Quindi fornisci un servizio tramite il tuo codice. Quindi sei un fornitore di servizi. Ora qualcuno vuole usare un codice simile, quindi non deve riscrivere il codice. Usa semplicemente il tuo codice magari tramite un servizio web. Quindi diventa un consumatore di servizi. Quindi fare un programma che utilizza tali servizi è chiamato SOA. E l'accoppiamento libero è presente in quanto il fornitore di servizi e il consumatore possono interagire anche se utilizzano linguaggi di programmazione diff. Spero che tu capisca.

dai blog ittoolbox.

Quanto segue delinea le somiglianze e le differenze con le tecniche di progettazione passate:

• SOA e programmazione strutturata o Somiglianze: molto simili alle chiamate di subroutine in cui vengono passati i parametri e l'operazione della funzione è astratta dal chiamante, ad esempio CICS link and execute e la parola riservata COBOL CALL. I quaderni vengono utilizzati per definire la struttura dei dati che è tipicamente definita come uno schema XML per i servizi. o Differenze: SOA è debolmente accoppiato, il che implica che le modifiche a un servizio hanno un impatto minore per il consumatore (il programma "chiamante") e i servizi sono interoperabili tra lingue e piattaforme.

• SOA contro OOA / OOD o Somiglianze: incapsulamento, astrazione e interfacce definite o Differenze: SOA è vagamente accoppiato senza gerarchia di classi o ereditarietà, astrazioni di basso livello - livello di classe rispetto al servizio aziendale

• SOA rispetto a sviluppo basato su componenti (CBD) legacy - ad es. CORBA, DCOM, EJB o Somiglianze: riutilizzo attraverso l'assemblaggio di componenti, interfacce, chiamate remote o Differenze: ampia adozione di standard, schemi XML rispetto a oggetti in marshalling, orchestrazione dei servizi, progettazione per il riutilizzo è più semplice, i servizi sono incentrati sul business rispetto all'IT, i servizi aziendali sono granulari (ambito ampio)

• SOA (per l'integrazione) contro Enterprise Application Integration (EAI) o Somiglianze: best practice (interfacce ben definite, schemi standardizzati, architettura basata sugli eventi), interfacce riutilizzabili, schemi comuni o Differenze: standard, adozione e strumenti migliorati

Leggendo le risposte sopra, mi sembra che SOA sia ciò che gli sviluppatori (almeno quelli bravi) hanno fatto dal primo giorno.

Potrebbe anche stare per "Struct of Arrays" (al contrario di "Array of Structs") che è un argomento comune nella programmazione parallela (specialmente SIMD), ma immagino che non sia ciò che intendi qui!

SOA è una parola d'ordine che è stata inventata dai fornitori di tecnologia per aiutare a vendere le loro tecnologie correlate all'Enterprise Service Bus. L'idea è che tu faccia in modo che le tue applicazioni a isola nell'azienda (ad esempio: sistema di contabilità, sistema di controllo delle scorte, ecc.) Espongano tutti i servizi, in modo che possano essere orchestrati in modo flessibile in "applicazioni", o piuttosto diventino parte di un business aggregato con ambito aziendale logica.

Fondamentalmente un carico di vecchie cazzate che non funziona quasi mai, perché manca il punto che le ragioni per cui la tecnologia è così com'è in un'organizzazione dipendono dalla cultura, dall'evoluzione, dalla storia dell'azienda e il blocco è così alto che qualsiasi il tentativo di ristrutturare la tecnologia è destinato a fallire.

Ascolta l'edizione di questa settimana del podcast Floss Weekly , che copre SOA. Le descrizioni sono di livello piuttosto alto e non approfondiscono troppi dettagli tecnici (anche se esempi più concreti e riconoscibili di progetti SOA sarebbero stati utili.

Un'architettura applicativa tradizionale è:

• Un'interfaccia utente
• Materiale indefinito (implementazione) incapsulato / nascosto dietro l'interfaccia utente

Se si desidera accedere ai dati in modo programmatico, potrebbe essere necessario ricorrere allo screen-scraping.

Mi sembra che SOA sia un'architettura che si concentra sull'esposizione di dati e / o API leggibili dalla macchina, invece di esporre le interfacce utente.

SOA o Service-Oriented Architecture è un modello di architettura software in cui applicazioni o sistemi sono costruiti da servizi software sottostanti (e solitamente distribuiti) conformi a un insieme specifico di caratteristiche, vale a dire:

1. Basato su interfaccia, politica e contratto
2. Trasparenza della posizione
3. Autonomo
4. Astratto
5. riutilizzabile
6. Componibile
7. apolide
8. Scopribile
9. Estensibile
10. Debolmente accoppiato

L'obiettivo principale della SOA è l'agilità nello sviluppo del software, ovvero la capacità di rispondere al cambiamento in modo semplice ed economico, consentendo così alle aziende di rispondere rapidamente ai mercati in evoluzione.

I servizi sono tipicamente (ma non esclusivamente) implementati come servizi web, cioè operano sull'onnipresente protocollo HTTP web e sono implementati usando SOAP basato su XML o il paradigma REST leggero (e più popolare).

Dipende da chi sei!

Se sei un imprenditore, SOA è una soluzione per aumentare i tuoi guadagni e l'agilità aziendale. Se sei un architetto aziendale, SOA è un modo per disegnare un pezzo di software bello e pulito su una tela bianca. Se sei un architetto, SOA è la soluzione per progettare servizi liberamente accoppiati su una piattaforma di integrazione, per collegare semplicemente i servizi alle prese. Se sei uno sviluppatore SOA è un paradigma di programmazione in cui un servizio è al centro del design e del codice.

Dovresti leggere 100-SOA-Questions [pdf]

Saluti

Service Oriented Architecture (SOA) è uno stile di architettura software che crea applicazioni come una raccolta di parti collegabili, ognuna delle quali può essere riutilizzata da altre applicazioni.