Approccio alla progettazione dei servizi: un'unica operazione generica e le relative implicazioni

3

L'argomento principale della nostra organizzazione è l'approccio alla progettazione dei servizi.

Primo approccio: il team desidera progettare servizi che hanno essenzialmente una sola operazione, possono prendere qualsiasi XML e restituire un messaggio XML di risposta. L'operazione e i parametri sono nel messaggio XML di richiesta. Una volta ricevuto il messaggio, il servizio determina l'azione / metodo richiesto. I motivi citati sono la facilità di implementazione e la flessibilità dell'introduzione di operazioni future.

Secondo approccio - Il secondo gruppo è inflessibile su contratti di servizio ben definiti e messaggi specifici. I motivi citati sono prestazioni migliori, convalida dei messaggi e controllo delle versioni. Questo è anche il mio approccio preferito.

Quali sono i pro e i contro? Ci possono essere delle difficoltà nell'introdurre un ESB più avanti nell'architettura se abbiamo scelto il primo approccio?

    
posta bcrier 03.01.2014 - 18:16
fonte

2 risposte

1

Servizi di progettazione richiesti logicamente dal dominio dell'applicazione , non designati artificialmente da un'architettura a priori astratta.

Alcuni avranno una semplice operazione e saranno apolidi, altri potrebbero essere più complessi.

Per quanto riguarda la scelta di un meccanismo di interfaccia, separa il formato del messaggio dai servizi e dai client usando il modello dell'adapter, in modo da non lavorare a maglia una camicia di forza sin dall'inizio;)

    
risposta data 03.01.2014 - 22:22
fonte
0

Con per servizi generici:

I servizi generici sono incubi da mantenere. Non puoi facilmente decifrare cosa sta succedendo. E sono difficili da testare poiché ci sono generici. Se il contratto è definito, posso usare uno strumento come SOAP UI per creare facilmente dei messaggi di test. Se generico, devo creare manualmente l'XML (potrei comunque usare l'interfaccia utente SOAP per inviarlo). Che schifo. Strike 1 per manutenibilità e 2 per testabilità.

Tutto con servizi generici entra come una stringa XML. Tutto ciò che non è una stringa deve essere lanciato o convertito nel tipo corretto. Per questo motivo saranno più lenti e consumeranno più risorse. L'analisi XML extra e il richiamo dinamico dei metodi dalle stringhe hanno un sovraccarico maggiore. Sciopero 3 per l'analisi, il cast e la conversione XML inutili e le prestazioni del servizio.

Ho realizzato un modello di dati e un servizio un po 'generici, una volta dove la parte (non tutta) del messaggio erano metadati ed era molto più difficile per le persone capire come i dati andassero e venissero fuori. Era flessibile ma alla fine probabilmente si sarebbe potuto utilizzare un contratto più esplicito poiché non ci sono state troppe aggiunte / modifiche che hanno sfruttato la sua flessibilità sin dall'inizio del servizio.

La pallottola d'argento di non dover mai più cambiare un sistema perché è generica non viene mai realizzata. È un sogno che esiste nella testa dell'architettura astronomica.

I servizi sono meglio serviti con contratti espliciti. Mi mandi X e ti restituirò Y come definito nel contratto. Posso pubblicare il mio contratto per i consumatori in modo che possano codificarlo e persino deriderlo prima del rilascio del servizio.

Il cambiamento accade, quindi la versione dei contratti di servizio. Non è un grosso problema per eseguire alcune versioni differenti del servizio sul tuo server web avendo URL diversi.

Un servizio generico per dominarli è meglio servirlo negli incendi di Mount Doom.

    
risposta data 03.01.2014 - 23:46
fonte

Leggi altre domande sui tag