Systemplattformen für die Realisie- rung offener ... · vsis inf min uni hh 07_08 VIS2-Mid-1 Systemplattformen für die Realisie-rung offener verteilter Systeme: Standards für 'Middleware

VIS2-Mid-1 vsis inf min uni hh 07_08

Systemplattformen für die Realisie-

rung offener verteilter Systeme:

Standards

für

'Middleware'

Systemplattformen für die Realisie-

rung offener verteilter Systeme:

Standards

für

'Middleware'


Was ist „Middleware“ ?

“The software layer that lies between the operating system and the applications on each side of a

distributed computing system in a network”

[Definition nach ObjectWeb]

Distributed Application

Middleware

Middleware API

Operating System(Processes, Communication,

Memory Management)

Operating System API

Distributed Application

Middleware

Middleware API

Operating System(Processes, Communication,

Memory Management)

Operating System API

Network


Was ist „Middleware“ ?

• Aufgaben: zum Beispiel

— allgemein: Verbergen der Heterogenität und des Ortes, Programmierabstraktionen

— Transport komplexer Daten (Messaging)

— Vermittlung von Funktionsaufrufen (Remote Procedure Calls)

— Herstellung v. Transaktionssicherheit über ansonsten unabhängige Teilsysteme

• Kategorien:

— kommunikations-orientiert: z.B. RPC, Java RMI

— anwendungs-orientiert: z.B. CORBA, J2EE, .NET, MIDP

— nachrichten-orientiert: z.B. Java Message Service (JMS)


Middleware-Systemarchitektur „klassisch“...

Framework Local Services

FRAMEWORK

API veneer

ToolsApplication •••UserInterface

Platform_j• OS

• Hardware

Platform Interface

Application Programming Interface

•••

Application

Platform_i• OS

• Hardware

[Bernstein 93]

“Middleware” : (Distributed) System Services


'Open Distributed Processing' (ODP)

• Ziel: Standardisiertes Rahmenwerk für Entwicklung verteilter Systeme

— ISO / ITU-T Standard (1991)

— herstellerunabhängige Umgebungen

— heterogene Technologien (Hardware & Software)

• ODP Reference Model (ODP-RM)

— Meta-Modell für die Beschreibung einer Architektur für verteilte Systeme

• durch: Konzepte, Regeln und Definition von Infrastrukturobjekten

— ODP Transparencies: z.B. Orts- und Zugriffstransparenz etc.

— ODP Functions: z.B. Namensdienste, Verzeichnisdienste etc.

— ODP Viewpoints: Sichten “verschiedener Personen” auf ein verterteiltes System

— ODP Viewpoints definieren ODP Functions,welche ODP Transparencies implementieren


‘Middleware’-Standards für verteilte Systeme:

Offenes,heterogenes,

verteiltes Infor-mationssystem

Enterprise Projection

• Beschreibung von Systemumgebungund Zweck aus Unternehmenssicht

• Requirements, Constraints, Actions, Policies

Information Projection

• Modellierung der Informationen undderen Verarbeitung (Informationsfluss)

Computational Projection

• Sicht des Anwendungsprogrammierers• Zerlegung in logische, funktionale Komponenten• Objekte mit Schnittstellen, die Dienste anbieten/nachfragen• Beschreibung durch Computational Languages, z.B. Java, IDL

Engineering Projection

• Beschreibung der erforderlichenSystemunterstützung für Objekte derComputational Projection

• Einführung generischer Infrastrukturobjekte

Technological Projection

• konkrete Technologien (HW / SW)

5 “Viewpoints”:

a) ISO „Open Distributed Processing“ (ODP)


Middleware - Standardisierung: OSF DCE und OMG CORBA

Standardisierungsziel:

Herstellerübergreifendes Architekturmodell und Systemplattformzur Unterstützung offener verteilter Anwendungen, dazu:

‘Open Software Foundation’ (OSF) / ‘Open Group’ (OG):

---> “Distributed Computing Environment” (DCE)

c) Architektur- und Objektmodell CORBA:

b) Erweiterte (Betriebs-) Systemplattform - DCE:

‘Object Management Group’ (OMG):

---> “Common Object Request Broker” (CORBA)

Middleware-Standards fürverteilteSysteme:


Distributed Computing Environment

• Entwickelt in den frühen 90ern

— Open Software Foundation (u.a. DEC, Hitachi, IBM, HP, Sun, AT&T)

— OSF wurde schließlich Teil der Open Group

• Ziel: Jeder Knoten eines Netzwerkes soll …

— Benutzer authentifizieren

— Zugriff auf Systemressourcen bieten

— und diese entfernt über eine API ansprechen

• Bietet ein Framework und Toolkit für Entwicklung vert. Systeme

— Seit 2005 unter der LGPL verfügbar

• Basiert auf individuellen Entwicklungen der OSF-Mitglieder


ad b: Konkrete Bausteine einer offenen Middleware:'Distributed Computing Environment' (OSF/OG DCE)

Verteilte Anwendungen

Betriebssystem- undNetzwerkdienste

- Entwicklungswerkzeuge

- Menge integrierter Dienste mitfest definierten (Programmier-)Schnittstellen

D istributedC omputingE nvironment

DCE umfasst:

- verbesserte NCA- DECdns Name Service- DIR-X (X.500 von Siemens)- Kerberos (MIT + HP extensions)- PC-NFS (Sun)- AFS 4.0 Distributed file system- Concert Multi-thread-arch. (DEC)- DECdts Time services


Herstellerübereinkunft: OSF/OG „Distributed Computing Environment“ (DCE): Architektur

Local Operating and Communication Services

Thread Service

Remote Procedure Call (RPC)

TimeService

DirectoryService

SecurityService

Verteilte Anwendung

• TRAN • TRPC• Tran-C• Server Core

ENCINA Toolkit

Distrib.File Sys.

Sonst.


ad c: 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, Naming, Security ...)

Beziehungen zu: ISO/IEC JTC1 WG7 (ODP)

CCITT/ITU und ISO X.500 (Directory) etc.

Unix bzw. X/Open


CORBA - Bestandteile

• Ziel:

— CORBA-konforme Implementierungen vereinfachen das Erstellenverteilter Anwendungen in heterogenen Umgebungen

• Spezifikation ist unabhängig von

— Programmiersprachen

— Betriebssystemen

— Hardware

• Bestandteile der Spezifikation

— Architektur

— Interface Definition Language

— Protokolle

— Services

• Implementierungen

Orbix, MICO, IBM, ORBit, VisiBroker, OmniORB, TAO, MiddCor, OpenORB, JacORB, Orbacus, Java ORB


CORBA-Architektur

Interface repository Implementation repository

Dynamicinterface

Staticstubs ORB interface

(portable)Object adapter

IDL Skeleton

Client Server Object

- Find object instance

- Supervise transfer of control

- Data transfer from caller to object instance

- Error management

Object Request Broker Kernel

Interface Definition

Language (IDL)


Client SideObject

ImplementationSide

ORB

C

C++

Ada

I D L

I D L

I D L

I D L

I D L

I D L

COBOL

C

Ada

C++

Small

talk

JAVA

I D L

I D L

I D L

I D L

I D L

I D L

ORB

C++

COBOL

Small

talk

JAVA

Die Rolle der IDL


Interface Definition Language (IDL)

- Definition der Typen der Argumente

- Spezifikation der Prozedurköpfe

- Zuweisung von Identifikationsnummern zu den Prozeduren

- Definition des Programms und der Version

Bestandteile

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

- 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

Datenabstraktion

Marshalling/Unmarshalling-Routinen (Stubs)

- Generierung für jeden im Schnittstellenmodul definierten Datentyp

(Stubs) automatisch möglich


CORBA IDL-Beispiel

struct Rectangle{ 1

long width;

long height;

long x;

long y;

} ;

struct GraphicalObject { 2

string type;

Rectangle enclosing;

boolean isFilled;

};

interface Shape { 3

long getVersion() ;

GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; 4

interface ShapeList { 5

exception FullException{ }; 6

Shape newShape(in GraphicalObject g) raises (FullException); 7

All allShapes(); // returns sequence of remote object references 8

long getVersion() ;

};


CORBA IDL-Beispiel

public interface ShapeListOperations {

Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;

Shape[] allShapes();

int getVersion();

}

public interface ShapeList extends ShapeListOperations, org.omg.CORBA.Object,

org.omg.CORBA.portable.IDLEntity { }

Java-Interfaces, generiert vom IDL-Compiler

… zusätzlich werden generiert:

• Skeleton- bzw. Proxy-Klassen

• sowie Klassen, korrespondierend mit den structs-Feldern im IDL


CORBA-Architektur

Object Request Broker Kernel

• vermittelt zwischen Clients und

(entferntem) aufzurufendem Objekt

• Nachrichtentransfer zwischen

Client und Server

• Konvertiert zwischen Strings und

Objektreferenzen

• Sucht/findet und aktiviert

Objektinstanz

• verwendet Inter-ORB Protokoll


CORBA-Architektur

Stubs (Proxies) / Skeletons

• Generierung aus IDL-Beschreibung

• Proxies in der Client-Sprache• Skeletons in der Server-Sprache

• (Un-) Marshalling

• Request (Skeleton) & Reply (Proxy)• Argumente, Ergebnisse, Exceptions


CORBA-Architektur

Implementation Repository

• Sucht und aktiviert registrierte

Server auf Anfrage

Interface Repository

• Liefert Informationen über registrierte IDL-Schnittstellen

• Methodennamen, formale Parameter, Exceptions

• Auf diese Weise wird Reflection realisiert

• verwendet bei Dynamic Invocation


CORBA-Dienste

• besitzen standardisierte IDL-Schnittstelle

• Beispiele:

— Naming Service

— Trading Service

— Event Service

• … und viele weitere…

— Life Cycle Management Service

— Relationship Service

— Transaction Service

— Time Service

— Security Service


• ... Heterogenität

• ... Integration— legacy

• ... Verteilung

• ... Ersetzbarkeit— Information hiding

• ... Wiederverwendbarkeit— Vererbung

• ... Erweiterbarkeit— Polymorphie

CORBA löst Probleme der...

• ... schneller Standardisierungsprozess— 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

Vorteile von CORBA

Unter den Randbedingungen...


Nachteile von CORBA

• ... grundlegender Mängel, z.B.— Ortstransparenz (lokale und entfernte Objekte werden gleich behandelt)

• ... Entwurfs- und Prozessunzulänglichkeiten— Standard bestehend aus einer Vereinigung aller Features in allen Vorschlägen

� Spezifikation sehr komplex, oft nicht eindeutig, vollständige Implementierung zu teuer

• ... verfügbarer Implementierungen— meist unvollständig, nicht adequat

— Referenzimplementation von Feature-Vorschlägen wurde nicht verlangt

• ... IDL— IDL “kleinster gemeinsamer Nenner”

— IDL definiert nur Interface, keine Implementierung

— keine Semantik in IDL

— z.T. mangelhafte Abbildbarkeit auf Sprachen

— schlechte Reversibilität

Kritik hinsichtlich...


Neuer, anwendungsnaher Ansatz zur Systemintegration heute: „Web Services“

• „A web service is any service that is available over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language.”

[Ethan Cerami, Web Services Essentials, O'Reilly, 2002 ]

• “A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.”

[W3C, Web Services Glossary]

• Web Services are... „...self-contained, modular business applicationsthat have open, Internet-oriented, standards-based interfaces.”

[UDDI consortium: UDDI_Executive_white_paper, 2001]

d) nach dem Motto “alles neu, macht der Mai…”: “Web Services”:


Web Services: Charakteristika

Ein Web Service ist also ein Dienst, der…

• über das Internet oder Intranets verfügbar ist,

• ein standardisiertes (XML-) Nachrichtensystem verwendet,

• programmiersprachen- und betriebssystemunabhängig ist,

• unter Verwendung einer XML-Grammatik selbstbeschreibend ist

• und über einen einfachen Mechanismus auffindbar ist.

Register Dienstnehmer Dienstanbieter

� Dienst auffinden

� Dienstbeschreibung

abrufen

� Dienst aufrufen


Web Services: Charakteristika

Wie gesagt, das hinter den Web Services stehende Konzept ist nicht neu -

CORBA, DCE, DCOM etc. können das doch auch - aber:

• bisherige Ansätze sind meist sehr komplexe Standards und benötigen eine neue / eigene Infrastruktur

— sie sind gut für die Server-zu-Server Kommunikation

— sie bieten untereinander keine Interoperabilität

• Web Services verwenden die standardisierten Internetprotokolle, d.h.

— Firewalls und Proxies können somit leicht durchdrungen werden

— es ist keine neue Infrastruktur ist notwendig – Erprobtes wird verwendet

— sie sind gut für Client-to-Server Kommunikation

— sie sind untereinander voll interoperabel


Web Services : Einsatz und Vision

• Heute:

— unternehmensinterner Einsatz, z.B. im Rahmen von EAI

— unternehmensübergreifener Einsatz, aufbauend auf bestehenden Geschäftsbeziehungen

• Morgen:

— (Manuelle) Suche nach Diensten in einem Verzeichnis

• Übermorgen:

— Abbildung komplexer Geschäftsprozesse

— (Vollständig) automatisierte Dienstnutzung

— Realisierung virtueller Unternehmen


Web Service-Protokollebenen

Discovery UDDIDiscovery UDDI

Description WSDLDescription WSDL

XML Messaging SOAP, XML-RPCXML Messaging SOAP, XML-RPC

Transport HTTP, SMTP, FTP Transport HTTP, SMTP, FTP

Transport: Verantwortlich für den Nachrichtentransport zwischen den Anwendungen

XML Messaging: Verantwortlich für Transport und Kodierung der Nachrichten (in XML)

Description: Verantwortlich für Beschreibung der öffentlichen Schnittstelle des Dienstes

(funktional, prozedural, quality-of-service)

Discovery: Verantwortlich für das Zusammenfassen der Dienste in einer allgemeinen

„Registrierung“ und deren leichtes Einstellen und Auffinden.


WS Transport

• HyperText Transport Protocol (HTTP)

— einfaches Request / Response Protokoll

— basiert auf TCP und ist somit verbindungsorientiert und zuverlässig

— für jedes Request / Response-Paar wird eine eigene Verbindung aufgebaut: es gibt keinen expliziten Zustand über mehrere Paare

— als Basisprotokoll des WWWs gelangt es leicht durch Firewalls

• Nachrichtenübermittlung an den Server mit POST-Anfragen

POST /myFunctions/echo HTTP/1.1

Host: www.myserver.com

Content-Type:Text/plain

Content-Length: 12

Hello World!

Header-Daten

Anfrage-Daten


WS Messaging: SOAP

• SOAP: Simple Object Access Simple Object Access ProtocolProtocol

• plattformunabhängiges, zustandsloses und XML-basiertes Protokoll

zum Austausch von Einwegnachrichten

• komplexere Kommunikationsformen können auf Basis dieser Einweg-

nachrichten erzeugt werden (request/response etc.)

• SOAP-Nachrichten bestehen

aus einem „Umschlag“,

einem optionalen „Kopfteil“

und einem „Nachrichten-

körper“ mit optionaler

Fehlerbehandlung

SOAP Envelope (required)SOAP Envelope (required)

SOAP Header (optional)

SOAP Body (required)

SOAP Fault (optional)


WS Messaging: SOAP

• SOAP Anfrage

• SOAP Antwort


WS Description: WSDL

•• WSDL:WSDL: Web Services Web Services DescriptionDescription LanguageLanguage

• XML-Grammatik zur Beschreibung von Web Services

• unabhängig von der verwendeten Plattform und Programmier-sprache

• enthält Angaben zu:

— allen öffentlichen Funktionen des Dienstes (die Schnittstelle)

— den verwendeten Datentypen für Anfragen und Antworten

— dem zu verwendenden Transportmechanismus

— der physikalischen Adresse des Dienstes

• WSDL-Dienstbeschreibungen können automatisch generiert werden


WSDL in a nutshell…

<definitions> Wurzelelement in WSDL<definitions> Wurzelelement in WSDL

<types> Welche Datentypen werden übertragen ?

<messages> Welche Nachrichten gibt es ?

Welche Operationen/Funktionenwerden unterstützt ?

Welches Transportprotokoll wirdverwendet und wie sind dessen Details ?

<service> Wo finde ich den Web Service ?

<portType>

<binding>


WSDL - Beispiel


WS Discovery: UDDI

•• UDDI:UDDI: Universal Universal DescriptionDescription, Discovery, and Integration, Discovery, and Integration

• definiert, wie Informationen über Web Services und deren Anbieter publiziert und gefunden werden können

• Besteht aus drei Elementen:

— einem logisch zentralen, physikalisch aber verteiltem Registry-Service,

— einem Satz von XML-Schemata zur Beschreibung der Anbieter und ihrer Web Services und

— einer SOAP-Schnittstelle für den Zugriff auf die Registry

• Enthält Informationen aus drei Kategorien:

White Pages

Allgemeine Anbieterdaten

White Pages

Allgemeine Anbieterdaten

Yellow Pages

Kategorien zur Einordnung

Yellow Pages

Kategorien zur Einordnung

Green PagesTechnische Informationender angebotenen Dienste

Green PagesTechnische Informationender angebotenen Dienste


UDDI Registrierung

• Die UDDI UDDI RegistryRegistry ist logisch zentralisiert, physikalisch aber verteilt realisiert.

• Eine Replikation der Daten unter den einzelnen Knoten erfolgt alle 24 Stunden.

— Alle Knoten enthalten jeweils alle registrierten Daten

• Registrierungen können entweder über eine WWW-Schnittstelle oder über die API vorgenommen werden.

— die SOAP-Schnittstelle wird von allen Knoten unterstützt

UDDIRoot

UDDI„Wolke“

Anfragen


UDDI und SOAP

Die UDDI Registry ist über eine SOAP-Schnittstelle ansprechbar:

BenutzerBenutzer

UDDISOAP Request

UDDISOAP Response

UDDI Registry KnotenUDDI Registry Knoten

HTTPServer

UDDIRegistry Service

SOAPProzessor

B2B DirectoryErzeugen, Anzeigen, Aktualisieren und Löschen von registrierten Daten implementierungsneutrale

Umsetzung

UDDI-Wolke


Web Services: Entwicklung bis 2004

• Weite Unterstützung in der Industrie (HP, IBM, Microsoft, Bea, Ariba…)

• 2004 bereits über 20 verschiedene „WS-xx-Specifications“ verabschiedet (!)

• Aber: das „Rad“ mehrfach „neu erfunden“ !

• Offene Fragen (u.a.):

— Interoperabilität (??)

— Sicherheit (inzwischen teilweise adressiert)

— Vertrauen in Registry-Betreiber (!)

— Bezug zu neueren Anwendungen wie z.B. „Mobilität“

— Akzeptanz (?)

— etc.

Adobe Acrobat-Dokument

.. und August 2006 ->


Documents

Systemplattformen für die Realisie- rung offener ... · vsis inf min uni hh 07_08 VIS2-Mid-1 Systemplattformen für die Realisie-rung offener verteilter Systeme: Standards für 'Middleware