Referenzierung von EJBs mit JNDI im WebLogic Server Whitepaper

Größe: px
Ab Seite anzeigen:

Download "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 / 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 = "http://localhost:7101"; 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

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Schritt 4: Hallo Enterprise Bean

Schritt 4: Hallo Enterprise Bean Prof. Dr. Th. Letschert FB MNI JEE Schritt 4: Hallo Enterprise Bean Einstieg: EJBs erzeugen und nutzen Meine erstes EJB Projekt Enterprise Beans sind eine Backend Technologie, die mit unterschiedlichen

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany Enterprise JavaBeans Einführung Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Inhalt Allgemeines Motivation Rollen Aufbau einer EJB Arten von Beans Enterprise JavaBeans

Mehr

Clustering von Application Servern am Beispiel von JBoss 3.2

Clustering von Application Servern am Beispiel von JBoss 3.2 Clustering von Application Servern am Beispiel von JBoss 3.2 Cluster Workshop iternum GmbH Alexanderstraße 7 60489 Frankfurt/Main www.iternum.com Agenda Clustertechnik allgemein Was ist Clustering? Gründe

Mehr

-Testen verteilter Anwendungen

-Testen verteilter Anwendungen -Testen verteilter Anwendungen Seminar Simulation und Bildanalyse mit Java im SS04 Konstantin Tjo, Urs Pricking Testen verteilter Anwendungen 1 Übersicht Einführung in verteilte Anwendungen RMI (Remote

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Programmieren in Java

Programmieren in Java Programmieren in Java objektorientierte Programmierung 2 2 Zusammenhang Klasse-Datei In jeder *.java Datei kann es genau eine public-klasse geben wobei Klassen- und Dateiname übereinstimmen. Es können

Mehr

Separates Deployment von Produktdaten Cornelius Dirmeier (Dokumentversion 47)

Separates Deployment von Produktdaten Cornelius Dirmeier (Dokumentversion 47) Separates Deployment von Produktdaten Cornelius Dirmeier (Dokumentversion 47) Einleitung Faktor-IPS verwaltet Produktdaten während der Produktentwicklung in XML Dateien. Zur Laufzeit liegen die Produktdaten

Mehr

Benutzung von Eclipse zur Entwicklung von Java EE 5 Anwendungen mit dem JBoss Application Server

Benutzung von Eclipse zur Entwicklung von Java EE 5 Anwendungen mit dem JBoss Application Server Benutzung von Eclipse zur Entwicklung von Java EE 5 Anwendungen mit dem JBoss Application Server Starten und Auswahl des Workspaces Starten Sie Eclipse als die Entwicklungsumgebung. Wählen Sie als Workspace

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Enterprise JavaBeans Basics Enterprise JavaBeans (EJB) Enterprise JavaBeans (EJB) Komponenten sind wohl definiert verteilt (MI-based) serverseitig Sie dienen

Mehr

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften

Mehr

Mobile und Verteilte Datenbanken

Mobile und Verteilte Datenbanken Mobile und Verteilte Datenbanken Java RMI Vorlesung Wintersemester 2013/2014 groppe@ifis.uni-luebeck.de Institut für Informationssysteme Universität zu Lübeck Kommunikations-Middleware Bietet höhere Kommunikations-Dienste

Mehr

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB) silbergrau Consulting & Software GmbH Enterprise Java Beans (EJB) Fachhochschule Hagenberg WS 2002 / 2003 Silbergrau Consulting & Software GmbH Dr. Andreas Erlach Inhaltsübersicht Application Server J2EE

Mehr

Web-Services Implementierung mit Java

Web-Services Implementierung mit Java Web-Services Implementierung mit Java J. Heinzelreiter WS 2004/05 Java-APIs für Web-Services (1) Anwendungs-Code JAXR JAXM JAX-RPC SAAJ SOAP/SwA JWSDL WSDL XML/XML-Schema Web-Services/Java - 2 Java-APIs

Mehr

11. Enterprise Java Beans Grundlagen der Programmierung II (Java)

11. Enterprise Java Beans Grundlagen der Programmierung II (Java) 11. Enterprise Java Beans Grundlagen der Programmierung II (Java) Prof. Dr. Bernhard Humm Hochschule Darmstadt University of Applied Sciences Sommersemester 2006 Übersicht Grundlagen der Programmierung

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Clustering von Application Servern am Beispiel von BEA WebLogic 8.1

Clustering von Application Servern am Beispiel von BEA WebLogic 8.1 Clustering von Application Servern am Beispiel von BEA WebLogic 8.1 Cluster Workshop iternum GmbH Alexanderstraße 7 60489 Frankfurt/Main www.iternum.com Agenda Clustertechnik Allgemein Was ist Clustering?

Mehr

Remote- und Server-Programmierung. Dr. Wolfgang Süß Thorsten Schlachter

Remote- und Server-Programmierung. Dr. Wolfgang Süß Thorsten Schlachter Remote- und Server-Programmierung Dr. Wolfgang Süß Thorsten Schlachter Remote Method Invocation (RMI) Servlets WebServices 2 Remote Method Invocation (RMI) Das Remote Method Invocation (RMI)-Framework

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

Konfigurationslanleitung für J2EE und Eclipse im KBS-Pool

Konfigurationslanleitung für J2EE und Eclipse im KBS-Pool Konfigurationslanleitung für J2EE und Eclipse im KBS-Pool JBoss vorbereiten Wir haben ein zip-archiv mit JBoss 4.0.5 in /opt/jboss-4.0.5.zip hinterlegt. Entpacken Sie dieses in ihrem Homeverzeichnis an

Mehr

Programmierung von Client/Server- Anwendungen

Programmierung von Client/Server- Anwendungen Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Geronimo, konfigurierbarer Java EE Application Server

Geronimo, konfigurierbarer Java EE Application Server Geronimo, konfigurierbarer Java EE Application Server http://www.hs furtwangen.de http://www.informatik.hs furtwangen.de/~reich http://geronimo.apache.org/ Christoph Reich 01.06.2007 Überblick Geronimo

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. WebSphere Application Server Teil 2. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. WebSphere Application Server Teil 2. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 2 Schnittstellen el0100 copyright W. G. Spruth, wgs

Mehr

EJB3.0 Unit-Testing Reloaded

EJB3.0 Unit-Testing Reloaded EJB3.0 Unit-Testing Reloaded Werner Eberling werner.eberling@mathema.de www.mathema.de Werner Eberling, MATHEMA Software GmbH - EJB3.0 - Unit-Testing Reloaded (G4 - Folie 1) Java Forum Stuttgart 2007 Automatisiertes

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht Enterprise JavaBeans Überblick 1. Überblick Komponententechnologien 2. Einführung 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Modul Software Komponenten 10 Komponentenarchitektur

Modul Software Komponenten 10 Komponentenarchitektur Modul Software Komponenten 10 Komponentenarchitektur Teil 3 Peter Sollberger Eine erste CORBA Anwendung Inhalt Dienstag, 4. November Object Request Broker CORBA Architektur und Komponenten (Teil 1) Übung:

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008 PIWIN I Kap. 7 Objektorientierte Programmierung - Einführung 1 PIWIN I Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I Vorlesung 3 SWS WS 2007/2008 FB Informatik

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK Inhaltsverzeichnis jetzt lerne ich Vorwort 17 1 Einleitung 19 1.1 Zentrale Konzepte 20 1.1.1

Mehr

Enterprise Java Beans

Enterprise Java Beans Enterprise Java Beans Beispiel Minibank nur: Kunde, Konto, Überweisung personen.person Attributes Name:String Vorname:String überweisungen.überweisung Attributes Verwendungszweck:String Datum:Date betrag:integer

Mehr

AS 7 / EAP 6 - Clustering. heinz.wilming@akquinet.de @akquinet h3p://blog.akquinet.de

AS 7 / EAP 6 - Clustering. heinz.wilming@akquinet.de @akquinet h3p://blog.akquinet.de AS 7 / EAP 6 - Clustering heinz.wilming@akquinet.de @akquinet h3p://blog.akquinet.de Was ist die EAP 6? EAP6!= EAP5 +1 JBoss Enterprise ApplicaBon PlaCorm 6 Stabile und unterstützte Pla>orm Basiert auf

Mehr

7.1.1 Grundzüge der Fernaufruf-Implementierung

7.1.1 Grundzüge der Fernaufruf-Implementierung 7.1.1 Grundzüge der Fernaufruf-Implementierung = Aufrufbeziehung Aufrufer Vertreter (proxy, client stub) Fernaufrufdienst A d a p t e r Treiber (skeleton, server stub) Fernaufrufdienst Aufgerufener (Modul,

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

Web- Applikationen. in Java-Web

Web- Applikationen. in Java-Web Einführung in Java-Web Web- Applikationen Frank Huber Humboldt-Universität zu Berlin Allgemeines Java: Programmierung ist Programmierung nach Konvention Insbesondere bei Web-Applikationen wurde eine API

Mehr

Variablen manipulieren per JDI

Variablen manipulieren per JDI Variablen manipulieren per JDI Zusammenfassung Jede moderne Java IDE verfügt über eine mächtige und dennoch meist einfach zu bedienende Benutzeroberfläche die das finden von Fehlern in lokalen oder entfernt

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Application Server und Continuous Integration

Application Server und Continuous Integration Application Server und Continuous Integration Outline 2 Einleitung Application Server Java EE Enterprise Applikationen vs. Web Applikationen Web Application Life Cycle Servlets JavaServer Pages verschiedene

Mehr

J2EE-Praktikum. EJB-Security. Peter Thiemann. J2EE-Praktikum, WS2005/2006. Universität Freiburg

J2EE-Praktikum. EJB-Security. Peter Thiemann. J2EE-Praktikum, WS2005/2006. Universität Freiburg J2EE-Praktikum EJB-Security Peter Thiemann Universität Freiburg J2EE-Praktikum, WS2005/2006 Inhalt 1 EJB Sicherheit 2 Schnittstelle für den Bean Provider 3 Zusammenfassung EJB Security Allgemeines Sicherheitsziele

Mehr

Enterprise JavaBeans 3.1

Enterprise JavaBeans 3.1 Uwe Rozanski Enterprise JavaBeans 3.1 Einstieg, Umstieg, Praxis und Referenz inklusive CD-ROM 1.1 Überblick Java EE steht für Java Enterprise Edition und ist ein Standard für die Programmierung verteilter

Mehr

Auszug aus Axis2 Schulung

Auszug aus Axis2 Schulung Auszug aus Axis2 Schulung Dieses Dokument ist ein Auszug aus unserem Skript zur Axis2- Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen Mehr

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

Anleitung. Ein einfaches RMI-Beispiel. (ab Java 5.0) c Y. Pfeifer. (Juni 2014)

Anleitung. Ein einfaches RMI-Beispiel. (ab Java 5.0) c Y. Pfeifer. (Juni 2014) Anleitung Ein einfaches RMI-Beispiel (ab Java.0) c Y. Pfeifer (Juni 014) 1 Ein einfaches RMI-Beispiel Vorgehensweise: 1. Java Projekt anlegen. Zwei Packages server & client erstellen Auf der Server-Seite

Mehr

JavaEE Grundlagen. Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A

JavaEE Grundlagen. Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A JavaEE Grundlagen FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A Sommersemester 2012 2 Die Java EE

Mehr

Ein einfacher Server. .NET Remoting. Klassentypen

Ein einfacher Server. .NET Remoting. Klassentypen Einführung - eine Klienten-Applikation kann mit einer Komponente interagieren die hinter einer Grenze liegt - Remoting ermöglicht eine Kommunikation von Komponenten Kontext-, Applikationsdomänen- (leichtgewichtiger

Mehr

Programmieren I. Prinzipieller Ablauf. Eigenschaften von JAVA. Source-Code Javac Bytecode. Java Virtual Machine (Java, Browser, Appletviewer)

Programmieren I. Prinzipieller Ablauf. Eigenschaften von JAVA. Source-Code Javac Bytecode. Java Virtual Machine (Java, Browser, Appletviewer) Programmieren I Grundlagen von JAVA Dr. Klaus Höppner Hello World in JAVA Hochschule Darmstadt WS 2007/2008 Elementare Datentypen 1 / 17 2 / 17 Eigenschaften von JAVA Prinzipieller Ablauf Plattform-und

Mehr

Praktikum Spring MVC. 1.2. Spring integrieren In der pom.xml Einträge für Spring hinzufügen.

Praktikum Spring MVC. 1.2. Spring integrieren In der pom.xml Einträge für Spring hinzufügen. Praktikum Spring MVC Aufgabe 1 Im ersten Teil des Praktikums wird eine Test Webapplikation entwickelt, anhand derer einige Konzepte von Spring nachvollzogen werden können. Dabei handelt es sich um Spring

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 A. Beschreibung der Projektarbeit. Welche Aufgabe haben Sie im Rahmen der Projektarbeit gelöst? 2. Mit welchen Tools bzw. Programmen (Anwendung,

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Server Installation 1/6 20.10.04

Server Installation 1/6 20.10.04 Server Installation Netzwerkeinrichtung Nach der Installation müssen die Netzwerkeinstellungen vorgenommen werden. Hierzu wird eine feste IP- Adresse sowie der Servername eingetragen. Beispiel: IP-Adresse:

Mehr

Security Technologien in Java EE 6

Security Technologien in Java EE 6 Security Technologien in Java EE 6 Java Forum Stuttgart 2010 Sebastian Glandien Acando GmbH sebastian.glandien@acando.de Agenda I. Einleitung II. Java Authentication SPI for Containers (JSR-196) I. Message

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

Hello World from CORBA

Hello World from CORBA Hello World from CORBA ein erster Überblick Aufruf einer Objekt-Methode Client gettemperature() Thermometer Objekt- Implementation Thermometer th = new Thermometer(); double t = th.gettemperature(); th

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2010 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de

Innovator 11 excellence. DDL importieren. Data-Definition-Language-Dateien in Datenbankschema importieren. HowTo. www.mid.de Innovator 11 excellence DDL importieren Data-Definition-Language-Dateien in Datenbankschema importieren HowTo www.mid.de Zweck In Innovator Data excellence können Sie mit dem DDL-Import Ihr physisches

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Erste Schritte in Java

Erste Schritte in Java Erste Schritte in Java Im einführenden Kapitel haben wir die Grundbegriffe der imperativen Programmierung an einem Beispiel (Algorithmus von Euklid) kennengelernt. In diesem Kapitel sehen wir uns an einem

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

Mehr

LDAP-Server. Jederzeit und überall auf Adressen von CAS genesisworld zugreifen

LDAP-Server. Jederzeit und überall auf Adressen von CAS genesisworld zugreifen LDAP-Server Jederzeit und überall auf Adressen von CAS genesisworld zugreifen Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den Beispielen verwendeten

Mehr

Java Einführung Programmcode

Java Einführung Programmcode Java Einführung Programmcode Inhalt dieser Einheit Programmelemente Der erste Programmcode Die Entwicklungsumgebung: Sun's Java Software Development Kit (SDK) Vom Code zum Ausführen des Programms 2 Wiederholung:

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Web-Anwendungen mit Arquillian testen

Web-Anwendungen mit Arquillian testen Michael Kotten open knowledge @michaelkotten @_openknowledge Wozu denn testen? Ich mach doch keine Fehler! Wozu denn testen? > Notwendig bei komplexen Systemen > Sicherung von > Qualität > Funktionalität

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

Android Processes & Services

Android Processes & Services Android Processes & Services Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Ziele heute Arbeitsblatt 4 besprechen (inkl. Repetition)

Mehr

Erste Schritte zum lauffähigen Java Programm

Erste Schritte zum lauffähigen Java Programm Erste Schritte zum lauffähigen Java Programm Diese kleine Einführung ist eine Hilfe für Studenten der Vorlesung SWT I zur Meisterung der sich ergebenden Hürden bei der Erstellung eines ersten kleinen Java-Programms.

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

Allgemeines. Architektur der Anwendung. Server starten. Anmeldung

Allgemeines. Architektur der Anwendung. Server starten. Anmeldung Allgemeines Architektur der Anwendung Grundsätzlich führen viele Wege nach Rom bzw. es gibt nicht den einen Weg, wie die gestellte Aufgabe mit Magnolia gelöst werden muss. Es wäre problemlos möglich, eine

Mehr