Qual è il livello appropriato di granularità per i servizi in un'architettura distribuita o orientata ai servizi?

Un aspetto importante di SOA è che un servizio SOA è una merce o un prodotto. Questo non è un problema tecnico, ma un problema aziendale. Nello stesso modo in cui pianifichi un'applicazione, consideri le richieste dei clienti ecc.

Il sovraccarico di gestione di Business \ Product nello sviluppo di un servizio dovrebbe essere simile allo sviluppo di un'applicazione

Riguardo gli aspetti più "tecnici" della tua domanda.

• Un servizio può contenere più di una operazione, quindi di solito raggruppate le operazioni correlate in un unico servizio.
• Ci sono varie suite di software (ESB - Enterprise Service Bus) che consentono di gestire un ambiente con un gran numero di servizi - come la gestione di un repository di servizi, il routing centrale, ecc. - forse dovresti prendere in considerazione l'utilizzo di uno

Sembra davvero che tu abbia un qualche tipo di problema di stratificazione, granularità.

Gli endpoint a funzione singola si sentono in errore, a meno che non vi siano motivi validi per farlo - le diverse politiche di sicurezza potrebbero essere un fattore trainante, ma non sembrano giuste.

Se si finisce con troppi servizi come

FooMyObject
BarMyObject

Hai fatto poche ma estese chiamate di metodo attraverso il filo; che è probabile che sia lento dato il sovraccarico delle chiamate richieste.

Dovrebbe generalmente essere un valore aziendale non banale racchiuso dietro ogni chiamata remota per giustificare il sovraccarico. I protocolli troppo chiacchieroni non tendono a scalare bene, YMMV.

L'architettura distribuita non funziona con le parole d'ordine.

So what is SOA ... when does it make sense?

SOA è per le grandi aziende ed è un approccio per integrare un sistema back-end eterogeneo in un'unica infrastruttura ... Qualsiasi altra architettura di applicazione orientata ai servizi.

but this just feels wrong

Un servizio non è altro che un "modulo" o un gruppo di "moduli" che espone la sua interfaccia esterna in un modo che altre tecnologie possono interfacciare in modo affidabile. Per qualsiasi altra cosa non hai bisogno di un servizio.

Ho poco tempo a controllare Remobjects SDK per .NET. È un esempio un po 'più complesso e otterrai una comprensione più chiara della direzione in cui l'architettura può evolversi e quali parti sono infine necessarie - non c'è bisogno di prenderla - basta indagare. Questo è molto efficace.

L'applicazione sarà ancora un'applicazione, forse suddivisa in parti recitative autonome. Di sicuro dovrai decomporre la tua applicazione: separa i dubbi nella vista dominio.

Controlla il libro Modelli di integrazione aziendale: progettazione, costruzione e distribuzione di soluzioni di messaggistica vedrai che c'è molto di più oltre i semplici servizi.

Quello che stai cercando di ottenere è un CBA - Component Based Architecture. In pratica classifica i tuoi servizi e li aggiungi a un componente corrispondente. Fai riferimento a link

Ho già eseguito questo tipo di setup SOA. Ecco alcune cose a cui prestare attenzione:

• Versioning. Cosa succede quando hai 5 utenti diversi di un servizio e vuoi aggiungere un 6, ma il 6 richiede una funzionalità che gli altri 5 non hanno? Quindi ora hai bisogno di una nuova versione del servizio, ma questo significa che devi cambiare gli altri 5?
• Configurazione. Dovrai gestire molta configurazione "gunk" per indirizzare i consumatori dei servizi ai fornitori di servizi. È qui che aiutano alcuni prodotti SOA (ESB, ecc.). Ma ancora nella mia esperienza questa è sempre una sfida.
• Condivisione / coerenza delle conoscenze. A seconda della grandezza della tua squadra, può essere difficile mantenere la coerenza tra i diversi servizi. Uno sviluppatore potrebbe utilizzare un set di standard per il servizio A e un altro sviluppatore potrebbe utilizzare diversi standard per il servizio B. Inoltre, dato che più sviluppatori sono coinvolti, potrebbero iniziare a duplicare l'un l'altro senza saperlo, e si finiscono con due servizi diversi che fanno lievi variazioni sulla stessa funzionalità.

Non sto dicendo che SOA sia una cattiva idea. Ma devi adottarlo con gli occhi aperti alle sfide. Buona fortuna.

Ciò che stai creando è un'architettura orientata ai servizi. In una vera architettura distribuita, il limite che controlla la granularità è la latenza tra processi e non la funzionalità. L'obiettivo nella vera elaborazione distribuita è massimizzare il parallelismo (ad es. Il framework MapReduce di Google).

Con quanto sopra detto, dovresti cercare di mantenere le interfacce di servizio il più semplici possibile. In caso di dubbi, l'errore sul lato dell'interfaccia di servizio dovrebbe essere troppo semplice. Tutti i servizi complessi sono iniziati come servizi semplici che hanno funzionato.

Molte persone pensano che SOA sia focalizzata sull'integrazione delle applicazioni. Ma il basic, SOA è uno stile architettonico, in cui il sistema è stato progettato in un modo per dividere il servizio e il servizio che interagiscono tra loro. Proprio come OOP, è uno stile di software di sviluppo software attraverso la collaborazione tra gli oggetti.

Il servizio non era solo i componenti sono accessibili da remoto come WebService, Rest, RMI, ecc.

Ma il servizio è: Un servizio è l'autorità tecnica per una specifica capacità aziendale. Qualsiasi parte di dati o regola deve essere di proprietà di un solo servizio.

Ciò significa che anche quando i servizi pubblicano e si sottoscrivono gli uni agli altri, sappiamo sempre quale sia l'autorevole fonte di verità per ogni dato e regola.

Inoltre, quando guardiamo i servizi dalla lentezza delle capacità di business, ciò che vediamo è che molte interfacce utente presentano informazioni appartenenti a capacità diverse - il prezzo di un prodotto a prescindere dal fatto che sia disponibile o meno. Per consentirci di rispettare la suddetta definizione di servizi, ciò ci porta a capire che tali interfacce utente sono in realtà un mashup: ogni servizio ha il frammento dell'interfaccia utente che tratta i suoi dati particolari.

fonte: link

Per conoscere SOA, ti suggerisco di leggere la fonte dall'uomo di cui mi fido da tanto tempo, è Udi Dahan link