Infrastrukturen für Informationssysteme. © Prof. T. Kudraß, HTWK Leipzig Überblick N-Tier-Architektur eines Informationssystems Begriff Middleware Arten.

Präsentation zum Thema: "Infrastrukturen für Informationssysteme. © Prof. T. Kudraß, HTWK Leipzig Überblick N-Tier-Architektur eines Informationssystems Begriff Middleware Arten."—  Präsentation transkript:

1 Infrastrukturen für Informationssysteme

2 © Prof. T. Kudraß, HTWK Leipzig Überblick N-Tier-Architektur eines Informationssystems Begriff Middleware Arten von Infrastrukturen – Verteilte Datenbanken und Gateways (SQL/MED) – Objektorientierte Middleware (CORBA, RMI, Java EE, Persistenz-Frameworks) – Nachrichtenbasierte Ansätze (EAI, Messaging)

3 © Prof. T. Kudraß, HTWK Leipzig Wozu Infrastrukturen für Integration? Überwindung technischer Heterogenität – bisher nur logische und semantische Probleme betrachtet Kommunikation zwischen Quelle und Informationssystem – erfordert einheitliche Protokolle – einfachste Infrastruktur: HTTP-Protokoll zum Abruf physisch entfernter Informationen Aufgaben einer Integrationsinfrastruktur – Quellen finden: über eindeutige Bezeichner (URL, IP-Adresse) oder Suche in Verzeichnissen – Anfragen an die Quellen senden, z.B. parametrisierte Funktionsaufrufe oder auch tatsächliche Anfragen in einer Query Language – Quellen müssen Anfragen empfangen, Antworten generieren und zurückschicken können

4 © Prof. T. Kudraß, HTWK Leipzig Informationssystem als Verteilte Anwendung (4 Tier Model) Grundlage für die meisten Applikationen im E-Bereich: E-Business, E-Commerce, E-Government

5 © Prof. T. Kudraß, HTWK Leipzig Architektur eines Informationssystems

6 © Prof. T. Kudraß, HTWK Leipzig Middleware Problem: Transparenz – Verteilung der Komponenten muss für Benutzer transparent sein (d.h. verteilt genauso wie auf einem Rechner) – Orts-, Zugriffs- und Skalierungstransparenz Middleware Services (Middleware) – in der Mitte zwischen Betriebssystemschicht und der darauf basierenden Netzwerk-Software sowie der spezifischen Anwendung – Ermöglicht den Zugriff auf lokale und nichtlokale Services – Middleware = Softwareschicht auf Basis standardisierter Schnittstellen und Protokolle, die Dienste (Services) für eine transparente Kommunikation verteilter Anwendungen bereitstellt Weiterentwickung zu Application Server-Produkten – SAP Netweaver – IBM Websphere – Oracle / BEA Weblogic

7 © Prof. T. Kudraß, HTWK Leipzig Middleware (Einordnung)

8 © Prof. T. Kudraß, HTWK Leipzig Ansätze für Integrations-Infrastrukturen Infrastruktur-Produkte sind anwendungs- unabhängig Über 100 Anbieter mit weltweitem jährl. Umsatz von zweistelligen Miliardenbeträgen Arten von Integrations-Infrastrukturen – verteilte Datenbanken und Gateways – objektorientierte Middleware (Vorläufer von Applikationsservern) – nachrichtenbasierte Ansätze (a.k.a. Enterprise Application Integration, EAI) – dienstbasierte Ansätze (Web Services, Enterprise Service Bus) Folgevorlesung

9 © Prof. T. Kudraß, HTWK Leipzig Verteilte Datenbanken Grundaufgabe: Zugriff auf externe Daten aus einer Datenbank heraus Homogen: – Basieren auf RDBMS eines einzigen Herstellers – Verschiedene Instanzen physisch verteilt, kommunizieren untereinander über oftmals proprietäre Protokolle (vgl. Oracle) Heterogen: – bestehen aus einem RDBMS – Zugriff auf Datenbanken anderer Hersteller über produktspezifische Gateways Heterogen/generisch: – Bestehen aus einem RDBMS – Zugriff auf andere Datenbanken über generische Schnittstellen Nicht relational: – RDBMS greift über Wrapper auf nicht relational gespeicherte Daten zu – Verteilte Dateisysteme (Hadoop Distributed File System)

10 © Prof. T. Kudraß, HTWK Leipzig Homogene verteilte Datenbanken klassische verteilte Datenbanken Vorteile: – Ausfallsicherheit – Erhöhte Performance (Alternative: paralle DB und Cluster Computing) Zugriff auf verteilte Datenbankinstanzen – spezielle externe Sichten (Database Links) – Orts- aber keine Verteilungstransparenz – Beispiel: CREATE DATABASE LINK server1 CONNECT TO my_account IDENTIFIED BY my_pw USING server1; SELECT some_attribute FROM my_table@server1; Verwendung in Anfrage:

11 © Prof. T. Kudraß, HTWK Leipzig Heterogene verteilte Datenbanken Gateways zum Zugriff auf Datenbanken anderer Hersteller Produkte: – IBM DataJoiner, jetzt Teil des WebSphere Information Integrator: www.ibm.com/software/data/integration – Oracle Transparent Gateways, siehe: www.oracle.com/technology/products/com Aufgaben eines Gateways – Syntaktische Übersetzungen von Anfrage(teilen) zwischen verschiedenen SQL-Dialekten – Übersetzung von Datentypen – Übersetzung von Zugriffen auf Kataloginformationen (ermöglicht Optimierung verteilter Anfragen) SQL-Standardisierung reduziert Heterogenität der Datenbanken

12 © Prof. T. Kudraß, HTWK Leipzig Generischer Zugriff auf verteilte Datenbanken Generische Schnittstellen für RDBMS – ODBC: Open Database Connectivity – JDBC: Java Database Connectivity – OLE-DB: Object Linking and Embedding Beispiel-Szenario: Oracle: Stored Procedure in Java, die über JDBC auf entfernte MySQL-DB zugreift Nachteile: – Keine systemübergreifenden Anfragen (nicht gleichzeitig auf lokalen und entfernten Tabellen) – Keine Optimierung der Anfragen – höherer Entwicklungsaufwand im Vergleich zu anderen Ansätzen

13 © Prof. T. Kudraß, HTWK Leipzig Zugriff auf nicht-relationale Quellen: SQL/MED SQL-Standard 2003 erweitert für Informations- integration: SQL/MED – Management of External Data Konzepte von SQL/MED – FOREIGN DATA WRAPPER: Zugriff auf Datenquellen mit einem gemeinsamen Interface, Funktionalität zum Zugriff auf die jeweilige Quelle, Kommando registriert Wrapper, Implementierung muss gebunden sein – FOREIGN SERVER: gehört logisch zu einem FOREIGN DATA WRAPPER, beschreibt den Zugriff auf eine bestimmte Datenquelle des zugehörigen Typs – FOREIGN TABLE: beschreibt die Daten einer Datenquelle in relationaler Form, kann z.B. zur Definition von Tabellensichten auf externe XML-Dateien genutzt werden, Zusammenfassung verschiedener FOREIGN TABLES über ein FOREIGN SCHEMA möglich

14 © Prof. T. Kudraß, HTWK Leipzig SQL/MED (Forts.) Anfragebearbeitung – Registrierung der notwendigen Wrapper, Server und externen Tabellen Verwendung wie lokale Tabellen – Anfrageteile an jeweilige Datenquelle gesandt, FOREIGN Server helfen bei Anfrageplanung – Konfiguration der FOREIGN-Konzepte über Attribut- Wert-Paare (z.B. Beschreibung einer Textdatei) Datentyp DATALINK – zweite Erweiterung in SQL/MED – explizite Verknüpfung zu einer Datei in einem DBMS- externen Dateisystem – Dateizugriff über Optionen konfigurierbar

15 © Prof. T. Kudraß, HTWK Leipzig Objektorientierte Middleware Grundidee: vollständige Kapselung der physischen Verteilung von Objekten Kommunikation: – entfernte Objekte spezifizieren Interface zur Publikation ihrer Methoden – Aufruf der Methoden wie bei lokalen Objekten Middleware-Services übernehmen Aufgaben aus der Applikation: – Lokalisation von Objekten – komplexere Transaktionsprotokolle – verteilte Ausführung (Parallelisierung, Verfügbarkeit) Anwendungsunabhängigkeit, im Idealfall auch betriebssystem- und sprachunabhängig Beispiele: CORBA, JAVA RMI, Java EE,.NET

16 © Prof. T. Kudraß, HTWK Leipzig Was leistet CORBA? Common Object Request Broker Architecture Standard der OMG 1992 – Beruht auf Objektmodell, Objektorientierte Programmierung – Liefert abstrakte Beschreibung der Schnittstellen mit Interface Definition Language (IDL) – Object Request Broker (ORB) ermöglicht Kommunikation und Koordination zwischen beliebígen CORBA-Objekten – CORBA Services

17 © Prof. T. Kudraß, HTWK Leipzig CORBA Client-Server-Prinzip Client sendet Anforderung für einen Service an eine Objektimplementierung (Server) Server besitzt wohldefiniertes Interface, in Interface Definition Language (IDL) spezifiziert Übersetzungsroutinen für viele Programmiersprachen (Language Bindings) Ausführung des Services, Ergebnisse an Client zurück

18 © Prof. T. Kudraß, HTWK Leipzig CORBA Beispiel

19 © Prof. T. Kudraß, HTWK Leipzig Wie arbeitet CORBA? Object Request Broker (ORB) – Einbettung von Objekt–Implementierungen (Server Objekte) – Vergabe von Objektreferenzen – Entgegennahme von Aufrufen vom Client – Transport der Aufrufe zum Server – Ggf. Aktivierung eines Server-Objektes – Übergabe des Aufrufs zum Serverobjekt – Entgegennahme von Ergebnissen und Transport / Rückgabe zum Client – Unterstützung von Sicherheits- und Abrechnungsfunktionen

20 © Prof. T. Kudraß, HTWK Leipzig CORBA Services and Facilities Facilities Application Objects Horizontal Common Facilities User Interface Information Management Systems Management Task Management Object Request Broker Common Object Services NamingPersistenceLife CyclePropertiesConcurrencyCollectionsSecurityTrader ExternalizationEventsTransactionsQueryRelationshipsTime Change Management Licensing Workflow Facility Agent Facility... Vertical Common Facilities Corba Health Corba Finance Corba Tel

21 © Prof. T. Kudraß, HTWK Leipzig Kritik an CORBA viele Service-Spezifikationen zu allgemein ohne konkreten Nutzen, z.B. Life Cycle-Service (zur Unterstützung des Objektlebenszyklus) oder Relationship Service (zur Verwaltung von Beziehungen zwischen Objekten) hohe Komplexität bei Erstellung von CORBA-basierten Anwendungen aufgrund Plattformunabhängigkeit (z.B. IDL, spezielle Datentypen) enge Kopplung von Objekten über statische Interface erschwert unabhängige Entwicklung unterschiedliche ORB-Varianten erschwerte Portabilität von Anwendungen

22 © Prof. T. Kudraß, HTWK Leipzig Java RMI als Alternative RMI – basiert auf Java – plattformunabhängig, erfordert nur JVM – nur entfernte Java-Objekte ansprechbar CORBA – verbirgt alle Abhängigkeiten durch Object Request Broker – Sprachunabhängige Interface Definition Language (IDL)

23 © Prof. T. Kudraß, HTWK Leipzig Java Remote Method Invocation Erstellung von verteilten Java-Anwendungen (Java-to-Java ) Methoden eines remote Java Objekts werden von einer JVM aufgerufen, die auf einem anderen Host läuft. ein Java Programm kann ein remote Objekt aufrufen sobald es eine Referenz des remote Objekts hat – über den Bootstrap Naming Service von RMI oder – über ein (Aufruf-) Argument bzw. einen Rückgabewert ein Client kann ein remote Objekt in einem Server aufrufen - Server kann wiederum ein Client eines remote Objekts sein Java Object Serialization zum Speichern und Retrieval von Java Objekten – Zustand serialisiert über einen Stream geschrieben und gelesen (wie in Datei) Sockets als Basis-Kommunikationsmechanismen

24 © Prof. T. Kudraß, HTWK Leipzig Java-RMI Ablauf Java VM Netz JNDI Java Applikation Java Object Skeleton Stub 1: lookup 2: get 3: call 4: call Skeleton 7: result to Stub 5: call OBJ6: return result 8: result

25 © Prof. T. Kudraß, HTWK Leipzig Remote Method Invocation (RMI) entferntes Objekt (remote Object) – Aufruf von Methoden von Java-Objekten, die auf anderer JVM erzeugt und verwaltet werden (auf anderem Rechner) rmic – rein Java-basierte Lösung keine Sprache zur Schnittstellendefinition – Compiler rmic generiert den Stub für Client und Server direkt aus den Klassen – Java Skeleton = Server Stub Registry – Registrierung der remote objects beim Binder – Ansprache über Binder oder handle-driven Broker

26 © Prof. T. Kudraß, HTWK Leipzig RMI Programmierung Erstellung eines RMI-Programms in folgenden Schritten: 1.Definiere das entfernte Interface (Interface Definition File), das die entfernten Methoden beschreibt, welche der Client benutzt zur Interaktion mit dem remote Server 2.Definiere die Server-Applikation, welche das entfernte Interface implementiert (Interface Implementation File) 3.Aus dem Interface Implementation File kann mit Hilfe des rmic-Compilers das Stub Class File generíert werden (Impl_stub.class) 4.Starte die Registry und den Server 5.Definiere den Client, der die entfernten Methoden des Servers aufruft und starte den Client

27 © Prof. T. Kudraß, HTWK Leipzig Java EE Java Plattform für Business Anwendungen als sprachspezifischer Ansatz zur Umsetzung einer objektorientierten Middleware Enterprise Edition: Robuste Plattform für unternehmensweite, geschäftskritische Anwendungen – Einbindung in Unternehmensinfrastruktur – Transaktions-Unterstützung – Datenbank Zugriff Komponentenmodell der Java EE basiert auf klassischer 3-Schichten- Architektur für verteilte Anwendungen Zwei Typen von Anwendungsarchitekturen – Web basiert – Traditionelle Client/Server Architektur

28 © Prof. T. Kudraß, HTWK Leipzig Architektur von Java EE 6

29 © Prof. T. Kudraß, HTWK Leipzig Beispiel: Persistenz Java Persistence API – Persistenz-Lösung – bridge the gap between objects and relations – Bestandteile: Java Persistence API Query Language Beschreibung der objektrelationalen Abbildung (Metadaten) Java Database Connectivity API (JDBC) – Aufruf von SQL aus Java heraus – Nutzung der API aus: Enterprise Bean, Servlet, JSP Seite

30 © Prof. T. Kudraß, HTWK Leipzig Persistenz von Java-Objekten Java-Objekte sind normalerweise transient Speicherungsmöglichkeiten: – Objektserialisierung Serializable – Manuelles Objekt-Relationales Mapping Handgeschriebener JDBC-Code – OR-Mapping-Tools Container Managed Persistence (EJB 2.x) Tools und Frameworks: Castor/JDO, Hibernate Standards: Java Persistence API (JPA) – Objektorientierte Datenbanksysteme (OODBMS) db4o (Versant)

31 © Prof. T. Kudraß, HTWK Leipzig Persistenz von Java-Objekten (Forts.) Bestandteile: - Hibernate Konfigurationsdatei (XML) - Beschreibung der objektrelationalen Abbildung (Metadaten): pro persistenter Klasse Hibernate Mapping XML-Datei - Hibernate Query Language (HQL) - Hibernate Java Library u.a. benötigte JAR-Dateien (Low-level API: JDBC) - Java-Klassen - DB mit DB-Schema Beispiel: Hibernate Persistenz-Lösung – bridge the gap between objects and relations

32 © Prof. T. Kudraß, HTWK Leipzig Enterprise Application Integration Zwei Sichtweisen auf EAI – Produkte zur Integration von Softwaresystemen – Produkte zur Integration von Prozessen Prozessintegration vs. Datenintegration – Verknüpfung von Prozessen zur Laufzeit vs. Integration eines bestehenden Datenbestandes – Prozessintegration schon wirksam bei Produktion der Daten Geschäftsprozesse betreffen viele Anwendungen, vgl. Workflowmanagement zur Realisierung von automatisierbaren Geschäftsprozessen Kommunikation – synchrone Remote Procedure Calls (RPC) vs. Asynchroner Nachrichtenaustausch – Vorteile loser Kopplung: höherer Durchsatz, weniger fehleranfällig und flexibler

33 © Prof. T. Kudraß, HTWK Leipzig Message Broker Prozessintegration durch Nachrichtenaustausch auf Basis eines Messagebrokers Aufgaben des Messagebrokers – Transaktionale Sicherstellung der Nachrichtenzustellung auch bei Fehlern oder Systemausfällen – Transformation der Nachrichten aus Quellformat in verschiedene Zielformate – Analyse von Nachrichten und deren Weiterleitung gemäß Inhalt oder Typ (content-based routing) – zentrale Administration der Nachrichtenverteilung – revisionssichere Archivierung aller Nachrichten SCM ERP CRM E-CommerceE-Procurement SCM ERP CRM E-CommerceE-Procurement Message- broker

34 © Prof. T. Kudraß, HTWK Leipzig Publish / Subscribe Messaging (Pub/Sub) 1:m Kommunikation virtueller Kanal (Topic)

35 © Prof. T. Kudraß, HTWK Leipzig Publish-Subscribe Aufgaben des Messagebrokers – Nachrichtenvermittlung von den Publishern an die Subscriber – Transformation von Nachrichten – Workflowfunktionalität zur Behandlung von abhängigen Ereignissen Produkte – Java Message Service (JMS) – IBM MQSeries – Software AG EntireX – JBoss, ActiveMQ EAI-Systeme mit ERP-Adaptern vs. Message Queues Wenig Unterstützung bei Informationsintegration – aber: Transformation von Nachrichten (z.B. als XML- Dokumente), Methoden des Schema Mapping denkbar