L'architettura Mission Oriented Architecture (MOA) è un modo migliore per descrivere le cose rispetto a SOA?

0

Potrei sembrare un troll, ma mi piacerebbe capire seriamente questo più profondo. Il posto in cui lavoro ha iniziato a usare il termine MOA, rispetto a SOA, poiché riteniamo che dia più chiarezza e voglia di confrontarlo con i veri obiettivi di SOA.

Un'architettura orientata alla missione è un approccio in base al quale un'applicazione viene suddivisa in vari elementi di missione aziendale, con il database, le risorse dei file, la funzionalità batch e in tempo reale tutti strettamente accoppiati in termini di distribuzione di quella parte della funzionalità. La missione consente agli sviluppatori di concentrarsi su una specifica funzionalità per farlo correttamente e di costruirlo con la capacità per quel pezzo di scalare come entità indipendente all'interno dell'applicazione complessiva. Accoppiando strettamente i dati, le risorse del file e la logica di business, raggiungi gli obiettivi di lavorare su un problema molto grande nei pezzi di dimensioni del morso.

Alcune definizioni di SOA si mescolano con quella che è essenzialmente una chiamata di metodo su un servizio web rispetto a un vero "servizio". Come architetto, ho sempre trovato divertente mettere tutti sulla stessa pagina per quanto riguarda SOA.

È meglio definirlo una "missione" rispetto a un "servizio"?

    
posta Brian Langbecker 03.11.2013 - 04:47
fonte

2 risposte

4

Mi sembra una cattiva idea.

L'obiettivo principale di SOA è progettare la tua architettura intorno a servizi semplici, componibili, liberamente accoppiati che possono essere utilizzati per raggiungere non solo la tua "missione" corrente, ma anche il futuro "missioni" che possono emergere (come fanno sempre ....).

Se accoppieresti strettamente tutto intorno a una specifica "missione", allora sei appena tornato alla cattiva vecchia metodologia di costruire un nuovo stack software specifico per progetto, forse troppo ingegnerizzato e incompatibile per ogni applicazione. E probabilmente ti ritroverai presto a creare una rete disordinata di integrazioni point-to-point tra di loro quando emergeranno nuovi requisiti.

Ovviamente non c'è nulla di sbagliato nell'avere una "missione" di per sé - in realtà è un modo molto utile per rimanere concentrati su ciò che effettivamente crea valore. Ma non dovresti cadere nella trappola di strutturare l'architettura dell'applicazione attorno ad esso.

P.S. Non confondere SOA con "servizi web". Questo è un modo per implementare un servizio remoto, ma è perfettamente possibile fare SOA senza di essi. Ad esempio, è possibile implementare un modello di servizio liberamente accoppiato perfettamente con le interfacce Java in un processo JVM.

    
risposta data 03.11.2013 - 05:21
fonte
1

NO, non credo che dovresti spingere per cambiare la terminologia da SOA a MOA. A meno che tu non creda di convincere il mondo intero ad aggiornare tutti i riferimenti a SOA.

Hai ragione, quando dici che le persone che lavorano insieme devono usare una terminologia intesa come la stessa cosa per tutti. Nella tua mente, Mission Oriented Architecture sembra una scelta migliore, ma quando ho letto questa domanda ho pensato che stavi parlando di applicazioni che lanciano razzi sulla luna. Chiaramente se dovessi lavorare con te, non puoi ancora supporre che avrò la stessa interpretazione del termine che hai già.

SOA non è un termine con cui il tuo team o la tua azienda si sono inventati. Se vuoi che qualcuno venga istruito (non importa quanto sia divertente) in che cos'è SOA, puoi iniziare facendo in modo che leggano i link esterni:

Ma quando qualcuno si unisce al tuo team o un'azienda di terze parti si integra con te, otterrà questo:

  • link (è una coincidenza che in realtà ci sia una foto di un razzo su quella pagina Questo è stato solo uno dei migliori hit di Google che ho trovato dopo aver scritto le cose precedenti)
risposta data 03.11.2013 - 05:13
fonte

Leggi altre domande sui tag