Questo è non un problema di architettura. È un problema di progettazione o di gestione.
Perché non puoi aggiungere nuove operazioni al servizio web? Questo è uno dei principali vantaggi di avere un servizio web. L'aggiunta di una nuova operazione è un cambiamento continuo e garantito. Quindi o c'è una politica sbagliata che ti impedisce esplicitamente di farlo (problema di gestione), una barriera tecnica per farlo (ad esempio nessun privilegio da ridistribuire - diversi tipi di problemi di gestione), o sei in qualche modo riuscito a rev-lock il tuo client applicazioni (grave problema di progettazione).
L'architettura va bene. Non c'è nulla che devi cambiare per supportare questo tipo di estensibilità. Se non puoi apportare modifiche al servizio web che è lì, quindi avvolgilo con uno che può cambiare e iniziare a usare quello da ora in poi.
Le richieste multiple sono, ancora una volta, un problema di progettazione. In particolare, è un problema di progettazione di messaggi. Normalmente non tentare di architettare l'intero sistema in modo da inviare letteralmente più richieste simultanee . Invece, progetti i tuoi servizi web attorno al "chunky interface" concept, al contrario dell'interfaccia "chatty" in stile RPC.
In poche parole, un'interfaccia complessa significa che esponi unità di lavoro a livello utente grossolane come operazioni. I tuoi contratti di servizio non dovrebbero assomigliare a "chiamate di metodo", dovrebbero apparire come attività . Ad esempio, invece di avere molte diverse operazioni (chatty) per modificare il numero di telefono di un singolo cliente, indirizzo postale, indirizzo e-mail, ecc., Si progetta un contratto (grosso) CustomerUpdateRequest che accetta una sequenza di clienti ed esegue tutti degli aggiornamenti in esso.
Quando progetti i tuoi messaggi in questo modo, non dovresti mai preoccuparti di qualcosa come raggruppare più richieste, perché non avrebbe alcun senso logico farlo. Non hai intenzione di raggruppare una richiesta di aggiornamento del cliente con una richiesta di spedizione perché non vi è alcun motivo per cui tali richieste vengano mai inserite esattamente nello stesso momento.
Non vedo alcuno scopo pratico nel tentativo di "isolare l'applicazione dal servizio web" - il servizio web è il tuo isolamento, dalle dipendenze della libreria, dalle dipendenze della piattaforma, dalle dipendenze di revisione, ecc. Un'orchestrazione motore o bus di servizio può fornire un livello più alto di astrazione, ma ciò non rimuove la dipendenza da contratti , solo endpoint . E a meno che tu non sia disposto a fare una seria riprogettazione (stiamo parlando, ad esempio, di riscrivere ogni applicazione e servizio per usare pub / sub e altri pattern di messaggistica asincroni), quindi ci sarà non avere alcun beneficio.
Hai già tutto ciò che ti serve per supportare più client. Ciò di cui hai bisogno è un processo di distribuzione migliore, un percorso di aggiornamento più chiaro e contratti di messaggistica più appropriati per un SOA. Per il ridimensionamento, se un servizio Web non è in grado di gestire il carico, utilizzare un servizio di bilanciamento del carico - i servizi Web dovrebbero essere comunque stateless.
Se la tua architettura diventa veramente grande - e intendo enorme , al punto in cui il tuo database e i suoi servizi sono iper-ottimizzati ma ci sono troppe transazioni che avvengono per in secondo luogo per tenere il passo - quindi si potrebbe prendere in considerazione l'implementazione di Comando-Query Separation . Ma non iniziare questo percorso a meno che non sei preparato a vederlo fino alla fine, perché non vedrai la maggior parte dei benefici finché non avrai completamente isolato le query dai comandi.