Ecco una domanda piuttosto teorica e astratta: in che modo l'architettura orientata ai servizi (SOA) differisce dall'approccio basato sui componenti? Il concetto di SOA è un'estensione all'approccio basato sui componenti?In che modo l'architettura orientata ai servizi e lo sviluppo basato sui componenti sono in relazione tra loro?
Quali sono i tuoi pensieri? Forse conosci qualche buona carta che copre questo argomento?
I due concetti sono piuttosto ortogonali, né complementari né contraddittori. Se hai minacciato di infilare una forchetta arrugginita nei miei occhi e mi hai costretto a generalizzare, direi che lo sviluppo basato sui componenti era una tecnica per modellare e assemblare uno specifico software, dove SOA è una tecnica per organizzare sistemi separati in modo tale possono parlare tra loro.
come ho detto, una generalizzazione grossolana, ma è tutto quello che ho intenzione di dare, senza una domanda più specifica :)
Si potrebbe dire che SOA è una forma di alto livello di sviluppo basato su componenti, dove i componenti sono stati trasformati in parti riutilizzabili di funzionalità denominate servizi.
In this article gli autori vista sviluppo basato su componenti a supportare SOA - alla fine il vostro SOA necessita servizi da attuare e si progetta componenti come deliverable che forniscono l'implementazione. Alcune delle competenze sono quelle di ottenere la granularità e la coesione dei componenti giusti.
Credo che questa prospettiva rappresenti una ragionevole caratterizzazione di come la SOA venga effettivamente eseguita oggi. Per me la chiave è che ti concentri innanzitutto sui servizi, su ciò che devi fare in senso aziendale, poi in seguito sui design dei componenti. [Ecco uno article sull'identificazione dei servizi. Disclaimer: Sono una persona IBM, questi articoli sono scritti da colleghi.]
Tuttavia, se si riavvolge l'orologio penso che lo sviluppo basato sui componenti sia un approccio che precede la SOA e che abbia avuto molti gli stessi obiettivi di SOA. Considero eccessivamente cinica l'opinione che SOA sia solo una campagna pubblicitaria, che attacca nuove etichette su vecchi concetti. Tuttavia vi è una considerevole sovrapposizione tra CBD e SOA. Ho appena visto la SOA come la migliore saggezza collettiva che abbiamo finora su come fare l'integrazione, senza dubbio man mano che impareremo altre nuove tecniche emergeranno fino a quando il kitbag generale merita di nuovo un nuovo nome.
Il mio punto di vista personale è che la SOA ha preso slancio perché è emersa una serie di tecnologie che hanno consentito a team tecnici disparati all'interno di un'organizzazione (ad esempio una base IBM e base Microsoft) di creare componenti che potrebbero utilizzare i rispettivi servizi. In altre parole, è emerso un livello di maturità nel modo in cui i componenti sono emersi, in modo tale che una nuova etichetta (SOA) fosse attraente.
Sviluppo basato su componenti richiesto un repository di frammenti di codice (a volte stack di oggetti completi) generalmente in una sintassi di codice. Per essere utili su qualsiasi altra cosa, questi frammenti dovrebbero essere portati o richiamati attraverso un'interfaccia comune (ad esempio Windows API o COM, COM + e altri) tra VB6 & VC++ per esempio. Quindi le funzioni VC++ potrebbero essere utilizzate e chiamate da VB6. Di conseguenza, il riutilizzo dei componenti richiedeva a volte un intero lotto di refactoring da riutilizzare, il che era controintuitivo. C'era anche il problema del legame precoce e tardivo. I componenti del repository devono ancora essere costruiti e distribuiti come parte funzionante della base di codice per poter essere utilizzati. Il codice avrebbe dovuto essere sottoposto a test dell'unità prima di aggiungerlo al repository, ma necessitava ancora di test di integrazione per confermare la funzionalità. Dovresti anche costruire i parametri corretti per "attraversare l'interfaccia dell'oggetto". Di nuovo, questo codice wrapper generalmente richiesto.
Questi repository di codice potrebbero non includere tutto per essere veramente multipiattaforma. L'indipendenza dalla piattaforma è solitamente richiesta quando i problemi sono segmentati tra domini, specialmente nei sistemi integrati. L'interfaccia è inclusa nel software costruito e distribuito, non nel codice di funzionamento effettivo.
Quello che ti manca tra i due è un quadro. SOA non è CBDv2 né un'estensione ad esso, devi passare attraverso il framework di implementazione del servizio. Anche i quadri non sono un nuovo concetto.
Entrambi CBD & SOA alla fine promuovono il riutilizzo del codice. Il CBD è generalmente più ristretto rispetto alla SOA! SOA ha bisogno di un quadro per essere efficace, il CBD no. Il CBD è abbinato al suo linguaggio di sviluppo e alla piattaforma di destinazione.