Come arricchire una semplice applicazione SOAP di due endpoint per diventare di livello enterprise?

Naviga le tue risposte
4

Immagina di avere uno scambio di dati tra due endpoint (webservices o let's call URL). I dati possono viaggiare in qualsiasi modo (Xml, JSON, GET, POST) non importa.

Ho il codice sorgente del primo endpoint (l'ho disegnato a sinistra). Il secondo è di una terza parte e richiamerà la mia infrastruttura su un terzo endpoint (che è anche parte della mia infrastruttura).

Vorreiimplementarequalchesessione/statopermettereinrelazionelaprimachiamataconillorocallback.Inoltre,vorreiaggiungereloggingdistribuito,supportoperlarisoluzionedeiproblemiinunambientediproduzione,configurazione,monitoraggiodelleprestazioni,dashboardecosìvia.

Chetipodiconsiderazionedovreifareperaffrontarelaprogettazionediquestotipodiarchitettura?

Lasciatemichiarireconunesempio(cherispondealcommentodi@SparKot)

Dovreiregistrarelaprimachiamataecapireselaterzapartemistachiamandoomeno.

Possofarlosoloselamiaclassechiamante"di terze parti" (la casella bianca più in alto sul lef) e la classe chiamata da "terza parte" (la casella bianca più in basso sul lef) condivide un'infrastruttura di registrazione. Come implementeresti questo?

Le possibilità sono:

  • Condividi un database
  • Condividi una coda di messaggi
  • Condividi un servizio WCF
  • Condividi una cache AppFabric
  • Cos'altro?
  • Pipeline?

Quale considerazione prenderesti riguardo a questo servizio di tracciamento? La mia classe dovrebbe essere ospitata sullo stesso server? Che tipo di domanda ti spingerebbe a progettare l'architettura che trasforma due semplici richieste WebClient.Open in qualcosa che è più tracciabile e tollerante ai guasti?

    
posta Revious 11.02.2014 - 14:14
fonte

2 risposte

2

Analizzerei un'infrastruttura di logging condivisa come qualcosa di log ( link ) o logstash ( link ).

Se hai tutte le chiamate che generano un ID di richiesta per ogni chiamata e hai una conversazione per l'intera conversazione. Passa questi nelle intestazioni di ogni chiamata, ogni componente può registrare metriche, informazioni, errori ecc utilizzando questi ID. E puoi quindi estrarre informazioni utili dalla tua piattaforma di registrazione che ti consentiranno di approfondire ogni chiamata in dettaglio su entrambi i lati della chiamata (client e server).

    
risposta data 18.02.2014 - 17:16
fonte
1

Questa risposta è solo per documentare il primo sforzo che ho fatto per risolvere i problemi. Non è completo quindi non sarebbe la risposta accettata.

Tuttavia non c'è ancora un'altra risposta completa qui. Da allora spero che apprezzerai il mio impegno.

In realtà il codice è strutturato come nel primo progetto. Ma penso che non sia molto leggibile.

Problemi prima delle modifiche architettoniche

  • Il nome degli spazi dei nomi non sta dicendo nulla della responsabilità di ogni classe
  • È davvero utile dividere tra livello DAO e BLO un'architettura così piccola? Non c'è quasi nessuna logica.
  • La logica / responsabilità del BLO non è identificabile dai nomi di classe / metodi / spazio dei nomi
  • Che cos'è UserType? Lo spazio dei nomi non lo raggruppa con nessun'altra classe ..
  • La classe Config è un buon nome per me poiché identifica una funzionalità. Ma è l'unica classe con uno scopo preciso specificato dal suo nome.
  • Get3rdPartyUrl e l'accesso (a quell'URL) potrebbero essere messi insieme in una stessa classe, mentre InitializeConfigValue e ParseErrorMessage potrebbero essere inseriti in un'altra classe della Guida.

Il contatto con una 3rdParty WS è riutilizzabile. Tutto dovrebbe ereditare da un'unica interfaccia che definisce anche la registrazione.

Design della classe prima del refactoring

Designdellaclassedopoilrefactoring

    
risposta data 31.03.2014 - 14:11
fonte

Leggi altre domande sui tag

Organizzazione per funzione aziendale rispetto a funzione tecnica Organizzazione delle funzioni collegate DLL