Domanda Orientamento al servizio rispetto all'orientamento agli oggetti: possono coesistere?


C'è stato un grande interesse in Architettura orientata ai servizi (SOA) presso la mia azienda di recente. Ogni volta che cerco di vedere come potremmo usarlo, mi imbatto sempre in un blocco mentale. crudamente:

  • L'orientamento all'oggetto dice: "mantieni dati e metodi che manipolano i dati (processi di business) insieme";

  • L'orientamento al servizio dice: "mantieni il processo aziendale nel servizio e passa i dati ad esso".

I precedenti tentativi di sviluppare SOA hanno finito per convertire il codice orientato agli oggetti in strutture di dati e procedure separate (servizi) che li manipolano, il che sembra un passo indietro.

La mia domanda è: quali modelli, architetture, strategie, ecc. consentono a SOA e OO di lavorare insieme?


Modificare: Le risposte che dicono "OO per interni, SOA per i confini del sistema" sono grandiose e utili, ma non è proprio quello che stavo ottenendo.

Diciamo che hai un Account oggetto che ha chiamato un'operazione commerciale Merge che lo combina con un altro account. Un tipico approccio OO sarebbe simile a questo:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

Mentre l'equivalente SOA che ho visto assomiglia a questo:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

Nel caso OO la logica del business (e la consapevolezza dell'entità grazie a un pattern ActiveRecord) vengono elaborate nel Account classe. Nel caso SOA il Account l'oggetto è in realtà solo una struttura, dal momento che tutte le regole aziendali sono nascoste nel servizio.

Posso avere classi ricche, funzionali e servizi riutilizzabili allo stesso tempo?


37
2018-01-14 12:43


origine


risposte:


Penso davvero che SOA sia utile solo per le interfacce esterne (in generale, per quelle esterne alla tua azienda), e anche in questo caso, solo nei casi in cui le prestazioni non contano davvero, non hai bisogno della consegna ordinata dei messaggi.

Alla luce di ciò, penso che possano coesistere. Mantieni le tue applicazioni funzionanti e comunicanti utilizzando la filosofia OO e solo quando sono necessarie interfacce esterne (di terze parti), esponile tramite SOA (questo non è essenziale, ma è unidirezionale).

Sento davvero che SOA è abusato, o almeno le architetture con SOA vengono proposte troppo spesso. Non conosco davvero grandi sistemi che utilizzano SOA internamente, e dubito che potrebbero. Sembra più una cosa che potresti semplicemente usare per fare mashup o semplici richieste di previsioni del tempo, non costruire sistemi seri in cima.


10
2018-01-14 12:55



La mia opinione è che SOA possa essere utile, a livello macro, ma probabilmente ogni servizio sarà ancora abbastanza grande da richiedere diversi componenti interni. I componenti interni possono beneficiare dell'architettura OO.

L'API SOA dovrebbe essere definita con maggiore attenzione rispetto alle API interne, poiché si tratta di un'API esterna. I tipi di dati passati a questo livello dovrebbero essere il più semplici possibile, senza logica interna. Se esiste una logica che appartiene al tipo di dati (ad esempio, la convalida), dovrebbe preferibilmente essere presente un servizio incaricato di eseguire la logica sul tipo di dati.


10
2018-01-14 13:08



SOA è una buona architettura per comunicare tra sistemi o applicazioni.

Ogni applicazione definisce un'interfaccia "di servizio" che consiste delle richieste che gestirà e degli obiettivi previsti.

I punti chiave qui sono servizi ben definiti, con un'interfaccia ben definita. Il modo in cui i tuoi servizi sono effettivamente implementati è irrilevante per quanto riguarda la SOA.

Quindi sei libero di implementare i tuoi servizi con tutte le ultime e migliori tequio OO, o qualsiasi altra metodologia che funzioni per te. (Ho visto casi estremi in cui il "servizio" è impiantato da umani reali che immettono dati su uno schermo - ma tutto era ancora un libro di testo SOA!).


10
2018-01-14 13:14



Penso che questo sia un fraintendimento dell'orientamento agli oggetti. Anche in Java, i metodi generalmente non fanno parte del oggetti ma dei loro classe (e anche questa "appartenenza" non è necessaria per l'orientamento agli oggetti, ma questa è una materia diversa). Una classe è solo una descrizione di un tipo, quindi questa è davvero una parte del programma, non dei dati.

SOA e OO non si contraddicono a vicenda. Un servizio può accettare dati, organizzarli in oggetti internamente, lavorare su di essi e infine restituirli nel formato desiderato.


4
2018-01-14 13:32



Ho sentito James Gosling dire che si potrebbe implementare SOA in COBOL.

Se leggi la descrizione di Alan Kay delle origini di OOP, descrive un gruppo di piccoli computer che interagiscono per eseguire qualcosa di utile.

Considera questa descrizione:

La tua X dovrebbe essere composta da Ys. Ogni Y dovrebbe essere responsabile di un singolo concetto e dovrebbe essere completamente descrivibile in termini di interfaccia. Una Y può chiedere ad un'altra Y di fare qualcosa tramite uno scambio di messaggi (secondo le loro interfacce specificate).

In alcuni casi, una X può essere implementata da una Z, che gestisce in base alla sua interfaccia. A X non è consentito l'accesso diretto a un'altra X's Z.

Penso che le seguenti sostituzioni siano possibili:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

Se si pensa principalmente in termini di incapsulamento, occultamento delle informazioni, accoppiamento lento e interfacce black-box, c'è parecchia somiglianza. Se vieni impantanato nel polimorfismo, nell'eredità, ecc. Stai pensando alla programmazione / implementazione invece dell'architettura, IMHO.


4
2018-01-14 13:35



Se consenti ai tuoi servizi di ricordare lo stato, allora possono essere considerati come oggetti grandi con un tempo di chiamata possibilmente lento.

Se non sono autorizzati a mantenere lo stato, sono proprio come hai detto tu - operatori di dati.

Sembra che tu possa suddividere il tuo sistema in troppi servizi. Hai scritto, criteri di comune accordo su come dividere?

Adozione della SOA non significare buttare via tutti i tuoi oggetti ma si tratta di dividere il tuo sistema in grossi pezzi riutilizzabili.


3
2018-01-14 14:01