Utilizzo di XSLT per la messaggistica anziché gli oggetti di messaggio Java marshalling / unmarshalling

Question

Utilizzo di XSLT per la messaggistica anziché gli oggetti di messaggio Java marshalling / unmarshalling

#1 da (5 voti)
#2 da (4 voti)

2

Finora ho usato oggetti Java fatti a mano o generati (ad es. JAXB) come "gestori" per i messaggi nel software di elaborazione dei messaggi come i convertitori di protocollo. Ciò porta spesso a una noiosa programmazione, come copiare / convertire i dati dall'oggetto messaggio di un sistema a un'istanza dell'oggetto messaggio di sistema di un altro. E sicuramente porta un sacco di codice Java con getter e setter per ogni attributo di messaggio, codice di validazione, ecc.

Mi chiedevo se sarebbe una buona idea convertire il messaggio XML di un sistema in un altro formato di sistema - o persino convertire richieste in risposte dallo stesso sistema - usando XSLT. Ciò significherebbe che non avrei più bisogno di unmarshall XML stream per oggetti Java, copiare / convertire dati usando Java e marshallare l'oggetto messaggio risultante in un altro flusso XML.

Poiché ogni messaggio potrebbe effettivamente avere uno scopo, collegheremo il messaggio (e il carico utile che contiene nelle sue proprietà o elementi / attributi XML) alle funzioni EXSLT. Ciò cambierebbe il mio approccio al design da uno stile imperativo a uno dichiarativo.

Qualcuno l'ha già fatto prima e, in tal caso, quali sono le tue esperienze? La quantità ridotta di codice Java 'boiler plate' pesa sulla maggiore complessità di (E) XSLT?

java xml xslt

posta Joost van Stuijvenberg 21.06.2012 - 14:56

fonte

2 risposte

Leggi altre domande sui tag java xml xslt

Separazione contro segregazione Risolve un problema di sicurezza - ma poi tutti lo sanno

score 5 · Answer 1

usare XSLT per trasformare i messaggi è una tecnica molto comune che troverai supportata nella maggior parte dei framework ESB come Apache Camel, Mule, Spring Integration, Ikasan ecc.

Il compromesso è che XSLT può essere difficile da mantenere e può esserci una mancanza di flessibilità nel modello di programmazione che offre. Ho scoperto che dovrei spesso chiamare a un'origine dati per effettuare una ricerca o un POJO per eseguire qualche altra trasformazione complessa. Alla fine abbiamo usato XSLT solo per trasformazioni abbastanza semplici e altri componenti nel flusso ESB hanno fatto il resto.

C'è anche un costo di prestazioni in termini di esecuzione della trasformazione e la convalida in seguito. C'è una vasta gamma di librerie tra cui scegliere che eseguono la trasformazione e la convalida con caratteristiche di prestazione variabili (pensa alla memoria e agli impatti della CPU).

C'è un altro costo di serializzazione quando alla fine si trasforma nuovamente in un oggetto Java.

score 4 · Answer 2

XSLT può diventare davvero complicato molto velocemente

Avendo passato molto tempo a sopportare il dolore delle soluzioni XSLT scarsamente applicate, consiglierei strongmente contro di loro, a meno che le tue trasformazioni di mappatura non siano semplici come il cervello.

Preferirei piuttosto lavorare su un carico di POJO piuttosto semplici e ripetitivi che cercano di trovare un bug di trasformazione piuttosto che un violino infinito con costrutti esoterici XSLT.

Note a margine interessanti

Off topic, ma potrebbe essere degno di nota, è che è possibile aggiungere codice personalizzato abbastanza facilmente alle classi JAXB generate automaticamente utilizzando le tecniche descritte in questo articolo . Inoltre, questo articolo su Hypertext Application Language (HAL) contiene alcuni interessanti tecniche di bridging che utilizzano i tipi SAM, i contratti e tutte le funzioni guidate tramite Guava. Potrebbe rendere un lavoro noioso molto più interessante.