Enterprise Java Beans - informatik.uni-augsburg.de · Übertragungsprotokoll (z.B. SMTP) kann verwendet werden – HTTP wird in der Praxis aufgrund der Verwendbarkeit zwischen Unternehmen

Enterprise Java Beans

Beispiel Minibank• nur: Kunde, Konto, Überweisung

kontoführung.KontoAttributes

Kontostand:IntegerPIN:StringKontonummer:Integer

überweisungen.ÜberweisungAttributes

Verwendungszweck:StringDatum:Datebetrag:Integer

personen.PersonAttributes

Name:StringVorname:String

personen.Kunde

besitzt

11

gebucht_von

*

1

gebucht_auf

1

*

sd interne Überweisung

:System:Kunde

loop

2: enterData(String name, String nr, String zweck, int betrag)2: enterData(String name, String nr, String zweck, int betrag)

buchen()buchen()

3: buchen()3: buchen()

4: abmelden()4: abmelden()

1: authentifizieren(String user, String password)1: authentifizieren(String user, String password)

enterData(String name, String nr, String zweck, int betrag)enterData(String name, String nr, String zweck, int betrag)

ok=authentifizieren(String user, String password)ok=authentifizieren(String user, String password)

Von Systemoperationen zu Enterprise Komponenten

Systemoperationen

Systemschnittstelle(Controller)

Von Systemoperationen zu Enterprise Komponenten

• Die Systemoperationen werden typischerweise in Controllern zur Verfügung gestellt

• Im Beispiel:

Systemoperation

Schnittstelle nach aussen

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

Application Server

Architektur des BeispielsDie vertikale Dimension

Web Browser

Datenbank

Enterprise Beans

Java Server Faces

Entity Classes

Präsentationsschicht

Anwendungslogik

Datenhaltung

Remote Method Invocation / Distributed Objects

Client

Stub

Network

DistributedObject

Skeleton

Remote Interface Remote Interface

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 RMI-IIOP (RMI over Internet Inter-ORB (=Object RequestBroker))

Was fehlt?• Wichtige Punkte in Business Anwendungen

– Security– Persistenz– Transaktionen

• Wie werden diese Probleme gelöst?

Implizite Middleware

Client

Stub

Network

DistributedObject

Skeleton

Remote Interface

Remote Interface TransactionService

DatabaseService

SecurityService

RequestInterceptor

Remote Interface

Was sind nun EJBs?• Eine Enterprise Bean ist ein verteiltes

Objekt zusammen mit ihrem RemoteInterface

• In Java Termini:– 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ändischImplementierungen hinzufügen)

EJB

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: @Stateful– Stateless Session Bean: @Stateless– Message Driven Bean: @MessageDriven– Business Interface: @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) zurVerfügung


:System:Kunde

loop


buchen()buchen()






@Remotepublic interface BenutzerControllerRemote {

boolean authentifizieren(String user, String pw);String enterData(String name, int kontonr,

String zweck, int betrag);boolean buchen();

int getKontostand();Kontoauszug getKontoauszug(Date start, Date end);String getCurrentName();

}

Systemoperationenfür Überweisung

andere Systemoperationen

Bean-Implementierung• Beim Login: Merken des derzeitigen Kunden in der Bean

– entspricht „Controller-Gedanken“

@Statefulpublic 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;

}}


:System:Kunde

loop


buchen()buchen()






spätere Operationen bauen darauf auf!

@Statefulpublic class BenutzerControllerBean implements BenutzerControllerRemote {…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();return true;

}return false;}

}

analog: getZielkonto() … wurde definiert durch SysOp enterData()

alter Zustand

Bean Pooling• Container verwaltet einen ganzen Pool von EJBs:

• 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

Client

Container

Session Bean

Session Bean

Session Bean

Session Bean

BusinessInterface

Pool

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 sieansprechen kann.

(Web) Services

Was passiert, wenn man fremdeKomponenten 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 mitWeb 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:

Network

XML Messaging

Service Description

Service Publication

Service Discovery

Service Flow

HTTP, SMTP, …

SOAP

WSDL

UDDI

BPEL4WSNaming:

WSDL : Web Service Definition Language

SOAP: Simple ObjectAccess Protocol

UDDI: Universal Description, Discovery and Integration

BPEL4WS: Business ProcessExecution Language forWeb Service

SOAPSimple Object Access Protocol

Network

XML Messaging

Service Description

Service Publication

Service Discovery

Service Flow

HTTP, SMTP, …

SOAP

WSDL

UDDI

BPEL4WS

SOAP ist somit eine Technik für Marshalling und Unmarshalling!

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ückenund so Anwendungen miteinander verbinden.

• SOAP ist eine Recommendation des W3C

Network

XML Messaging

Service Description

Service Publication

Service Discovery

Service Flow

HTTP, SMTP, …

SOAP

WSDL

UDDI

BPEL4WS

WSDLWeb 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…

Network

XML Messaging

Service Description

Service Publication

Service Discovery

Service Flow

HTTP, SMTP, …

SOAP

WSDL

UDDI

BPEL4WS

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 Designklassedas Fremdsystem integrieren (wird dann der Stub in derImplementierung)

– 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

Documents

Enterprise Java Beans - informatik.uni-augsburg.de · Übertragungsprotokoll (z.B. SMTP) kann verwendet werden – HTTP wird in der Praxis aufgrund der Verwendbarkeit zwischen Unternehmen