Best practice per la convalida di messaggi XML

Question

Best practice per la convalida di messaggi XML

#1 da (3 voti)
#2 da (1 voti)

4

Due sistemi comunicano tramite messaggi XML su una coda di messaggi e qualsiasi messaggio ricevuto deve essere convalidato per struttura, contenuto e logica aziendale prima di essere elaborato.

Uno schema XML offre convalida su struttura e contenuto con restrizione del tipo di dati, campi obbligatori, strutture di scelta e simili.

Ma ovviamente questo mi porta solo a metà strada. In un sistema al quale sto lavorando attualmente, eseguiamo la restante convalida deserializzando il messaggio in una struttura di oggetto e convalidando il contesto con una libreria di codici dedicata.

Il problema è che prima di tutto la convalida è in due posti diversi e si sovrappone un po 'poichè alcune validazioni possono essere fatte in entrambi i modi, e in secondo luogo mantenere il codice di validazione può diventare noioso.

C'è un modo migliore per farlo, qualsiasi procedura o strumento migliore là fuori?

validation xml

posta lox 16.03.2011 - 11:48

fonte

2 risposte

Leggi altre domande sui tag validation xml

Devi inviare email ai clienti una volta all'anno - il modo migliore per registrarli eventuali problemi con l'utilizzo di git in un ambiente CI?

score 3 · Answer 1

I tipi di dati e i campi obbligatori nello schema definiscono la struttura del documento XML e, a mio avviso, solo convalidano che il documento sia in effetti un "documento completo di tipo X". Se questa prima convalida fallisce, un tentativo di deserializzazione potrebbe fallire.

La seconda convalida potrebbe essere considerata un'applicazione o anche specifica del contesto, errori significherebbe "il tuo documento valido non contiene valori validi per l'applicazione (al momento)".

Se condividi questa visione, i due passaggi di convalida non avrebbero mai una sovrapposizione funzionale, forse solo tecnica.

score 1 · Answer 2

Vorrei avere solo un punto in cui eseguire la convalida e che sarebbe la serializzazione degli oggetti e la convalida aziendale. Dipende dalla soluzione, ma la preoccupazione di avere 2 parti simili di logica nelle differenze è ovvia. La seconda preoccupazione è che l'utilizzo della convalida dello schema potrebbe rendere la vostra integrazione più fragile e incline al fallimento nella produzione / manutenzione se mai doveste cambiare la struttura. Se non si utilizza la convalida dello schema, l'interfaccia è meno fragile e può accettare oggetti validi dal punto di vista aziendale / di dominio che altrimenti potrebbero fallire e richiedere modifiche di convalida dello schema.