Referenzierung von EJBs mit JNDI im WebLogic Server Whitepaper

Transkript

1 esentri AG Pforzheimer Straße 132 DE Ettlingen Tel +49 (0) 7243 / Fax +49 (0) 7243 / info@esentri.com esentri.com Referenzierung von EJBs mit JNDI im WebLogic Server Whitepaper

2 Agenda Agenda... 2! Einleitung... 3! Vorwort... 3! Glossar... 4! 1 Enterprise Java Beans... 5! 1.2 EJB Allgemein... 5! Entity Beans... 5! Message-Driven Beans... 6! Session Beans... 6! 1.3 Referenzierung der EJB... 6! remote... 6! lokal... 6! 1.4 EJB Annotationen... 7! 7! 7! Deployment Descriptor... 8! 2 Java Naming and Directory Interface (JNDI)... 10! 2.1 Namensrichtlinien... 11! 2.2 Context und InitialContext... 15! Context erzeugen... 15! Lookup ausführen... 16! Manueller Lookup VS. Dependency Injection... 16! 3 Anwendungsszenarien... 17! 3.1 Lookup einer EJB im Java EE 6 Namensraum über einen Java SE Client... 20! 3.2 Lookup einer EJB mit mappedname über einen Java SE Client... 21! 3.3 Lokale Referenz von EJBs im selben Modul über DI... 22! 3.4 JNDI Lookup innerhalb eines Moduls (JAR)... 24! 3.5 JNDI Lookup innerhalb einer Applikation (EAR)... 24! 3.6 E2E Call, applikationsübergreifend (mehrere EAR)... 25! 3.7 Zugriff auf eine EJB mit mehreren Interfaces... 26! 3.8 Aufruf einer EJB über ein Servlet und JSP... 28! 4 Lookup im WebLogic Cluster... 30! 4.1 Zugriff auf WebLogic Cluster... 30! 4.2 Load Balancing... 31! Round Robin... 31! Weight-Based... 31! Random... 32! Serveraffinität... 32! 4.3 Failover... 35! Failover Detection... 35! Replica-Aware Stubs... 35! 4.4 Anwendungsfälle im Cluster... 36! externer Client... 36! clusterinterne Lookups... 38! 5 Best Practices & Empfehlungen... 39! Abbildungsverzeichnis... 41! Quellen... 42! 2

3 Einleitung Vorwort Ziel des Whitepapers ist die Erläuterung wie die Referenzierung von EJBs mit JNDI im WebLogic Server funktioniert. Darüber hinaus werden die verschiedenen Möglichkeiten erklärt und Empfehlungen für deren Einsatz aufgezeigt. Beim Lesen des Dokumentes wird Java EE Knowhow vorausgesetzt. Beim Deployment im WebLogic Server wird eine EJB mit einem Namen im Naming Service registriert. Um auf eine Instanz dieser EJB zugreifen zu können, wird mit dem JNDI-Interface auf den Naming Service zugegriffen dieser Vorgang wird als Lookup bezeichnet. Dieses Whitepaper soll den Lesern einen Überblick über die Möglichkeiten eines Lookups auf EJB nach Java EE 5 und 6 Konventionen bieten. Es wird ebenfalls aufgezeigt, wie der Vorgang im Cluster inklusive Failover-Betrachtung aussieht. Im ersten Kapitel wird eine Einführung Enterprise Java Beans gegeben sowie die Unterschiede zwischen den lokalen und remote Interfaces beschrieben. Das zweite Kapitel beschäftigt sich mit JNDI, was es mit den Namensräumen auf sich hat, wie JNDI verwendet und wie im WebLogic Server damit umgegangen werden kann. Einige Anwendungsfälle im Bezug auf die Verwendung von JNDI mit den unterschiedlichen Namensräumen werden im dritten Kapitel aufgezeigt. Das vierte Kapitel umfasst die Funktionsweise von JNDI im Cluster und beschreibt das Verhalten und den Einsatz des JNDI in einem WebLogic Cluster unter der Berücksichtigung von Load Balancing und Failover-Szenarien. Abschließend werden Best Practices im Umgang mit Referenzen auf EJB im Java EE ausgesprochen und sollen dem Leser als Hilfestellung dienen. 3

4 Glossar Dieses Kapitel behandelt häufig auftretende Begriffe und Abkürzungen, welche in diesem Dokument verwendet werden. Abkürzung Begriff Erläuterung API Application Programming Interface Eine bereitgestellte Programmierschnittstelle, über welche ein System in andere Programme integriert werden kann DD Deployment Descriptor XML-Konfigurationsdatei mit Informationen für das Deployment (z.b. Referenzen auf benötigte Ressourcen) DI Dependency Injection Konzept zur Auflösung von Abhängigkeiten zur Laufzeit DMI Direct Method Invocation Die Methode eines lokalen Objektes wird direkt (nicht über einen Stub) aufgerufen (vgl. RMI) EAR Enterprise Archive Applikationscontainer für JAR und WAR EE Enterprise Edition Java EE; Javaspezifikation für Businessapplikationen EIS Enterprise Information System Java EE Jargon für die Datenhaltungsschicht (z.b. Datenbank, ERP System,...) EJB Enterprise Java Bean Java EE Standard; Java Klassen zur Umsetzung von u.a. Transaktionen und Geschäftslogik in mehrschichtigen Enterprise Applikationen ERP Enterprise Resource Planning Software für Ressourcenmanagement (z.b. Personal, Rohstoffe, Lieferungen,...) IIOP Internet Inter-ORB Protokoll zur Kommunikation verteilter Objekte Protocol JAR Java Archive Mit Metadaten angereicherte ZIP-Datei, welche mehrere Javaklassen enthalten kann JDBC Java Database Connectivity Datenbankschnittstelle für relationale Datenbanken auf der Java Plattform JNDI Java Naming and Directory Interface Eine SPI für Namens- und Verzeichnisdienste; Objekte und Daten können über einen Namen registriert und abgerufen werden JVM Java Virtual Machine Teil der Java Laufzeitumgebung; exekutiert Java Bytecode LB Load Balancing Verfahren zur Lastverteilung auf Servern RMI Remote Method Invocation Aufruf einer Methode eines entfernten (Java) Objektes; ein Stub als Proxy kümmert sich um den Transport durch das Netzwerk SPI Service Provider Interface API im Java EE Umfeld, welches von Dienstanbietern implementiert und zur Verfügung gestellt wird WAR Web Archive Eine JAR mit Ressourcen für Webapplikationen (u.a. Servlets, JavaServer Pages,HTML,JavaScript,..) WLS WebLogic Server Applikationsserver von Oracle 4

5 1 Enterprise Java Beans 1.2 EJB Allgemein In klassischen Java EE Applikationen (siehe Abb. 01) wird die Geschäftslogik in EJBs gekapselt. Diese sind Java Klassen, welche über Annotationen im Sourcecode oder Deployment Deskriptoren (XML-Dateien) konfiguriert werden. EJBs bieten ein lokales und remote-interface an, welche von Clients für den Zugriff auf die EJB verwendet werden. Abb. 1: Übersicht über die Java Enterprise Edition Architektur Wenn die EJB auf dem Server deployed wird, so wird ihre Position mit einem Namen im Naming Service registriert. Über das Java Naming and Directory Interface ist es dem Client dann möglich, den Aufenthaltsort der EJB zu ermitteln. Das JNDI greift hierbei auf ein Factory Object zu, eine Art Fabrik für die aufgerufene EJB. Diese Fabrik generiert eine Instanz der EJB, sodass der Client über RMI auf deren Funktionalitäten und die darunterliegenden Daten zugreifen kann. Die Java EE Umgebung definiert eine Reihe von Schnittstellen, welche bestimmte Funktionsbereiche z.b. Webanwendungen, Datenbankzugriff etc. umfassen. Ein Application Server muss diese Schnittstellen konform zur Spezifikation implementieren. Diese Schnittstellen werden als SPI bezeichnet. Das JNDI ist ebenfalls ein SPI, weshalb sich der Einsatz des JNDI in Funktionsumfang oder Funktionsweise unter den verschiedenen Providern unterscheidet. Dieses Whitepaper geht dabei auf die JNDI Implementierung und Funktionsweise des WebLogic Server von Oracle ein. Grundsätzlich existieren drei Arten von EJBs: Entity Beans, Message-Driven Beans und Session Beans Entity Beans Die Entity EJB repräsentieren Geschäftsdaten bzw. Objekte aus einer Datenquelle, meist einer Datenbank oder ERP System. Diese Geschäftsobjekte sind stellvertretend für die im Geschäftsprozess manipulierten Daten. Die Bean stellt Methoden zur Manipulation der Daten (Lese- und Schreibzugriffe) bereit. Zusammen mit Session Beans stellen sie die Geschäftsfunktionalitäten zur Verfügung. Seit Java EE 5 (EJB 3.0) sind Entity Beans als obsolet deklariert. Als Alternative steht die Java Persistance API (JPA) zur Verfügung, welche als eigene Java EE Spezifikation als Nachfolger von Entity Beans gelten. Aus diesem Grund werden Entity Beans in diesem Dokument nicht näher berücksichtigt. 5

6 1.1.2 Message-Driven Beans Message-Driven Beans bieten die Möglichkeit, Nachrichten asynchron zu versenden oder zu empfangen. Jede Message-Driven Bean ist hierbei an eine bestimmte Message Queue gebunden. Jedes Mal wenn eine Nachricht an dieser Message Queue ankommt wird diese an eine Instanz dieser Message-Driven Bean geliefert Session Beans Session Beans umfassen im Wesentlichen eine Reihe von Geschäftsfunktionen respektive Methoden, welche über eine synchrone API zur Verfügung gestellt werden. Sie abstrahiert die Komplexität der Geschäftslogik gegenüber dem Client. 1.3 Referenzierung der EJB Um die angebotene Funktionalität einer EJB verwenden zu können, stellt die Bean ein Interface zur Verfügung. Dieses Interface kann abhängig von der Nutzung und dem Deployment der EJB als lokal oder remote deklariert werden. In diesem Kapitel werden die wesentlichen Unterschiede dieser beiden Zugriffsmethoden aufgezeigt. Ebenfalls wird die Möglichkeit in Erwähnung gezogen das Interface als Hybrid (lokal und remote) zur Verfügung zu stellen und welche Konsequenzen sich daraus ziehen lassen. Die Interfaces (lokal wie remote) werden ausschließlich von Session und Entity EJBs verwendet remote Der Zugriff auf EJB in einem verteilten System geschieht über die RMI (Remote Method Invocation). Hierbei ist es möglich, Funktionalitäten von EJB eines anderen Applikationsservers respektive eines anderen Clusterknotens aufzurufen. Die meisten Applikationsserver nehmen hierbei weitere Optimierungen für den Fernzugriff ) vor. Obwohl lokale EJB ebenfalls über das Remote Interface einen Zugriff auf andere EJB erhalten können, wird davon abgeraten. Remote EJB generieren einen größeren Overhead, da beim Aufruf die Argumente serialisiert werden müssen, damit sie über das Netzwerk transportiert und anschließend wieder ausgelesen werden können. Per Default verwendet der Applikationsserver eine pass-by-value Semantik. Hierbei werden die Argumente kopiert, bevor sie an die EJB Komponente gesendet werden, auch wenn sie sich auf derselben JVM befinden lokal Wenn der Client sich auf derselben JVM befindet wie die EJB, so kann auf diese über ein lokales Interface ) mittels DMI zugegriffen werden. Befindet sich der Client hingegen nicht auf demselben Applikationsserver, so wird über das Remote Interface auf die EJB zugegriffen. Die Nutzung von lokalen Interfaces kann ebenfalls von Vorteil sein, wenn mehrere Beans voneinander abhängig sind und oft miteinander kommunizieren. Um eine bessere Performance zu gewährleisten sollte wenn möglich ein lokales Interface zur Verfügung gestellt werden, falls die EJB Komponenten lokal in derselben JVM liegen. Lokale Aufrufe folgen der pass-by-reference Semantik und sind performanter als die Remote Variante. Es sollte daher anstatt der für remote Zugriffe vorbehaltenen pass-by-value Semantik eher die pass-by-reference Semantik angestrebt werden. Die Argumente welche über diese Semantik übertragen werden müssen als Referenz und nicht als Wert übergeben werden. 6

7 1.4 EJB Annotationen Neben den gängigen Annotationen um den Zugriff auf das Bean Interface als remote oder lokal zu deklarieren bieten sich dem Entwickler weitere Möglichkeiten. Die EJB Annotation wird verwendet, um eine Abhängigkeit zu einer anderen EJB anzugeben. Die referenzierte EJB kann über den lokalen Kontext der referenzierenden EJB aufgerufen werden. Parameter name beaninterface beanname mappedname description Beschreibung Gibt den Namen an unter welchem JNDI Namen die Bean im Komponentennamensraum (java:comp/env) gefunden werden kann. Spezifiziert das Interface der referenzierten Bean (notwendig bei mehreren implementierten Interfaces); Standardwert ist Object.class. Gibt den Namen der referenzierten EJB an. Entspricht dem name Attribut der Annotation. Die EJB lässt sich über ihren globalen JNDI mappedname Namen referenzieren. Dieses Attribut ist produktspezifisch. Eine Beschreibung der EJB Referenz. WebLogic initialisiert automatisch die annotierte Variable mit der Referenz über Dependency Injection. public<class<bluebean<implements<friend{< Im Falle von Unklarheiten können die Attribute beanname, beaninterface oder mappedname verwendet werden um die abhängige EJB explizit zu benennen. Die Verwendung von mappedname sollte mit Bedacht erfolgen, da dieses Attribut herstellerspezifisch ist. Mit diesen Annotationen wird angegeben, ob eine Session Bean stateful oder stateless ist. Diese Annotationen markieren die EJB als Session Bean, sodass der EJB Container diese Bean entsprechend konfiguriert und sich um das Transaktionsmanagement kümmert. Parameter name mappedname description Beschreibung Gibt den Namen an unter welchem die Bean im JNDI hinterlegt ist Definiert im WebLogic JNDI root einen globalen JNDI Namen namens bluesclues, unter welchem die Bean gefunden werden kann Eine Beschreibung der Session Bean public<class<bluebean<implements<friend{< Im oberen Beispiel wurde die EJB unter dem Namen Blue im JNDI Tree hinterlegt. Die Bean kann im Namensraum unter diesem Namen gefunden werden, z.b. java:global/appname/modulename/blue. Da ein mappedname angegeben wurde, lässt sich die Bean auch direkt über diesen Namen im JNDI Tree zu finden. Es gilt hier zu beachten dass mappedname stets providerspezifisch ist. Nicht alle Applikationsserver unterstützen jedoch den Gebrauch dieses Parameters und bieten untereinander wenig Portabilität. In WebLogic wird ein Lookup auf ein mit mappedname gebundenes Objekt über ein Hashtag, gefolgt von der vollständigen Interfacebezeichnung, ausgeführt. Die Form des Lookup folgt dabei einer strengen Richtlinie und setzt sich folgendermaßen zusammen: <mappedname>#<fully.qualified.interface.name>5 7

8 Beispiel: Der mappedname ist bluesclues, das verwendete Interface namens BlueManGroupCall liegt im Package com.acme.blue, dann wäre der Lookup: Object<obj<=<ctx.lookup( bluesclues#com.acme.blue.bluemangroupcall );<< Deployment Descriptor Der Deployment Descriptor ist eine XML-Konfigurationsdatei zur Verwaltung von EJB und deren Abhängigkeiten. Vor Version 3.0 war es notwendig, die EJB Definition in ihnen einzutragen. Sie zeigte den Zusammenhang zwischen den Bean-Implementierungen und den Interfaces. Bis zur Version 3.0 konnte eine EJB ausschließlich über einen Deployment Descriptor konfiguriert werden. Mit Beginn der Version 3.0 können die meisten Konfigurationseinstellungen über Annotationen beschrieben werden. Der umgekehrte Fall gilt ebenfalls: Einträge im Deployment Descriptor können Annotationen ersetzen. Wichtig ist hierbei zu beachten, dass die Einträge über Annotationen und über den DD durchaus unterschiedliche Werte besitzen können. In diesem Fall wird die Konfiguration des DD die Annotation in der EJB beim Deployment bevorzugt. Im Deployment Descriptor ejb-jar.xml sind die EJB angegeben welche in diesem Modul residieren. Der WebLogic Deployment Descriptor weblogic-ejb-jar.xml verwendet die in der ejb-jar.xml verwendeten Referenzen und bereitet sie für das Deployment vor. Für Stateless Session Beans besteht bei Letzterem die Option im statelessr sessionrdescriptor das statelessrclustering zu definieren Parameter welche sich auf das Verhalten dieser EJB im Cluster auswirken. So kann darin der Load Balancing Algorithmus für das Home Interface und die Bean angegeben werden (siehe Abb. 02). In ejb-reference-description können Referenzen auf eine andere EJB erstellt werden. Die weiteren Parameter ejb-refname und jndi-name geben den Namen der Bean an, welchen man der Bean im name Attribut ihrer Beschreibung gegeben hat. Ist beispielsweise eine Ressource mybean )<annotiert, so kann die Bean diese über folgenden Eintrag referenzieren: <ejbrrefrname>mybean</ejbrrefrname>< Der Container, welcher die EJB behandelt kümmert sich um die Auflösung der Referenzen per Annotation. Die Ressource wird dann im komponentenweiten Namensraum der EJB (java:comp/env) registriert. Im oberen Beispiel löst der Container die Referenz nach java:comp/env/mybean auf. Wenn die Annotation keinen Namen definiert, so wird die Referenz aufgelöst auf java:comp/env/[ejb.klasse.mit.paketpfad]/[name des annotierten Feldes] Ist beispielsweise die EJB in welcher die DI stattfindet im Paket com.esentri.jndi mit dem Namen MyBean hinterlegt und das annotierte MyBeanInterface<fieldName;< dann wäre die annotierte Ressource im komponentenweiten Namensraum unter folgendem JNDI Pfad: java:comp/env/com.esentri.jndi.mybean/fieldname< Über den Deployment Descriptor als auch über Annotation referenzierte Ressourcen sind demnach im komponentenweiten Namensraum der Komponente in welcher sie referenziert sind verzeichnet. Die Ressource muss sich hierfür nicht in derselben Applikation befinden. Wichtig ist jedoch, dass sie sich auf derselben Serverinstanz befindet und im JNDI eingetragen ist. 8

9 Abb. 2: Auszug des Quellcode aus einem weblogic-ejb-jar.xml Der Deployment Descriptor der EJB für den WebLogic ist im JDeveloper als weblogic-ejb-jar.xml vorhanden. Dieser DD sorgt dafür dass die EJB des DD ejb-jar auf einen JNDI Namen gemapped werden. Hierbei kann unter Overview die Konfiguration der gewünschten Bean betrieben werden ohne dass die Konfiguration von Hand vorgenommen werden muss (siehe Abb. 03). Abb. 3: Konfiguration des weblogic-ejb-jar.xml Standardmäßig sind die EJB sowie das Home Interface bereits so vorkonfiguriert, dass sie im Cluster betrieben werden können. Hierbei ist zu beachten, dass ein Home Interface seit dem EJB Standard 3.0 (Java EE 5) nicht mehr benötigt wird. Dieses Interface musste damals von allen Remote Interfaces einer EJB erweitert werden um Methoden wie create() oder remove(). Hierbei wurde beim Client über das RMI auf das Home Interface zugegriffen und beim Client eine Instanz der EJB erstellt. Der Zugriff auf EJB wird über die JNDI und die neu dazugekommenen Namensräume vereinfacht. 9

10 2 Java Naming and Directory Interface (JNDI) Das Java Naming and Directory Interface bietet auf Java basierenden Applikationen ein einheitliches Interface an, über welches mehrere Namens- und Verzeichnisservices verwendet werden können. Es ermöglicht einen einheitlichen Zugriff auf Services wie LDAP, DNS oder CORBA. Das JNDI ist auf für Java EE als SPI verfügbar, wobei der Provider für eine Java EE konforme Implementierung zuständig. Das JNDI wird in diesem Dokument verwendet, um Lookups auf EJB im Java EE Umfeld durchzuführen. Alle hier behandelten Themen werden hier spezifisch im Bezug auf Java EE und EJB betrachtet. Die Klassen für die Nutzung von JNDI befinden sich im javax.naming.* Paket. In das JNDI werden Werte zusammen mit einem Namen abgelegt. Über ein Lookup wird das Objekt zurückgegeben, welches im JNDI unter dem gesuchten Namen abgelegt wurde. Ist ein Name bei der Ablage bereits vergeben, so wird eine NameAlreadyExistException ausgegeben. Wird beim Aufruf eine NameNotFoundException ausgelöst, so wurde im JNDI kein Objekt unter dem gesuchten Namen abgelegt. Eine NotFoundException hingegen könnte Hinweise darauf geben dass ein Eintrag unter besagtem Namen zwar existiert, das dazugehörige Objekt aber nicht mehr existiert und womöglich das JNDI Verzeichnis nicht aktualisiert wurde. Das JNDI speichert seine Einträge in einer Baumstruktur, welche auch als JNDI Tree bezeichnet wird. In WebLogic kann der JNDI Tree über die WebLogic Server Administration Console eingesehen werden (siehe Abb. 04). Die Einträge enthalten jeweils! Einen Binding Name unter dem das Objekt verzeichnet ist! Den Klassennamen des Objektes! Einen Hashcode (dezimal) sowie! Das tostring() Ergebnis, welcher sich wie folgt zusammenbaut: < < Abb. 4: Beispiel eines WebLogic JNDI Tree in der Administrationskonsole Der JNDI Tree des WebLogic Servers kann über die Administration Console mit der nach-folgenden URL betrachtet werden. Beispiel: 10

11 Im linken Panel erfolgt die Navigation über Umgebung -> Server (Environment -> Server). In der neuen Ansicht wird unter den Tabs Konfiguration -> Allgemein eine Übersicht über den Server ermöglicht. Über den Kennzahlen befindet sich der Link JNDI-Baum anzeigen (siehe Abb. 05). In einem neuen Fenster respektive Tab wird der JNDI Tree für den Server angezeigt. Abb. 5: WebLogic Server Administrationskonsole, Zugriff auf den JNDI Tree Im neu öffnenden Tab/Fenster befindet sich nun auf der linken Seite die Baumstruktur des JNDI. Im oberen Beispielbild existiert noch keine Applikation. Dennoch nutzt WebLogic JNDI in einem integrierten LDAP Repository speichert WebLogic sicherheitsrelevante Daten, unter anderem über seine Nutzer, Gruppen oder Sicherheitsrichtlinien. Der Lookup mit JNDI war im Java EE Umfeld bis Version 5 stark kontextuell abhängig und es existierten keine globalen Einträge für Ressourcen (z.b. EJB). Die Ressource wurde abhängig von der Position des Aufrufs mit einem unterschiedlichen JNDI Namen aufgerufen. Um auf eine EJB außerhalb der Applikation zugreifen zu können musste über RMI das Home Interface der gewünschten Bean herangezogen werden um anschließend eine Instanz davon auf dem Client zu erzeugen, über welche dann die Methodenaufrufe der EJB gingen. Da nur der komponentenweite Namensraum existierte musste man für jede Komponente auf welche man von der Bean aus lokal zugreifen wollte eine Referenz über den DD erstellen. Auf diese Problematik wurde in Java EE 6 eingegangen und durch das Hinzufügen drei neuer Namensräume vereinfacht. Dies ermöglichte den Zugriff über JNDI für jede auf dem Server abgelegte Komponente unter einem eindeutigen Namen, womit auch der Zugriff auf Komponenten auf anderen Servern vereinfacht wurde. Auch lokal wurde eine Referenz nicht mehr benötigt, da nun über modulweite (JAR/WAR) als auch applikationsweite (EAR) Namensräume ein direkter JNDI Lookup ausgeführt werden konnte. 11

12 2.1 Namensrichtlinien Das JNDI definiert keine Richtlinien, nach denen Namen erstellt werden müssen. Jedoch ist es in der Praxis weitgehend üblich nach der Java EE Konformität zu gehen. Diese sieht vor dass ein logischer Namensraum (namespace) vom Container der EE Komponente (z.b. EJB) zur Verfügung gestellt wird. Die Komponente wird in einem Deployment Descriptor vermerkt welcher neben den Daten auch Informationen über den logischen Namen, den Ressourcentypen sowie Referenzen der Komponente beinhalten. Der Enterprise Namensraum beruht auf einem Java URL Schema. Dieses Präfix ist Java EE Standard und ist die Standardreferenz für alle nicht-serialisierbaren Ressourcen. Zu diesem Präfix zählen vier Namensbereiche, auch Scopes genannt. Die Verwendung dieses Konzeptes ermöglicht es Namenskonflikte zu vermeiden, welche vom Context.INITIAL_CONTEXT_FACTORY, auch InitionalContext genannt, verwaltet werden. Mit einem / (Slash) wird ein Unterverzeichnis angesprochen. Die letzten drei Scopes wurden mit Java EE 6 eingeführt. Die Bezeichnungen in den [eckigen Klammern] sind optional. Das Wissen um die unterschiedlichen Namensräume mit JNDI ist unerlässlich. Das JNDI arbeitet in einem bestimmten Kontext - das heißt dass der Lookup stets vom Client, der aufrufenden Komponente, abhängig ist. Die Namensräume werden von comp über module und app bis zum global immer größer. Da ein größerer Namensraum einen größeren Overhead verursacht wird empfohlen möglichst auf einer feingranularen Ebene zu beginnen. java:comp/env, Bis inklusive Java EE 5 existierte nur der java:comp<namensraum. Das comp ist eine Abkürzung für Components und bezeichnet den für eine Komponente gültigen Namensraum. Wurde an dieser Komponente (manuell) eine Referenz zu einer anderen Komponente hergestellt, so konnte auf diese über den Namensraum java:comp/env/5 zugegriffen werden. Dieser Namensraum ist stark Kontextabhängig, da jede Komponente ihren eigenen java:comp/env Namensraum besitzt. Ist die referenzierte Komponente hierbei eine EJB, so wird diese in einem Unterordner namens ejb in diesem Namensraum abgelegt. Selbiges gilt für Datenquellen mit jdbc. < Beispiele: Java:comp/env/ejb/OrdersEntityBean< Java:comp/env/jdbc/Salary< Bei einem Lookup wird für gewöhnlich der komplette Name der Komponente (siehe obiges Beispiel) angegeben. Im WebLogic ist es bereits ausreichend, den Verzeichnispfad nach java:comp/env anzugeben (z.b. ejb/orders). Zu diesem Namensraum sind folgende Aspekte zu beachten:! Jede Komponente besitzt ihren eigenen java:comp/env Namensraum! Einträge im Namensraum müssen explizit im DD angegeben werden! Wenn EJB A eine Referenz auf EJB B deklariert, so hat A in seinem Namensraum eine Referenz auf EJB B Dies bedeutet dass jede Komponente welche auf eine andere Komponente zugreifen wollte diese als Referenz deklarieren musste. Hat man Java EE 5 im Einsatz so sollte man bedenken dass Servlets diesen Namensraum anders interpretieren. Während der java:comp/env Namensraum bei EJB für jede Bean einzeln existiert, so teilen sich alle Servlets innerhalb einer WAR untereinander diesen Namensraum (siehe Abb. 06). Dies bedeutet, dass Servlets ohne Angabe von Referenzen andere Servlets über diesen Namensraum erreichen können. Eine EJB kann jedoch nicht auf den privaten komponentenweiten Namensraum einer anderen EJB zugreifen. 12

13 Abb. 6: java:comp/env Namensraum der EJB1 mit Referenz auf EJB2 Der java:comp Namensraum sollte für EJB nur dann verwendet werden, wenn diese eine Referenz auf die Zielkomponente besitzt. Beispielsweise lassen sich für Servlets entfernte Ressourcen (resource-ref) in der web.xml angeben, welche dann über den komponentenweiten Namensraum verwendet werden können. Hierbei wird der Name angegeben unter welchem man vom Servlet aus auf die Ressource zugreift sowie den Namen der Ressource unter welcher sie im JNDI hinterlegt ist. Beispiel: <resourcerref>< < <resrrefrname>myusedresourcename</resrrefrname>< < <jndirname>realjndiresourcename</jndirname>< </resourcerref>< Eine Referenz über Dependency Injection sorgt ferner dafür dass die injizierte Ressource am komponentenweiten Namensraum eingetragen wird. Über DI injizierte Ressourcen sind somit ebenfalls stets über diesen Namensraum aufrufbar. java:module/, Der Namensraum des java:module wird verwendet um (lokale) EJB innerhalb eines Moduls zu addressieren. Die Syntax für den java:module Scope lautet wie folgt: java:module/<bean-name>[!<fully-qualified-interface-name>] Der Name des Interface wird nur dann benötigt, wenn die EJB mehrere Interfaces implementiert. Der Namensraum beschränkt sich auf das Modul der Applikation (siehe Abb. 07). Ein Modul ist hierbei ein JAR oder ein WAR innerhalb einem EAR und beherbergt mehrere Komponenten (z.b. EJBs). 13

14 java:app/, Der java:app Scope wird verwendet, um einen Lookup auf lokale EJB zu betreiben welche innerhalb derselben Applikation gepackt sind. Dieser Scope wird verwendet wenn eine EJB in einer EAR gepackt ist welche mehrere Java EE Module enthält (siehe Abb. 07). JNDI Adressen im java:app Namensraum besitzen folgende Form: java:app/<module-name>/<bean-name>[!<fully-qualified-interface-name>] Der Name des Interface wird nur dann benötigt, wenn die EJB mehrere Interfaces implementiert. java:global/, Der java:global Namensraum bietet die meisten Möglichkeiten um auf EJB innerhalb der Applikation zuzugreifen. Innerhalb dieses Namensraumes können applikationsweit remote EJB addressiert werden. Klassischer Aufbau: java:global[/<app-name>]/<module-name>/<bean-name>[!<fully-qualifiedinterface-name>] Die Parameter <apprname> sowie <modulername> sind entsprechend ihrer Paketnamen (ohne die Dateiendungen). Dabei ist <apprname> nur dann erforderlich, wenn die Ressource sich in einem EAR befindet. Der Name des Interface wird nur dann benötigt, wenn die EJB mehrere Interfaces implementiert. Der Container der EJB muss bei der Verwendung des global Namensraumes im JNDI einen Eintrag für jedes implementierte Interface lokal wie remote erstellen. Das folgende Schaubild demonstriert in abstrakter Weise wie JAR, WAR und EAR in einer Enterprise Applikation gepackt werden und wie der Lookup auf unterschiedlichen Namensräumen zu interpretieren ist. Abb. 7: Enterprise Application über mehrere EAR, Java EE 6 Namensräume Ein Lookup auf Modulebene würde den Inhalt einer einzelnen JAR betreffen. Hier sind die EJB lokal verpackt. Vom Standpunkt der Applikationsebene kann dort ein Lookup zwischen mehreren JAR innerhalb einer EAR erfolgen. Der globale Zugriff ermöglicht letztendlich einen LookUp über mehrere EAR hinweg. Wichtig zu beachten ist die Annotationen in EJBs. Für gewöhnlich entspricht der Name der Bean im JNDI seinem Klassennamen. Werden die eben erwähnten Annotationen jedoch angewandt und mit ihnen ein Name für die Bean deklariert, so ist diese Bean im JNDI über den Namen in der Annotation erreichbar. 14

15 2.2 Context und InitialContext Context erzeugen Um das JNDI nutzen zu können, wird ein sogenanntes Context Objekt erzeugt. Mit diesem ist es möglich, lokale Lookups zu erstellen. Um mit dem JNDI ein Lookup auf einen bestimmten Server (oder wie später gezeigt wird auch Servercluster) vorzunehmen, wird ein sogenannter InitialContext erzeugt. Dieser InitialContext wird zunächst initialisiert, indem ihm Umgebungsvariablen des Servers in Form einer HashTable mitgegeben werden. Möchte man das JNDI auf einem Server verwenden, so ist es auch erlaubt die Umgebungsvariablen wegzulassen und einen leeren InitialContext zu erzeugen. Der JNDI Kontext bezieht sich dann auf den lokalen Server, welcher die EE Komponente hostet. Folgende Umgebungsvariablen können in der HashTable für den InitialContext gesetzt werden: Umgebungsvariable Beschreibung Standardwert Diese Variable spezifiziert den Namen der InitialContext Factory, welche den InitialContext INITIAL_CONTEXT_FACTORY< erzeugt. Für den WebLogic wird leer WLInitialContextFactory verwendet um auf den WLS JNDI Service zuzugreifen. PROVIDER_URL< Die URL des Servers oder Clusters, auf dessen JNDI man zugreifen will. Das Kontextobjekt wird t3://localhost:7001 von diesem Provider gestellt. SECURITY_PRINCIPAL< Wenn der Client einen Zugriff auf den WebServer benötigt, muss man Nutzernamen und Passwort angeben damit man sich als guest Nutzer des WLS identifizieren kann. SECURITY_CREDENTIALS< Entspricht dem Passwort des Nutzers, mit dessen Nutzernamen man sich anmelden will. guest Beispiel für die Erstellung eines InitialContext: import<java.util.hashtable;< import<javax.naming.*;< < public<class<testingbean<{< private<initialcontext<context<=<null;<< < < public<initialcontext<getinitialcontext()<throws<namingexception<{< < < if<(context<==<null){< < < < Hashtable<environment<=<new<Hashtable();< < < < environment.put(context.initial_context_factory,< "weblogic.jndi.wlinitialcontextfactory");< < < < environment.put(context.provider_url,<"t3://localhost:7001");< < < < context<=<new<initialcontext(environment);< < < }< < < < < return<context;< < }< Eine weitere Möglichkeit um ein InitialContext Objekt zu erzeugen besteht im Einsatz der Environment-Klasse von WebLogic (weblogic.jndi.environment). Erstellt man ein neues Environment-Objekt, so werden die Standardwerte der Umgebungsvariablen eingesetzt. Man kann mittels Environment env = new Environment(); Context ctx = env.getinitialcontext(); einen InitialContext mit Standardwerten erzeugen. Die Klasse bietet Methoden an um die Standardparameter zu überschreiben, zum Beispiel auf diese Weise: 15

16 Environment env = new Environment(); env.setproviderurl("t3://myweblogiccluster.com:7001"); Context ctx = env.getinitialcontext(); Lookup ausführen Über den Kontext kann über die Namensräume ein Objekt geholt werden, welche im JNDI verzeichnet ist. Im Beispiel wird mit dem Lookup eine Bean namens OrdersBean geholt. Hierbei wird über den Lookup ein Objekt der Klasse Object zurückgegeben, welcher vom JNDI unter dem gesuchten Namen abgelegt wurde. try { OrdersBean ordbean = (OrdersBean)context.lookup("java:global/myEAR/myJAR/ OrdersBean"); } catch (NameNotFoundException e) { // unter dem gesuchten Namen existiert im JNDI kein Eintrag } catch (NamingException e) { // ein Fehler ist aufgetreten } Manueller Lookup VS. Dependency Injection In diesem Dokument wird überwiegend ein manueller Lookup mit JNDI auf die EJB betrieben. Dies ist dafür gedacht die Arbeitsweise mit JNDI im Java EE Bereich mit EJB zu demonstrieren. Dieses Unterkapitel stellt den Lookup mit JNDI und DI gegenüber, sodass ein Überblick über beide Techniken entsteht.! Für einen Zugriff auf entfernte Objekte (anderer Server) muss ein manueller Lookup über den InitialContext betrieben werden, da dies mit DI nicht möglich ist. Die Ressource ist mit einem manuellen Lookup von überall aus erreichbar.! Die Referenz auf Objekte auf demselben Server ist über DI einfacher, da der Container mit dem Management der Ressource beauftragt wird. Dies spart Code ein (u.a. try-catch Block um den InitialContext) und erfordert nicht die Angabe des vollständigen exakten JNDI Namens.! Die Session einer Stateful Session Bean ist in beiden Fällen dieselbe Instanz. Führt man aus dieser Session heraus einen Lookup auf die EJB aus oder greift über DI auf diese zu so wird dieselbe Instanz damit angesprochen.! Mit Java EE 6 ist eine EJB mit JNDI standardmäßig über drei Namensräume verfügbar: modulweit (java:module, JAR/WAR), applikationsweit (java:app, EAR) sowie über mehrere EAR und auch Server hinaus (java:global). Mit DI lassen sich die Referenzen nur innerhalb eines Servers (mit mappedname) ansprechen. Über DI bezogene Ressourcen sind in der referenzierenden Komponente im komponentenweiten Namensraum (java:comp) registriert.! Ändert sich der Aufenthaltsort einer Ressource, so muss jeder Lookup welcher diese Ressource anpeilt angepasst werden. Da sich bei DI der Container um die Auflösung der Referenz kümmert ist eine lose Kopplung gegeben, der Entwickler muss keine Anpassungen vornehmen.! Aufgrund des String-basierten Lookup kann erst zur Laufzeit ermittelt werden, ob die Referenz aufgelöst werden kann. Über DI wird die Ressource zur Kompilierungszeit bereits geprüft ob die Ressource erreichbar ist. 16

17 3 Anwendungsszenarien In diesem Kapitel werden verschiedene Anwendungsszenarien vorgestellt, wie man auf eine EJB mit JNDI zugreifen kann. Folgende Beispiele werden erläutert:! Lookup einer EJB im Java EE 6 Namensraum über einen Java SE Client! Lookup einer EJB mit mappedname über einen Java SE Client! Lokale Referenz von EJBs im selben Modul über DI! JNDI Lookup innerhalb eines Moduls (JAR)! JNDI Lookup innerhalb einer Applikation (EAR)! JNDI Lookup über mehrere EAR! Zugriff auf eine EJB mit mehreren Interfaces! Aufruf einer EJB über ein Servlet und JSP Zunächst werden die wichtigsten Elemente vorgestellt welche für die Ausführung der Szenarien notwendig sind. Die Szenarien sind teilweise aufeinander aufbauend und verwenden einen externen Client. Die Beispiele wurden im JDeveloper Studio entwickelt und auf dessen integrierten WebLogic Server deployed. Manche Szenarien könnten auf anderen Applikationsservern nicht lauffähig sein. Anwendungsszenarien zu Lookups im WebLogic Cluster werden in Kapitel 4 behandelt. Bevor die Anwendungsszenarien erläutert werden, werden zunächst die verwendeten Interfaces und Klassen näher betrachtet. Die Szenarien beinhalten stets eine Stateless Session Bean mit dem Namen CarBean, welche ein Interface namens TravelOption implementiert. CarBean.java package com.esentri.jndi; import com.esentri.jndi.transportation.traveloption; import javax.ejb.stateless; import javax.naming.context; import javax.naming.initialcontext; import = "Car", mappedname = "car-vehicle") public class CarBean implements TravelOption{ public String vehicle() { return "car"; public String travelleddistance(int i) { return "Average distance travelled with "+vehicle()+" after "+i+"hour(s): " + i*65 + " mile(s)."; public String comparetraveldistance(int i) { try { Context ctx = new InitialContext(); TravelOption bike = (TravelOption) ctx.lookup("java:global/s1_seclient/vehicles/bike"); return travelleddistance(i)+"\n"+bike.travelleddistance(i); } catch (NamingException e) { return "An error occurred with catching the context.\n" + e.getstacktrace(); } } 17

18 TravelOption.java (Interface) package com.esentri.jndi.transportation; import javax.ejb.local; public interface TravelOption { public String vehicle(); public String travelleddistance(int i); public String comparetraveldistance(int i); } Das obere Interface stellt drei Methoden zur Verfügung, welche von der Bean implementiert werden müssen. Die Methode vehicle gibt einen String zurück um welches Transportmittel es sich handelt. Die travelleddistance Methode gibt als Rückgabewert die durchschnittliche zurückgelegte Strecke nach i Stunden in Meilen zurück. Innerhalb der comparetraveldistance Methode wird travelleddistance aufgerufen sowie die Methode travelleddistance einer anderen EJB, welche dasselbe Interface implementiert und aus der EJB über einen Lookup referenziert wird. Im späteren Verlauf wird ein weiteres Interface namens VehicleColor einbezogen, welches die Farbe des Transportmittels angibt. VehicleColor.java package com.esentri.jndi.transportation; import javax.ejb.local; public interface VehicleColor { public String vehiclecolor(); } Weitere in den Anwendungsszenarien angegebenen EJB sind strukturiell an der CarBean angelehnt und verwenden die oben erwähnten Interfaces. Der initiale Lookup erfolgt stets aus einem externen Java Client, einer Klasse namens Lookup. Weitere interne Lookups erfolgen aus der EJB heraus. 18

19 Lookup.java // package & imports public class Lookup { //Hashtable und Umgebungsvariablen zur Initialisierung des Context Objektes static Hashtable<String,String> env; static String icfactory = "weblogic.jndi.wlinitialcontextfactory"; static String providerurl = " static String wlsprincipal = "username"; // Nutzername wenn nötig static String wlscredentials = "password"; // Passwort zum Nutzer static String lookuptarget = "java:global/s1_seclient/vehicles/car"; public static void main(string[] args) { try { env = new Hashtable<String, String>(); env.put(context.initial_context_factory, icfactory); env.put(context.provider_url, providerurl); // Nutzerdaten, falls notwendig //env.put(context.security_principal, wlsprincipal); //env.put(context.security_credentials, wlscredentials); } } InitialContext ctx = new InitialContext(env); Object obj = ctx.lookup(lookuptarget); TravelOption option = (TravelOption) obj; System.out.println("Chosen vehicle: " + option.vehicle()); System.out.println(option.travelledDistance(3)); } catch (NamingException nnfe) { nnfe.printstacktrace(); } 19

20 3.1 Lookup einer EJB im Java EE 6 Namensraum über einen Java SE Client Um einen Lookup durchführen zu können muss vorerst eine Applikation auf den Server abgelegt werden, auf welche später zugegriffen werden kann. In dieser Applikation befindet sich das Projekt (Modul) Vehicles, welches die zu Beginn in Kapitel 3 erwähnte CarBean beinhaltet welche das TravelOption Interface implementiert. Nach dem Deployment im integrierten WebLogic Server ist die Applikation mit dem Namen des Deploymentprofils als Applikationsname im JNDI Tree registriert. Die Module der EJB tragen standardmäßig die Bezeichnung <ApplikationsName>_<ModulName>_ejb im JNDI Tree. In diesem Anwendungsbeispiel heißt das Deploymentprofil der Applikation s1_seclient. Unterhalb von java:global befindet sich ein Knoten mit diesem Namen, worunter auch das Modul vehicles zu finden ist 1 (siehe Abb. 08). Abb. 8: Auszug aus dem JNDI Tree der BlueBean (nach der Anpassung am Deploymentprofil) Nach dem Start ist der integrierte WebLogic Server per Default unter verfügbar, die Konsole lässt sich unter dieser Adresse unter /console/console.portal aufrufen. Von einer einfachen Javaklasse heraus lässt sich der Lookup ausführen.< < Da die CarBean EJB unter dem Namen Car abgelegt wurde kann unter dem globalen Namensraum des Servers auf diese zugegriffen werden (siehe Abb. 09). Abb. 9: Beispielausgabe des Methodenaufrufs nach dem Lookup 1 Für eine bessere Lesbarkeit wurde ein Deploymentprofil für das Modul erstellt und auf vehicles abgeändert. 20