Erweiterte Verbindungsmöglichkeiten und anwendungsspezifische Settings für EJB-Clients

Pimp your EJB-Client

Wolf-Dieter Fink


Die im vorangegangenen Artikel [1] vorgestellten Verbindungsmöglichkeiten haben keinen Einfluss auf die Selektion der Server. Alles wird über den Identifier der EJB geregelt. Clients, die aus verschiedenen Gründen, wie Lastverteilung oder Anwendungsdaten, Einfluss auf die Selektion benötigen, müssen entsprechende Mechanismen implementieren, um das Verhalten an die eigenen Bedürfnisse anzupassen.

ArtikelserieTeil 1: Verbindungsmöglichkeiten und Unterschiede zu früheren VersionenTeil 2: Komplexe Szenarien und NodeSelectoren

Ändern der EJB-Selektion ohne Cluster

Wird kein Cluster Context verwendet – das ist der Fall, wenn die EJBs nicht als @Clustered annotiert sind, der Server nicht in einer Cluster-Konfiguration läuft oder die Konfiguration des Clients falsch ist –, so kann durch Angabe der voll qualifizierten Klasse mit der Property deployment.node.selector (Listing 1) die Default-Implementierung (RandomDeploymentNodeSelector) ausgetauscht werden. Die Klasse muss org.jboss.ejb.client.DeploymentNodeSelector implementieren. Die Methode selectNode(...) erhält eine Liste der Namen von ­Nodes, die die gewünschte EJB bereitstellen, und muss den Namen einer dieser Nodes zurückliefern. Es wird immer die gleiche Instanz des Selektors verwendet, sodass die Implementierung Multi-Thread-fähig sein muss.

Listing 1remote.connections=one, two, ...remote.connection.one.host=host1remote.connection.one.port=4447remote.connection.two.host=host2remote.connection.two.port=4447...deployment.node.selector=

Die Liste der verfügbaren Nodes enthält nur diejenigen Ziele, die auch in der Lage sind, den Request für diese Kombination aus Anwendung/Modul/Distinct-Name zu bearbeiten. Die Auswahl einer Node aus dieser Liste kann dann anhand der übergebenen Namen oder einer internen Implementierung vorgenommen werden.

Es wäre zum Beispiel möglich, eine Konfiguration auf dem Client zu hinterlegen, wie die Anzahl der Requests auf die verschiedenen Nodes verteilt werden sollen, um eine unterschiedliche Leistungsfähigkeit der Server berücksichtigen zu können.

Weiterhin kann mittels einer Implementation, die einen ThreadLocal verwendet, die Auswahl bei Multi-Thread-Clients eingeschränkt werden. In Listing 2 ist ein Beispiel eines Selektors zu sehen, der anhand eines Namens-Patterns die Auswahl Thread-spezifisch einschränken kann.

Listing 2public class PatternNodeSelector implements DeploymentNodeSelector { private static ThreadLo...

Erweiterte Verbindungsmöglichkeiten und anwendungsspezifische Settings für EJB-Clients

Pimp your EJB-Client

Wolf-Dieter Fink


Die im vorangegangenen Artikel [1] vorgestellten Verbindungsmöglichkeiten haben keinen Einfluss auf die Selektion der Server. Alles wird über den Identifier der EJB geregelt. Clients, die aus verschiedenen Gründen, wie Lastverteilung oder Anwendungsdaten, Einfluss auf die Selektion benötigen, müssen entsprechende Mechanismen implementieren, um das Verhalten an die eigenen Bedürfnisse anzupassen.

ArtikelserieTeil 1: Verbindungsmöglichkeiten und Unterschiede zu früheren VersionenTeil 2: Komplexe Szenarien und NodeSelectoren

Ändern der EJB-Selektion ohne Cluster

Wird kein Cluster Context verwendet – das ist der Fall, wenn die EJBs nicht als @Clustered annotiert sind, der Server nicht in einer Cluster-Konfiguration läuft oder die Konfiguration des Clients falsch ist –, so kann durch Angabe der voll qualifizierten Klasse mit der Property deployment.node.selector (Listing 1) die Default-Implementierung (RandomDeploymentNodeSelector) ausgetauscht werden. Die Klasse muss org.jboss.ejb.client.DeploymentNodeSelector implementieren. Die Methode selectNode(...) erhält eine Liste der Namen von ­Nodes, die die gewünschte EJB bereitstellen, und muss den Namen einer dieser Nodes zurückliefern. Es wird immer die gleiche Instanz des Selektors verwendet, sodass die Implementierung Multi-Thread-fähig sein muss.

Listing 1remote.connections=one, two, ...remote.connection.one.host=host1remote.connection.one.port=4447remote.connection.two.host=host2remote.connection.two.port=4447...deployment.node.selector=

Die Liste der verfügbaren Nodes enthält nur diejenigen Ziele, die auch in der Lage sind, den Request für diese Kombination aus Anwendung/Modul/Distinct-Name zu bearbeiten. Die Auswahl einer Node aus dieser Liste kann dann anhand der übergebenen Namen oder einer internen Implementierung vorgenommen werden.

Es wäre zum Beispiel möglich, eine Konfiguration auf dem Client zu hinterlegen, wie die Anzahl der Requests auf die verschiedenen Nodes verteilt werden sollen, um eine unterschiedliche Leistungsfähigkeit der Server berücksichtigen zu können.

Weiterhin kann mittels einer Implementation, die einen ThreadLocal verwendet, die Auswahl bei Multi-Thread-Clients eingeschränkt werden. In Listing 2 ist ein Beispiel eines Selektors zu sehen, der anhand eines Namens-Patterns die Auswahl Thread-spezifisch einschränken kann.

Listing 2public class PatternNodeSelector implements DeploymentNodeSelector { private static ThreadLo...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang