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
*
*
gebucht_auf
gebucht_von
1
personen.Kunde
1
besitzt
1
kontoführung.Konto
Attributes
1
Kontostand:Integer
PIN:String
Kontonummer:Integer
Von Systemoperationen zu
Enterprise Komponenten
sd interne Überweisung
:Kunde
Systemschnittstelle
(Controller)
1: authentifizieren(String user, String password)
ok=authentifizieren(String user, String password)
Systemoperationen
loop
2: enterData(String name, String nr, String zweck, int betrag)
enterData(String name, String nr, String zweck, int betrag)
3: buchen()
buchen()
4: abmelden()
:System
Von Systemoperationen zu
Enterprise Komponenten
• Die Systemoperationen werden typischerweise in
Controllern zur Verfügung gestellt
• Im Beispiel:
Schnittstelle nach aussen
Systemoperation
Implementierung der Operation
Enterprise Java Beans
• Produkt von Sun Microsystems, momentan in Version
3.0 verfügbar, Spezifikation JSR 220 von Mai 2006
• benötigt einen Server als Laufzeitumgebung (z.B. Sun
Java System Application Server Platform Edition 9 basiert auf glassfish (open source))
• Andere EJB Server: JBOSS (redhat), IBM Websphere,
Geronimo (Apache)
• Server stellt Container zur Verfügung, der Lösungen für
die Enterprise-Challenges bereitstellt
• Programmierer kann seine Business Logik als EJB
implementieren und in den Container deployen,
Container macht daraus eine Business Applikation
Architektur des Beispiels
Die vertikale Dimension
Web Browser
Präsentationsschicht
Anwendungslogik
Java Server Faces
Application Server
Enterprise Beans
Entity Classes
Datenhaltung
Datenbank
Remote Method Invocation /
Distributed Objects
Distributed
Object
Client
Remote Interface
Remote Interface
Stub
Skeleton
Network
Remote Invocation –
was passiert?
• Marshalling:
– Umwandlung von Daten in eine zur Übertragung über
das Netzwerk brauchbare Form
• Unmarshalling:
– Rückwandlung der übertragenen Daten und
Herstellung eines plattformspezifischen Formats
• Konzepte: Stub und Skeleton
Technisch
– Ein (Client-)Stub ist ein Stück Code im Client, das
den Remote-Aufruf transparent macht
• Marshalling – Unmarshalling
• Senden der Nachricht
• Empfangen der Antwort
– Ein Skeleton (auch Server-Stub) ist das Gegenstück
auf dem Server
• Marshalling – Unmarshalling
• Empfangen der Nachricht
• Aufruf der Methode auf dem Server
• Senden der Antwort
bei EJBs: Remote Invocation nach dem Standard RMIIIOP (RMI over Internet Inter-ORB (=Object Request
Broker))
Was fehlt?
• Wichtige Punkte in Business Anwendungen
– Security
– Persistenz
– Transaktionen
• Wie werden diese Probleme gelöst?
Implizite Middleware
Distributed
Object
Transaction
Service
Remote Interface
Client
Request
Interceptor
Remote Interface
Remote Interface
Stub
Skeleton
Network
Database
Service
Security
Service
Was sind nun EJBs?
•
•
Eine Enterprise Bean ist ein verteiltes
Objekt zusammen mit ihrem Remote
Interface
In Java Termini:
EJB
– einfach eine Java Klasse samt Interface
•
•
oftmals genannt: POJO, POJI (Plain Old
Java Object / Interface)
In den Termini der JSR 220:
– Remote Interface heißt auch “Business
Interface”
•
Der Application Server stellt die Request
Interceptors zur Verfügung (hier kann man
allerdings auch noch händisch
Implementierungen hinzufügen)
Business Interface
Komponenten in einer Java EE
Architektur
•
•
Die Enterprise Java Beans werden unterschieden in:
Session Beans
– Stateful Session Beans
– Stateless Session Beans
•
Message Driven Beans
– kommunizieren asynchron mittels Nachrichten
– (nicht Teil der Vorlesung)
•
Umsetzung im Source Code durch Annotationen an die Klasse
–
–
–
–
Stateful Session Bean:
Stateless Session Bean:
Message Driven Bean:
Business Interface:
@Stateful
@Stateless
@MessageDriven
@Remote
Session Beans
• Session Beans kommunizieren über RMI-IIOP
• Zuordnung: ein Client zu einer Session Bean
• Stateless Session Beans implementieren
Systemoperationen, bei denen man sich keine
Sessioninformation merken muss
– typischerweise: Operation A kam dran vor Operation
B, Ergebnis von A wird in B benutzt, dieses muss
zwischengespeichert werden
– Session = Moment der ersten Benutzung bis zum
expliziten Beenden der Session bzw. Timeout
Session Beans
• bei Stateful Session Beans wird jede Bean jeweils
einem Client zugeordnet
– d.h. beim Aufruf der zweiten Methode innerhalb der
selben Session hat die Session Bean den selben
Zustand (Felder der Klasse), wie nach dem Ende des
ersten Aufrufs
Enterprise Beans – Business
Interface
• Enterprise Beans stellen Systemoperationen über ein
Business Interface (= normales Java Interface) zur
Verfügung
sd interne Überweisung
:Kunde
:System
1: authentifizieren(String user, String password)
ok=authentifizieren(String user, String password)
loop
2: enterData(String name, String nr, String zweck, int betrag)
enterData(String name, String nr, String zweck, int betrag)
3: buchen()
buchen()
4: abmelden()
@Remote
public interface BenutzerControllerRemote {
boolean authentifizieren(String user, String pw);
String enterData(String name, int kontonr,
String zweck, int betrag);
boolean buchen();
Systemoperationen
für Überweisung
int getKontostand();
Kontoauszug getKontoauszug(Date start, Date end);
String getCurrentName();
}
andere
Systemoperationen
Bean-Implementierung
• Beim Login: Merken des derzeitigen Kunden in der Bean
– entspricht „Controller-Gedanken“
@Stateful
public class BenutzerControllerBean implements BenutzerControllerRemote {
…
private Kunde current;
public boolean authentifizieren(String user, String pw) {
int knr = Integer.parseInt(user);
Konto k = getKonto(knr);
if(k != null && k.getPin().equals(pw)){
current = k.getBesitzer();
return true;
}
return false;
}
}
sd interne Überweisung
:Kunde
1: authentifizieren(String user, String password)
ok=authentifizieren(String user, String password)
loop
2: enterData(String name, String nr, String zweck, int betrag)
enterData(String name, String nr, String zweck, int betrag)
3: buchen()
buchen()
4: abmelden()
:System
spätere Operationen bauen
darauf auf!
@Stateful
public class BenutzerControllerBean implements BenutzerControllerRemote {
…
alter Zustand
public boolean buchen() {
Konto zk = getZielkonto();
Konto qk = current.getKonto();
String betrag = getBetrag();
String zweck = getZweck();
int qks = qk.getKontostand();
if(betrag <= qks ){
Ueberweisung nu =
Ueberweisung.erstelleUeberweisung(betrag, zweck, qk , zk);
nu.buchung_durchfuehren();
analog: getZielkonto() … wurde definiert
return true;
}
durch SysOp enterData()
return false;}
}
Bean Pooling
•
Container verwaltet einen ganzen Pool von EJBs:
Container
Pool
Session Bean
Client
Business
Interface
Session Bean
Session Bean
Session Bean
•
•
bei stateless Beans kann der Container jeden Aufruf an eine
beliebige Bean Instanz weiterleiten
bei stateful Beans muss es pro Session immer die selbe Bean sein
Sicht des Clients
• Wie werden nun Systemoperationen aufgerufen?
• Genauer: Wie bekommt man eine Remote-Referenz auf
eine EJB?
• Antwort: JNDI
– Java Naming and Directory Service
– Namensdienst, an sich unabhängig vom EJB-Container
– Jede Bean-Klasse bekommt beim Deployment einen
eindeutigen JNDI-Namen (ein String), mit dem man sie
ansprechen kann.
(Web) Services
Was passiert, wenn man fremde
Komponenten verwenden muss
• konkretes Beispiel:
– Abwicklung einer Überweisung an eine Fremdbank
• Bei internen Überweisungen: „einfach“ +/- auf den
Konten rechnen
• Bei externen Überweisungen: Einbindung einer
Softwarekomponente eines Dritten nötig!
– (etwas abstrahiertes) Szenario unseres Beispiel:
• Fremdbank-Überweisung wird über einen Dritten
abgewickelt, Rückmeldung über Erfolg kommt asynchron
über andere Softwarekomponente, wir verbuchen sofort auf
dem Quellkonto
• Wie geht das?
Möglichkeiten
• Man könnte:
– wiederum EJBs verwenden
• dafür muss allerdings die Gegenseite (der „Dritte“) auch
EJBs verwenden und seine Business-Interfaces ausliefern
– proprietäre Datenübertragungsformate definieren, „alles
selbst machen“
– Web Services benutzen
Services, technologische Vision
• Unabhängigkeit von Programmiersprachen durch
standardisiertes Datenaustauschformat
• Serviceorientierte Architektur
• Lose Kopplung durch Integration über das Internet
– Idee der losen Kopplung:
• Server stellen Schnittstellen in einem standardisierten
Format nach aussen zur Verfügung
• Darin sind alle Informationen enthalten, die der Client zur
Benutzung der Dienste benötigt
• Damit werden Clients auch ohne „Implementierungswissen“
über den Serverdienst programmierbar
Web Services, was ist das?
• Definition:
• Web Services sind
–
–
–
–
–
–
–
abgeschlossene
beliebig komplexe
selbsterklärende Software-Komponenten
beschrieben mittels einer formalen Definition (XML)
die über ein Standard-Protokoll
veröffentlicht, gesucht und gefunden werden können und
sich mit anderen Komponenten verbinden können
Effiziente Projektabwicklung mit
Web Services
• Automatische Generierung von Schnittstellencode (Stub)
• Keine komplizierten Installations- und
Anpassungsarbeiten
• Geringer Einarbeitungsaufwand, wenig Spezialwissen
notwendig
• XML-Format vereinfacht Tests und Überwachung
• Kostengünstige oder frei verfügbare (Open-Source)Tools für Pilotprojekte
• Umfassende Unterstützung der Anwendungsentwicklung
durch Plattformen
• Unabhängigkeit von Herstellern
Integration mit Web Services
• Die Nutzung von Web Services erleichtert die
Durchführung von Integrationsprojekten
• denn:
– Web Services ermöglichen die Wiederverwendbarkeit von
Funktionalitäten in unterschiedlichen Zusammenhängen
– Web Services ermöglichen die Modellierung von
Geschäftsprozessen auf einer fachlichen, nichttechnischen
Ebene
– Workflow-Code lässt sich automatisch generieren
– Legacy-Anwendungen können leichter eingebunden
werden
Web Services
• Abstraktionsebenen bei Web Services:
BPEL4WS
Service Flow
Naming:
WSDL : Web Service
Definition Language
UDDI
Service Discovery
Service Publication
WSDL
Service Description
SOAP
XML Messaging
HTTP, SMTP, …
Network
SOAP: Simple Object
Access Protocol
UDDI: Universal
Description, Discovery and
Integration
BPEL4WS: Business Process
Execution Language for
Web Service
SOAP
Simple Object Access Protocol
SOAP ist somit eine Technik
für Marshalling und Unmarshalling!
BPEL4WS
Service Flow
UDDI
Service Discovery
Service Publication
WSDL
Service Description
SOAP
XML Messaging
HTTP, SMTP, …
Network
SOAP
•
standardisierte Verpackungsstruktur, um XML-Dokumente über
Internetprotokolle transportieren zu können
•
SOAP ist grundsätzlich nicht auf HTTP beschränkt, jedes
Übertragungsprotokoll (z.B. SMTP) kann verwendet werden
– HTTP wird in der Praxis aufgrund der Verwendbarkeit
zwischen Unternehmen benutzt (Firewalls!)
•
•
SOAP kann unterschiedliche Infrastrukturen überbrücken
und so Anwendungen miteinander verbinden.
SOAP ist eine Recommendation des W3C
BPEL4WS
Service Flow
UDDI
Service Discovery
Service Publication
WSDL
Service Description
SOAP
XML Messaging
HTTP, SMTP, …
Network
WSDL
Web Service Description Language
•
WSDL ist die Beschreibungssprache für Web Services
– Der Benutzer eines Web Service möchte wissen:
• Welche Methoden werden angeboten?
• Welche Parameter erwarten die Methoden (einschl. der
Datentypen)?
• Welche Werte liefern sie zurück?
– Ein Web Service muss diese Informationen zurückliefern
¾ Schnittstelle
•
WSDL enthält alle wesentlichen Informationen, z.B.
•
– die Syntax des Service
– die Bindung an ein bestimmtes Netzprotokoll
– die Festlegung des Übertragungsformats
– die Zuordnung zu bestimmten Internetadressen
Natürlich: keine Semantik…
BPEL4WS
Service Flow
UDDI
Service Discovery
Service Publication
WSDL
Service Description
SOAP
XML Messaging
HTTP, SMTP, …
Network
Unterschiede zu EJBs
• Ähnlich: Eine stateless Session Bean ist konzeptuell
vergleichbar zu einem Web Service
– tatsächlich: Die EJB Spezifikation sieht den Zugriff auf eine
Stateless Bean mittels Web-Service-Technologie als eine
Alternative zum RMI-IIOP
• Stateful Session Beans haben einen impliziten Zustand
(der Container sorgt für die richtige Zuordnung),
Services kennen dieses Prinzip nicht
– über Session-ID Konzepte realisierbar
• Message Driven Beans kommunizieren asynchron,
Service-Aufrufe sind synchron
Neue Implementierung
• Einbindung von Services von Fremdsystemen einfach in
den Entwicklungsprozess integrierbar
•
Wenn im Design klar wird, dass man Fremdsysteme brauchen wird:
– relevante Stelle für den Aufruf suchen als Designklasse
das Fremdsystem integrieren (wird dann der Stub in der
Implementierung)
– einfach als normale Klasse mit Operationen im Design
behandeln, remote-Aufruf ist transparent im Design
• natürlich haben wir nun etwas abstrahiert
– real würde noch Authentifizierung gegenüber dem Dritten
stattfinden (auch als Service realisierbar)
Alternativen zu SOAP
• JSON: JavaScript Object Notation
– Oft bei Ajax-Technologie im Browser verwendet
• REST: Representational State Transfer
– Eigentlich kein Protokoll
Hauptunterschied zu Soap:
• Weniger Overhead
• Leichter zu verarbeiten