Vorlesung „SOA – Entwicklung verteilter Systeme auf … · Object Request Broker, zentrale CORBA-Komponente, ermöglicht transparente Kommunikation über GIOP / IIOP ... (EntireX)

Vorlesung „SOA –Entwicklung verteilter Systeme auf Basis serviceorientierter Architekturen“

Dr.-Ing. Iris Braun, WS 2008/2009

2. Technologien

Dr.-Ing. Iris Braun Vorlesung SOA, 2. Technologien Folie 2

Gliederung

• Anforderungen an die Technologien zur Umsetzung von SOA

• Vorstellung geeigneter Technologien– Klassischer RPC – Middleware– Komponentenplattformen– Web Services– RESTful Services

• Bewertung


Bewertung der Technologien zur Umsetzung von SOA

• Anforderungen:– Effect: Funktionalität kapseln– Visibility: Über wohldefinierte Schnittstelle anbieten– Interaction: Lose Kopplung über

Nachrichtenaustausch– Interoperabilität– Transparenz der zugrundeliegenden Implementierung

• Geeignete Technologien?– Klassischer RPC – Middleware– Komponentenplattformen– Web Services


Middleware

Client-Server-Paradigma

Middleware(z.B. Java RMI, CORBA,

.NET, SOAP)

Server(z.B. Kontenserver)

Anwendungs-interaktion

Transportorientierte Schichten

(z.B. TCP/IP, SNA)

Phys. Netzwerk(z.B. Fast Ethernet, Token Ring, ATM)

TransportorientierteSchichten

Phys. Netzwerk

Client(z.B. Kasse)

Aufrufender (Nutzer) Aufgerufener (Anbieter)


Remote Procedure Call (RPC)

• Erweiterung des Prozeduraufrufs zum Fernaufruf• Ziel: Syntaktische und semantische Uniformität

– Aufrufmechanismus– Sprachumfang– Fehlerfälle

1. Absetzen des Aufrufs2. Kodierung des Aufrufs3. Absenden 4. Warten

9. Dekodierung10.Erhalt der Ergebnisse11.Fortsetzung des Programms

5. Dekodierung6. Ausführung7. Kodierung8. Senden

Aufrufender (Client) Aufgerufener (Server)


RPC: Beispielarchitektur

• Beispielsystem: DCE (Distributed Computing Environment)

Ruf-

Paket

Import Export

Client-Rechner Server-RechnerNetz

sende

empf.

warten

Aufruf-kodierung

De-kodierung

Aufruf

Ergebnis

Aus-führung

De-kodierung

Kodierung

empf.

sende

lokalerAufruf

lokalesErgebnis

Ergebnis-

Paket

Client Client-Stub

Laufzeit-system

Laufzeit-system

Server-Stub

Server

DirectoryService


RPC für SOA

+ Interaction, Effect: Aufrufparameter und Ergebnisse+ Visibility: Schnittstellenbeschreibung: IDL (Interface

Definition Language)+ Visibility: Verzeichnisdienst (Directory Service)+ Getrennte Adressräume+ Kopplung über relativ schmalen Kanal möglich

– Plattform- und programmiersprachenabhängig – Synchrone Übergabe des Kontrollflusses, Client muss auf

Server warten– Strenge Client- / Server Semantik– Nicht für Austausch größerer Datenmengen geeignet


XML-RPC

+ Aufruf entfernter Prozeduren (RPC) über XML-Nachrichten+ W3C-Standard+ Interoperabel, Module in vielen Programmiersprachen verfügbar− Beschränkt auf RPC, synchrone Kommunikation:

+ Einfacher implementierbar, − weniger flexibel

− Keine SOAP-vergleichbare Industrieunterstützung

Client Server

Daten

Daten

Daten

DatenXML XML

HTTP



Client(z.B. Kasse)

Middleware im Client-Server-Paradigma

Transportorientierte Schichten

(z.B. TCP/IP, SNA)

Phys. Netzwerk(z.B. Fast Ethernet, Token Ring, ATM)

TransportorientierteSchichten

Phys. Netzwerk

Client(z.B. Kasse)

Middleware(z.B. Java RMI, CORBA,

.NET, SOAP)


Middleware

Anwendungs-interaktion

Objekt-interaktion

Definition von Middleware: “Infrastrukturdienste für verteilte Anwendungen zur Überbrückung der Heterogenität unterschiedlicher Systeme und Netze.”


Java Remote Method Invocation (RMI)

• Interaktion auf Objekt-Ebene

Client-Rechner Server-Rechner

Objekt-Interface, von A und B implementiert

RemoteObjectRegistry

Naming Lookup

Laden von Klassen-Informationen zu B

Aufruf von B

Antwort

B Remote-Objekt

LokalesObjekt

(Remote-Interface)

A


Java RMI: Interne Systemarchitektur

Remote Reference Layer:• Verwaltung entfernter Objektreferenzen• Aufruf replizierter Objekte• Aktivierung von Objekten bei Bedarf

AnwendungClient-Objekte

Server-Objekte

RMISystem

Stub

Remote Reference Layer

Transport Layer


Java RMI für SOA

− Nur zur Vernetzung von verteilten Java-Anwendungen - auf Java-Umgebung beschränkt

− Schnittstellenbeschreibung in Java, keine spezielle IDL− Visibility: Sehr einfacher Namensdienst

+ Keine Umwandlung in spezielles Übertragungsformat, hohe Performanz

+ Kann wie lokales Objekt aufgerufen werden

C++ Java


CORBA - Architektur

• ORB: Object Request Broker, zentrale CORBA-Komponente, ermöglicht transparente Kommunikation über GIOP / IIOP (General / Internet Inter-ORB Protocol)

• AO: Application Objects, nutzen den ORB zur Kommunikation• CORBA definiert Standarddienste, u.a. Naming Service (findet

Objekte über Name), Persistence Service (nichtflüchtiges Speichern/Laden von Objekten), Trader Service (Gelbe Seiten), Transaction Service

ORB ORB

DienstDienst

ORB

AO

AOAO

GIOP /IIOP


CORBA - Architektur

• standardisierte Schnittstelle: IDL (Interface Definition Language), enthält u.a. Datentypen, Schnittstellen von Objekten und Instanzvariablen

• Ermöglicht automatische Codegenerierung: IDL-Compiler erzeugt „Übersetzer“ für Client (Stub) und Server (Skeleton)

• Implementierung von Objekten: sprachunabhängig• Auch dynamische Schnittstellen möglich

Client

Stub

Server

durchden ORB

durchgeführtSkeleton

Objektreferenz


CORBA für SOA

+ Ermöglicht plattform- und sprachenunabhängige Kommunikation durch IDL und standardisierten ORB

+ Visibility: Namensdienst-Lösung (mittlerweile von URI verdrängt)

− Komplexe Spezifikation -> Entstehung inkompatibler Lösungen

• Best Practice Credit Suisse AG:– Seit 1999 CORBA-Implementierung nach SOA-

Prinzipien– Rund 800 „Public Services“, 44 Prozent mehrfach

verwendet


Komponentenarchitekturen

Komponente– funktional/technisch abgeschlossene ausführbare Einheit

innerhalb eines Komponentencontainers– eindeutige Klassifizierung– als Einheit entwickel- und konfigurierbar– klar spezifizierte Schnittstelle (Kapselung)– Granularität der Anwendung (Komplexität vs.

Wiederverwendbarkeit)

„Software-Komponenten sind ausführbare Software-Einheiten, die unabhängig hergestellt, erworben und konfiguriert werden und aus denen sich funktionierende Gesamtsysteme zusammensetzen lassen.“ – Szyperski [SZY02]


Komponentenframeworks

• Java (Sun u.a.):- Java Applets- Enterprise Java Beans (EJB)

• CORBA (Common Object Request Broker Architecture):- CORBA Components- Standard der Object Management Group (OMG)

• .NET / COM+ (Component Object Model):- Objektorientiert, COM+ relativ proprietär, .NET offener- Entwicklung von Microsoft

• OSGi (Open Service Gateway Initiative):- 1999 gegründetes Non-Profit-Konsortium- dynamische Verwaltung von Komponenten zur Laufzeit- Java-basiert, plattformunabhängig- Eclipse nutzt OSGi als Plugin-Konzept


Java Applets: Grundprinzip

HTML -Seite

Applet

Laden vonApplets

JAVA -Interpreter

WWW Client(Browser)

WWW Server

Zugriff (HTTP)

Alternative: Java Web Start: Ebenfalls dynamisches Laden von Java-Code zum Client, dort aber permanentes Caching mit Verknüpfung mit Arbeitsplatz-Oberfläche und automatischem Update -> verbesserte Performance


Enterprise Java Beans (EJB)

• Java Bean: Komponente mit– Öffentlichen Methoden, Attributen (getProperty/setProperty)– Events: Ereignis- und EventListener-Klassen– BeanInfo: Introspection (Informationen über Bean abfragen)

• Enterprise Java Beans: Serverkomponenten, nichtvisuell– Ausführung in EJB-Container (Laufzeitumgebung)– Session Beans: nicht persistent, Steuerung der Dialoge mit

Business-Objekten, Schnittstelle zum Client, Varianten: Stateless / Stateful

– Entity Beans: persistent, Business-Objekte mit Schnittstelle zur Datenebene, Primärschlüssel-Mapping auf Datenbank

– Message Driven Beans: ermöglichen asynchrone Kommunikation über Java Messaging Service

Client Session Bean(z.B. Überweisung)

Entity Bean(z.B. Konto)

EJB-Container


EJB für SOA

+ Interface-Beschreibung in Java+ Stateless Session Beans können über Web Service-Schnittstelle

aufgerufen werden+ Enterprise Beans können als Client auf WS zugreifen+ Komposition / Wiederverwendbarkeit+ Lose Kopplung (dependency injection)+ Plattformunabhängig

− Sprachabhängig (Java) (mit WS-Schnittstelle auch Interoperabilität möglich)

− Kein zentrales Repository− EJB-Container sehr „schwergewichtig“


(Distributed) Component Object Model (COM)

• Ermöglicht den Export von Klassen (COM-Objekte) aus Dynamic Link Libraries (DLLs), basiert auf Client-Server-Prinzip

• COM-Objekte werden mittels COM-Interface beschrieben– IDL kann zur Beschreibung verwendet werden

• Nutzung von COM-Objekten über COM-Server:– In-Process-Server: DLL wird direkt in Client-Prozess geladen– Local Server: Programm, das ein Objekt über RPC anbietet– Remote Server: wenn Netzwerk zwischen Client und Server

liegt, DCOM (Distributed COM)• sprachunabhängig (Binärformat), aber plattformabhängig • Versionsunabhängig, ortsunabhängig• COM+: Dienste für Transaktionen, Synchronisation usw.


DCOM für SOA

+ Protokoll, um Programmkomponenten über Netzwerk kommunizieren zu lassen

+ Beschreibung des COM-Interface mit IDL möglich+ In Windows-Welt sehr populär (ActiveX)+ sprachunabhängig (Binärformat), aber plattformabhängig − Portierungen auf Unix/Mainframes durch Software AG (EntireX)

− Teilweise deutliche Einschränkungen, Lizenz teuer!− Kein offener Standard Änderungen jederzeit möglich− Sicherheitsprobleme

Windows Unix


Microsoft .NET

• Erweiterung des DCOM Konzeptes

• wichtigste Elemente:– Common Language Runtime (CLR): sprachunabhängige

Laufzeitumgebung (virtuelle Maschine), bietet u.a. Typprüfung und Garbage Collection

– Assemblies: selbstbeschreibende Komponenten, enthalten Schnittstellen als Metadaten, Programmcode und Ressourcen, Versionierung, Signierung möglich

– Umfangreiche Klassenbibliothek (Base Class Library BCL), in Namensräume gegliedert (z.B. System.Collections)

– Unterstützt Web-Service-Technologien

• Basiert auf ECMA-Standard 335


.NET für SOA

+ Visibility: Schnittstelle der Assemblies als Metadaten+ .NET Enterprise Services und .NET Remoting Services+ sprachunabhängige Laufzeitumgebung (CLR)+ Standardisiert+ Unterstützt Web-Service-Technologien:

+ Erzeugung von Schnittstellenbeschreibung in WSDL+ Stub-Generierung aus WSDL

− Bisher aber plattformabhängig


OSGi (Open Service Gateway Initiative)

• komponentenbasierte Framework-Architektur– 1999 gegründetes Non-Profit-Konsortium

• BMW, Telekom, Ericsson, IBM, Intel, Oracle, Sun, Siemens, …– verschiedene „Expert Groups“ erstellen Spezifikationen

• Heimvernetzung, Automobile, Fabrikautomation, mobile Geräte• Eigenschaften:

– Kommunikationsstandard für Vernetzung von Endgeräten• Fernsteuerung, Diagnose und Wartung

– Verwaltung von Diensten auf Komponentenbasis– Bundles sind wiederverwendbar, plattformunabhängig– integrieren und verändern von Komponenten zur Laufzeit– Plattform bietet Basisdienste an

Log-/Config.-/User-Management, Device Access, Web-Server– mehrere Komponenten in VM, geringer Ressourcenbedarf– Java basiert


• Bundles (Komponenten)– dynamisches Bereitstellen und Nutzen von Services– in standardisierten .jar-Dateien verpackt

• enthält Manifest-Datei für Metadaten

• OSGi-Framework– Layer 3: Service Registry (Steuerung

der Interaktion)– Layer 2: Life Cycle (dynamische

Verwaltung von Bundles)– Layer 1: Modules (Klassen, Ressourcen

des Frameworks)– Layer 0: Execution Environment

(Laufzeitumgebung)

– verwendet Java 2 Security Model

OSGi Framework - Kernelemente


OSGi für SOA

+ Bundles bieten Services an+ Beschreibung der Interfaces in Java+ Schnittstelle zu anderen Sprachen über JNI+ Registry zum Suchen und Nutzen der Services durch andere

Bundles+ Core Services als Bundles in Plattform integrierbar+ Hohe Dynamik: Services und Bundles können zur Laufzeit

integriert, verändert oder entfernt werden

− Bundles laufen innerhalb eines Containers – keine Kommunikation mit entfernten Services

− SOA-Umsetzung für lokale Maschinen (Fokus auf Embedded Systems)

− Java-basiert - programmiersprachenabhängig


Web Services: Begriffsdefinition

• World Wide Web Consortium (W3C):„A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web servicesupports direct interactions with other software agents usingthe XML-based messages exchanged via Internet-basedprotocols.”

• IBM:„Web Services are self-contained, modular applications thatcan be described, published, located and invoked over a network, generally, the World Wide Web.”

• Cerami:„A Web Service is any piece of software that makes itselfavailable over the Internet and uses a standardized XML messaging system.”


Web Services: Architektur

Dienstnutzer Dienstanbieter

Verzeichnis

UDDI

WSDL

: Dienstschnittstellenbeschreibung

publizierenfinden

SOAP

interagieren


Web Services: Basic Protocol Stack

UDDI (Universal Description, Discovery and Integration)Discovery

MessagingSOAP (Simple Object Access Protocol*)XML-RPC (XML Remote Procedure Call)

WSDL (Web Services Description Language)Description

HTTP (Hyper Text Transfer Protocol)SMTP (Simple Mail Transfer Protocol)FTP (File Transfer Protocol)JMS (Java Message Service)

Transport

Secu

rity

Managem

ent

*: ursprüngliche Abkürzung, die nicht mehr verwendet wird


SOAP

• W3C-Standard, aktuelle Version: 1.2• Setzt auf vorhandenen Protokollen

auf: HTTP, HTTPs, SMTP, ...

• SOAP-Envelope: besteht aus– Header: optional, enthält Meta-

Informationen wie Transaktions-und Verschlüsselungsattribute

– Body: enthält „Nutzdaten“ und Bereich für Fehlermeldungen (fault messages)

soapenv:envelope

soapenv:header

Header 1

Header 2

soapenv:body

Body(message payload)


SOAP

• Teilnehmer eines SOAP-Austauschs:– Sender– Intermediary (Vermittler)– Receiver (Empfänger)

• Vermittler erscheint je nach Sicht als Empfänger oder als Sender

• Wenn A‡B: Active Intermediary– Vermittler verändert Header der

SOAP-Nachricht

Sender

Intermediary

Receiver

Als Empfänger

Als Sender

Nachricht A

Nachricht B


WSDL

• Web Services Description Language: allgemeingültige, programmiersprachenunabhängige Schnittstellenbeschreibung

• W3C-Standard, aktuelle Version: Version 2.0, aber von den meisten Engines/Tools noch nicht unterstützt (WSDL 1.1)

• 6 Hauptelemente (WSDL 1.1):– Types: alle Datentypen, die zwischen Client und Server

ausgetauscht werden– Messages: abstrakte Beschreibung der Nachrichten– Port Types: Menge von abstrakten Operationen– Binding: legt konkretes Protokoll und Datenformate für

Operationen und Nachrichten eines Port Types fest– Port: Adresse für ein Binding (Kommunikations-Endpunkt)– Service: Menge von Ports


OperationOperation

Operation

MessageMessage

Message

WSDL

Operation

Port Type

Abstraktes InterfaceOperationOperation

MessageMessage

Message

Binding

Konkrete Implementierung

realisiert durch

Port

adressiert durch


UDDI

• Universal Description, Discovery and Integration• OASIS-Standard, aktuell Version 3.0• Ziel: Standardisierte Methode zum

Veröffentlichen und Auffinden von Web Services• 3 Hauptkategorien:

– White Pages: Namensregister, Kontakt zum Anbieter, mehrsprachige Unternehmenvor-stellung, Klassifizierungscode (z.B. „Bank“)

– Yellow Pages: „Branchenbuch“, Einordnung der Web Services in standardisierte Geschäftskategorien (z.B. UNSPSC)

– Green Pages: technische Informationen zu den angebotenen Web Services (tModel), Geschäftsmodell und -prozesse

UNSPSC: United Nations Standard Products and Services Code

UDDI

White Pages(Business)

Yellow Pages(Services)

Green Pages(technische

Spezifikation)


UDDI

• Mögliche Anfragen an UDDI-Registry (via SOAP-Nachrichten)– Authentifikation (bei Nutzeranmeldung)– Suchen (Nachrichten zum Auffinden von Diensten, SOAP-

Body beginnt mit find)

– Detailinformationen abfragen (von Entities)– Hinzufügen und Ändern (gleich aufgebaut, automatische

Erkennung durch die Registry ob Änderung oder Erstellung)– Löschen (erfordert wie Hinzufügen/Ändern Authentifikation)

• Unabhängiges Konsortium verwaltet frei zugängliche UDDI-Register, automatischer Abgleich der öffentlichen Informationen

+ Globales „öffentliches“ Register UBR (UDDI Business Registry)− Hat aber in den letzten Jahren an Bedeutung verloren


Zusammenfassung Web Services

Web ServiceProvider

Web ServiceClient

SOAP

HTTP

Client Anwendung

Anwendungsdaten

XML XML

Server Anwendung

UDDI-Registry

findWSDL

publishWSDL

bin

d

Anwendungsdaten


Web Services für SOA

+ Ansatz von XML-RPC: Kopplung heterogener Softwaresysteme+ XML-Technologien (allgemein verfügbare Standards) für

Schnittstellenbeschreibung und Nachrichtenaustausch+ Möglichst einfache, leicht umsetzbare Protokolle+ Interoperabilität von Plattformen und Programmiersprachen+ Idee weltweiter Verzeichnisdienste und Service Marketplaces

Vision „Internet der Dienste“: Sammlung von Diensten, die von Menschen, Maschinen und Anwendungen effizient genutzt werden können

− XML-Overhead

XML Dienstbeschreibung

Dienstnutzer Dienstanbieter

XML

XMLInternetprotokolle

z.B. HTTP

REST-basierte Web Services

REST: Representational State TransferArchitekturstil, beschrieben in der Dissertation von Roy T. Fielding [Fie00]Client verändert seinen Anwendungszustand, indem er Repräsentationen von Resourcen von einem Server bezieht

Grundlegende Konzepte:Eindeutige Identifikation von Ressourcen (z.B. über URIs)Repräsentationen von Ressourcen (z.B. in XHTML)Selbstbeschreibende Nachrichten (z.B. mittels HTTP)Hypermedia zur Veränderung des Anwendungszustands

http://holtin.com/hotels

Resource Identifier

Hotel-Liste

Resource Representation

XML

HTML


Buchung Dresden

RESTful Web Services: Hypermedia

Client Server

GET http://holtin.com/hotelsAccept: text/html

Hotel-Liste XML

HTMLHoltin HotelsHoltin DresdenHoltin Hamburg

GET …/hotels/dresdenHotel

DresdenXML

HTMLHoltin Hotel DresdenDirekt am Elbufer ab 99€!AdresseBuchung

Buchung Dresden HTML


GET …/hotels/dresden/buchung

REST: Uniform Interface

Bedingung: alle Komponenten nutzen einheitliche Schnittstelle, d.h. begrenzte Anzahl an Methoden (CRUD)

Beispiel SOAP Web Service

http://holtin.com/HotelService

• getHotelList• checkRoomAvailability• bookHotelRoom• cancelBooking• obtainInvoice

REST Web Service

Hotel-Liste

Liste Buchungen

Hotel

Details

Buchung

Rechnung

GETPUT

POSTDELETE

Z.B. cancelBooking = DELETE Buchung


Das REST-Missverständnis

Häufig: „REST ist XML über HTTP“ (HTTP+POX: „HTTP and plainold XML“)• Query-Parameter kaschieren spezielle Methodenaufrufe, oft

gibt es nur eine Ressource die die gesamte Funktionalität bereitstellt

Kein REST im eigentlichen Sinn!Besser: Ressourcen-orientierte Architektur (ROA) [RR07]

GET …/rest?action=cancelbooking&bid=1Accept: application/xml…

<?xml version=“1.0“?><booking id=“1“><state>cancelled</state>

</booking>


RESTful Services für SOA

+ Interaction: Client-Server, Nachrichtenaustausch über standardisierte Protokolle (HTTP)

+ lose Kopplung, Zustandslosigkeit+ Uniform Interface (Einheitliche Schnittstelle)+ Plattformunabhängig, Transparenz der Implementierung

− Visibility: Dienstbeschreibung: − WSDL ungeeignet (beschreibt hauptsächlich Operationen)+ mögliche Alternative WADL (noch) wenig verbreitet

− Geringe Werkzeugunterstützung (verglichen mit SOAP WS)− Browser machen optimale Umsetzung schwierig (z.B. fehlende

PUT-/DELETE-Unterstützung bei Formularen) − Kaum zusätzliche Unterstützung für geschäftskritische

Anwendungen (Sicherheit, Zuverlässigkeit, Zusammenarbeit mehrerer Partner etc.)



Bewertung der Technologien zur Umsetzung von SOA

XML-RPC

Java RMI

DCOM .NET CORBA OSGi Web Serv.

REST Serv.

Kapselung der Funktionalität + + + + + + + +

wohldefinierte Schnittstelle + + + + + + + +

Transparenz der zugrundeliegenden Implementierung

+ + + + + +

Lose Kopplung + + + + + + + +

Standardisierung + (+) + +

Interoperabilität + (+) (+) (+) + (+) + +

Industrieunter-stützung + + + ++ (+)


Standardisierungsgremien

W3C OASIS WS-I

Gründung 1994 1993 (SGML Open), 1998

2002

Mitglieder (ca.) 400 600 200

Gesamtziel (in Bezug auf SOA)

Entwicklung des Web, fundamentale Standards für Online-Business und Informations-austausch

Onlinehandel fördern durch spezialisierte Web Services Standards

Standardisierte Interoperabilität

Wichtige Ergebnisse (in Bezug auf SOA)

XML, XML-Schema, XQuery, XPath, XSLT, WSDL, SOAP, XML Encryption, XML Signature, Web Services Architektur

UDDI, SAML, ebXML, WS-Security, WS-BPEL, XACML

Basic Profile, Basic Security Profile

Documents

Vorlesung „SOA – Entwicklung verteilter Systeme auf … · Object Request Broker, zentrale CORBA-Komponente, ermöglicht transparente Kommunikation über GIOP / IIOP ... (EntireX)