Nachrichtenorientierte Middleware &Nachrichtenorientierte ...€¦ · — difficult to identify and react to failures — but the interaction requires both client and server to be

Middleware:

Nachrichtenorientierte Middleware &Nachrichtenorientierte Middleware &Anwendungsorientierte Middleware

GliederungGliederung• Kommunikationsorientierte Middleware

Alt ti RMI/RPC— Alternativen zu RMI/RPC— Nachrichtenorientierte Middleware (MOM)

• Anwendungsorientierte Middlewareg— Motivation und Abgrenzung— Historische Vertreter— Aktuelle Vertreter— Beispiel

vsis inf min uni hh ws 12_13 VIS-1 Middlew-2

Eigenschaften von RMI/RPC

• The caller must wait until the response comes backp

— the caller makes a request, the receiver gets the request, processes the request, sends a response, the caller receives the responsecaller receives the response

• Synchronous interaction requires

• Synchronizing client and server has several disadvantages:• Synchronous interaction requires

both parties to be “on-line”— The receiver does not need to exist at

the time of the call (e g CORBA /

— connection overhead (sessions)

— higher probability of failures

diffi lt t id tif d t t f ilthe time of the call (e.g. CORBA / Java RMI can create an instance of the service/server/object when called if it does not exist already)

— difficult to identify and react to failures

— but the interaction requires both client and server to be “alive” at the same time

• One-to-one system— not practical for nested calls

— not practical for complex interactions


RMI/RPC Nachteile (1): Overhead

• Synchronous invocations require to maintain a session between the caller

d th iand the receiver.— Maintaining sessions is expensive and

consumes CPU resources.There is also a limit on how many sessions— There is also a limit on how many sessions can be active at the same time (thus limi-ting the number of concurrent clients con-nected to a server)For this reason client/server systems often— For this reason, client/server systems often resort to connection pooling to optimize resource utilization and

• have a pool of open connections• associate a thread with each

connection• allocate connections as needed.

When the interaction is not one-to-one the— When the interaction is not one-to-one, the context (the information defining a session) needs to be passed around. The context is usually volatile.


RMI/RPC Nachteile (1): Fehlerbehandlung

• Failures in synchronous calls— If the client or the server fail the context isIf the client or the server fail, the context is

lost and resynchronization might be difficult.

— If the failure occurred before 1, nothing has happenedhappened

— If the failure occurs after 1 but before 2 (receiver crashes), then the request is lost

— If the failure happens after 2 but before 3, id ff t i i t iside effects may cause inconsistencies

— If the failure occurs after 3 but before 4, the response is lost but the action has been performed (do it again?)

• Finding out when the failure took place may not be easy.

— Worse still if there is a chain of— Worse still, if there is a chain of invocations, the failure can occur anywhere.


Alternative zu RMI/RPCAlternative zu RMI/RPC• Asynchronous Interaction

U i h i t ti th ll d th t t t d— Using asynchronous interaction, the caller sends a message that gets stored somewhere until the receiver reads it and sends a response.

— The response is sent in a similar manner

• Asynchronous interaction can take place in two forms:— Non-blocking invocation:

RPC but the call returns immediately without waiting for a response, similar toRPC but the call returns immediately without waiting for a response, similar to batch jobs

P i t t— Persistent queues:The call and the response are actually persistently stored until they are accessed by the client and the server


Messaging, Message Passing, Message Queuing

• Message Passing ist ein Kommunikationsmodell zum asynchronen Transport von Daten zwischen Prozessen.p

• Die Daten werden innerhalb von Nachrichten (Messages) übertragen.

• Message Passing arbeitet auf der Basis von Warteschlangen:— Nachrichten werden vom Sender in eine Warteschlange gelegt

und werden von dort aus an den Empfänger weitergeleitet— und werden von dort aus an den Empfänger weitergeleitet.

• Die Warteschlange arbeitet nach dem FIFO Prinzip.

Sender Empfänger

Nachricht Nachricht

Warteschlange

• Einfaches Interaktionsmodell: point-to-point-messages


Komplexere Interaktionen

• Complement to synchronous interactionsinteractions— Suitable to modular design: the

code for making a request can be in a different module (even a request()be in a different module (even a different machine!) than the code for dealing with the response

— It is easier to design sophistica-

q ()

receiveprocess

queue

It is easier to design sophisticated distribution modes (multicast, transfers, replication, coalescing messages) and it also helps to h dl i ti i

do with answer

return

queue

handle communication sessions in a more abstract way

— More natural way to implement comple interactionscomplex interactions


Alternat. Interaktionsmodell: Publish-Subscribe

• Prozesse erhalten Rollen als Publisher bzw. Subscriber.

• Subscriber abonnieren Nachrichten zu einem Thema.

• Publisher veröffentlichen Nachrichten zu einem Thema.

• Broker übernehmen die Vermittlung.

• Eine mögliche Realisierung erfolgt durch themenspezifische Warteschlangen.

W a rte s c h la n g e z uT hT h e m a a

S u b s c r ib e r

T h b

T h e m a a

P u b lis h e r

W a rte s c h la n g e z uT h b

S u b s c r ib e r

N a c h r ic h t b

T h e m a b

V e rm it t le r (B ro k e r)

T h e m a b N a c h r ic h t b


Persistente WarteschlangenPersistente Warteschlangen• Eine der wesentlichen „Quality of Service“-Eigenschaften ist die

garantierte Auslieferung einer Nachricht.

• Was ist dabei das Hauptproblem:— Der Empfängerprozess kann ausfallen.— Das Netzwerk kann unterbrochen sein.

• Garantierte Auslieferung wird sichergestellt durch das persistente Zwischenspeichern von NachrichtenZwischenspeichern von Nachrichten. — z.B. Datenbank, Dateisystem, ...

• (Nur) wenn der Empfänger bereit ist zu empfangen, wird die Nach-( ) p g p g ,richt zugestellt.

• Garantierte Auslieferung stellt sicher, dass eine Nachricht an den Empfänger ausgeliefert wirdEmpfänger ausgeliefert wird.

• Garantierte Auslieferung sagt jedoch nichts über den Zeitpunkt der Auslieferung aus. Dies muss ggfs.über andere QoS-Eigenschaften i h t llt dsicher gestellt werden.


Message Oriented Middleware (MOM)

• MOM ist die Middleware-Technologie zum Message-Passing-Kommunika-tionsmodell.

• MOM bietet neben der rein asynchronen Kommunikation weitere Mecha-nismen und Dienste:

— Unterstützung der verschiedenen Messaging Modelle — Warteschlangenverwaltung— Verbindungsmanagement— Verbindungsmanagement— Quality-of-Service-Zusicherungen (QoS)

Empfänger

Warteschlangen

Sender

Zugriffs

Warteschlangen

Zugriffs

Middleware-Protokoll (proprietär)

Warteschlangen-verwalter

Zugriffs-schnittstelle

Zugriffs-schnittstelle

Protokoll-Stack


Beispiel: Java Message Service (JMS)Beispiel: Java Message Service (JMS)• Einheitlichen Zugriffsschnittstelle (API) für Java-Anwendungen auf

einen MOM-Servereinen MOM Server— Teil der Java-Plattform (Java EE oder stand-alone)

• D St d d t h id t i R ll• Der Standard unterscheidet zwei Rollen— JMS Provider: der jeweilige MOM-Server— JMS Client: die Java-Anwendung (Empfänger und Sender von Nachrichten)JMS Client: die Java-Anwendung (Empfänger und Sender von Nachrichten).

• JMS unterstützt verschiedene Interaktionsmodelle:— Einfaches Point-to-Point-Modell— Publish-Subscribe-Modell— Request-Reply-Modell— Request-Reply-Modell

• Nachteil: Keine Interoperabilität zwischen Produkten (aber Porta-bilität)bilität)


Zusammenfassung:Kommunikationsorientierte Middleware (KM)Kommunikationsorientierte Middleware (KM)

• Ziele: Abstraktion von der Netzwerkprogrammierung

• Aufgaben— Kommunikation

— Datentransformation

— Verbergen der HeterogenitätKommunikationsorientierte

Anwendungskomponente

• Programmiermodelle:— Entfernte Prozeduraufrufe (RPC)

KommunikationsorientierteMiddlewareBetriebs-

system Verteiltes System— Entfernte Methodenaufrufe (RMI)

— Nachrichtenorientiertes Modell

• Beispiele: DCE-RPC, CORBA RMI, Java RMI, JMS


Anwendungsorientierte Middleware (AM)Anwendungsorientierte Middleware (AM)• AM setzt auf kommunikationsorientierter Middleware (KM) auf.

• AM erweitert KM um Funktionalität zur Unterstützung verteilter Anwendun-gen.

• AM eignet sich auf Grund ihrer Eigenschaften insbesondere für Informa-tionssysteme

• Informationss steme eichnen sich d rch folgende Eigenschaften a s• Informationssysteme zeichnen sich durch folgende Eigenschaften aus:— Software-intensiv— datenzentriert

i t kti— interaktiv— nebenläufig

• Erweiterungen der AM gegenüber KM sind:• Erweiterungen der AM gegenüber KM sind:— Laufzeitumgebung— Dienste

K t d ll— Komponentenmodell


AM-Systemarchitektur „klassisch“

[Bernstein 93]FRAMEWORK

ToolsApplication •••UserInterface

Framework Local Services

API veneerInterface

Application

Application Programming Interface

Application

Pl tf I t f

“Middleware” : (Distributed) System Services

Platform_j• OS• Hardware

Platform Interface

•••Platform_i• OS• Hardware • Hardware• Hardware


KM + Laufzeitumgebung

• Laufzeitumgebung setzt auf dem Betriebssystem des jeweiligen Knoten im verteilten System auf.

• Laufzeitumgebung erweitert die Funktionalität des Betriebssystems um— verbesserte Ressourcenverwaltung— Unterstützung der Nebenläufigkeit— Verbindungsverwaltung— Verbesserung der Verfügbarkeit— verbesserte Sicherheitsmechanismen

Laufzeitumgebung

Kommunikationsinfrastruktur

Laufzeitumgebung

Betriebs-Verteiltes System

Betriebssystem


KM + Laufzeitumgebung + Dienste

• Dienste stellen häufig benötigte Funktionalität wiederverwendbar bereit

• Welche und wie viele Dienste eine Middleware anbietet, kann stark variieren.

• Zu den grundlegenden Diensten einer Middleware zählen:g g— Namensdienst— Sitzungsverwaltung

T kti lt— Transaktionsverwaltung— Persistenz


LaufzeitumgebungDienste Dienste


Verteiltes SystemBetriebs-system


KM + Laufzeitumgebung + Dienste + Komponentenmodell

• Ein Komponentenmodelle bieten eine konzeptionelle und technische Basis zur komponentenbasierten Entwicklung von Anwendungen.p g g

• Ein Komponentenmodell definiert:— einen Komponentenbegriffg— eine Komponentenlaufzeitumgebung— Verträge zwischen Komponenten und Komponentenlaufzeitumgebung

A n w e n d u n g s -k o m p o n e n te



K o m p o n e n te n m o d e ll

L a u fz e itu m g e b u n g

K o m p o n e n te n m o d e ll

D ie n s te D ie n s te

K o m m u n ik a t io n s in fra s tru k tu r

V e rte ilte s S y s te mB e tr ie b s -s y s te m


Komponentenbasiertes Paradigma (Wdh.)Komponentenbasiertes Paradigma (Wdh.)Komponentenbegriff: Wiederverwendbarkeit von Anwendungsfunktionalität

Komponenten sind grob granularere Einheiten auf fachlicher Ebene mit klaren SchnittstellenKomponenten sind grob-granularere Einheiten auf fachlicher Ebene mit klaren Schnittstellen – und diese...…sind in sich abgeschlossen (self-contained) bzw. definieren genau ihre Abhängigkeiten

nd sie mfassen im Wesentlichen n r die An end ngslogik ( gl Einsat konte t s )…und sie umfassen im Wesentlichen nur die Anwendungslogik (vgl. Einsatzkontext, s.u.)

Laufzeitumgebung: Dienste und SchnittstellenK t d i i ll C t i füh t (IOC P i i )— Komponenten werden in speziellen Containern ausgeführt (IOC-Prinzip)

— Einheitliches Deployment-Modell— Konfiguration der Komponenten beim Deployment je nach Einsatzkontext (Sicherheit,

)Transaktionen, Persistenz, …)

Container 1Rechner 1

K1K2

K3Container 1

Rechner 2vsis inf min uni hh ws 12_13 VIS-1 Middlew-19

Middleware-Dienste für KomponentenMiddleware Dienste für Komponenten• Namensdienst (damit Komponenten sich gegenseitig finden können)

• Remote-Prozeduraufruf (RMI/RPC) (für entfernten Zugriff auf Komponenten)

• Nachrichtenkommunikation (für asynchrone Kommunikation mit bzw. zwi-schen Komponenten)schen Komponenten)

• Transaktionssicherheit (für Nebenläufigkeit und Fehlerbehandlung innerhalb und zwischen Komponenten)und zwischen Komponenten)

• Resource Pooling (Datenbankverbindungen, Komponenten)

• Security (Zugriffsrechte)

• Persistenz und Caching (persistente Speicherung von Objekten/Daten)

• …


Standardisierte Anwendungsmiddleware: OSF DCE und OMG CORBAOSF DCE und OMG CORBA

Standardisierungsziel: Herstellerübergreifendes Architekturmodell undg gSystemplattform zur Unterstützung offener verteilter Anwendungen, dazu:

Erweiterte (Betriebs-) Systemplattform - DCE:‘Open Software Foundation’ (OSF) / ‘Open Group’ (OG):

Erweiterte (Betriebs ) Systemplattform DCE:

Middleware-Standards ---> “Distributed Computing Environment” (DCE)Standards für verteilte Systeme:

Architektur- und Objektmodell CORBA:

‘Obj t M t G ’ (OMG)

Systeme:

‘Object Management Group’ (OMG):

---> “Common Object Request Broker” (CORBA)


DCE: EinführungDCE: Einführung• “Distributed Computing Environment” (ca. 1990)

t i k lt d “O S ft F d ti ” (OSF)— entwickelt von der “Open Software Foundation” (OSF)— Ziel: Vereinfachung der Entwicklung verteilter Systeme

• Realisiert als Middleware— Transparenzschicht über dem Betriebssystem

Di t Bibli th k d W k— Dienste, Bibliotheken und Werkzeuge

• Client/Server Modell— Aktive Clients— Passive Server


Herstellerübereinkunft: OSF/OG „Distributed C ti E i t“ (DCE) A hit ktComputing Environment“ (DCE): Architektur

Verteilte AnwendungENCINA

Time Directory Security

• TRAN • TRPC

T C

Toolkit

DistribTimeService

DirectoryService

SecurityService

• Tran-C• Server Core

Distrib.File Sys. Sonst.

Thread Service

Remote Procedure Call (RPC)

Local Operating and Communication Services


Praktische Relevanz von DCE

• unterschiedliche Herstellerunterschiedliche Hersteller

• unterschiedliche Betriebssysteme

• unterschiedliche Netzwerktechnologien

• Komponenten von unterschiedlichen Herstellern

• Standardkomponenten

• keine einheitliche Steuerungs- / Überwachungsumgebung

• keine globalen Entwicklungswerkzeuge

• einheitliche Implementierungen auf vielen HW-Plattformeneinheitliche Implementierungen auf vielen HW Plattformen

• gute Integration von Security-Funktionen


Standardarchitektur für die Objektkoordination in offenen verteilten Systemen: OMG “CORBA”offenen verteilten Systemen: OMG CORBA

OMG: “Object Management Group”:OMG: Object Management Group :

non-profit Software-Konsortium (gegr. 1989)

über 800 Mitglieder (Firmen: HW, SW, User, IT etc.)

Ziel: Unterstützung für Anwendungs-Interoperabilität

Umgebung: heterogen, ‘multi-vendor’, verteilt, ...

bisher: ‘Object Management Architecture’ (Referenzmodell) +

‘Common Object Request Broker’ (CORBA) +

‘Object Services’ (z.B. Transaktionen, Trading, ...)

Beziehungen zu: ISO/IEC JTC1 WG7 (ODP)

CCITT/ITU und ISO X.500 (Directory) etc.

Unix bzw. X/Openvsis inf min uni hh ws 12_13 VIS-1 Middlew-25

CORBA: EinführungCORBA: Einführung• „Common Object Request Broker Architecture“ (CORBA)

t i k lt d Obj t M t G ‘ (OMG) 1992/96— entwickelt von der ‚Object Management Group‘ (OMG), ca. 1992/96— Ziel: Kommunikationsinfrastruktur für verteilte Objekte

• Teil der „Object Management Architecture“ (OMA)— CORBA Services: technische Dienste— CORBA Facilities: fachbezogene Dienste (domain vs. horizontal)

• Objektorientiertes Client/Server-Modell— Server-Objekte— Aufrufe auf Server-Objekten durch Clients


De-facto Standard: OMG „Common Object R t B k A hit t “ (CORBA)Request Broker Architecture“ (CORBA)

Client Server ObjectInterface DefinitionLanguage (IDL)

StaticIDL Skeleton

Dynamicinterface

Staticstubs ORB interface Object adapter

Fi d bj i- Find object instance- Supervise transfer of control- Data transfer from caller to object instance

E t

Object Request Broker Kernel

Interface repository Implementation repository

- Error management


CORBA: Architektur

• Object Request Broker (ORB)—transparente Vermittlungsschicht

• RMI—„Remote Method Invocation“p g

—Objektreferenzen zur Adressierung—Veröffentlichung von Referenzen über

Namensdienst• Interface Repository

—Verwaltung von ObjektschnittstellenBi d L f it ö li h—Bindung zur Laufzeit möglich

StatischerDynamisches

SkeletonStatischesSkeleton

Client Serverobjekt

ORBDynamischer

Serverobjekt

CORBA

StatischerStub

SkeletonPOA

SkeletonORB-Dienste

DynamischerStub

InterfaceRepository

ImplementationRepositoryRepository


CORBA: RMICORBA: RMI• Ziele

Obj kt i ti l Ab t kti fü t ilt K ik ti— Objektorientierung als Abstraktion für verteilte Kommunikation— Orts- und Zugriffstransparenz— SprachunabhängigkeitSprachunabhängigkeit— Interoperabilität

• IDL• IDL— „Interface Definition Language“— gemeinsamer Nenner für Programmiersprachen (C++ Java Smalltalk etc )— gemeinsamer Nenner für Programmiersprachen (C++, Java, Smalltalk etc.)— „Language Bindings“ legen Abbildung fest

• Abl f• Ablauf— Generierung von Stub (Client) / Skeleton (Server)

Marshalling / Unmarshalling— Marshalling / Unmarshalling


CORBA Dienste [C/D/K/B12]


DCE vs. CORBA

• DienstlokalisationVerzeichnisdienst

• SicherheitSecurity Service— Verzeichnisdienst

• DienstgranularitätDCE: Prozedur

— Security Service

• Heterogenität verbergenIDF— DCE: Prozedur

— CORBA: Objekte

• Dienstaufruf

— IDF— IDL

• Komponentenmodell• Dienstaufruf— DCE: RPC— CORBA: RMI

• Komponentenmodell— DCE: n/a— CORBA:

• Stukturierung / Konfiguration— DCE: Zellen

• CBOF (Common Business Object Facility, nicht fertig gestellt)

— CORBA: Domänen • CCM (CORBA Component Model, verabschiedet 1999, kaum Verwendung in der Praxis)


Die Rolle der CORBA IDL

Cli t SidObject

I l t tiClient Side ImplementationSide

C COBOL

C++

I D L

I D LC

I D L

I D L

ORB

I D L

I D L

Ada

I D L

I D L

ORB

COBOL

Ada

I D L

I D L

Smalltalk

I D L

I D L

C++

JAVA

C++Smalltalk

JAVA


CORBA Interface Definition Language (IDL)

- Definition der Typen der Argumente - Spezifikation der Prozedurköpfe

Z i Id tifik ti d P d

Bestandteile

- Zuweisung von Identifikationsnummern zu den Prozeduren- Definition des Programms und der Version

SchnittstellenspracheSchnittstellensprache

- wird benötigt, z.B: wenn Client und Server in unterschiedlichen Sprachen geschrieben sind (heterogene Umgebungen!)bietet skalare und strukturierte Datentypen- bietet skalare und strukturierte Datentypen

- kann von verschiedenen Sprachen aus benutzt werden

Datenabstraktion- entspricht von der Idee her z.B. Definitionsdatei in Modula-2- Server exportiert die Schnittstelle, Client importiert die Schnittstelle- Server und Client müssen dieselbe Schnittstelle benutzen

Datenabstraktion

Marshalling/Unmarshalling-Routinen (Stubs)Generierung für jeden im Schnittstellenmodul definierten Datentyp- Generierung für jeden im Schnittstellenmodul definierten Datentyp (Stubs) automatisch möglich


CORBA IDL-Beispiel: „RouteFinder.idl“module RouteFinder {typedef string Location;

struct Ratings {Speed s; Length l;Complexity c; Beauty b;typedef sequence<Location> LocationSeq;

typedef long Speed;

Complexity c; Beauty b;};

//typedef float Length;enum Complexity {LOW, MEDIUM, HIGH};typedef boolean Beauty;

// Exceptionsexception UnknownRoute {};exception UnknownLocationyp y

enum Policy { FAST, SHORT,SIMPLE, NICE };

{ Location where };exception Reject{ string reason; };SIMPLE, NICE };

union SingleRating switch (Policy) {Speed s; Length l;

{ g }

// Interfacesinterface Route;Speed s; Length l;

Complexity c; Beauty b;};

interface Route;interface RouteFactory;interface Update;interface Lookup;interface Lookup;interface ExtendedLookup;

};vsis inf min uni hh ws 12_13 VIS-1 Middlew-34

IDL-Beispiel: 'RoomBooking' in CORBA IDLIDL Beispiel: RoomBooking in CORBA IDL

aus: A Vogel K Duddy: "Java Programming with CORBA" John Wiley & Sons 1997

module RoomBooking {

aus: A. Vogel, K. Duddy: Java Programming with CORBA , John Wiley & Sons, 1997

interface Meeting {// A meeting has two read-only attributes which describe the// purpose and the participants of that meeting// purpose and the participants of that meeting.

readonly attribute string purpose;readonly attribute string participants;

}};interface MeetingFactory {

// A meeting factory creates meeting objects.g y g jMeeting CreateMeeting ( in string purpose, in string participants);

};


IDL-Beispiel: 'RoomBooking' in CORBA IDL (cont.)IDL Beispiel: RoomBooking in CORBA IDL (cont.)interface Room {

// A Room can be booked for several (here: 8) time slots.Sl t { 9 10 11 12 1 2 3 4}enum Slot {am9, am10, am11, pm12, pm1, pm2, pm3, pm4};

// Since cardinality of slots cannot be determined in IDL MaxSlots defines it:const short MaxSlots = 8;

// "Meetings" associates meetings with time slotstypedef Meeting Meetings [MaxSlots];exception NoMeetingsInThisSlot {};exception SlotAlreadyTaken {};

// The attribute "name" names a room:readonly attribute string name;

// "View" returs the bookings for a room, "Book" and "Cancel" book resp. cancel// reservation for a room (here: only for a day):

Meetings View ();g ();void Book ( in Slot a_slot, in Meeting a_meeting ) raises (SlotAlreadyTaken);void Cancel ( in Slot a_slot ) raises (NoMeetingsInThisSlot)

};};};


Vor- & Nachteile von CORBA

• ... HeterogenitätCORBA löst Probleme der...

• schneller Standardisierungsprozesse

Unter den Randbedingungen...

• ... Integration— legacy

• ... Verteilung

• ... schneller Standardisierungsprozesse— etwa 18 Monate bis zum Markt

• ... große Akzeptanz... Verteilung

• ... Ersetzbarkeit— Information hiding

— über 800 Mitglieder— viele Produkte— viele Sprachabbildungen (Mappings)

• ... Wiederverwendbarkeit— Vererbung

• Erweiterbarkeit

• ... große Verbreitung— Client bereits in jedem Browser ab

Netscape 4 Navigator vorhanden... Erweiterbarkeit

— Polymorphie

• IDL “kleinster gemeinsamer Nenner”Probleme: • IDL kleinster gemeinsamer Nenner• IDL definiert nur Interface, keine Implementierung• keine Semantikspezifikation in IDL-Beschreibung• z T mangelhafte Abbildbarkeit auf Sprachen

Probleme:

z.T. mangelhafte Abbildbarkeit auf Sprachen• schlechte Reversibilität


Aktueller Vertreter: Java EEAktueller Vertreter: Java EE• Voller Name: Java Platform Enterprise Edition

Java Platform Enterprise Edition abgekürzt Java EE oder früher J2EE ist die Spe— Java Platform, Enterprise Edition, abgekürzt Java EE oder früher J2EE, ist die Spe-zifikation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in Javaprogrammierten Anwendungen und insbesondere Web-Anwendungen.

— Java EE ist damit eine herstellerunabhängige Spezifikation eines Komponentenmodells• inkl dazugehöriger Middleware Services• inkl. dazugehöriger Middleware Services,• inkl. Schnittstellen zu anderen Komponenten

• Komponenten: „Enterprise Java Beans“ (EJB)p „ p ( )— Java-basiertes Modell (keine Programmiersprachenunabhängigkeit)— Konfiguration über XML-Deskriptoren bzw. Java-Annotations

• Laufzeitumgebung: „EJB Container“ (Application Server)— Container implementiert die Java EE SpezifikationContainer implementiert die Java EE Spezifikation— Komponenten (-entwickler) benutzen Java EE APIs— Einmal implementierte Komponenten können auf Produkten verschiedener

H t ll d l d“ d (th ti h )Hersteller „deployed“ werden (theoretisch…)


Historische EntwicklungEase of De-velopment

Web Services

Java EE5Annotations,EJB 3.0,Persistence API,JSF

EnterpriseJava Plat

Robustness J2EE 1.4Web Services,Management,

Services JSF, Renewed WebServices

J2EE 1 2

Java Plat-form

J2EE 1.3EJB 2.0,ConnectorArchitecture

g ,Deployment, Async.ConnectorEnterprise

Java APIs J2EE 1.2Servlet,JSP, EJB, JMS, JTA,JNDI

JPE

Java APIs

JNDI, RMI/IIOPProject

Dec 1999 Sept. 2001 Nov. 2003 May 2006May 1998vsis inf min uni hh ws 12_13 VIS-1 Middlew-39

Nachfolger: Java EE 6Nachfolger: Java EE 6• Neuerungen

P fil T il d Pl tf /API fü ifi h A d ( B— Profiles: Teilmengen der Platform/APIs für spezifische Anwendungen (z.B. Java EE Web Profile)

— SOA: Support für SCA (Service Component Architecture)— Existierende Spezifikationen aufnehmen:

• JSR-196: Java Authentication SPI for Containers JSR 236 Ti f A li i S ?• JSR-236: Timer for Application Servers ?

• JSR-237: Work Manager for Application Servers ?• JSR-299: Web Beans• JSR-311: JAX-RS: Java API for RESTful Web Services

— …

• Spezifikation: Fertigstellung (SDK): Dezember 2009

• In Konkurrenz zu: Microsoft’s “.NET”-Plattform• Nächste Version: Java EE 7 – z.Zt. draft2 von Okt/Nov. 2012….vsis inf min uni hh ws 12_13 VIS-1 Middlew-40

Java EE Beispiel: „Duke‘s Bank Applicaton“Java EE Beispiel: „Duke s Bank Applicaton

http://java.sun.com/javaee/5/docs/tutorial/doc/vsis inf min uni hh ws 12_13 VIS-1 Middlew-41


withdraw(…)( )deposit(…)transferFunds(…)

getAccountsOfCustomer(…)getDetails(…)

createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )removeCustomerFromAccount(…)

createCustomer( )http://java.sun.com/javaee/5/docs/tutorial/doc/

createCustomer(…)removeCustomer(…)



withdraw(…)Authentifizierung( )deposit(…)transferFunds(…)

Authentifizierung& Autorisierung(bankCustomer)


( )

createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )AuthentifizierungremoveCustomerFromAccount(…)

createCustomer( )

g& Autorisierung(bankAdmin)

http://java.sun.com/javaee/5/docs/tutorial/doc/createCustomer(…)removeCustomer(…)



withdraw(…)( )deposit(…)transferFunds(…)


Transaktion

createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )removeCustomerFromAccount(…)

createCustomer( )http://java.sun.com/javaee/5/docs/tutorial/doc/

createCustomer(…)removeCustomer(…)


Zusammenfassung

• Kommunikationsorientierte Middle-ware

— Alternativen zu RMI/RPC— nachrichtenorientierte Middleware

(MOM)(MOM)

• Anwendungsorientierte Middleware— Motivation und Abgrenzung— historische Vertreter: DCE & CORBA— historische Vertreter: DCE & CORBA— aktuelle(r) Vertreter: Java EE— Beispiel: Duke’s Bank Application


Documents

Nachrichtenorientierte Middleware &Nachrichtenorientierte ...€¦ · — difficult to identify and react to failures — but the interaction requires both client and server to be