Enterprise Java Beans(1,5 MByte)

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.
WEB
Browser
HTML
Enterprise
Java
Bean(s)
SQL
JDBC (oder
andere)
WEB
Browser
WEB
Server
Servlet
JSP
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
Server
Servlets
JSPs
EJBs
SQL
HTTP
Server
Servlet
Container
EJB
Container
Backend
Java Application Server
Browser
Web Application Server
Bevorzugte
Struktur
eines Web
Application
Servers
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
JTS
JIDL
JNDI
JMS
JMAPI
JDBC
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
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 Session Bean (transientes Objekt)
M Message-driven Bean
E Entity Bean (persistentes Objekt)
S
S
EJB Container
(andere Bezeichnungen:Laufzeitumgebung,
Framework, Object Transaction Monitor - OTM)
Drei verschiedene Arten
von EJBs
• Entity Beans
• Session Beans
EJB Server
(Web Application Server)
• 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.
Entity Bean
EJB Client ruft
Methoden der
Session Bean auf
EJB Client
Session Fassade
EJB Architektur
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)
1
Solaris
2
3
Queue
Queue
A
B
4
z/OS
DB2
Queues are persistent.
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
Descriptor
Methoden
Enterprise Bean
Klient
find
create
remove
Environment
EJB Home
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
Home Interface
Implementation
Deployment Descriptor
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
Aufgabenaufteilung
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
Struktur eines Web Application Servers
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
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
WebSphere plug-in,
same address space
Address space
Address space
This figure shows a simple configuration in which no J2EE server is needed. This servlet can connect
to CICS or IMS, or to DB2 through JDBC. However, coding business logic inside servlets is not
recommended.
Address space
Address space
Address space
Servlet container inside HTTP Server, separate EJB container
The figure above shows a more usable configuration in which the servlets run in a different
address space than the EJBs, so the EJBs are invoked from remote calls using the
RMI/IIOP protocol. The EJBs frequently then get information from other servers, for
example CICS.
Address space
Address space
Address space
Separate J2EE server with both Web container and EJB container
In addition to running your servlets locally within the WebSphere plug-in, you can also use
the WebSphere plug-in to run servlets remotely in a Web container, as shown above. This
allows you to localize your servlets and EJBs to the same z/OS address space, so that no
remote EJB calls (using the RMI/IIOP protocol) are required.
WebSphere includes a Web Component (the Web
or Servlet Container and an EJB Component (EJB
Container). Not shown is the HTTP Server (Web
Server).
Web-Application Server Schnitstellen zur Außenwelt
Not shown is the HTTP Server (Web Server).
Java Archive (jar)
The jar tool combines multiple Java files into a single JAR archive file.
jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB
compression format. Compression reduces bandwidth when downloading an applet.
However, jar was designed mainly to facilitate the packaging of java applications into a
single archive.
ejb – jar – Datei
jar is a general-purpose archiving and compression tool, based on ZIP and the ZLIB compression
format. Compression reduces bandwidth when downloading an applet. However, jar was designed
mainly to facilitate the packaging of java applications into a single archive.
Files with a .jar extension or JAR files, are essentially just a collection of files.
Eine ejb – jar – Datei ist das standardmäßige Verpackungsformat für Enterprise JavaBeans. Dabei
handelt es sich um eine normale Java – ARchivdatei (JAR), die mit Hilfe des Hilfsprogramms jar
erzeugt werden kann. Sie enthält aber spezielle Dateien, die alle jene Informationen zur Verfügung
stellen, die ein EJB – Container zur Inbetriebnahme der in der JAR – Datei enthaltenen Beans benötigt.
In einer ejb – jar – Datei gibt es zwei Arten von Inhalten:
• Die Klassendateien aller Beans einschließlich ihrer Home – und Client – Interfaces sowie die Bean –
Implementationen. Darüber hinaus können auch containergenerierte Klassen enthalten
sein.(beispielsweise konkrete Implementierungen der Home – und Client – Interfaces ).
• die Deployment Deskriptor – Dateien. Als Minimum muss eine ejb – jar – Datei, eine standardmäßige
ejb – jar.xml – Datei enthalten sein.
Die kompilierten Java – Klassen, aus denen die EJBs bestehen, befinden sich in packagespezifischen
Verzeichnissen innerhalb der ejb – jar – Datei, genau wie es bei normalen JAR – Dateien der Fall ist.
Der Deployment Deskriptor, mit dem die EJBs beschrieben und konfiguriert werden, muss in der ejb –
jar – Archivdatei unter META-INF/ejb-jar.xml zu finden sein.
Web Archiv (WAR)
The war file contains the web application that can be deployed on the any servlet/jsp container. The .war file
contains jsp, html, javascript and other files for necessary for the development of web applications.
Eine WAR – Datei (Web ARchiv) dient standardmäßig dazu, Web – Anwendungen zu verpacken.
In einer WAR – Datei gibt es drei Arten von Inhalten:
• Die Klassendateien aller Servlets, die Bestandteil der Webanwendung sind. Diese sind unter dem
Verzeichnis WEB-INF/classes in einer package – spezifischen Verzeichnisstruktur zu finden.
• Die statischen HTML – Seiten, welche für das Ausführen der Webanwendung nötig sind. Es ist aber auch
möglich, JSP – Seiten, als dynamische Generierung von Response – Seiten zu verwenden. Diese
Dokumente befinden sich innerhalb der WAR – Datei in einer Verzeichnisstruktur. Zum Beispiel könnten alle
Bilder im Verzeichnis images abgelegt sein, während die index.html im context – root des Archivs liegt.
• Die Deployment Deskriptor – Dateien. Der Deployment Deskriptor eines Web – Archives ist, wie auch schon
der ejb – jar – Deskriptor, eine XML – Datei, welche eine Beschreibung der Anwendung, die Namen und die
Parameter der Servlets zur Laufzeit, sowie sessionrelevante Einstellungen enthält. Als Minimum muss eine
standardmäßige web.xml – Datei enthalten sein, welche im Verzeichnis WEB-INF zu finden ist. Wie bei den
Java Archiven ist es auch hier möglich, das noch weitere Deskriptoren, je nach Art des Produktes und des
Herstellers, in dem Web – Archiv Verwendung finden.
Außerdem werden auch Sicherheitsaspekte, wie zum Beispiel der Loginmechanismus einer Anwendung
definiert.
web.xml
Der Deployment Deskriptor eines Web – Archives ist, wie auch schon der ejb – jar – Deskriptor, eine
XML – Datei, welche eine Beschreibung der Anwendung, die Namen und die Parameter der Servlets zur
Laufzeit, sowie sessionrelevante Einstellungen enthält.
Außerdem werden auch Sicherheitsaspekte, wie zum Beispiel der Log-in-mechanismus einer
Anwendung definiert.
EAR – Archive
Zusammenspiel von WAR, JAR und EAR
Eine J2EE Anwendung besteht aus Web – und EJB – Komponenten. Beide Arten von
Komponenten sind in Archiven verpackt, Verhalten und Eigenschaften sind in Deployment
Deskriptoren (DD) definiert. Alle Komponenten einer Anwendung sind in einem EAR
(Enterprise Application Ressource) zusammengestellt. Eine vollständige Anwendung kann
durch Installation eines EAR – Files auf einen anderen Application Server verteilt werden
und sollte sich dort wie erforderlich konfigurieren lassen.
DD
Deployment
Descriptor
Die Application.xml – Datei ist eine XML – Datei, welche nur die Namen der Enterprise – Anwendung und deren
Bestandteile enthält.
Tag Library :
see below
WebSphere Application Server for z/OS
Unter z/OS besteht ein WebSphere Application Server (WAS) aus einem Controller und
mehreren Servants. Controller und Servant besitzen jeder eine eigene JVM, in der jeweils
ein Servlet Container und ein EJB Container laufen.
Servant
Controller
Servant
Servant
WebSphere Application Server (WAS)
Controller und Servant laufen in unterschiedlichen virtuellen Adressenräumen; der
Controller läuft mit Speicherschutzschlüssel 2 und im Kernel Status. Die Servants laufen
mit Speicherschutzschlüssel 8 im User Status.
Normalerweise eine (oder wenige) Anwendungen in einem Servant.
Basic WebSphere Runtime Structure on z/OS
A WebSpere Application Server (WAS) Servant houses Servlets, EJBs. and other Java
classes. Queues managed by the Workload Manager (WLM) are used to distribute incoming
messages to multiple Servants. Each servant runs in its own z/OS region.
In the WebSphere Application Server for z/OS environment, the classification of each
transaction is managed by a control region. This is a sepatate process running in its own
virtual address space. The control region acts as a queuing manager that queues work
requests to workload management for execution in server address spaces.
HTTP Protocol Catcher
In general, an “HTTP Protocol Catcher” is any program which communicates on the TCP/IP network using requests
formatted in HTTP protocol. A protocol catcher understands the HTTP protocol and is capable of interpreting from the
request format what the target of the request is. When WebSphere for z/OS is active on the same system, a protocol
catcher can be used to route appropriate requests to WebSphere for z/OS web applications for processing.
In WebSphere for z/OS, the primary protocol catcher is known as the HTTP Internal Transport. See (2) in the Figure
above. This WebSphere component is configured to run in the Controller (CR) address space of a J2EE application
server. The Internal Transport component will listen for incoming protocol requests using selected ports on the
TCP/IP stack. When a request is received, the Internal Transport validates that the request can execute in this server.
Provided the request is valid, the Internal Transport routes the request for execution to the web container in this
server.
The other supported HTTP protocol catcher on z/OS is the IBM HTTP server, which uses port 80 as a default.. See (1)
in the Figure above. The HTTP server listens for incoming HTTP requests from remote clients on the network. You
can activate the WebSphere HTTP Plug-in component in the HTTP server address space. The plug-in can be
configured to filter HTTP requests received by the HTTP server and direct requests to run WebSphere web
applications to the Internal Transport function of the appropriate J2EE application server.
The plug-in uses HTTP protocol to re-direct the Web request to the WebSphere for z/OS Internal Transport. The J2EE
Internal Transport validates the incoming request and then schedules the request to run in the web container of the
application server.
It is worth stressing here that once the request has reached the web container, the web application is scheduled in
the same way, irrespective of the way in which the request was “caught”. So the web application does not need to be
aware of the route by which the request arrived, although it can find this out if it is important.
The HTTP Internal Transport is a component that
executes in the CR address space of a z/OS J2EE
application server. The Internal Transport will bind
to two selected TCP/IP port addresses, which are
configured by the WebSphere for z/OS V
administrator, and listen for incoming requests.
When an HTTP request is received, the Internal
Transport checks the URL of the web container
definition in the application server configuration to
see if it matches a web application supported by this
J2EE server. If this request is supported, the HTTP
handler schedules the associated web application in
the web container; if not, the request is failed.
Basic WebSphere Runtime Structure on z/OS
•
•
•
•
•
•
•
The basic execution environment for WebSphere on z/OS is a server.
A server is a Controller/Servant configuration,
In WebSphere z/OS a region is a virtual address space
For every Controller there are one or more Servant Regions
The Controller is the protocol entry point.
Multiple protocols are supported: HTTP(S) and IIOP.
The Servant Region is where the J2EE components execute, with a WLM Queue
between them
• There can be multiple servers on a single z/OS system (image).
WebSphere Application Server for z/OS
Organization based on concepts:
• Servers
• Nodes (and Node Agents): a logical grouping of WebSphere-managed servers
• Cells: a grouping of Nodes
z/OS and Work Load Manager
To balance work on the system, WebSphere uses the services of the WorkLoad Manager (WLM)
provided by z/OS and z/OS. Three distinct WLM services are employed by WebSphere:
1. Routing
The WLM routing service is used to direct clients to servers on a specific z/OS server, based on a
measurement of current system utilization known as the performance index.
2. Queuing and address space management
The WLM queuing service is used to dispatch work requests from the Websphere Application
Server for z/OS Control Region to one or more Websphere Application Server for z/OS Server
Regions. It is possible for a Work Manager to register with WLM as a “queueing manager” (e.g.,
Websphere Application Server for z/OS Control Region is a Queue Manager). This tells WLM that
this server would like to use WLM-managed queues to direct work to other servers, which allows
WLM to manage server spaces to achieve the specified performance goals established for the
work.
3. Prioritizing work to meet performance goals
WebSphere delegates the responsibility for starting and stopping Server Regions to the WLM
Address Space management service. This allows WLM to manage application server instances in
order to achieve the performance goals specified by the business.
WebSphere Scalability under z/OS
Scalability is a problem with most Unix, Linux and Windows implementations. The following figures
represent the results of a WebSpere scalability test under z/OS
The test was performed with five z990 Systems, with 16 CPUs each, and an additional z990 with 4 CPUs
configured as a coupling facility.
Trader Benchmark
z/OS uses for many tests a standard client/server benchmark called the Trader application. This
benchmark has been repeatedly updated over the years and is now available in versionTrade V6.1.
Shown above is the Topologie of the Trade V6.1 Benchmark.
CPUs
WebSphere Scalability for the Trader benchmark, single System
These are the benchmark results. for a single system with 8 CPUs.
18 585
WebSphere Scalability for the Trader benchmark, five Systems
A single system with 16 CPUs is able to handle 3 717 Trader transactions/s. The theoretical maximum for 5 systems is
5 x 3717 tx/s = 18 585 tx/s. The actual measured throughput is 15 947 tx/s, or 15 947 / 18 585 = 86 % of the theoretical
maximum.
The Java Management Extensions (JMX) technology represents a universal, open technology for management, and monitoring
Animation in F:\qrx\2005-2008\websphere\wasv6_architecture
Neue
Dienste
IMS/DB
Client/Server Aufgabenstellung
DB2
WAS
CICS
Internet
Servlet
EJB
Tuxedo
Presentation
Glue
SAP
• Browser orientierter Web Zugang
• Datenhaltung in existierenden
Datenbanken
• Dominierender Anteil der Business Logik
in existierenden Transaktionsprogrammen
und/oder Stored Procedures
• Neue Software (z.B. EJBs) stellen
Querverbindungen zwischen existierenden
Komponenten her (Glue)
• System Management - TCO
Browser
IMS/DC
Unternehmens-Architektur
Die Anpassung existierender Transaktionsmonitor- oder Stored Procedure Anwendungen an das Internet erfolgt über
einen vorgeschalteten Web Application Server, z.B. WebSphere. EJBs übernehmen nicht die Aufgaben existierender
transaktionaler Mainframe Anwendungen, sondern ergänzen diese. Zusätzlich werden mit EJBs neue Dienste
implementiert, besonders dann, wenn nur mäßige Anforderungen bezüglich Transaktionssicherheit und
Zuverlässigkeit bestehen. Die persistente Datenspeicherung erfolgt beispielsweise über DB2.