Infrastrukturen für
Informationssysteme
Ü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)
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
Informationssystem als Verteilte Anwendung (4 Tier Model)
Grundlage für die meisten Applikationen im E-Bereich:
E-Business, E-Commerce, E-Government
Architektur eines Informationssystems
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
Middleware (Einordnung)
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
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)
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:
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
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
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
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
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
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
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
CORBA Beispiel
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
CORBA Services and Facilities
Facilities
Application Objects
Horizontal Common Facilities
InterfaceUser Information
Management Systems
Management Task Management
Object Request Broker
Common Object Services
Naming Persistence Life Cycle Properties Concurrency Collections Security Trader
Externalization Events Transactions Query Relationships Time Change
Management Licensing Workflow Facility Agent Facility ...
Vertical Common
Facilities Corba
Health Corba
Finance Corba Tel
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
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)
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
Java-RMI Ablauf
Java VM Java VM Java VM
Java 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 OBJ 6: return result
8: result
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
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
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
Architektur von Java EE 6
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
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)
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“
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
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
Publish / Subscribe Messaging (Pub/Sub)
1:m Kommunikation
virtueller Kanal (Topic)
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
