Qual è la vera differenza tra l'ingegneria del software basata su componenti e l'architettura orientata ai servizi?
Clemens Szyperski e David Messerschmitt presentano i seguenti cinque principi che un componente software dovrebbe avere:
- Multiple-uso
- Non contesto-specifica
- Componibile con altri componenti
- incapsulato
- Un'unità di distribuzione e versioning indipendenti
Erl riconosce le seguenti caratteristiche per SOA:
- Accoppiamento lento: quantità minima di interdipendenze tra i servizi
- Contratto di servizio: l'interazione tra i servizi si basa su un Accordo di documentazione e documentazione
- Autonomia: i servizi controllano la logica che incapsulano.
- Astrazione: i servizi nascondono la loro logica interna dall'ambiente esterno eccetto quelle parti che sono descritte nel contratto di servizio.
- Riusabilità: la divisione della logica nei servizi favorisce il riutilizzo.
- Componibilità: i servizi possono essere assemblati da altri servizi
- Statelessness: quantità minima di informazioni specifiche sull'attività è memorizzata.
- Discoverability: l'esistenza di meccanismi di scoperta in modo che i servizi possano essere scoperto dai loro utenti
Un buon articolo è link
Aggiorna
Come hai notato, ci sono già domande su SOA che hanno una risposta. Ma la mia domanda è un po 'più specifica, perché cerca un confronto con l'ingegneria del software basata su componenti.
Una domanda simile alla mia è How L'architettura orientata ai servizi e lo sviluppo basato sui componenti sono in relazione tra loro?