systemplattformen für die realisie- rung offener ... · vsis inf min uni hh 07_08 vis2-mid-1...
TRANSCRIPT
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'
VIS2-Mid-2 vsis inf min uni hh 07_08
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
VIS2-Mid-3 vsis inf min uni hh 07_08
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)
VIS2-Mid-4 vsis inf min uni hh 07_08
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
VIS2-Mid-5 vsis inf min uni hh 07_08
'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
VIS2-Mid-6 vsis inf min uni hh 07_08
‘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)
VIS2-Mid-7 vsis inf min uni hh 07_08
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:
VIS2-Mid-8 vsis inf min uni hh 07_08
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
VIS2-Mid-9 vsis inf min uni hh 07_08
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
VIS2-Mid-10 vsis inf min uni hh 07_08
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.
VIS2-Mid-11 vsis inf min uni hh 07_08
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
VIS2-Mid-12 vsis inf min uni hh 07_08
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
VIS2-Mid-13 vsis inf min uni hh 07_08
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)
VIS2-Mid-14 vsis inf min uni hh 07_08
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
VIS2-Mid-15 vsis inf min uni hh 07_08
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
VIS2-Mid-16 vsis inf min uni hh 07_08
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() ;
};
VIS2-Mid-17 vsis inf min uni hh 07_08
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
VIS2-Mid-18 vsis inf min uni hh 07_08
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
VIS2-Mid-19 vsis inf min uni hh 07_08
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
VIS2-Mid-20 vsis inf min uni hh 07_08
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
VIS2-Mid-21 vsis inf min uni hh 07_08
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
VIS2-Mid-22 vsis inf min uni hh 07_08
• ... 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...
VIS2-Mid-23 vsis inf min uni hh 07_08
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...
VIS2-Mid-24 vsis inf min uni hh 07_08
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”:
VIS2-Mid-25 vsis inf min uni hh 07_08
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
VIS2-Mid-26 vsis inf min uni hh 07_08
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
VIS2-Mid-27 vsis inf min uni hh 07_08
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
VIS2-Mid-28 vsis inf min uni hh 07_08
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.
VIS2-Mid-29 vsis inf min uni hh 07_08
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
VIS2-Mid-30 vsis inf min uni hh 07_08
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)
VIS2-Mid-31 vsis inf min uni hh 07_08
WS Messaging: SOAP
• SOAP Anfrage
• SOAP Antwort
VIS2-Mid-32 vsis inf min uni hh 07_08
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
VIS2-Mid-33 vsis inf min uni hh 07_08
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>
VIS2-Mid-34 vsis inf min uni hh 07_08
WSDL - Beispiel
VIS2-Mid-35 vsis inf min uni hh 07_08
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
VIS2-Mid-36 vsis inf min uni hh 07_08
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
VIS2-Mid-37 vsis inf min uni hh 07_08
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
VIS2-Mid-38 vsis inf min uni hh 07_08
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 ->
VIS2-Mid-39 vsis inf min uni hh 07_08