Document

Enterprise Computing
Prof. Dr.-Ing. Wilhelm G. Spruth
WS 2010/11
Teil 10
Enterprise Java Beans
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.
Mainframe
PC,
Workstation
Java 2
Editionen
Embedded
Devices,
Klein- und
Kleinstgeräte
J2EE (1)
Die Java Platform, Enterprise Edition, abgekürzt Java EE oder früher J2EE, ist die
Spezifikation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in Java
programmierten verteilten Geschäftsanwendungen und insbesondere Web-Anwendungen.
Darin ist spezifiert:
• Enterprise JavaBeans (EJB), die Komponenten der Geschäftsanwendungen,
• Infrastruktur zur Ausführung von EJBs.
Die Infrastruktur beinhaltet Web-Applikationsserver mit sogenannten Containern, in denen
die EJBs ausgeführt werden. Der Server beziehungsweise der Container
•
•
•
•
interagiert mit den Unternehmenssystem-Ressourcen (z.B. Datenbank)
übernimmt die Interaktion mit verteilten Beans in anderen Servern und Maschinen.
kontrolliert die Ausführung von selbst definierten Transaktionen
handhabt Sicherheitseinstellungen.
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 Konfguration ist der HTTP Server (Web Server) 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 a servlet
or an EJB to access an application database.
Der Servlet Container wird häufig auch als Web Container bezeichnet.
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
http
Server
Apache
Microsoft IIS
Lotus
……..
Java
Application
Server
Websphere
Weblogic
Netweaver
Geronimo
http Server – Web Application Server Interconnection
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
Drei verschiedene Arten
von EJBs
E
S
S
• Entity Beans
EJB Container
(andere Bezeichnungen:Laufzeitumgebung,
Framework, Object Transaction Monitor - OTM)
EJB Server
(Web Application Server)
• Session Beans
• Message Beans
S
Session Bean (transientes Objekt)
M
E
Message-driven Bean
Entity Bean (persistentes Objekt)
• EJBs sind Komponenten, die auf dem Server ablaufende Geschäftslogik implementieren. Sie
modellieren Geschäftsprozesse, wie z.B. eine Überweisung.
• 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.
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.
Session Bean
Man unterscheidet zustandslose (stateless) und zustandsbehaftete (stateful) Session
Beans.
Eine zustandsbehaftete Session Bean hat ein eigenes Gedächtnis. Sie kann Informationen
aus einem Methodenaufruf speichern, damit sie bei einem späteren Aufruf einer anderen
(oder der gleichen) Methode wieder zur Verfügung stehen. Die Zustandsbehaftung wird
durch die Vergabe einer eindeutigen ID umgesetzt, über diese ID können die
zustandsbehafteten (stateful) Session Beans unterschieden werden.
Im Gegensatz dazu müssen einer zustandslosen Session Bean bei jedem Aufruf alle
Informationen als Parameter übergeben werden, die für die Abarbeitung dieses Aufrufs
benötigt werden. Da eine zustandslose Session Bean keine Informationen speichern kann,
ist sie nicht von anderen Session Beans der gleichen Klasse unterscheidbar, sie hat also
keine eigene Identität.
Entity Beans
Entity Beans repräsentieren für den Client eine objektorientierte Sicht auf einen Datensatz,
z.B. eine Zeile in einer Datenbank. Sie erlauben im Gegensatz zu Session Beans auch
Mehrbenutzerbetrieb: Auf eine Instanz eines Entity Beans können gleichzeitig mehrere
Benutzer zugreifen. 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.
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.
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. Der EJB 3.0 Standard enthält die Java
Persistence API als eine Alternative zu den Entity Beans. Entity Beans werden heute als „deprecated
technology“ betrachtet.
Weitere Alternative: „Konnektoren“ sind Java Klassen, die einen Zugriff auf CICS, Oracle, DB2
ermöglichen.
Message Based Queuing (MBQ)
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.
MBQexistiert 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 ein Java-spezifisches MBQ; es 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. Der Sender (z.B. eine
remote EJB, oder aber auch ein nicht-Java Objekt) 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
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.
An MDB (message-driven bean ) knows that a message has arrived at a specific destination
through the use of an MDB listener, which is provided by a Java Web Application Server
(e.g. WebSphere).
EJB Schnittstellen
Die „EJB Object“ Schnittstelle (remote, lokal) empfängt alle Methodenaufrufe (z.B. get, put, modify).
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, an Enterprise Java Bean will need a remote client view if the bean is to be used
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.
Emterprise Bean
remote Interface
Home Interface
Implementation
Deployment Descriptor
Beispiele für Parameter des Deployment
Descriptors:
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 EJBs,
• 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 EJB – Code
zu finden sind. Dies sind vor allem Informationen über die Struktur der EJB und ihrer
Abhängigkeiten zu anderen EJBs oder Ressourcen wie z. B. einer Datenbankverbindung.
Außerdem können im Deployment Deskriptor Umgebungsvariablen gesetzt werden, die
von der EJB ausgelesen werden können und somit ihr Verhalten beeinflussen. Dies führt zu
einer höheren Flexibilität, da dieselbe EJB in verschiedenen Umgebungen eingesetzt
werden kann und nur der Deployment Deskriptor angepasst werden muss.
Vergleich CICS – Enterprise Java Beans
CICS
EJB
Definition
Define
Command
Deployment
Descriptor
Installation
Install
Command
Deploy
Command
Package
Anwendungsprogramm
Mapset
TRID
Group
xxxx
yyyy
zzzz
CICS Group
JAR, WAR, EAR