Middleware: Anwendungsorientierte Middleware

Transkript

1 Middleware: Nachrichtenorientierte Middleware & Nachrichtenorientierte Middleware & Anwendungsorientierte Middleware

2 Gliederung Kommunikationsorientierte Middleware Alternativen ti zu RMI/RPC Nachrichtenorientierte Middleware (MOM) Anwendungsorientierte Middleware Motivation und Abgrenzung Historische Vertreter Aktuelle Vertreter Beispiel VIS-1 Middlew-2

3 Eigenschaften von RMI/RPC The caller must wait until the response comes back the caller makes a request, the receiver gets the request, processes the request, sends a response, the caller receives the response 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 / Java RMI can create an instance of the service/server/object when called if it does not exist already) but the interaction requires both client and server to be alive at the same time Synchronizing client and server has several disadvantages: connection overhead (sessions) higher probability of failures difficult to identify and react to failures One-to-one system not practical for nested calls not practical for complex interactions VIS-1 Middlew-3

4 RMI/RPC Nachteile (1): Overhead Synchronous invocations require to maintain a session between the caller and dthe receiver. Maintaining sessions is expensive and consumes CPU resources. There is also a limit on how many sessions can be active at the same time (thus limiting the number of concurrent clients connected to a server) 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 context (the information defining a session) needs to be passed around. The context is usually volatile. VIS-1 Middlew-4

5 RMI/RPC Nachteile (1): Fehlerbehandlung Failures in synchronous calls If the client or the server fail, the context is lost and resynchronization might be difficult. If the failure occurred before 1, nothing has happened 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, side effects may cause inconsistencies i i 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 invocations, the failure can occur anywhere. VIS-1 Middlew-5

6 Asynchronous Interaction Alternative zu RMI/RPC Using asynchronous interaction, ti the caller sends a message that t 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 to batch jobs Persistent t queues: The call and the response are actually persistently stored until they are accessed by the client and the server VIS-1 Middlew-6

7 Messaging, Message Passing, Message Queuing Message Passing ist ein Kommunikationsmodell zum asynchronen Transport von Daten zwischen Prozessen. 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. Die Warteschlange arbeitet nach dem FIFO Prinzip. Nachricht Nachricht Sender Empfänger Warteschlange Einfaches Interaktionsmodell: point-to-point-messages VIS-1 Middlew-7

8 Komplexere Interaktionen Complement to synchronous interactions Suitable to modular design: the code for making a request can be in a different module (even a different machine!) than the code for dealing with the response It is easier to design sophistica- ted distribution modes (multicast, transfers, replication, coalescing messages) and it also helps to handle communication sessions in a more abstract way request() do with answer queue queue receive process return More natural way to implement complex interactions VIS-1 Middlew-8

9 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 arteschlange zu Thema a Thema a Subscriber Publisher Nachricht b Warteschlange zu Thema b Verm ittler (Broker) Thema b Nachricht b Subscriber VIS-1 Middlew-9

10 Persistente 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 Nachrichten. z.b. Datenbank, Dateisystem,... (Nur) wenn der Empfänger bereit ist zu empfangen, wird die Nachricht zugestellt. Garantierte Auslieferung stellt sicher, dass eine Nachricht an den Empfänger ausgeliefert wird. Garantierte Auslieferung sagt jedoch nichts über den Zeitpunkt der Auslieferung aus. Dies muss ggfs.über andere QoS-Eigenschaften sicher gestellt werden. VIS-1 Middlew-10

11 Message Oriented Middleware (MOM) MOM ist die Middleware-Technologie zum Message-Passing-Kommunikationsmodell. MOM bietet neben der rein asynchronen Kommunikation weitere Mechanismen und Dienste: Unterstützung der verschiedenen Messaging Modelle Warteschlangenverwaltung Verbindungsmanagement Quality-of-Service-Zusicherungen (QoS) Sender Warteschlangen Empfänger Zugriffsschnittstelle Zugriffsschnittstelle Warteschlangenverwalter Middleware-Protokoll (proprietär) Protokoll-Stack VIS-1 Middlew-11

12 Beispiel: Java Message Service (JMS) Einheitlichen Zugriffsschnittstelle (API) für Java-Anwendungen auf einen MOM-Server Teil der Java-Plattform (Java EE oder stand-alone) Der Standard d unterscheidet t zwei Rollen JMS Provider: der jeweilige MOM-Server 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 Nachteil: Keine Interoperabilität zwischen Produkten (aber Porta- bilität) VIS-1 Middlew-12

13 Zusammenfassung: Kommunikationsorientierte Middleware (KM) Ziele: Abstraktion von der Netzwerkprogrammierung Aufgaben Kommunikation Datentransformation Verbergen der Heterogenität Programmiermodelle: Entfernte Prozeduraufrufe (RPC) Entfernte Methodenaufrufe (RMI) Nachrichtenorientiertes Modell Betriebssystem Anwendungskomponente Kommunikationsorientierte Middleware Verteiltes System Beispiele: DCE-RPC, CORBA RMI, Java RMI, JMS VIS-1 Middlew-13

14 Anwendungsorientierte Middleware (AM) AM setzt auf kommunikationsorientierter Middleware (KM) auf. AM erweitert KM um Funktionalität zur Unterstützung verteilter Anwendungen. AM eignet sich auf Grund ihrer Eigenschaften insbesondere für Informationssysteme Informationssysteme steme zeichnen sich durch folgende Eigenschaften aus: Software-intensiv datenzentriert interaktiv nebenläufig Erweiterungen der AM gegenüber KM sind: Laufzeitumgebung Dienste Komponentenmodell VIS-1 Middlew-14

15 AM-Systemarchitektur klassisch [Bernstein 93] FRAMEWORK User Interface Application API veneer Tools Application Framework Local Services Application Programming Interface Middleware : (Distributed) System Services Platform Interface Platform_i OS Hardware Platform_j OS Hardware VIS-1 Middlew-15

16 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 Betriebs- system Kommunikationsinfrastruktur Verteiltes System VIS-1 Middlew-16

17 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 g Diensten einer Middleware zählen: Namensdienst Sitzungsverwaltung Transaktionsverwaltung Persistenz Dienste Laufzeitumgebung Dienste Betriebssystem Kommunikationsinfrastruktur Verteiltes System VIS-1 Middlew-17

18 KM + Laufzeitumgebung + Dienste + Komponentenmodell Ein Komponentenmodelle bieten eine konzeptionelle und technische Basis zur komponentenbasierten Entwicklung von Anwendungen. Ein Komponentenmodell definiert: einen Komponentenbegriff eine Komponentenlaufzeitumgebung Verträge zwischen Komponenten und Komponentenlaufzeitumgebung Dienste Komponentenmodell Laufzeitumgebung Dienste Anwendungskomponente Anwendungskomponente Anwendungskomponente Betriebssystem Kommunikationsinfrastruktur Verteiltes System VIS-1 Middlew-18

19 Komponentenbasiertes Paradigma (Wdh.) Komponentenbegriff: Wiederverwendbarkeit von Anwendungsfunktionalität Komponenten sind grob-granularere granularere Einheiten auf fachlicher Ebene mit klaren Schnittstellen und diese... sind in sich abgeschlossen (self-contained) bzw. definieren genau ihre Abhängigkeiten und sie umfassen im Wesentlichen nur die Anwendungslogik ngslogik (vgl. Einsatzkontext, t s.u.) Laufzeitumgebung: Dienste und Schnittstellen Komponenten werden in speziellen Containern ausgeführt (IOC-Prinzip) Pi i Einheitliches Deployment-Modell Konfiguration der Komponenten beim Deployment je nach Einsatzkontext (Sicherheit, Transaktionen, Persistenz, ) K1 Container 1 Rechner 1 K2 K3 Container 1 Rechner 2 VIS-1 Middlew-19

20 Middleware-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) Transaktionssicherheit (für Nebenläufigkeit und Fehlerbehandlung innerhalb und zwischen Komponenten) Resource Pooling (Datenbankverbindungen, Komponenten) Security (Zugriffsrechte) Persistenz und Caching (persistente Speicherung von Objekten/Daten) VIS-1 Middlew-20

21 Standardisierte Anwendungsmiddleware: OSF DCE und OMG CORBA Standardisierungsziel: Herstellerübergreifendes Architekturmodell und Systemplattform zur Unterstützung offener verteilter Anwendungen, dazu: Erweiterte (Betriebs-) Systemplattform - DCE: Middleware- Standards für verteilte Systeme: Open Software Foundation (OSF) / Open Group (OG): ---> Distributed Computing Environment (DCE) Architektur- und Objektmodell CORBA: Object Management Group (OMG): ---> Common Object Request Broker (CORBA) VIS-1 Middlew-21

22 DCE: Einführung Distributed Computing Environment (ca. 1990) entwickelt von der Open Software Foundation (OSF) Ziel: Vereinfachung der Entwicklung verteilter Systeme Realisiert als Middleware Transparenzschicht über dem Betriebssystem Dienste, Bibliotheken und Werkzeuge Client/Server Modell Aktive Clients Passive Server VIS-1 Middlew-22

23 Herstellerübereinkunft: OSF/OG Distributed Computing Environment (DCE): Architektur ENCINA Toolkit TRAN TRPC Tran-C Server Core Verteilte Anwendung Time Directory Security Distrib. Service Service Service File Sys. Sonst. Remote Procedure Call (RPC) Thread Service Local Operating and Communication Services VIS-1 Middlew-23

24 Praktische Relevanz von DCE unterschiedliche Hersteller unterschiedliche Betriebssysteme unterschiedliche Netzwerktechnologien Komponenten von unterschiedlichen Herstellern Standardkomponenten keine einheitliche Steuerungs- / Überwachungsumgebung keine globalen Entwicklungswerkzeuge einheitliche Implementierungen auf vielen HW-Plattformen gute Integration von Security-Funktionen VIS-1 Middlew-24

25 Standardarchitektur für die Objektkoordination in offenen verteilten Systemen: OMG CORBA 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/Open VIS-1 Middlew-25

26 CORBA: Einführung Common Object Request Broker Architecture (CORBA) 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 VIS-1 Middlew-26

27 De-facto Standard: OMG Common Object Request Broker Architecture t (CORBA) Client Interface Definition Language (IDL) Server Object Dynamic interface Static stubs ORB interface IDL Skeleton Object adapter Object Request Broker Kernel Interface repository - Find object instance - Supervise transfer of control - Data transfer from caller to object instance - Error management Implementation repository VIS-1 Middlew-27

28 CORBA: Architektur Object Request Broker (ORB) transparente Vermittlungsschicht Objektreferenzen zur Adressierung Veröffentlichung von Referenzen über Namensdienst RMI Remote Method Invocation Interface Repository Verwaltung von Objektschnittstellen Bindung zur Laufzeit möglich Client Serverobjekt Serverobjekt Dynamischer Stub Statischer Stub ORB- Dienste Statisches Skeleton Dynamisches Skeleton POA CORBA Interface Repository Implementation Repository VIS-1 Middlew-28

29 Ziele IDL CORBA: RMI Objektorientierung ti als Abstraktion für verteilte Kommunikation Orts- und Zugriffstransparenz Sprachunabhängigkeit Interoperabilität Interface Definition Language gemeinsamer Nenner für Programmiersprachen (C++, Java, Smalltalk etc.) Language Bindings legen Abbildung fest Ablauf Generierung von Stub (Client) / Skeleton (Server) Marshalling / Unmarshalling VIS-1 Middlew-29

30 CORBA Dienste [C/D/K/B12] VIS-1 Middlew-30

31 DCE vs. CORBA Dienstlokalisation Verzeichnisdienst Dienstgranularität DCE: Prozedur CORBA: Objekte Sicherheit Security Service Heterogenität verbergen IDF IDL Dienstaufruf DCE: RPC CORBA: RMI Komponentenmodell DCE: n/a CORBA: CBOF (Common Business Stukturierung / Konfiguration Object Facility, nicht fertig DCE: Zellen gestellt) CORBA: Domänen CCM (CORBA Component Model, verabschiedet 1999, kaum Verwendung in der Praxis) VIS-1 Middlew-31

32 Die Rolle der CORBA IDL Client Side Object Implementation ti Side C COBOL C++ I D L I D L C COBOL I D L I D L ORB ORB I D L I D L Ada Ada I D L I D L I D L I D L Small talk I D L I D L Small talk C++ JAVA JAVA VIS-1 Middlew-32

33 CORBA Interface Definition Language (IDL) Bestandteile - Definition der Typen der Argumente - Spezifikation der Prozedurköpfe - Zuweisung von Identifikationsnummern zu den Prozeduren - Definition des Programms und der Version Schnittstellensprache - wird benötigt, z.b: wenn Client und Server in unterschiedlichen Sprachen geschrieben sind (heterogene Umgebungen!) - 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 Marshalling/Unmarshalling-Routinen (Stubs) - Generierung für jeden im Schnittstellenmodul definierten Datentyp (Stubs) automatisch möglich VIS-1 Middlew-33

34 CORBA IDL-Beispiel: RouteFinder.idl module RouteFinder { typedef string Location; typedef sequence<location> LocationSeq; typedef long Speed; typedef float Length; enum Complexity {LOW, MEDIUM, HIGH}; typedef boolean Beauty; enum Policy { FAST, SHORT, SIMPLE, NICE }; union SingleRating switch (Policy) { Speed s; Length l; Complexity c; Beauty b; }; struct Ratings { Speed s; Length l; Complexity c; Beauty b; }; // Exceptions exception UnknownRoute {}; exception UnknownLocation { Location where }; exception Reject { string reason; }; // Interfaces interface Route; interface RouteFactory; interface Update; interface Lookup; interface ExtendedLookup; }; VIS-1 Middlew-34

35 IDL-Beispiel: 'RoomBooking' in CORBA IDL aus: A. Vogel, K. Duddy: "Java Programming with CORBA", John Wiley & Sons, 1997 module RoomBooking { interface Meeting { // A meeting has two read-only attributes which describe the // purpose and the participants of that meeting. readonly attribute string purpose; readonly attribute string participants; }; interface MeetingFactory { // A meeting factory creates meeting objects. Meeting CreateMeeting ( in string purpose, in string participants); }; VIS-1 Middlew-35

36 IDL-Beispiel: 'RoomBooking' in CORBA IDL (cont.) }; interface Room { // A Room can be booked for several (here: 8) time slots. 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 slots typedef 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 (); void Book ( in Slot a_slot, in Meeting a_meeting ) raises (SlotAlreadyTaken); void Cancel ( in Slot a_slot ) raises (NoMeetingsInThisSlot) VIS-1 Middlew-36

37 Vor- & Nachteile von CORBA CORBA löst Probleme der Heterogenität... Integration legacy... Verteilung... Ersetzbarkeit Information hiding... Wiederverwendbarkeit Vererbung... Erweiterbarkeit Polymorphie Unter den Randbedingungen schneller Standardisierungsprozesse etwa 18 Monate bis zum Markt... große Akzeptanz über 800 Mitglieder viele Produkte viele Sprachabbildungen (Mappings)... große Verbreitung Client bereits in jedem Browser ab Netscape 4 Navigator vorhanden Probleme: IDL kleinster gemeinsamer Nenner IDL definiert nur Interface, keine Implementierung keine Semantikspezifikation in IDL-Beschreibung z.t. mangelhafte Abbildbarkeit auf Sprachen schlechte Reversibilität VIS-1 Middlew-37

38 Aktueller Vertreter: Java EE Voller Name: Java Platform Enterprise Edition 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 Anwendungen und insbesondere Web-Anwendungen. Java EE ist damit eine herstellerunabhängige Spezifikation eines Komponentenmodells inkl. dazugehöriger Middleware Services, inkl. Schnittstellen zu anderen Komponenten Komponenten: Enterprise Java Beans (EJB) Java-basiertes Modell (keine Programmiersprachenunabhängigkeit) Konfiguration über XML-Deskriptoren bzw. Java-Annotations Laufzeitumgebung: EJB Container (Application Server) Container implementiert die Java EE Spezifikation Komponenten (-entwickler) benutzen Java EE APIs Einmal implementierte Komponenten können auf Produkten verschiedener Hersteller deployed d werden (theoretisch ) ti h VIS-1 Middlew-38

39 Historische Entwicklung Ease of Development Enterprise Java Platform Enterprise Java APIs J2EE 1.2 JPE Project Servlet, JSP, EJB, JMS, JTA, JNDI, RMI/IIOP Robustness J2EE 1.3 EJB 2.0, Connector Architecture Web Services J2EE 1.4 Web Services, Management, Deployment, Async. Connector Java EE5 Annotations, EJB 3.0, Persistence API, JSF, Renewed Web Services May 1998 Dec 1999 Sept Nov May 2006 VIS-1 Middlew-39

40 Nachfolger: Java EE 6 Neuerungen 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: Timer for Application i 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 VIS-1 Middlew-40

41 Java EE Beispiel: Duke s Bank Applicaton VIS-1 Middlew-41

42 Java EE Beispiel: Duke s Bank Applicaton withdraw( ) deposit( ) transferfunds( ) getaccountsofcustomer( ) getdetails( ) createaccount( ) removeaccount( ) addcustomertoaccount( ) removecustomerfromaccount( ) createcustomer( ) removecustomer( ) VIS-1 Middlew-42

43 Java EE Beispiel: Duke s Bank Applicaton Authentifizierung ( ) & Autorisierung (bankcustomer) withdraw( ) deposit( ) transferfunds( ) getaccountsofcustomer( ) getdetails( ) createaccount( ) removeaccount( ) addcustomertoaccount( ) removecustomerfromaccount( ) g Authentifizierung & Autorisierung (bankadmin) createcustomer( ) removecustomer( ) VIS-1 Middlew-43

44 Java EE Beispiel: Duke s Bank Applicaton withdraw( ) deposit( ) transferfunds( ) getaccountsofcustomer( ) getdetails( ) Transaktion createaccount( ) removeaccount( ) addcustomertoaccount( ) removecustomerfromaccount( ) createcustomer( ) removecustomer( ) VIS-1 Middlew-44

45 Zusammenfassung Kommunikationsorientierte Middleware Alternativen zu RMI/RPC nachrichtenorientierte Middleware (MOM) Anwendungsorientierte Middleware Motivation und Abgrenzung historische Vertreter: DCE & CORBA aktuelle(r) Vertreter: Java EE Beispiel: Duke s Bank Application VIS-1 Middlew-45