Relazione tra SOA e OOA

Question

Relazione tra SOA e OOA

#1 da (7 voti)
#2 da (2 voti)

4

Thomas Erl definisce SOA come segue nel suo sito :

Service-oriented computing represents a new generation distributed computing platform. As such, it encompasses many things, including its own design paradigm and design principles, design pattern catalogs, pattern languages, a distinct architectural model, and related concepts, technologies, and frameworks.

Questo suona sicuramente come una categoria completamente nuova che è parallela all'orientamento agli oggetti. Quasi uno in cui ci si aspetterebbe che esista una lingua completamente nuova. Come C procedurale e C # orientato agli oggetti.

Ecco la mia comprensione: Nella vita reale, non abbiamo un linguaggio completamente nuovo per SOA. E la maggior parte delle applicazioni che hanno un'architettura SOA hanno un design orientato agli oggetti al di sotto di esso. SOA è una "strategia" per rendere l'intera applicazione / servizio distribuito e affidabile. SOA ha bisogno di OOPS al di sotto di esso.

È corretto? Dove si colloca SOA (se non del tutto) con pratiche di programmazione orientate agli oggetti?

Modifica: ho appreso attraverso le risposte che OOA e SOA funzionano tra loro e non possono essere confrontati (in un modo "che è meglio"). Ho cambiato il titolo in "Relazione tra SOA e OOA" piuttosto che "confronto".

language-agnostic object-oriented-design soa

posta TheSilverBullet 10.09.2012 - 12:11

fonte

2 risposte

2

Bene, penso che la tua domanda rientri nel dominio di questa domanda: Qual è il prossimo livello di astrazione?

Lì ho fatto un'indagine simile (nei commenti) su Aspect Oriented Programming, cioè un diverso livello di astrazione (diverso da OOP) o meno. La conclusione è stata che non lo è, è semplicemente un approccio diverso all'utilizzo di OOP. Penso che lo stesso valga per SOA. Le astrazioni di dati e algoritmi necessarie per qualcosa che potrebbe essere chiamata SOA sono praticamente le stesse di quelle usate per qualcosa che può essere catalogato come OOP. Continuando su questa idea, ciò di cui avresti bisogno per sviluppare meglio il software SOA sono le librerie e le strutture che trattano il codice della piastra di riscaldamento, piuttosto che una nuova lingua, e credo che sia così oggi, hai delle strutture come Mule ESB e Spring Framekwork .

Ecco un'interessante discussione sul modo diverso di assumere SOA e su come Spring ti aiuta con questo:

link

risposta data 10.09.2012 - 12:24

fonte

Leggi altre domande sui tag language-agnostic object-oriented-design soa

utilizzando metodi e classi statici Tag HTML personalizzati: ci sono delle specifiche che indicano un modo standard per gestirle?

score 7 · Accepted Answer

OOP è un paradigma di programmazione. SOA è un concetto di architettura di sistema. SOA può essere implementato usando il codice OO (o qualsiasi altro tipo di codifica, non importa). OOP può essere parte di un'architettura SOA o può essere utilizzato al di fuori di tale architettura. OO e SOA sono due concetti diversi (livello saggio). Potremmo ad esempio confrontare l'architettura basata su SOA con un'architettura non basata su SOA o confrontare OOP con Programmazione procedurale utilizzata in linguaggi come COBOL II. Tuttavia, confrontare SOA con OO non sarebbe valido.

SOA needs OOPS working underneath it.

Non sono d'accordo. OOP è facoltativo.

SOA is a "strategy" to make the entire application/service distributed and reliable

Vero (i puristi possono discutere sull'esattezza della formulazione però ...).

Modifica:

Ho aggiunto questa sezione in risposta al primo commento qui sotto:

Pensa a un servizio come una scatola nera. Il modo in cui il servizio è costruito internamente non è la tua preoccupazione (questa è generalmente una buona cosa). Ti concentri principalmente sul consumo del servizio tramite la sua API. Se lo fai tramite classi in un programma OO o anche tramite la richiesta URL sul browser come in questo esempio: collegamento , se si fa clic su questo collegamento Yahoo Finance otterrà un CSV file di informazioni di magazzino. Non era richiesta alcuna classe sul cliente. La magia è nascosta all'interno del servizio.

I framework come Microsoft WCF forniscono mezzi per comunicare con i servizi tramite metodi diversi e gestiscono molti dei dettagli necessari per creare un ambiente di servizio ricco. Potresti voler cercare maggiori dettagli su WCF.