Post on 18-Aug-2020
transcript
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-3
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.
vsis inf min uni hh ws 12_13 VIS-1 Middlew-4
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.
vsis inf min uni hh ws 12_13 VIS-1 Middlew-5
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-6
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-7
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-8
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-9
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.
vsis inf min uni hh ws 12_13 VIS-1 Middlew-10
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-11
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)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-12
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-13
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-14
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-15
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-16
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
Kommunikationsinfrastruktur
LaufzeitumgebungDienste Dienste
Kommunikationsinfrastruktur
Verteiltes SystemBetriebs-system
vsis inf min uni hh ws 12_13 VIS-1 Middlew-17
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
A n w e n d u n g s -k o m p o n e n te
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-18
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)
• …
vsis inf min uni hh ws 12_13 VIS-1 Middlew-20
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)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-21
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-22
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-23
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-24
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-26
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-27
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-28
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-29
CORBA Dienste [C/D/K/B12]
vsis inf min uni hh ws 12_13 VIS-1 Middlew-30
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)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-31
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-32
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-33
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);
};
vsis inf min uni hh ws 12_13 VIS-1 Middlew-35
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)
};};};
vsis inf min uni hh ws 12_13 VIS-1 Middlew-36
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-37
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…)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-38
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
Java EE Beispiel: „Duke‘s Bank Applicaton“Java EE Beispiel: „Duke s Bank Applicaton
withdraw(…)( )deposit(…)transferFunds(…)
getAccountsOfCustomer(…)getDetails(…)
createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )removeCustomerFromAccount(…)
createCustomer( )http://java.sun.com/javaee/5/docs/tutorial/doc/
createCustomer(…)removeCustomer(…)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-42
Java EE Beispiel: „Duke‘s Bank Applicaton“Java EE Beispiel: „Duke s Bank Applicaton
withdraw(…)Authentifizierung( )deposit(…)transferFunds(…)
Authentifizierung& Autorisierung(bankCustomer)
getAccountsOfCustomer(…)getDetails(…)
( )
createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )AuthentifizierungremoveCustomerFromAccount(…)
createCustomer( )
g& Autorisierung(bankAdmin)
http://java.sun.com/javaee/5/docs/tutorial/doc/createCustomer(…)removeCustomer(…)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-43
Java EE Beispiel: „Duke‘s Bank Applicaton“Java EE Beispiel: „Duke s Bank Applicaton
withdraw(…)( )deposit(…)transferFunds(…)
getAccountsOfCustomer(…)getDetails(…)
Transaktion
createAccount(…)removeAccount(…)addCustomerToAccount(…)removeCustomerFromAccount( )removeCustomerFromAccount(…)
createCustomer( )http://java.sun.com/javaee/5/docs/tutorial/doc/
createCustomer(…)removeCustomer(…)
vsis inf min uni hh ws 12_13 VIS-1 Middlew-44
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
vsis inf min uni hh ws 12_13 VIS-1 Middlew-45