Enterprise Computing

Enterprise Computing Prof. Dr.-Ing. Wilhelm G. Spruth Teil 12 Enterprise Java Beans

Mainframe PC, Workstation Java 2 Editionen Embedded Devices, Klein- und Kleinstgeräte

J2EE (1) Die Java 2 Enterprise Edition (J2EE) von Sun beinhaltet eine Spezifikation für Verteilte Geschäftsapplikationen. Darin ist neben den Komponenten der Geschäftsapplikation, den Enterprise JavaBeans (EJB), auch die Infrastruktur zu deren Ausführung spezifiziert. Die Infrastruktur beinhaltet Applikationsserver mit sogenannten Containern, in denen die EJB ausgeführt werden. Der Server beziehungsweise der Container interagiert mit den Unternehmenssystem-Ressourcen (z.b. Datenbank) und übernimmt auch die Interaktion mit verteilten Beans in anderen Servern und Maschinen. Weiterhin kontrolliert er die Ausführung von selbst definierten Transaktionen und handhabt Sicherheitseinstellungen. Eigenschaften einer EJBean und deren Anforderungen an die Ablaufumgebung (z.b. Sicherheit, Transaktionssteuerung) werden durch die Attribute eines DeploymentDescriptors (Metadaten) deklarativ beschrieben.

Enterprise HTML Java WEB Bean(s) Browser WEB WEB Servlet Browser Server JSP SQL JDBC (oder andere) WEB Browser WEB Application Server Datenbank Server Dynamischer WEB Seiten Inhalt (3) Im einfachsten Fall enthält das Java Servlet die Anwendungslogik. In komplexeren Fällen lohnt es sich, die Anwendung in Komponentenform zu implementieren. Java Beans implementieren das Java Komponentenmodell. Enterprise Java Beans sind Java Beans mit zusätzlicher Funktionalität, besonders Transaktionseigenschaften (ACID), Persistenz und Sicherheit.

J2EE (2) Die EJB Spezifikation legt fest: Regeln, denen eine EJBean entsprechen muß Funktionalität, die der Container über entsprechende Schnittstellen erbringt Art der Beschreibung einer EJBean für die Installation und für dieverteilung Abbildung auf das CORBA IIOP Protokoll Eine EJB Komponente verfügt über die Möglichkeit entfernter Zugriffe, z.b. auf ein RMI oder CORBA Objekt. Sie kann unter Nutzung von RMI oder RMI/IIOP als Remote Objekt exportiert werden. Wie eine JavaBeans Komponente hat sie Eigenschaften, die durch Introspektion untersucht werden können. Bei der Definition von Zugriffsmethoden verwendet sie JavaBeans Konventionen.

Client Klassen rufen EJB Methoden direct auf, wenn in der gleichen JVM. Wenn nicht, Remote Method Invocation (RMI).

HTML Web Servlets Server JSPs EJBs SQL HTTP Servlet EJB Server Container Container Backend Bevorzugte Struktur eines Web Application Servers Java Application Server Browser Web Application Server Datenbank Server In dieser Konfguratio ist der HTTP Server (Web Server) ist lediglich ein Zusatz und gehört nicht unbedingt zum Lieferumfang eines Web Application Servers. Servlet Container und EJB Container laufen in einer gemeinsamen Java virtuellen Maschine (JVM). Dies reduziert den Kommunikationsaufwand. Servlet Klassen können EJB Klassen direkt aufrufen. Bei getrennten JVMs erfolgt die entsprechende Kommunikation mit Hilfe eines RMI Protokolls (JRMP oder RMI/IIOP). Der Web Application Server enthält weitere Elemente für Administration und Datenbankzugriff.

Typical application flow for Web browser clients using either JDBC (from a servlet) or EJB to access application databases

The typical application flow is as follows: 1. A Web client requests a URL in the browser (input page). 2. The request is routed to the Web server over the Internet. 3. The Web server immediately passes the request to the Web server plug-in. All requests go to the Web server plug-in first. 4. The Web server plug-in examines the URL, verifies the list of host name aliases from which it will accept traffic based on the virtual host information, and chooses a server to handle the request. 5. A stream is created. A stream is a connection to the Web container. It is possible to maintain a connection (stream) over a number of requests. The Web container receives the request and, based on the URL, dispatches it to the proper servlet. 6. If the servlet class is not loaded, the dynamic class loader loads the servlet (servlet init(), then doget()or dopost()). 7. JNDI is used for lookup of either datasources or EJBs required by the servlet. 8. Depending upon whether a datasource is specified or an EJB is requested, the JNDI directs the servlet: To the corresponding database and gets a connection from its connection pool in the case of a data source. To the corresponding EJB container, which then instantiates the EJB when an EJB is requested. 9. If the EJB request involves an SQL transaction, it goes back to the JNDI to look up the datasource. 10.The SQL statement is executed and the retrieved data is sent back either to the servlet or to the EJB. 11.Data beans are created and handed off to JSPs in the case of EJBs. 12.The servlet sends data to JSPs. 13.The JSP generates the HTML that is sent back through the plug-in to the Web server. 14.The Web server sends the output page (output HTML) to the browser. F\:redbooksWebSp\\WebSp13,pdf

Enterprise Java Beans (EJB) EJB EJB EJB EJB EJB EJB EJB EJB Container (andere Bezeichnungen:Laufzeitumgebung, Framework, Object Transaction Monitor - OTM) EJB Dienste Enterprise Java Beans sind Java Beans mit erweiterter Funktionalität. Diese wird von dem EJB Container zur Verfügung gestellt und enthält unter anderem JTS Java Transaction Service JNDI Java Naming directory Interface JMS Java Messaging Servics JDBC Java Data Base Connectivity JMAPI Java Management API JIDL Java Interface Definition Language JTS JIDL JNDI JMS JMAPI JDBC

Enterprise Java Beans (EJB) Enterprise Java Beans sind Java Beans mit erweiterter Funktionalität. Dies sind unter anderem: JTS, Transaction Service, an API for invoking transaction services. JNDI, Java Naming and Directory Interface, an API for accessing naming and directory services. JMS, Java Message Service, an API for invoking asynchronous message delivery services. JDBC, Java Database Connectivity API, accesses data in existing databases through a common interface. JMAPI, Java Management API, which defines access to a set of services for managing Java resources. JIDL, Java interface definition language, an interface to the CORBA set of services for distributed computing.

E M S M E E S S Session Bean (transientes Objekt) M Message-driven Bean E Entity Bean (persistentes Objekt) S EJB Container (andere Bezeichnungen:Laufzeitumgebung, Framework, Object Transaction Monitor - OTM) EJB Server (Web Application Server) Drei verschiedene Arten von EJBs Entity Beans Session Beans Message Beans EJBs sind Komponenten, die eine objektorientierte Sicht auf persistent gespeicherte Entitäten, also eindeutig identifizierbare und über Attribute beschreibare Informationseinheiten, repräsentieren. Diese Entitäten sind beispielsweise in einer Datenbank gespeichert. Handelt es sich dabei um eine relationale Datenbank, so korrespondieren Entity Beans z.b. mit einer Zeile der entsprechenden Datenbanktabelle. Entity Beans modellieren Geschäftskonzepte, bei-spielsweise ein Konto. EJBs sind Komponenten, die auf dem Server ablaufende Geschäftslogik implementieren. Sie modellieren Geschäftsprozesse, wie z.b. eine Überweisung.

Persistenz Die permanente Speicherung eines Objektes auf einem Plattenspeicher wird als Persistenz bezeichnet. Moderne RAID Technologien und Backup Strategien stellen sicher, dass Daten auch Fehlerfälle intakt überstehen. Konzeptuell können Objekte in einer Objektdatenbank (z.b. POET oder Jasmine) gespeichert werden.in der Praxis werden SQL (oder IMS, ADABAS oder VSAM) Daten als Objekte gekapselt; der Zugriff erfolgt z.b. über eine JDBC (Java Data Base Connectivity), SQLJ oder DB2Connect Schnittstelle. Persistente Objekte existieren permanent außerhalb des Gültigkeitsbereichs des Programms, das sie erzeugt hat. Persistenz wird implementiert, indem der Status (die Attribute) eines Objekts zwischen den einzelnen Programmausführungen gespeichert wird. Wenn das Objekt erneut benötigt wird, wird es aus seiner gespeicherten Form wieder hergestellt. Der Herstellungsprozeß erzeugt ein neues Objekt, das mit dem ursprünglichen identisch ist. Bei der Persistenz werden den gespeicherten Daten alle Objektattribute (etwa Klassenname, Feldname und Zugriffs-Modifier) zugeordnet, so daß verhindert wird, daß die Daten versehentlich mit einem falschen Objekttyp abgelegt werden.

Stateless und stateful Session Beans Es existieren zwei Arten von Session Beans: Stateless und Stateful. Session Beans speichern keine Daten persistent z.b. auf einem Plattenspeicher. Entity Beans speichern Daten persistent. Diese können sich entweder in einer Objektorientierten Datenbank oder einer relationalen Datenbank befinden.

Stateless Session Beans Stateless Session Beans behalten keine Zustandsinformation von einem Aufruf zum nächsten. Man kann sie wie Funktionsaufrufe verstehen, die allein mit den übergebenen Parametern arbeiten. Zum Beispiel gibt man einen Wert und eine Währung an und erhält den Betrag in Euro. Sie haben keine Persistenz in der Datenbank und repräsentieren deshalb auch keine Datenbankdaten. Vielmehr stellen sie Geschäftsprozesse oder Abläufe dar, die auf Initiative eines Clients hin ausgeführt werden, der ihre Funktionen benutzt. Jeder Methodenaufruf ist hierbei unabhängig von anderen und vorangegangenen Methodenaufrufen. Aufgrund ihrer Zustandslosigkeit sind sie für den EJB Container relativ leicht zu handhaben und verbrauchen nicht viele Ressourcen.

Stateful Session Beans Stateful Session Beans behalten einen Zustand von Aufruf zu Aufruf. Sie beziehen sich immer auf einen Clienten. Verschiedene Clients "sharen" niemals eine Session Bean. Damit der Container den State einer Session Bean besser managen kann, wird ihm im Deployment Deskriptor der Bean mitgeteilt, ob es sich um eine stateless oder stateful Session Bean handelt. Bei einem Bestellvorgang werden, die zuvor selektieren Produkte in der Bestellung belassen. Beim Hinzufügen eines Artikels ein einen Warenkorb sind die vorher hinzugefügten weiterhin vorhanden. Session Beans werden entweder durch ein Time-out oder durch ein explizites Entfernen durch den Client zerstört. Bein Überschreiten eines bestimmten Zeitwerts löscht der Container die Session Bean. Ein Client muss sich darauf einstellen, das sein entferntes Interface nicht mehr gültig ist, weil der Container die Session Bean nach einer längeren Zeit der Inaktivität entfernt hat. Ein Client kann aber auch durch Aufrufen von remove() auf das entfernte EJBObject, die Session Bean entfernen. In jedem Fall wird die ejbremove() der Session Bean vom Container vor der Zerstörung aufgerufen.

Entity Beans Entity Beans repräsentieren für den Client eine objektorientierte Sicht auf einen Datensatz,.B. eine Zeile in einer Datenbank. Sie erlauben im Gegensatz zu Session Beans auch Mehrbenutzerbetrieb, das heißt, dass auf eine Instanz eines Entity Beans gleichzeitig mehrere Benutzer zugreifen können. Der Container, in den Entity Beans während der gesamten Lebensdauer eingebettet sind, stellt dazu entsprechende Mechanismen bereit, um z.b. Sicherheit, Transaktionskonsistenz und Parallelität sicherzustellen. Für den Klienten ist der Container transparent, so dass keine zusätzlichen Schnittstellen existieren, die eine Manipulation des Containers ermöglichen würden. Da Entity Beans nicht an einen einzelnen Client gebunden sind, endet ihre Lebensdauer nicht nach dem Beenden einer Client - Verbindung. Im Gegensatz zu Session Beans können bzw. müssen sie sogar nach einem Systemausfall automatisch wiederhergestellt werden, da in der Regel ihre Existenz an das Vorhandensein der mit ihnen verbundenen Daten gebunden ist. Das heißt, die Erstellung einer Instanz eines Entity Beans erzeugt z.b. automatisch eine neue Zeile in einer Datenbank und fügt die bei der Erstellung mit übergebenen Daten des erstellten Datensatzes der Datenbank hinzu. Wird die Instanz entfernt, wird automatisch der mit dieser Instanz verbundene Datensatz aus der Datenbank gelöscht. Je nachdem, zu welchem Zweck Entity Beans entwickelt worden sind, unterscheidet man auch bei ihnen zwischen zwei verschiedenen Arten: Container managed Persistence (CMP) Entity EJB Bean managed Persistence (BMP) Entity EJB

Container und Bean managed Persistence Bei Container managed Persistence EJBs wird die Persistenz der repräsentierten Daten von dem Container, in den die EJB eingebettet ist, garantiert. Der Entwickler braucht sich bei der Erstellung dieser Art von Entity Beans also nicht darum zu kümmern, wie die Daten des Entity Beans gesichert werden. Der Container kann z.b. zum lesenden und schreibenden Zugriff auf eine relationale Datenbank eigenständig SQL Code generieren und ausführen. Der Entwickler muss somit nur festlegen, welche Daten er von den anzusprechenden Datenbanken im Entity Bean repräsentieren möchte und verknüpft diese dann mit der Bean Klasse. Bei Bean managed Persistence EJBs ist es Aufgabe des Entwicklers, sich um die Art und Weise zu kümmern, wie die Daten des Entity Beans gesichert werden. in der Praxis können aber Situationen auftauchen, z.b. bei einer Datenbankanfrage mittels Join, in denen man mit BMP EJBs durch handoptimierte SQL-Statements eventuell Leistungsverbesserungen erzielen kann. Joins über mehrere Datenbanken mit mehreren Tabellen sind mit CMP EJBs gar nicht oder nur schwer realisierbar, weswegen man auch hier meist BMP EJBs verwendet. Letztendlich kann der Entwickler bei BMP Entity Beans auch das Objektmodell freier gestalten, er ist hier nicht so sehr an das Datenbankschema gebunden wie bei CMP Entity Beans.

Container Managed Persistence (CMP) Das Ziel ist, dass der Entwickler das Datenbankschema nicht kennen muss, sondern dass durch CMP ein Mapping zwischen dem abstrakten und dem physischen Schema vollzogen wird. Die Steuerung der Persistenz soll durch den Server erfolgen. Vom Beanentwickler müssen lediglich die Objekteigenschaften angegeben werden, die gesichert werden sollen. Um Entity Beans persistent zu machen, sieht dieses Konzept die Deklaration sämtlicher Attribute im Deployment Deskriptor vor. Weiterhin muss das objektrelationale Mapping, also die Abbildung zwischen den Attributen und den Datenbankstrukturen, im Deployment Deskriptor angegeben werden. Der Server ist somit in der Lage, selbständig die benötigte Datenbanktabelle zu erzeugen bzw. Eintragungen innerhalb dieser vorzunehmen. Auch bei Änderungen von Attributen einer Entity Bean werden die Daten vom Server automatisch in der Tabelle gespeichert. Bei einer Suchanfrage kommt ebenfalls der Server zum Einsatz. Hierzu verfügt jeder Server über ein Generatorwerkzeug, welches in der Lage ist, aus dem Deployment Deskriptor Code zu erzeugen, der die genannte Funktionalität bietet. Der Beanentwickler muss keinen Programmcode verfassen, die mit dem Datenbankzugriff zusammenhängt. Dies reduziert den Entwicklungsaufwand beträchtlich. Außerdem ergibt sich aus der Abhängigkeit von CMP Entity Beans von einem Generator ein weiterer Vorteil. Man ist unabhängig von der darunter liegenden Persistenzschicht, was zu einer sehr hohen Portierbarkeit führt. Eine verbesserte Wartbarkeit ist dadurch gegeben, dass Änderungen am Namensschema bzw. an den Attributen einer Bean konsistent durch den Generator berücksichtigt werden. Auch die Fehleranfälligkeit ist vergleichsweise gering, woraus folgt, dass der generierte Code nicht so intensiv getestet werden muss, wie selbst geschriebener Quelltext.

Bean managed Persistence EJB Bei Bean managed Persistence EJBs ist es Aufgabe des Entwicklers, sich um die Art und Weise zu kümmern, wie die Daten des Entity Beans gesichert werden. Dies mag auf den ersten Blick ein Nachteil sein, in der Praxis können aber Situationen auftauchen, z.b. bei einer Datenbankanfrage mittels Join, in denen man mit BMP EJBs durch handoptimierte SQL-Statements eventuell Leistungsverbesserungen erzielen kann. Joins über mehrere Datenbanken mit mehreren Tabellen sind mit CMP EJBs gar nicht oder nur schwer realisierbar, weswegen man auch hier meist BMP EJBs verwendet. Letztendlich kann der Entwickler bei BMP Entity Beans auch das Objektmodell freier gestalten, er ist hier nicht so sehr an das Datenbankschema gebunden wie bei CMP Entity Beans.

EJB Client ruft Methoden der Session Bean auf Entity Bean Session Fassade EJB Architektur EJB Client Session Bean Entity Bean Aufgabenteilung: Session Beans enthalten die Business Logik Entity Bean Entity Beans speichern Daten Session Beans: führen Geschäftsprozesse (Business Logik) aus manipulieren persistente Objekte (Daten), die als Entity Beans modelliert sind Probleme mit dem Session Fassade EJB Architektur Modell: Entity Beans sind verteilte Objekte, die von beliebigen Klienten aufgerufen werden können Entity Beans sind transaktionsfähig Beides ist bei einer Session Fassade unnötiger Overhead. Lösungsansatz : Java Data Objects (JDO) an Stelle der Entity Beans. JDOs sind reguläre Java Klassen, die über einen Persistence Encapsulation Mechanismus verfügen. Weitere Alternative: Konnektoren sind Java Klassen, die einen Zugriff auf CICS, Oracle, DB2 ermöglichen.

Message Based Queuing (MBQ) Message oriented Middleware (MOM) Queues are persistent. 1 2 3 4 Solaris Queue Queue z/os DB2 A B Eine Nachricht wird zunächst an eine lokale (persistente) Queue, von dort an eine entfernte Queue, und von dort an einen Empfänger (hier DB2) geleitet. Die Übertragung erfolgt transaktionssicher (ACID Bedingungen werden eingehalten). Schritte 1-3 : Wenn erfolgreich, Antwort senden, sonst retransmit Step 4: Wenn z/os nach DB2 versagt: roll back nach Queue B, dann recover. MOM existiert unabhängig von Java. IBM MQSeries ist Marktführer. Für praktisch alle Betriebssysteme verfügbar: AIX, DG/UX, HP-UX, Windows, OS/390, OS/400, Psion Pervasive SOD, Sequent, Sinix, Solaris, Tandem, TPF, TrueUnix, VMS/VAX.

JMS Message Message Driven Bean Der J2EE Java Message Service (JMS) ist eine Java-spezifische MOM; Er ermöglicht eine Nachrichtenübermittlung durch asynchrone Methodenaufrufe Eine Message Driven Bean (MDB) ist eine spezielle Art einer Enterprise Java Bean (EJB). Eine Message Driven Bean ist ein potentieller Empfänger eines derartigen asynchronen Methodenaufrufes. Dieser Methodenaufruf kann von einer beliebigen anderen Java Klasse ausgehen. Die sendende EJB wartet nicht auf eine Antwort. Eine Message-driven Bean ist ein Bestandteil der Enterprise Java Bean 2.0 Specification. Eine MDB ist ein Java Message Service (JMS) Message Consumer, auf den ein Client nicht direkt zugreifen kann.

JMS Server Message Driven Bean The most visible difference between message-driven beans and session and entity beans is that clients do not access message-driven beans through interfaces. MDBs "listen" on a specific JMS destination, which usually is a queue. When a message arrives on the destination, that message is delivered to the MDB, which causes the bean's onmessage() method to be invoked. The onmessage() method can be viewed as the only interface to an MDB.

Components of the JMS Server Message listener service An MDB (message-driven bean ) knows that a message has arrived at a specific destination through the use of an MDB listener, which in turn is part of the message listener service (also called a JMS server) provided by a Java Web Application Server (e.g. WebSphere). The message listener service manages an MDB's runtime configuration, which includes listener ports and listener settings, and also manages the MDB listener state. A listener manager controls and monitors one or more JMS listeners, each of which monitors a JMS destination. Listener ports A listener port is a component of the Web Application Server that monitors a JMS destination, looks for messages, and is managed by the message listener service. MDBs are bound to a specific listener port. When a message arrives at the destination that the listener port is monitoring, the message is taken off the destination (e.g. a receiving queue) by the message listener service and delivered to the appropriate MDB (message-driven bean).

Message Driven Bean Alle Instanzen eines MDB Typs sind gleich, da sie nicht direkt für den Client sichtbar sind und keine Zustände annehmen. Daraus resultiert die Möglichkeit für den Container, Pools aus MDB Instanzen zu bilden, um Skalierbarkeit zu erzeugen.

Message Driven Beans (MDB) Eine Message Driven Bean ist eine zustandslose Komponente, die von javax.jms.message gesteuert wird. Wie die Session und Entity Beans sind auch MDB serverseitig und transaktionssicher. Eine MDB wird vom EJB Container, in dem sie sich befindet, immer dann aufgerufen, wenn dieser eine Nachricht aus einer JMS Queue (oder einem JMS Topic) erhalten hat. Damit erfüllt eine MDB die Aufgabe eines Message Listeners. Es ist für in einem Applicationserver befindliche MDB von zweitrangiger Bedeutung, wer Absender einer Nachricht ist. Das kann ein Java Client, eine Enterprise Bean, eine JSP Komponente oder aber auch eine Anwendung, die selbst nicht auf J2EE aufbaut, sein. Der allgemeine Client sendet die Nachricht zum EJB Server, ohne sich der einzelnen vorhandenen MDB im Container bewusst zu sein. Der Grund für die mangelnde Sicht auf einzelne MDB ist das Fehlen von Home und Remote Interfaces bei diesem Beantyp. Eine MDB ist vom Typ her eine zustandslose Session Bean. Das bedeutet, dass man es mit relativ kurzlebigen Instanzen der MDB zu tun hat, die sich keinen Client merken können. Durch die Einführung der MDB wird der EJB Container zu einem Listener für asynchrone Aufrufe und ruft direkt (ohne Interfaces) die MDB auf, die sich dann wie eine zustandslose Session Bean verhält.

EJB Schnittstellen Die EJB Object Schnittstelle (remote, lokal) empfängt alle Methodenaufrufe. Sie implementiert die Transaktions- Zustandsverwaltungs, Persistenz- und Sicherheitsdienste für die Bean je nach den Angaben des Deployment Descriptors. Eine EJB Object Schnittstelle ist enteder eine Remote, oder eine Local Schnittstelle. EJB Object Deployment Methoden Descriptor Enterprise Bean Klient find EJB Home create remove Environment EJB Container EJB Home dient der Identifizierung des Beans. Auf die EJB Home Schnittstelle kann mit JNDI zugegriffen werden. Sie implementiert alle Life-Cycle Dienste für die Bean.

EJB Object Schnittstelle The Enterprise Java Bean (EJB) 2.0 specification contains both a remote client view and a (new) local client view. Thus, session and entity beans can have a local home interface, and a local component interface, either with or instead of a remote home interface and a remote component interface (the latter is sometimes called "component interface", omitting the word "remote"). Local and remote interfaces. Which one to choose? Generally, your Enterprise Java Bean will need a remote client view in cases when you plan to use the bean in distributed environments. Specifically, these are the cases when the client that will be working with it will be in a different Java Virtual Machine (JVM). In the case of a remote client view, calling any method from the remote home interface and/or remote component interface will be handled via remote method invocation (RMI). An EJB can use local client view only if it is really guaranteed that other enterprise beans or clients will only address the bean within a single JVM. If this is the case, such access will be carried out with direct method calls, instead of RMI.

Installing (Deploying) a newly developed Application within a CICS Server CICS is a production server. New applications are developed outside the CICS Server. If you want to develop a new CICS application, you first develop it on a development Server (an IDE, Integrated Development Environment, for example Eclipse), then test it on a separate test system, and the install (deploy) it on the CICS production Server. When you install a new application on a CICS production Server, you first define it to CICS, using one or several define commands.. This assures that CICS can find the new application whenever it is called. Subsequently you install it, which involves copying the new code (and related information) into the CICS address space.

Installing (Deploying) a newly developed Application within a Web Application Server Just like CICS, a Web Application Server is a production server. New applications are developed outside the Web Application Server. The equivalent of the CICS define command is the Java EJB Deployment Descriptor. The equivalent of the CICS install command is called deployment.

Emterprise Bean remote Interface Deployment Descriptor Home Interface Implementation Beispiele für Parameter: EJB *.jar File EJB Container Datenbank Name Verbindung zu Legacy Anwendungen JNDI Namensraum des Containers Transaktions-Semantik Umgebungseigenschaften Deployment Descriptor Der Deployment Descriptor legt die Laufzeit Parameter einer EJB fest Parameter können statisch zur Assembly Zeit oder dynamisch zur Laufzeit festgelegt werden Der Deployment Descriptor wird typischerweise durch den EJB Entwickler angelegt, kann aber durch einen Administrator mit Hilfe eines Tools abgeändert werden

Deployment Descriptor Der Deployment Deskriptor ist eine Datei im XML Format, die eine oder mehrere Beans, deren Zusammenwirken und die Art, wie der EJB Container sie zur Laufzeit behandeln soll, beschreibt. Er enthält hauptsächlich deklarative Informationen, welche nicht im Bean Code zu finden sind. Dies sind vor allem Informationen über die Struktur der Bean und ihrer Abhängigkeiten zu anderen Beans oder Ressourcen wie z. B. einer Datenbankverbindung. Außerdem können im Deployment Deskriptor Umgebungsvariablen gesetzt werden, die von der Bean ausgelesen werden können und somit ihr Verhalten beeinflussen. Dies führt zu einer höheren Flexibilität, da dieselbe Bean in verschiedenen Umgebungen eingesetzt werden kann und nur der Deployment Deskriptor angepasst werden muss.

Werkzeuge: Erstellen, Test, Deploy, Manage JTS JDBC JNDI IIOP Enterprise Java Bean Container Session Beans, Entity Beans EJB Container Interface Servlet Container Native HTTP Server plug-in HTTP Server Apache, IIS, Netscape, Lotus Aufgabenaufteilung Der Web Server (http Server) betreut statische HTML Seiten, CGI und proprietäre Plug-ins Der Servlet Container ist die Laufzeitumgebung für Java Servlet Anforderungen und dynamische Seitenanforderungen (JSP) Die Servlets und JSPsbehandeln HTTP Anforderungen, verwaltet HTTP Sessions mit dem Klienten, erzeugt Presentation Logic via HTML, bewältigt nichttransaktionale (Business) Anwendungen Session und Entity Beans bewältigen (Business Logic) Anwendungen mit transaktionaler Integrität Struktur eines Web Application Servers

Web Server HTTP Server The Apache HTTP Server is a web server notable for playing a key role in the initial growth of the World Wide Web and in 2009 became the first web server to surpass the 100 million web site milestone. Apache was the first viable alternative to the Netscape Communications Corporation web server, currently known as Sun Java System Web Server. Apache is developed and maintained by an open community of developers under the auspices of the Apache Software Foundation. Internet Information Services (IIS) - formerly called Internet Information Server - is a set of Internet-based services for servers created by Microsoft for use with Microsoft Windows. It is the world's second most popular web server in terms of overall websites behind the industry leader Apache HTTP Server. IBM HTTP Server (IHS) is a web server based on the Apache Software Foundation's Apache HTTP Server that runs on AIX, HP-UX, Linux, Solaris, Windows NT, and z/os. It is available for download and use free of charge. The HTTP server is also included in the IBM WebSphere Application Server distribution packages. The Lotus Domino server provides enterprise-grade e-mail, collaboration capabilities, and a custom application platform. Its core services include: Email server (supporting Lotus Notes, POP3, IMAP, web browser and Outlook clients and SMTP support) Applications server (the Lotus Notes client provides the runtime) Web server (Lotus Notes data or other surfaced via a web browser) Database server (Notes Storage Facility) Directory server (LDAP) Die Namen Web Server und HTTP Server hatten ursprünglich die gleiche Bedeutung. Heute sind die Begriffe Web Server und http Server zweideutig, weil man teilweise hierunter einen HTTP Server mit integriertem Servlet Container versteht. Auch der Servlet Container wird häufig als Web Container bezeichnet.

Plug-in code The WebSphere HTTP Server plug-in is code that runs inside various Web servers: IBM HTTP Server, Apache, IIS, others. Requests are passed over to the plug-in, where they are handled based on a configuration file. The plug-in is code supplied with WebSphere. As workload comes into the HTTP Server, directives in the HTTP Server's configuration file (httpd.conf) are used to make a decision: is the incoming work request something the HTTP Server handles, or is it something that is to be passed over the plug-in itself. Once inside the plug-in, the logic that acts upon the request is determined by the plug-in's configuration file, not the HTTP Server's. That configuration file is by default called the plugin-cfg.xml file. Information on which of the supported application servers the request is to go to, is defined in this file. This file is something that is created by the WebSphere Application Server and mostly doesn't need modifying. In general, plug-ins provide functionality extensions for HTTP Server. There are many different plug-ins that can be configured to assist in customization of your Web environment. Another popular plug-in is the Lightweight Directory Access Protocol Server (LDAP) used for security authentication.

HTTP Server plugin This plugin is usually a.dll or.so file It is included in the webserver's configuration file as a plugin (Service statement on z/os) It usually has it's own configuration, located in a file (or some other location). It runs just like an API application in the HTTP server. Performs some very specific functions for the Application Server, as an example 1. Load balancing across multiple App Servers, 2. Enforcing Server affinity, 3. Routing requests based on an URL. The z/os HTTP Server has many facilities, which extend the functions of a basic Web server application server (WAS). One of these functions is the Plug-in interface of the z/os HTTP Server. This allows one of several products to interface with HTTP Server. Here, for example, are some ways in which HTTP Server can pass control to WebSphere; WebSphere plug-in, same address space Web container (Servlet Container) inside HTTP Server, separate EJB container Separate J2EE server with both Web container and EJB container