View
110
Download
5
Category
Preview:
Citation preview
Infrastrukturen für Informationssysteme
© 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)
© 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
© Prof. T. Kudraß, HTWK LeipzigInformationssystem als Verteilte Anwendung (4 Tier Model)
Grundlage für die meisten Applikationen im E-Bereich:E-Business, E-Commerce, E-Government
© Prof. T. Kudraß, HTWK Leipzig
Architektur eines Informationssystems
© 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
© Prof. T. Kudraß, HTWK Leipzig
Middleware (Einordnung)
© 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
© 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)
© 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 server1CONNECT TO my_accountIDENTIFIED BY my_pw USING ‘server1’;
SELECT some_attributeFROM my_table@server1;
Verwendungin Anfrage:
© 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
© Prof. T. Kudraß, HTWK LeipzigGenerischer 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
© Prof. T. Kudraß, HTWK LeipzigZugriff 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
© 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
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
CORBA Beispiel
© 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
© Prof. T. Kudraß, HTWK Leipzig
CORBA Services and Facilities
Facilities
ApplicationObjects
HorizontalCommonFacilities
UserInterface
InformationManagement
SystemsManagement
TaskManagement
Object Request Broker
Common Object Services
Naming Persistence Life Cycle Properties Concurrency Collections Security Trader
Externalization Events Transactions Query Relationships Time ChangeManagement
Licensing
WorkflowFacility
Agent Facility...
VerticalCommonFacilities
CorbaHealth
CorbaFinance
CorbaTel
© 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
© 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)
© 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
© Prof. T. Kudraß, HTWK Leipzig
Java-RMI Ablauf
Java VMJava VM
Java VMJava VM
•Netz
JNDI
Java Applikation
Java Object
Skeleton
Stub
Stub
1: lookup
2: get
3: call
4: call Skeleton
7: result to Stub
5: call OBJ6: return result
8: result
© 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
© 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
© 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
© Prof. T. Kudraß, HTWK Leipzig
Architektur von Java EE 6
© 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
© 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)
© 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“
© 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
© 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-Commerce E-Procurement
SCM
ERP CRM
E-Commerce E-Procurement
Message-broker
© Prof. T. Kudraß, HTWK LeipzigPublish / Subscribe Messaging (Pub/Sub)
1:m Kommunikation virtueller Kanal (Topic)
© 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
Recommended