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

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)


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


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 server1CONNECT TO my_accountIDENTIFIED BY my_pw USING ‘server1’;

SELECT some_attributeFROM my_table@server1;

Verwendungin 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

© 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


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

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


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 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


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

© Prof. T. Kudraß, HTWK LeipzigPublish / 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

Documents

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