Qual è la pratica comune per il targeting di server stranieri in Oracle WebLogic Server

Question

Stiamo cercando di trovare qualcosa che si avvicini a un modello semplice e diretto per il targeting delle risorse JMS in WebLogic (probabilità di grasso, lo so). Code e argomenti possono essere facilmente e in modo abbastanza intuitivo mappati ai server JMS in esecuzione sui server WebLogic, ma i server esterni e le risorse al loro interno sembrano un po 'più complicati.

In entrambi i server WLS 10.0 e 10.3 esterni, in primo luogo, non sono definiti accanto ai server JMS ma come membri di un modulo JMS. In secondo luogo, vengono targetizzati per impostazione predefinita alla destinazione del modulo JMS in cui sono definiti, ovvero un cluster WLS o server WLS, a differenza delle risorse "non straniere" destinate ai server JMS tramite sottodeployments.

Tuttavia, con il targeting avanzato è possibile anche indirizzare i server stranieri ai server JMS. Ciò si traduce in un modello molto più simmetrico rispetto alle risorse JMS straniere/"non-straniere".

Advanced Targeting http://dexter.xebialabs.com/Media/foreign_server_advanced_targeting.png

Quindi, le domande sono:

1. C'è qualche ragione al di là incidente storico perché Resource estera e di risorse “non-stranieri” targeting è così diverso (risorse estere per default in un WLS Cluster o server WLS rispetto alle risorse non estere dei server JMS)?
2. Esiste una prassi comune o migliore per il targeting di risorse straniere e non?
3. Ci sono dei motivi per cui non si vorrebbe indirizzare i server esterni ai server JMS tramite sottodeplianzi?

Grazie in anticipo!

Andrew Phillips

Answer 1

1) I server JMS esterni venivano definiti come componenti standalone, simili a connettori, bridge di messaggistica, ecc. Questi componenti (storicamente) indirizzano direttamente i server o i cluster di applicazioni invece di un componente intermedio come un server JMS.

Con le versioni successive, Oracle ha cercato di unire il JMS interno e quello esterno sotto un ombrello universale. Tuttavia, le opzioni target sono state mantenute diverse. Per fornire flessibilità con la parte JMS, sono state introdotte le distribuzioni secondarie. Sembra che Oracle abbia esteso le distribuzioni secondarie a Foreign Server per motivi di coerenza, rendendo le cose abbastanza complicate/disordinate.

io non lo chiamerei un incidente dal momento che le versioni più recenti continuano conformi a questa configurazione :)

2) Per le applicazioni distribuite attraverso i cluster, è necessario disporre di un singolo modulo JMS definito per l'intero cluster inorder . Più definizioni del tuo factory di connessione schiarirà il bilanciamento del carico JMS.

Le nostre best practice erano incentrate sullo standard di creazione di un singolo modulo JMS per cluster (o server di app se non era cluster) e quindi sulla creazione del server esterno e delle code/fabbriche di connessione JMS weblogic all'interno dello stesso modulo . Inoltre, avere buone convenzioni di denominazione per le distribuzioni secondarie e per i moduli JMS è molto importante.

3) I server esterni (in particolare con IBM MQ) possono avere un sacco di problemi complessi quando si eseguono> 16 MDB simultanei. Abbiamo evitato il Foreign Server -> JMS Server -> Managed Server per ridurre il livello aggiuntivo di astrazione/complessità inorder per mantenere la configurazione più semplice. Riduci anche il rischio che le eccezioni del tuo server esterno vengano mascherate da un'eccezione criptica del server JMS (non ho alcuna prova di ciò).

Un compagno di squadra una volta suggerì che il server straniero -> l'installazione del server delle applicazioni era più performante ma il team A di Oracle confermava che si trattava solo di un cambiamento logico/estetico e non avrebbe dovuto davvero importare.

Spero che questo aiuti!

Answer 2

Anche se io non sono un esperto in questo campo, la mia comprensione di questo argomento è stato questo: Il fondamento è stata la separazione di 'cosa' e 'come' le preoccupazioni in JMS-moduli e JMS -servers. I moduli JMS gestiscono i messaggi e le destinazioni e i server jms gestiscono il modo in cui questi messaggi vengono archiviati e consegnati.

Quando si tratta di server stranieri JMS, probabilmente questo diventa torbido. La risorsa è semplicemente una destinazione e "come" è teoricamente la preoccupazione del server straniero.