ƒ Web Services

Resümee (4)

ƒ RPC-Fehlersemantikklassen

ƒ maybe, at-least-once, at-most-once

ƒ Weiteres zu RPCs

ƒ asynchroner RPC, call-back, context-handle, broadcast

ƒ Sicherheitsstufen (Authentifizierung, Verschlüsselung, Signatur)

ƒ Lookup-Service

ƒ Web Services

ƒ WSDL-Servicebeschreibung (als XML-Dokument)

ƒ SOAP-Serviceaufruf

ƒ Ressourcen-orientierte Architektur

ƒ Ressource

ƒ Repräsentation einer Ressource

ƒ REST: RepresentationalState Transfer

Middleware-Entwicklung, die

Web Services historisch voranging

1. RPC-Bibliotheken (z.B. von SUN für UNIX)

ƒ Unterstützung des Client-Server-Paradigmas

ƒ einfache Schnittstellenbeschreibungssprache, Stubgeneratoren

ƒ Sicherheitskonzepte: Authentifizierung, Autorisierung, Verschlüsselung

2. Client-Server-Verteilungsplattformen (z.B. DCE)

ƒ Verzeichnisdienst, globaler Namensraum, globales Dateisystem

ƒ Programmierhilfen: u a Synchronisation Multithreading

ƒ Programmierhilfen: u.a. Synchronisation, Multithreading

3. Objektbasierte Verteilungsplattformen (z.B. CORBA)

ƒ Kooperation zwischen verteilten Objekten

ƒ objektorientierte Schnittstellenbeschreibungssprache

ƒ „Object Request Broker“ als Vermittlungsinstanz

CORBA (Version 2.0 ca. ab 1997)

ƒ Common Object Request Broker Architecture

ƒ ORB(Object Request Broker) als Vermittlungsinfrastruktur (Weiterleitung von Methodenaufrufen etc.)

ƒ IDL(Interface Description Language) mit Stub-Generatoren

ƒ Systemfunktionen und Basisdienste in Form von Object Services Methodenaufruf unterschiedlicher Semantik:

synchron(mit Rückgabewerten; analog zu RPC) verzögert synchron (Aufrufer wartet nicht auf das Ergebnis, sondern holt es sich später ab) one way(asynchron: Aufrufer wartet nicht;

keine Ergebnisrückgabe)

CORBA

ƒ Ab ca. 2000 entstand der Wunsch nach einer wesentli- chen Erweiterung der CORBA-Funktionalität aufgrund

ƒ neuer Anforderungen durch E-Commerce-Anwendungen

ƒ Ausbreitung des WWW

ƒ Aufkommen von Java

ƒ Aufkommen mobiler Geräte

ƒ Allerdings geriet die CORBA-Weiterentwicklung ins Stocken

ƒ zu weitreichende AnforderungenÆkomplex / ineffizient

Man lese dazu auch: Michi Henning:

The rise and fall of CORBA. Commun.

ACM, Vol. 51, No. 8 (Aug. 2008), 52-57

zu weitreichende Anforderungen Ækomplex / ineffizient

ƒ kommerzielle Implementierungen der Erweiterungen zögerlich

ƒ fehlende Unterstützung durch Microsoft (eigene Architektur: DCOM und .NET)

ƒ man versuchte, es jedem Recht zu machen (widersprüchliche Interessen, barocke Konstrukte durch Kompromisse)

ƒ aufkommende Konkurrenzsysteme (z.B. Web Services), die z.T.

direkter und besser an die neuen Anforderungen angepasst waren

-invariante Dienste

ƒ Verändern Aufträge den Zustand des Servers?

ƒ typische zustandsinvariante Dienste: Auskunftsdienste (z.B. Namensdienst oder Zeitservice)

ƒ typische zustandsändernde Dienste: Datei-Server

ƒ Idempotente Dienste / Aufträge

ƒ Wiederholung eines Auftrags führt zum gleichen Effekt

ƒ Beispiel: „Schreibe in Position 317 von Datei XYZ den Wert W“

(ist aber nicht zustandsinvariant!) (ist aber nicht zustandsinvariant!)

ƒ Gegenbeispiel: „Schreibe ans Ende der Datei XYZ den Wert W“

ƒ Gegenbeispiel: „Wie spät ist es?“ (ist aber zustandsinvariant!)

ƒ Bei Idempotenz oder Zustandsinvarianz kann bei fehler- haftem Auftrag (timeout beim Client) dieser problemlos erneut abgesetzt werden (→ einfache Fehlertoleranz)

Zustandslose („stateless“) /

zustandsbehaftete („statefull“) Server

ƒ Hält der Server Zustandsinformation über Aufträge hinweg?

B (P t k ll) t d d Cli t

ƒ z.B. (Protokoll)zustand des Clients

ƒ z.B. Information über frühere damit zusammenhängende Aufträge

ƒ Beispiel: Datei-Server

open(“XYZ”);

read;

read;

close;

ƒ Bei zustandslosenServern entfällt open/close; jeder Auftrag muss

In klassischen Systemen hält sich das Betriebs- system Zustandsinformation, z.B. über die Position des Dateizeigers geöffneter Dateien

vollständig beschriebensein (Position des Dateizeigers etc.)

ƒ zustandsbehaftete Server daher i.Allg. effizienter

ƒ Dateisperren bei echten zustandslosen Servern nicht einfach möglich

ƒ Zustandsbehaftete Server können wiederholte Aufträge er- kennen (z.B. Speichern von Sequenznummern) ÆIdempotenz

Sind Web Server zustandslos?

ƒ Beim HTTP-Zugriffsprotokoll wird über den Auftrag g p g hinweg keine Zustandsinformation gehalten

ƒ - jeder link, den man anklickt, löst eine neue „Transaktion“ aus

ƒ Stellt z.B. ein Problem E-Commerce-Anwendungen dar

ƒ oft gewünscht: Transaktionen über mehrere Klicks hinweg und

ƒ Wiedererkennen von Kunden (beim nächsten Klick oder Tage später)

ƒ erforderlich z.B. für Realisierung von „Warenkörben“ von Kunden

Wiedererkennung von Kunden?

ƒ „URL rewriting“ und dynamische Web-Seiten

ƒ der Einstiegsseite eine eindeutige Identität anheften, wenn der Kunde diese erstmalig aufruft

ƒ diese Identität jedem link der Seite anheften und mit zurückübertragen

ƒ „Cookie“ als Context-Handle

ƒ kleine Textdatei, die ein Server einem Browser (= Client) schickt und die im Browser gespeichert wird

und die im Browser gespeichert wird

ƒ der Server kann das Cookie später wieder lesen und damit den Kunden wiedererkennen

ƒ Evtl. auch Wiedererkennung über IP-Adresse

ƒ aber oft Probleme bei dynamischen IP-Adressen, Proxies etc.

Gleichzeitige Server-Aufträge

ƒ Problem: Oft viele „gleichzeitige“ Aufträge

Iterativer Server („single threaded“):

ƒ Iterative Server bearbeiten nur einen einzigen Auftrag pro Zeit

ƒ eintreffende Anfragen während der Auftragsbearbeitung: abweisen, puffern oder schlichtweg ignorieren

ƒ einfach zu realisieren

ƒ bei trivialen Diensten mit kurzer Bearbeitungszeit sinnvoll

Konkurrente („nebenläufige“) Server

ƒ (Quasi)gleichzeitige Bearbeitung (Q )g g g mehrerer Aufträge g

ƒ sinnvoll (d.h. effizienter für Clients) bei längeren Aufträgen

Verschiedene Realisierungen

ƒ mehrere Prozessoren bzw.

Multicore-Prozessoren

ƒ Verbund verschiedener Server-Maschinen (Cluster)

ƒ dynamische Prozesse oder

ƒ dynamische Prozesse oder feste Anzahl vorgegründeter

ƒ Beachte: Auch bei Monoprozessor-Systemen ist Timesharing sinnvoll: Nutzung erzwungener Wartezeiten bei einer Auftrags- bearbeitung für andere Jobs; kürzere mittlere Antwortzeiten bei

dynamischen Handler-Prozessen

Für jeden Auftrag gründet derMaster

ƒ Neu gegründeter Slave („handler“) übernimmt den Auftrag

ƒ Client kommuniziert dann direkt mit dem Slave

Für jeden Auftrag gründet der Master einen neuen Slave-Prozessund wartet dann auf einen neuen Auftrag

Alternative: „Process preallocation“: Feste Anzahl statischer Slave-Prozesse (evtl. effi- zienter, da Wegfall der Erzeugungskosten)

ƒ Client kommuniziert dann direkt mit dem Slave

ƒ Slaves sind typischerweise Leichtgewichtsprozesse („threads“)

ƒ Slavesterminiereni.Allg. nach Beendigung des Auftrags

ƒ Die Anzahl gleichzeitiger Slaves sollte begrenzt werden

Master/Slave

Subject: Identification of equipment sold to LA County Date: Tue, 18 Nov 2003 14:21:16 -0800

From: "Los Angeles County"

The County of Los Angeles actively promotes and is committed to ensure a work environment that is free from any discriminatory influence be it actual or perceived. As such, it is the County’s expectation that our manufacturers, suppliers and contractors make a concentrated effort to ensure that any equipment, supplies or services that are provided to County departments do not possess or portray an image that may be construed as offensive or defamatory in nature.

One such recent example included the manufacturer’s labeling of equipment where the words

"Master/Slave" appeared to identify the primary and secondary sources. Based on the cultural diversity and sensitivity of Los Angeles County, this is not an acceptable identification label.

We would request that each manufacturer, supplier and contractor review, identify and remove/change any identification or labeling of equipment or components thereof that could be interpreted as discriminatory or offensive in nature before such equipment is sold or otherwise provided to any County department.

Thank you in advance for your cooperation and assistance.

Joe Sandoval, Division Manager Purchasing and Contract Services Internal Services Department County of Los Angeles

Server-Konzept

ƒ Server: quasiparallele Bearbeitung von Aufträgen

ƒ Server bleibt ständig empfangsbereit

ƒ Client: Möglichkeit zum „asynchronen RPC“

ƒ Hauptkontrollfluss delegiert RPCs an nebenläufige Threads

ƒ keine Blockade durch Aufrufe im Hauptfluss

ƒ echte Parallelität von Client (Hauptkontrollfluss) und Server

Ressourcen-orientierte Architektur (ROA)

ƒ Funktionalität wird nicht durch Services („SOA“), ( ), sondern durch (Web) Ressourcen angeboten

ƒ Ressource? Referent eines Uniform Resource Identifiers

ƒ RFC 1630 „URL“ Implizit: „Etwas, das adressiert werden kann“

(1994)

ƒ RFC 2396 „URI“

(1998)

A resource can beanything that has identity. Familiar examples include anelectronic document, an image, a service(e g "today's weather report for Los Angeles")

ƒ RFC 3986 „URI“

(2005)

service(e.g., today s weather report for Los Angeles ), and a collection of other resources.Not all resources are network "retrievable"; e.g., human beings, corpo- rations, and bound books in a library can also be con- sidered resources…

…Likewise,abstract conceptscan be resources, such as the operators and operands of a mathematical equa-

Statische Websites

Web Dienste

RSS Feeds

Foren Physische Dinge

(Web) Ressourcen

Repräsentation – Beispiel „Buch“

ƒ Das Buch als abstraktes Konzept p

ƒ es gibt verschiedene Ausgaben, Exemplare etc.

ƒ identifiziert per ISBN: URN:ISBN:978-3540002130

ƒ Was wir ausleihen / kaufen, ist eine Repräsentation des Buches

ƒ z.B. Hardcover, PDF, E-Book,…

h i Bild d C k i R ä t ti i

ƒ auch ein Bild des Covers kann eine Repräsentation sein

ƒ oder ein maschinenlesbares XML-Dokument für das Bibliothekssystem

REST

ƒ REST (als idealisierte Architektur des Web) steht für ( )

ƒ Representational: Nicht Ressourcen, sondern deren Repräsentationenwerden übertragen

ƒ State Transfer: Die Übertragung löst Zustandsübergänge aus und verändert damit die Ressourcen

ƒ REST: Entwicklung

ƒ Zurückführen des Erfolgs des WWW(z.B. bzgl. Skalierbarkeit) auf

h f d d k ll d h

Eigenschaften der verwendeten Protokolle und Mechanismen:

Abstraktion von HTTP und Formulierung einer idealisierten Architektur: REST

ƒ Mit REST wird versucht, die Möglichkeiten, die das Web(bzw.

HTTP) bietet, optimal auszunutzen (Caching; HTTP-Verben wie PUT und DELETE, die Web-Browser nicht kennen,…)

Eigenschaften von REST

ƒ Zustandslosigkeit

ƒ entschärft Crash-Problematik und Orphans

ƒ erlaubt Caching und bessere Skalierbarkeit

ƒ Einheitliche, a-priori bekannte, Schnittstelle für alle Ressourcen

ƒ einheitliche Aufrufe, z.B. GET, POST bei HTTP

ƒ Adressierungdirekt durch URIs

auch andere Protokolle möglich!

ƒ selbstbeschreibende Nachrichten: alle benötigten Metadaten sind enthalten, z.B. im HTTP-Header

ƒ bekannte Repräsentationen, z.B. MIME-Typen

ƒ Bevorzugte Repräsentation wählbar

Komponenten mit Java-IDE

ƒ JAX-RS: Java API for RESTful Web Services

Erweiterung von einfachen Java- Objekten zu Ressourcen per Java Annotations

@Path: Pfadzur Ressource Definition der verwendeten Media Types (@Consumes und @Produces)

Extraktion vonParametern Extraktion von Parametern aus dem Request mittels:

@PathParam: z.B. {cartID}

@QueryParam: z.B

?bookID=123

REST-Anwendungsmodell

ƒ „Hypermedia as the Engine of Application State“ yp g pp

ƒ Client kennt ausschliesslich die Basis-URI des Dienstes

ƒ Server leitet durch die Anwendungszustände

durch Bekanntgabe von Wahlmöglichkeiten (hyperlinks)

request/reply HTTP

ƒ Der Anwendungszustandkann beim Clientoder beim Server liegen, oder auch über beide verteiltsein

ƒ HTTP-Kommunikationsprotokoll selbst bleibt aber zustandslos request/ reply

REST: Zustandsspeicherung

ƒ Wenn der Server keinen Zustand hält, dann muss der , Client alleine durch den Zustandsraum navigieren

ƒ Beispiel: man klickt sich durch eine Hypertext-Struktur(und merkt sich die früher besuchten Dokumente bzw. Zustände)

ƒ Aktueller Zustand = derzeitiges Hypertextdokument beim Client

ƒ Client und Server sind völlig entkoppelt

ƒ Dem Server ist es egal (und nicht bewusst), welches Hypertext- Dokument (d.h. Zustand) der Client vorher hatte

Dokument (d.h. Zustand) der Client vorher hatte

ƒ Der Client übergibt jeweils eine vollständige URI, die den Folgezustand bezeichnet

ƒ Bookmarks machen Sinn (sind vollständige URI losgelöst von jeglichem Kontext)

ƒ Back button im Browser macht Sinn: er führt zu einem früheren, im Client gecachten Zustand

REST: Zustandsspeicherung

ƒ Bei komplexeren Anwendungen residiert typischerweise der p g yp Anwendungszustand beim Server

ƒ z.B. Flugbuchung, wo der Server mit externen Diensten kommuniziert

ƒ e-shop, wo der Warenkorb beim Server geführt wird

ƒ Dann funktioniert eine Kopie einer URI (bookmark) später meistens nicht, weil dem Server der Kontext dazu fehlt

ƒ auch back buttonim Browser ist problematisch: führt zu einer früheren Zustandskopie, ohne dass der Server dies mitbekommt – Client meint fälschlicherweise, in einem gewissen Zustand zu sein, der tatsächliche Zustand wird aber auf dem Server gehalten

Zustandsspeicherung beim Server

Server

http://example.org/carts/xyz

Client

GET /carts/xyz Basis-URI

Zustand auf dem Server

Zustandsspeicherung beim Server

Server

Books in your cart: None Recommended Books:

Client

200 OK Hypermedia

Zustand auf dem Server (leerer Warenkorb)

Recommended Books:

Book1, Book2, Book3

Wahlmöglichkeiten

Zustandsspeicherung beim Server

Server

Books in your cart: None Recommended Books:

Client

GET /books/Book1

Recommended Books:

Book1, Book2, Book3

Zustandsspeicherung beim Server

Server Information on «Book1»

Client

200 OK

Add book to cart Back

Wahlmöglichkeiten

Zustandsspeicherung beim Server

Server Information on «Book1»

Client

POST /carts/xyz add=Book1

Add book to cart Back

Neuer Zustand

Zustandsspeicherung beim Server

Server

Books in your cart: Book1 Recommended Books:

Client

201 Created

Neuer Zustand (Book1 im Warenkob)

Recommended Books:

Book1, Book2, Book3

Zustand wird auf dem Server gemerkt, indem die Ressource/carts/xyz/Book1 angelegt wird

ƒ Infrastructure (“middleware”) for dynamic,

Jini

cooperative, spontaneously networked systems

ƒ facilitates implementation of distributed applications

ƒ Infrastructure (“middleware”) for dynamic,

Jini

cooperative, spontaneously networked systems

ƒ facilitates implementation of distributed applications

−framework of APIs with useful functions / services

h l i (di l k )

−helper services (discovery, lookup,...)

−suite of standard protocols and conventions

ƒ Infrastructure (“middleware”) for dynamic,

Jini

cooperative, spontaneously networked systems

ƒ facilitates implementation of distributed applications

− services, devices, … find each other automatically (“plug and play”)

− dynamically added / removed components

− changing communication relationships

− mobility

Jini

ƒ Infrastructure (“middleware”) for dynamic, cooperative, spontaneously networked systems

ƒ facilitates implementation of distributed applications

ƒ Based on Java

ƒ uses RMI (Remote Method Invocation)

ƒ code shipping

ƒ requires JVM / bytecode everywhere

ƒ Service-oriented

ƒ (almost) everything is considered a service

ƒ service access through mobile proxy objects

ƒ requires JVM / bytecode everywhere

ƒ (Almost) everything relevant is a service

Service Paradigm

( ) y g

ƒ Jini’s run-time infrastructure offers mechanisms for adding, removing, finding, and using services

ƒ Services are defined by interfaces and provide their functionality via their interfaces

ƒ services are characterized by their typeand their attributes ( “600 d i” “ i 21 1”)

(e.g. “600 dpi”, “version 21.1”)

ƒ Services (and service users) may “spontaneously” form

a so-called “federation”

Jini: Global Architecture

ƒ Lookup Service (LUS)

i i t tit d b k

Lookup

ƒ main registry entity and brokerage service for services and clients

ƒ maintains information about available services

ƒ Services

ƒ specified by Java interfaces

ƒ registertogether with proxy objects d tt ib t t th LUS

Lookup Service Client Client

Client Service Service Service

1) register 2) find

3) use and attributes at the LUS

ƒ Clients

ƒ know the Java interfaces of the services, but not their implementation

ƒ findservices via the LUS

ƒ useservices via proxy objects

3) use

Network Centric

ƒ Jini is based on the network paradigm

ƒ network = hardware and software infrastructure

ƒ View is “network to which devices are connected to”, not “devices that get networked”

ƒ network always exists, devices and services are transient

ƒ Jini supports dynamic networks and adaptive systems

ƒ adding and removing components or communication relations should only minimally affect other components

Spontaneous Networking

ƒ Objects in an open, distributed, dynamic world find each other and form a transitory community

ƒ cooperation, service usage, …

ƒ Typical scenario: client wakes up (device is switched on, plugged in, …) and asks for services in its vicinity

ƒ Finding each other and establishing a connection should be fast, easy, and automatic

Some Fallacies of Common

Distributed Computing Systems

ƒ The “classical” idealistic view…

ƒ the network is reliable

ƒ latency is zero

ƒ bandwidth is infinite

ƒ the network is secure

ƒ the topology is stable

ƒ there is a single administrator

ƒ there is a single administrator

ƒ …isn’t true in fact

ƒ Jini addresses some of these issues

Middleware Infrastructure

ƒ Jini consists of a number of APIs

ƒ Is an extension to the Java platform dealing with distributed computing

ƒ Is an abstraction layer

between the application

and the underlying infra-

structure (network, OS)

Operating system

Jini’s Use of Java

ƒ Jini Jini requires JVM requires JVM (as bytecode interpreter) (as bytecode interpreter)

ƒ homogeneity in a heterogeneous world

ƒ Devices that are not “Jini-enabled” have to be managed by a Jini-enabled software proxy

( h h )

run protocols for discovery and join; have a JVM

(somewhere in the net)

Jini Infrastructure

ƒ Lookup service (LUS)

ƒ as repository / naming service / trader

ƒ Protocols

ƒ discovery & join, lookup of services

ƒ based on TCP/UDP/IP

ƒ Proxy objects

ƒ Proxy objects

ƒ transferred from service to clients (via LUS)

ƒ represent the service locally at the client

Lookup

Lookup Service

Lookup service^-

F dJiniti

Client use Service

Federation

Example

Lookup service

Printer proxy

Printer proxy

Office application

Printer

proxy arbitrary protocol

Communication between application and printer via functional calls of the proxy

Lookup Service

ƒ Uses Java RMI for communication

ƒ objects („proxies“) can migrate over the network

ƒ Besides the name/address of a service:

ƒ set of attributes

ƒ e.g.: printer(color: true, dpi: 600, ...)

ƒ proxies, which may be complex classes

ƒ e.g. user interfaces

ƒ Further possibilities:

ƒ responsibility can be distributed to a number of (logically separated) lookup services

ƒ increase robustness by running redundant lookup services

Discovery: Finding a LUS

ƒ Goal: Find a lookup service Goal: Find a lookup service (without knowing (without knowing anything about the network) to

ƒ advertise (register) a service, or

ƒ find (look up) an existing service

ƒ Discovery protocol:

ƒ multicast to well-known address/port

ƒ lookup service replies with a serialized object (its proxy)

ƒ from then on communication with the LUS is via this proxy

Discovery

Where is the lookup

service?

??

Lookup Service That’s me!!!

Multicast Request

Lookup-Service

Proxy Proxy

Reply

Lookup Service

Lookup Service

Proxy Proxy Proxy Proxy

Multicast Discovery Protocol

ƒ Search for lookup services p

ƒ no information about the host network needed

ƒ Discovery request uses multicast UDP packets

ƒ multicast addressfor discovery (224.0.1.85)

ƒ default port numberof lookup services (4160)

ƒ recommended time-to-liveis 15

ƒ usually does not cross subnet boundaries

ƒ Discovery reply is establishment of a TCP connection

ƒ port for reply is included in multicast request packet

Join: Registering a Service

ƒ Assumption: Service provider already has a proxy of the lookup service (Æ discovery)

ƒ It uses this proxy to register its service

ƒ Gives to the lookup service

ƒ its service proxy

ƒ attributesthat further describe the service

ƒ Service provider can now be found and used in this p

Jini federation

Join

Lookup Service

Lookup Service Lookup Service

Proxy Proxy

Entry 1 Entry 2

...

proxy

Entry1Entry2

...

Service

...

Service database in LUS Service

proxy

Join: More Features

ƒ To join, a service supplies:

it

ƒ its proxy

ƒ its ServiceID(if previously assigned; “universally unique identifier”)

ƒ set of attributes

ƒ Service waits a random amount of time after start-up

ƒ prevents packet storms after restarting a network segment

ƒ Registration with a lookup service is bound to a lease

ƒ service has to renewits lease periodically

Lookup: Searching Services

ƒ Client creates query for lookup service

h b b f d/

ƒ matching by registration numberof service and/or service type and/or attributes possible

ƒ wildcardsare possible („null“)

ƒ Via its proxy at the client, the lookup service returns zero, one or more matches (i.e., server proxies)

ƒ Selection among several matches is done by client

ƒ Client uses the service by calling functions of the service proxy

ƒ Any “private” protocol between service proxy and service provider is possible

Lookup

...

Lookup Service

Entry1Entry2 Entry n Entry1Entry2

...

Service proxy proxy Lookup Service

Proxy

Proxy

?

? ?

Client

Entry1Entry2

...

Service

.

Service database in LUS Entry1Entry2

...

Service proxy proxy

?

proxy proxy

Proxies

ƒ Proxy object is stored in the LUS upon registration y j p g

ƒ serialized object

ƒ implements the service interfaces

ƒ Upon request, service proxy is sent to the client

ƒ client communicates with service implementation via its proxy:

client invokes local methods of the proxy object

ƒ proxy implementation hiddenfrom client

Smart Proxies

ƒ Parts of (or the whole) service functionality may be executed by the proxy at the client

ƒ example: when dealing with large volumes of data, it usually makes sense to preprocessparts of the data (e.g.: compressing video data before transfer)

ƒ Partition of service functionality depends on service implementer’s choice

ƒ client needs appropriateresources

ƒ client needs appropriate resources

Client Service

Proxy Communication

Leases

ƒ Leases are contracts Leases are contracts between two parties between two parties

ƒ Leases introduce a notion of time

ƒ resource usage is restricted to a certain time frame

ƒ Repeatedly express interest in some resource:

ƒ I’m still interested in X

ƒ renew lease periodically

ƒ lease renewal can be denied

ƒ I don’t need X anymore

ƒ cancel lease or let it expire

Distributed Events

ƒ Objects on one JVM can register interest Objects o o e J ca eg ste te est in certain ce ta events of another object on a different JVM

ƒ “Publisher/subscriber” model

Subscriber Event

source

1. Registration

2. Event occurs 3. Send notification

Distributed Events – Example

ƒ Example: printer is plugged in

ƒ printer registersitself with local lookup service

ƒ Maintenance application wants to update software

Lookup-Service Proxy, attributes

Maintenance application

Any protocol Proxy, attributes

Proxy, attributes

ƒ Search for printers is “outsourced” to the lookup service

Distributed Events – Example

p p

ƒ “sensor service” looks for certain services on behalf of the maintenance application

ƒ maintenance application registers for eventsshowing the arrival of certain types of printers

ƒ sensor observes the lookup service

ƒ notifies applicationas soon

Lookup-Service

Sensor service

ƒ notifies applicationas soon as matching printer arrives via distributed events

Maintenance

Tell me about the arrival of new printers of type x!

ƒ Example: printer arrives, registers with lookup service

Distributed Events – Example

ƒ printer performs discovery and join

ƒ sensor finds new printer in lookup service

ƒ checks if there is an event registrationfor this type of printer

Lookup-Service A new printer arrived.

I have to notify all interested objects!

Notification Sensor service

Proxy, attributes

this type of printer

ƒ notifiesall interested objects

ƒ maintenance applicationretrieves printer proxy and

updates software Maintenance application

Notification service

Proxy, attributes

Resümee (5)

ƒ Middleware: historischer Kurzüberblick

ƒ CORBA: Architektur (ORB, IDL), Schicksal der Weiterentwicklung

ƒ Konkurrente Server

ƒ z.B. dynamische / statische Handler-Prozesse („slaves“)

ƒ Zustandsändernde / -invariante Dienste und Server

ƒ Idempotente und wiederholbare Aufträge

ƒ Stateless / statefull Server State ess / state u Se e

ƒ Zustandshaltung bei Webservern

ƒ URL rewriting, cookies

ƒ Zustandshaltung bei REST

ƒ Zustand als Hypermedia-Dokument

ƒ Zustandsspeicherung beim Server vs. zustandsloser Server

Resümee (5b)

ƒ Jini

ƒ Dienstparadigma, Netzzentrierung

ƒ Lookup-Service

ƒ Discovery

ƒ Join

ƒ Proxies und smart Proxies

ƒ Leases

ƒ verteilte Ereignisse

Mehr zu allgemeinen

Kommunikationsprinzipien

Im Folgenden: o ge de

ƒ Port-Konzept

ƒ Kommunikationskanäle

ƒ Ereigniskanäle

ƒ Timeouts bei der Kommunikation

ƒ Broadcast / Multicast

Das Port-Konzept

ƒ Port = adressierbarer Kommunikationsendpunkt, der die p , interne Struktur eines Nachrichtenempfänger abkapselt

ƒ Ein Prozess kann mehrere (evtl. typisierte) Ports haben

ƒ Manchmal bilden Ports Stauräume(„message queues“) für Nachrichten

ƒ Manchmal können Ports dynamischgegründet oder auch geschlossen/ geöffnetwerden

ƒ Neben Eingangsports („In-Port“) sind manchmal auch Ausgangsports („Out-Port“) möglich

Kommunikationskanäle

ƒ Kanäle, z.B. eingerichtet mit Ports als Endpunkten , g p

ƒ dazu je einen In- und Out-Port miteinander verbinden

ƒ Alternativ: Kanäle benen- nenund etwas auf den Kanal sendenbzw. von ihm lesen

ƒ Evtl. Broadcast-Kanäle:

Nachricht geht an alle

ƒ Flexibilität durch Umkonfiguration der Verbindungsstruktur

ƒ eigentlicher Adressat wird den Prozessen verborgen(„virtualisiert“) Nachricht geht an alle angeschlossenen Empfänger

Software-Komponenten

ƒ Kooperierende autonome Software-Komponenten

ƒ nicht notwendigerweise geographisch verteilt

ƒ mit i.Allg. getrennten Lebenszyklen

ƒ anonym: kennen nicht die Identität der Anderen

ƒ Auslösen von„Ereignissen“ durch Sender

ƒ Reagieren aufEreignisse beim Empfänger

ƒ Ereigniskanal als „Softwarebus“

ƒ agiert als Zwischeninstanz und verknüpft die Komponenten

ƒ registriertInteressenten (vgl. LUS)

ƒ Dispatchingeingehender Ereignisse

ƒ evtl. Puffern, Filtern, Umlenken von Ereignissen

Ereigniskanäle (2)

ƒ Probleme

ƒ Ereignisse können „jederzeit“ ausgelöst werden, werden von Empfängern aber i.Allg. nicht jederzeit entgegengenommen (ÆPufferung?)

ƒ falls Komponenten nicht lokal, sondern geographisch verteilt sind Æ„übliche“ Probleme nachrichtenbasierter Kommunikation:

Verzögerungen, evtl. verlorene Ereignisse, falsche Reihenfolge,…

B i i l

ƒ Beispiele

ƒ Microsoft-Komponentenarchitektur (.NET etc.)

ƒ „Distributed Events“ bei JavaBeansund Jini (event generator bzw. remote event listener)

Nachrichtenempfang

ƒ Idee: Receive soll max. eine gewisse Zeit lang blockieren

ƒ z.B. über Rückgabewert abfragen, ob Kommunikation geklappt hat oder der Timeoutzugeschlagen hat

ƒ Timeout-Wert adäquat setzen (oft schwierig)

ƒ Im Timeout-Fall geeignete Recovery-

Massnahmen treffen oder Exception auslösen

ƒ Verwendung bei:

ƒ Verwendung bei:

ƒ Echtzeitprogrammierung

ƒ Aufheben von Blockaden im Fehlerfall

(z.B. bei abgestürztem Kommunikationspartner)

ƒ Timeout evtl. auch beim synchronen (!) Senden sinnvoll

Zeitüberwachter

Nachrichtenempfang (2)

ƒ Sprachliche Einbindung z.B. so: p g receive ... delay t

{...}

else {...}

end

Wird nach mindes- tens t Zeiteinheiten ausgeführt, wenn bis dahin noch keine Nachricht empfangen

ƒ Beachte: Es wird mindestens so lange auf Kommunika- tion gewartet – danach kann (wie immer!) noch beliebig viel Zeit bis zur Fortsetzung des Ablaufs verstreichen

ƒ Was könnte „delay 0“ bedeuten? Ist das sinnvoll?

p g

(Broadcast / Multicast)

ƒ Multicast entspricht Broadcast bezogen auf die Gruppe

ƒ verschiedene Gruppen können sich evtl. überlappen

ƒ jede Gruppe hat eine Multicastadresse Broadcast: Senden an die

Gesamtheit aller Teilnehmer Multicast: Senden an eine Untergruppe aller Teilnehmer

Anwendungen von

Gruppenkommunikation

ƒ Informieren

ƒ z.B. Newsdienste

ƒ Suchen

ƒ z.B. Finden von

Objekten und Diensten

Typische Anwendungs- klasse von Replikation:

Fehlertoleranz

ƒ „Logischer Unicast“

ƒ an replizierte Komponenten

idealisierte Semantik

1. Modellhaftes Vorbild: Spei- cherbasierte Kommunikation

ƒ augenblicklicher „Empfang“ in zentralistischen Systemen

ƒ vollständige Zuverlässigkeit (kein Nachrichtenverlust etc.)

2. Idealisierte Sicht: Nachrich- tenbasierte Kommunikation:

tenbasierte Kommunikation:

ƒ gleichzeitiger Empfang

ƒ vollständige Zuverlässigkeit

ƒ Beide Ansichten sind aber in vert. Sys. nicht realistisch

(2. kann in der Realität bzw. bei Vorhandensein einer globalen Zeit durch eine „Sperrfrist“ als Zeitpunkt in der Zukunft erreicht werden)

Gruppenkommunikation – tatsächliche Situation

ƒ Zugrundeliegendes Medium (Netz) oft nicht multicastfähig g g ( ) g

ƒ LANs höchstens innerhalb von Teilstrukturen; WLAN als Funknetz a priori anfällig für Übertragungsstörungen

ƒ multicastfähige Netze sind typischerweise nicht verlässlich (keine Empfangsgarantie)

ƒ Daher typischerweise „Simulation“ von Multicast durch ein Protokoll aus vielen Punkt-zu-Punkt-Einzelnachrichten ein Protokoll aus vielen Punkt-zu-Punkt-Einzelnachrichten

ƒ z.B. Multicast-Server, der die Information an alle Empfänger einzeln weiterverteilt

tatsächliche Situation (2)

ƒ Nachrichtenkommunikation ist nicht „ideal“

ƒ nicht-deterministische Zeitverzögerung

→Empfang zu unterschiedlichen Zeiten

ƒ keine garantierte Zuverlässigkeit der Nachrichtenübermittlung

ƒ Ziel von Broadcast- / Multicast-Protokollen

ƒ möglichst gute Approximation der Idealsituation

ƒ Hauptproblem bei der Realisierung von Broadcast:

1. Zuverlässigkeit

2. garantierte Empfangsreihenfolge Das soll dem Problem nicht- deterministischer Nachrich- tenverzögerungen begegnen

Typische Fehlerfälle bei der Gruppenkommunikation

ƒ Während des Protokolls: Verlust von Einzelnachrichten oder Ausfall des Senders

ƒ Nachrichten können aus unterschiedlichen Gründen verloren gehen (z.B. Netzüberlastung, Empfänger hört gerade nicht zu, Hilfsprozess in der Kommunikationsinfrastruktur abgestürzt,...)

ƒ Problem dann: Empfänger sind sich nicht einig, da manche, aber nicht alle, informiert werden

ƒ Uneinigkeit der Empfänger kann die Ursache für sehr ärgerliche Folgeproblemesein (da wäre es manchmal besser, gar kein Prozess hätte die Nachricht empfangen!)

ƒ partielle Abhilfe durch aufwändigere Protokolle und mehr Redundanz

„Best Effort“ Broadcast

ƒ Euphemistische Bezeichnung, da keine extra Anstrengung

ƒ typischerweise einfache Realisierung ohne Ack etc.

ƒ Keinerlei Garantien

ƒ unbestimmt, wie viele / welche Empfänger erreicht wurden

ƒ unbestimmte Empfangsreihenfolge

ƒ Allerdings effizient (im Erfolgsfall)

ƒ Geeignet für die Verbreitung unkritischer Informationen

ƒ Geeignet für die Verbreitung unkritischer Informationen

ƒ z.B. Informationen, die Einfluss auf die Effizienz haben, nicht aber die Korrektheit betreffen

ƒ Evtl. als Grundlage zur Realisierung höherer Protokolle

ƒ wenn Fehlerfall selten →aufwändiges Recovery auf höherer Ebene tolerierbar

„Reliable“ Broadcast

ƒ Ziel: Unter gewissen (welchen?) Fehlermodellen einen

„möglichst zuverlässigen“ Broadcast-Dienst realisieren

Timeout:

kein ACK ACK

ACK

ƒ 1. Idee: Quittung („positives Acknowledgement“: ACK) für jede Einzelnachricht

ƒ im Verlustfall z.B. einzeln nachliefern oder (bei broadcastfähigem Medium) einen zweiten Broadcast-Versuch (→Duplikaterkennung!)

ƒ viele ACKs→teuer (d.h., Prinzip skaliert schlecht)

tiven Acknowledements („NACK“)

ƒ Alle broadcasts werden vom Sender nummeriert

ƒ Empfänger erkennt evtl. Lücke bei nächstem Empfang

ƒ Bei fehlender Nachrichten wird ein NACK gesendet

ƒ Fehlende Nachricht wird nachgeliefert

ƒ Sender muss daher Kopien von Nachrichten aufbewahren

ƒ aber wie lange?

ƒ Broadcast einer Nullnachricht“ ist evtl sinnvoll

ƒ Broadcast einer „Nullnachricht ist evtl. sinnvoll

ƒ →schnelles Erkennen von Lücken

ƒ Kombination von ACK / NACK mag sinnvoll sein

ƒ Verfahren hilft gegen Verlust von Nachrichten, aber nicht gegen den Crash des Senders „mittendrin“

Ein weiterer Reliable- Broadcast-Algorithmus

ƒ Zweck:Jeder nicht gecrashte und

zumindest indirekt erreichbare Prozess Denkübungen:

Bidi kti l K ik ti

zumindest indirekt erreichbare Prozess soll die Broadcast-Nachricht erhalten

ƒ Voraussetzung:zusammenhängendes

„gut vermaschtes“ Punkt-zu-Punkt-Netz

Sender s:Realisierung von broadcast(N) –send(N, s, sequ_num)an alle Nachbarn

(inklusive an s selber);

– sequ num ++

Beachte: receive≠ deliver (unterscheide Anwendungs-

b d T t b )

ƒ Bidirektionale Kommunikations- kanäle notwendig?

ƒ Wie effizient ist das Verfahren (Anzahl der Einzelnachrichten)?

ƒ Wie fehlertolerant? (Wie viel darf kaputt sein / verloren gehen...?)

Denkübung: Wieso?

Ist das notwendig?

– sequ_num ++

Empfänger r:Realisierung des Nachrichtenempfangs –receive(N, s, sequ_num);

wennr noch kein deliver(N)für sequ_num ausgeführt hat, dann: wennr ≠ s dann send(N, s, sequ_num) an alle Nachbarn von r ; Nachricht an die Anwendungsebene ausliefern („deliver(N)“) ;

ebene und Transportebene) Ist das notwendig?

Empfangsreihenfolge

ƒ Wie ist die Empfangsreihenfolge von Gruppennachrichten?

ƒ problematisch wegen der i.Allg. ungleichen Übermittlungszeiten

ƒ Bsp.: Update einer replizierten Variablen mittels „function shipping“:

ƒ Es sind verschiedene Grade des Ordnungserhalts denkbar

ƒ z.B. keine (ungeordnet), FIFO, kausal geordnet, total geordnet

FIFO-Ordnung bei Multicast

ƒ Alle Broadcast-Nachrichten eines (d.h.: ein und des ( selben) Senders an eine Gruppe kommen bei allen Mitgliedern der Gruppe in FIFO-Reihenfolge an

ƒ Denkübung: wie dies in einem Protokoll garantieren?

Probleme mit FIFO-Broadcasts

Falsche Schlussfolge-g rungdes Beobachters:

„Aufgrund einer unbe- gründeten Pumpenakti- vität wurde ein Leck er- zeugt, wodurch schliess- lich der Druck absank.“

Annahme: Steuerelemente kommunizieren über FIFO-Broadcasts:

„Irgendwie“ kommt beim Beobachter die Reihenfolge durcheinander!

Man sieht also:

ƒ FIFO-Reihenfolge nicht immer ausreichend, um Semantik zu wahren

ƒ eine Nachricht verursachtoft das Senden einer anderen (ÆKausalität!)

Das „Broadcastproblem“

ist nicht neu

ist nicht neu

ƒ Natürlicher Broadcast bei Licht- und Schallwellen

„Wenn ein Zuschauer von der Ferne das Exercie- ren eines Bataillons verfolgt, so siehter überein- stimmende Bewegungen desselben plötzlich eintreten, eheer die Commandostimme oder das Hornsignal hört; aber aus seiner Kenntnis derCausalzusammenhängeweiss er dass die

ƒ wann handelt es sich dabei um FIFO-Broadcasts?

ƒ wie ist es mit dem Kausalitätserhalt?

der Causalzusammenhängeweiss er, dass die Bewegungen die Wirkung des gehörten Comman- dos sind, dieses also jenen objectivvorangehen muss, und er wird sich sofort der Täuschung be- wusst, die in der Umkehrung der Zeitfolge in seinen Perceptionenliegt.“

Christoph von Sigwart(1830-1904): Logik. Zweiter Band. Die Methodenlehre (1878)

Nachrichtenabhängigkeit

ƒ Definition: Nachricht Y hängt kausal von Nachricht X ab, wenn es im Raum-Zeit-Diagramm einen von links nach rechts verlaufenden Pfad gibt, der vom Sendeereignis von X zum Sendeereignis von Y führt.

ƒ Beachte: Dies lässt sich bei geeigneter Modellierung auch abstrakter fassen (→„logische Zeit“ später in der Vorlesung und auch Vorlesung

„Verteilte Algorithmen“)

Kausaler Broadcast

Zweck: Wahrung von Kausalität bei der Kommunikation

ƒ Definition:Kausale Reihenfolge („causal order“): Wenn eine Nachricht N kausal von einer Nachricht M abhängt, und ein Prozess P die Nachrichten N und M empfängt, dann muss er M vor N empfangen haben.

ƒ „Kausale Reihenfolge“ (bzw.

„kausale Abhängigkeit“) las- sen sich insbesondere auch auf Broadcastsanwenden

ƒ Kausale Reihenfolge impliziert FIFO-Reihenfolge:

kausale Reihenfolge ist eine Art „globales FIFO“

Das Erzwingen der kausalen Reihenfolge ist mittels geeigneter Gegenbeispiel:

Keinekausalen Broadcasts!

M N M N

Resümee (6a)

ƒ Kommunikationskonzepte p

ƒ Ports; Kanäle; Ereigniskanäle als „Softwarebus“

ƒ Timeouts beim Empfangen von Nachrichten

ƒ Übersicht Gruppenkommunikation (Broadcast / Multicast)

ƒ Anwendungen

ƒ idealisierte Sicht

ƒ Fehlerproblematik

ƒ Vorbeugung gegen Fehler mit ACK, NACK

ƒ Algorithmus für „reliable Broadcast“

ƒ Redundanz („Fluten“ des Netzes) zur Erhöhung der Fehlertoleranz

ƒ Effizienz / Kosten (Zahl von Einzelnachrichten)

Resümee (6b)

ƒ FIFO-Broadcasts

ƒ zwei nacheinander ausgeführte Broadcasts ein und desselben Senders erreichen alle Empfänger in dieser Reihenfolge

ƒ nicht stark genug, um „akausale“ Beobachtungen zu verhindern

ƒ Kausale Broadcasts

ƒ kausale Abhängigkeit zweier Nachrichten

l d “ N h i ht f kti t“ k l

ƒ „causal order“: Nachrichtenempfang „respektiert“ kausale Abhängigkeit von Nachrichten (ist also „kausaltreu“)

ƒ „globalisiertes“ FIFO