Client/Server-Programmierung · Zu meiner Person Roland Wismu¨ller Betriebssysteme / verteilte Systeme Client/Server-Programmierung (1/15) 3 Studium der Informatik an der Techn

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (1/15) i

Roland Wismuller

Betriebssysteme / verteilte Systeme

[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404

Stand: 12. Januar 2018

Client/Server-Programmierung

WS 2017/2018

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (1/15) 2

Client/Server-ProgrammierungWS 2017/2018

0 Organisation

Zu meiner Person


➥ Studium der Informatik an der Techn. Univ. Munchen

➥ dort 1994 promoviert, 2001 habilitiert

➥ Seit Apr. 2004 Prof. fur Betriebssysteme und verteilte Systeme ander Univ. Siegen

➥ Forschung: Beobachtung, Analyse und Steuerung paralleler undverteilter Systeme

➥ Mentor fur die Bachelor–Studiengange Informatik mitNebenfach/Vertiefung Mathematik

➥ e-mail: [email protected]

➥ Tel.: 0271/740-4050

➥ Buro: H-B 8404

➥ Sprechstunde: Mo., 14:15-15:15 Uhr

Zur Fachgruppe”Betriebssysteme / verteilte Systeme“


Andreas Hoffmannandreas.hoffmann@uni-...

0271/740-4047

H-B 8405

➥ El. Prufungs- und Ubungssysteme

➥ IT-Sicherheit

➥ Web-Technologien

➥ Mobile Anwendungen

Damian Ludwigdamian.ludwig@uni-...

0271/740-2533

H-B 8402

➥ Capability-Systeme

➥ Compiler

➥ Programmiersprachen

Alexander Kordesalexander.kordes@uni-...

0271/740-4011

H-B 8407

➥ Automotive Electronics

➥ Fahrzeugnetzwerke

➥ Mustererkennung in Fahrzeug-Sensordaten

Lehrangebot


Vorlesungen/Praktika

➥ Rechnernetze I, 5 LP (jedes SoSe)

➥ Rechnernetze Praktikum, 5 LP (jedes WiSe)

➥ Rechnernetze II, 5 LP (jedes SoSe)

➥ Betriebssysteme I, 5 LP (jedes WiSe)

➥ Parallelverarbeitung, 5 LP (jedes WiSe)

➥ Verteilte Systeme, 5 LP (jedes SoSe)

➥ (wird auch als Betriebssysteme II anerkannt)

➥ Client/Server-Programmierung, 5 LP (jedes WiSe)

Lehrangebot ...


Projektgruppen

➥ z.B. Werkzeug zur Algorithmen-Visualisierung

➥ z.B. Infrastruktur zum Analysieren des Android Market

Abschlussarbeiten (Bachelor, Master, Diplom)

➥ Themengebiete: Mobile Plattformen (iOS, Android), Sensornetze,Parallelverarbeitung, Monitoring, ...

➥ z.B. Statische Analyse des Informationsflusses in Android Apps

Seminare

➥ Themengebiete: Webtechnologien, Sensornetze, Android, ...

➥ Ablauf: Blockseminare

➥ 30 Min. Vortrag, 5000 Worte Ausarbeitung

Zur Vorlesung


➥ Vorlesung mit praktischer Ubung

➥ 2+2 SWS, 5 LP

➥ Termine:

➥ Fr., 12:30 - 14:00, H-F 116 (Vorl.) bzw. H-A 4111 (Ubung)

➥ Mo., 16:00-17:30, H-B 8409/10 (Vorl.) bzw. H-A 4111 (Ubung)

➥ Information, Folien und Ankundigungen:

➥ http://www.bs.informatik.uni-siegen.de/lehre/

ws1718/csp

➥ Folienskript vollstandig verfugbar

➥ Folien werden ggf. leicht aktualisiert und i.d.R. spatestensam Tag vor der Vorlesung bereitgestellt (als PDF)

➥ Codebeispiele finden Sie lokal auf den Laborrechnern unter/home/wismueller/CSP

http://www.bs.informatik.uni-siegen.de/lehre/ws1718/csp


Lernziele


➥ Wissen um die Grundlagen, Techniken, Methoden und

Werkzeuge der verteilten Programmierung

➥ insbesondere objektorientierte und serviceorientierte

Middleware, sowie Komponenten

➥ Praktische Erfahrungen in der Programmierung von

Client/Server-Anwendungen

➥ Praktische Erfahrungen im Umgang mit unterschiedlicher

Middleware

Methodik


➥ Vorlesung: Grundlagen

➥ theoretisches Wissen zur verteilten Systemen, Middleware

und Komponenten

➥ Code-Beispiele und”Tutorials“

➥ Ubung: praktische Anwendung

➥ Nachvollziehen der Tutorials

➥ eigenstandige Programmierarbeit

➥ praktische Erfahrung, auch: Aufwerfen von Fragen

➥ Realisierung einer kleinen Borsenanwendung

➥ mit RMI, CORBA, EJB und Web Services

➥ zusatzlich kleinere einfuhrende und weiterfuhrende Aufgaben

➥ Programmierung ausschließlich in Java

Prufung


➥ Mundliche Prufung

➥ Dauer ca. 40 min.

➥ Stoff: Vorlesung und praktische Ubungen!

➥ Prufung erstreckt sich auch auf die praktischen Arbeiten

➥ aktive Teilnahme an der Ubung ist Zulassungs-Voraussetzung!

➥ Anmeldung:

➥ Terminabsprache im Sekretariat bei Fr. Syska

➥ per Email ([email protected])

➥ oder personlich (H-B 8403, vormittags)

➥ Anmeldung beim Prufungsamt

Einschub: Wichtiger Hinweis

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (1/15) ii

Fur Studierende der Informatik

➥ Bitte die Fristen des Prufungsamts beachten:

➥ Abgabe des Personalbogens: 10.11.2017

➥ Abgabe der Mentorengenehmigung: 23.11.2017

➥ ohne Mentorengenehmigung ist keine Prufungsanmeldungfur Kern- und Wahlfacher moglich!

➥ Anmeldezeitraum fur Klausuren: 04.12. - 21.12.2017➥ Abmeldung ist bis eine Woche vor der Prufung moglich

➥ (Mundliche Prufungen: Anmeldung ist jederzeit moglich)

➥ Fristen im WiSe 2017/18 einmalig vorgezogen

➥ Anfang Januar Umstellung von LSF auf unisono!

➥ Andere Studiengange (insbes. Wirtschaftsinformatik, Lehramt):

➥ bitte selbst bei Ihrem Prufungsamt informieren!

Organisatorisches zum Praktikum


➥ Benutzerordnung und Chipschlusselantrag:

➥ http://www.bs.informatik.uni-siegen.de/lehre/

ws1718/csp

➥ Chipschlusselantrag bitte unterscheiben lassen und direkt bei

Hr. Kiel (AR-P 209) abgeben

➥ Praktikumsbeginn: 23.10.

➥ Einfuhrung in die Rechner-Umgebung (Linux)

➥ Ausgabe der Kennungen

➥ Benutzerordnung im WWW beachten!



Rechnerumgebung im Labor H-A 4111


➥ Linux-PCs, privates IP-Netz, beschrankter Internet-Zugang

13 Arbeitsplätze(Intel, 2 Cores mit HT,

3,3 GHz, 4 GB) 3,2 GHz, 4 GB)

6 Arbeitsplätze(Intel, 4 Cores,

(lab.bvs)Labornetz 1 Gbit/s

httphttpsftp

Fachgruppennetz (bs.informatik.uni−siegen.de) / Internet

bsgate1.bs.informatik.uni−siegen.de

sftp (nur pubkey−Authentifizierung)

...bslab01−06,11−12,14−18

...bslab07−10,13,19

FileServer

Proxy

��

��

��

��

Inhalt der Vorlesung


➥ Grundlagen: Wiederholung

➥ Architekturmodelle

➥ Zeit und Zustand in verteilten Systemen

➥ Middleware

➥ Java RMI

➥ Java Datenbank-Schnittstelle JDBC

➥ CORBA

➥ Architektur, Dienste, IDL, ...

➥ Java Komponenten-Modelle

➥ Einfuhrung

➥ Java Beans

➥ Enterprise Java Beans

Inhalt der Vorlesung ...


➥ Servlets und JSP

➥ Web Services

➥ XML, SOAP, WSDL, ...

➥ Axis2

➥ Weitere Client/Server-Technologien

➥ u.a. .NET, DCOM

Zeitplan der Vorlesung (vorlaufig!)


Datum Montags-Termin Datum Freitags-Termin

09.10. — 13.10. V: Grundlagen, Wdh.

16.10. V: Grundlagen, Wdh. 20.10. V: JDBC

23.10. P: RMI 27.10. V: CORBA

30.10. V: CORBA 03.11. V: CORBA

06.11. P: RMI 10.11. V: Java Beans

13.11. P: RMI 17.11. V: EJB

20.11. P: CORBA 24.11. V: EJB

27.11. P: CORBA 01.12. V: EJB

Hellblau: freie Ubungstermine

Dunkelblau: Abgabetermine

Zeitplan der Vorlesung (vorlaufig!) ...


Datum Montags-Termin Datum Freitags-Termin

04.12. P: CORBA 08.12. V: Servlets, JSP

11.12. P: CORBA 15.12. V: Web Services

18.12. P: EJB 22.12. P: EJB

08.01. P: EJB 12.01. V: Web Services

15.01. P: EJB 19.01. V: Web Services

22.01. P: Web Services 26.02. V: Weitere Technologien

29.02. P: Web Services 02.02. P: Web Services

Hellblau: freie Ubungstermine

Dunkelblau: Abgabetermine

Literatur


Allgemeinere Literatur

➥ Ulrike Hammerschall, Verteilte Systeme und Anwendungen.

Pearson Studium, 2005.

➥ Robert Orfali, Dan Harkey, Client/Server-Programming with Java

and Corba. John Wiley & Sons, 1998.

Verteilte Systeme

➥ George Coulouris, Jean Dollimore, Tim Kindberg. Verteilte

Systeme – Konzepte und Design, 3. Auflage. Pearson Studium,

2002.

Literatur ...


Verteilte Programmierung mit Java

➥ Cay S. Horstmann, Gary Cornell. Core Java 2, Band 2 –

Expertenwissen. Sun Microsystems Press / Addison Wesley,

2008.

➥ Torsten Langner. Verteilte Anwendungen mit Java.

Markt+Technik, 2002.

➥ Jim Farley, William Crawford, David Flanagan. Java Enterprise in

a Nutshell, 3rd Edition. O’Reilly, 2005.

CORBA und COM

➥ Johann Hofmann, Fritz Jobst, Roland Schabenberger.

Programmieren mit COM und CORBA, Hanser, 2001.

Literatur ...


Enterprise JavaBeans

➥ Rima P. Sriganesh, Gerald Brose, Micah Silverman. MasteringEnterprise JavaBeans 3.0. Wiley, 2006.

➥ Bill Burke, Richard Monson-Haefel. Enterprise JavaBeans 3.0,5th Edition. O’Reilly, 2006.

Servlets

➥ Jason Hunter, William Crawford. Java Servlet Programmierung.O’Reilly, 2002.

Web Services

➥ Manfred Hein, Henner Zeller. Java Web Services,Addison-Wesley, 2003.

➥ Torsten Langner. Web Services mit Java, Markt+Technik, 2003.



1 Grundlagen: Wiederholung

1 Grundlagen: Wiederholung ...


Inhalt

➥ Architekturmodelle

➥ Zeit und Zustand in verteilten Systemen

➥ Middleware

➥ Java RMI

1.1 Architekturmodelle


Client/Server-Modell

➥ Asymmetrisches Modell: Server stellen Dienste bereit, die von

(mehreren) Clients genutzt werden konnen

➥ Server verwalten i.a. Ressourcen (zentralisiert)

Aufruf

Ergebnis

Client

Client

Server

RechnerProzeß

AufrufServer

Ergebnis

Server kann selbstwieder als Client agieren

➥ Haufigstes Modell fur verteilte Anwendungen (ca. 80 %)

1.1 Architekturmodelle ...


Client/Server-Modell ...

➥ I.A. nebenlaufige Anfragen mehrerer Client-Prozesse an den

Server-Prozeß

Client

Zeit(reply)(request)AntwortAnfrage

Start Ende

Server

Client

➥ Beispiele: Dateiserver, WWW-Server, DB-Server, DNS-Server, ...



n-Tier-Architekturen

➥ Verfeinerungen der Client/Server-Architektur

➥ Modelle zur Verteilung einer Anwendung auf die Knoten einer

verteilten Systems

➥ Vor allem bei Informationssystemen verwendet

➥ Tier (engl. Schicht / Stufe) kennzeichnet einen unabhangigen

Prozeßraum innerhalb einer verteilten Anwendung

➥ Prozeßraum kann, muß aber nicht physischem Rechner

entsprechen

➥ mehrere Prozeßraume auf einem Rechner moglich



2-Tier-Architektur

➥ Client- und Server-Tier

➥ Keine eigene Tier fur die Anwendungslogik

(Verteilung auf Client−und Server−Tier variiert)

Präsentation

Datenhaltung

Anwendungslogik

Client−Tier

Server−Tier

➥ Vorteil: einfach, performant

➥ Nachteil: schwer wartbar, schlecht skalierbar



3-Tier-Architektur

Präsentation

Anwendungslogik

Datenhaltung

Client−Tier

Middle−Tier

Server−Tier

➥ Standard-Verteilungsmodell fur einfache Web-Anwendungen:

➥ Client-Tier : Web-Browser zur Anzeige

➥ Middle-Tier : Web-Server mit Servlets / JSP / ASP

➥ Server-Tier : Datenbank-Server

➥ Vorteile: Anwendungslogik zentral administrierbar, skalierbar



Beispiel: typische Internet-Anwendung

Intranet

Internet

Web−Client

Web−Client

��

��

��

��

��

��

��

��

��

��

��

��

��

Anwen−dungs−Server

ServerWeb− Daten−

bank−Server

Tier 1 Tier 3 Tier 4Tier 2



Beispiel: typische Internet-Anwendung

Intranet

Internet

Web−Client

Web−Client

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Anwen−dungs−Server

ServerWeb− Daten−

bank−Server

Tier 1 Tier 3 Tier 4Tier 2

DMZ

��

��

��

��

Fire

wal

l

Fire

wal

l

��

��

��

��

��

ServerWeb−

1.2 Zeit und Zustand in verteilten Systemen


Was ist der Unterschied zwischen einem verteilten System undeinem Ein-/Mehrprozessorsystem?

➥ Ein- bzw. Mehrprozessorsystem:

➥ nebenlaufige Prozesse: pseudo-parallel durch time sharing

bzw. echt parallel

➥ globale Zeit: alle Ereignisse in den Prozessen lassen sich

zeitlich eindeutig ordnen

➥ globaler Zustand: zur jeder Zeit kann ein eindeutiger Zustand

des Systems angegeben werden

➥ Verteiltes System

➥ echte Parallelitat

➥ keine globale Zeit

➥ kein eindeutiger globaler Zustand

1.2 Zeit und Zustand in verteilten Systemen ...


Globale Zeit

➥ Auf Ein-/Mehrprozessorsystem

➥ jedem Ereignis kann (zumindest theoretisch) ein eindeutiger

Zeitstempel derselben lokalen Uhr zugeordnet werden

➥ bei Mehrprozessorsystemen: Synchronisation am

gemeinsamen Speicher

➥ In verteilten Systemen:

➥ viele lokale Uhren (eine pro Knoten)

➥ exakte Synchronisation der Uhren (prinzipiell!) nicht moglich

➥ ⇒ Reihenfolge von Ereignissen auf verschiedenen Knoten

nicht (immer) eindeutig zu ermitteln

➥ (vgl. spezielle Relativitatstheorie)



Eine Auswirkung der Verteiltheit

➥ Szenario: zwei Prozesse beobachten zwei andere Prozesse

Beobachter A

Beobachter B

Prozess 1

Prozess 2z

yx

z x y

x y z

➥ Die Beobachter sehen die Ereignisse ggf. in unterschiedlicherReihenfolge!

➥ Problem z.B., falls die Beobachter replizierte Datenbanken unddie Ereignisse Datenbank-Updates sind

➥ Replikate sind nicht mehr konsistent!



Globaler Zustand: Ein Beispiel zur Motivation

➥ Szenario: Peer-to-Peer -Anwendung, Prozesse senden sichgegenseitig Auftrage

➥ Frage: wann kann die Anwendung terminieren?

➥ Falsche Antwort: wenn kein Prozeß mehr einen Auftrag

bearbeitet

➥ Grund: Auftrage konnen noch in Nachrichten unterwegs sein!

AuftragProzeß 1 Prozeß 2

idle idle

➥ Weitere Anwendungen: verteilte Garbage-Collection, verteilteDeadlock -Erkennung, ...



➥ Wie bestimmt sich der Gesamtzustand eines verteilten Prozeß-

systems?

➥ naiv: Summe der Zustande aller Prozesse (falsch!)

➥ Zwei Aspekte mussen beachtet werden:

➥ Nachrichten, die noch in Ubertragung sind

➥ mussen mit in den Zustand aufgenommen werden

➥ Fehlen einer globalen Zeit

➥ ein Globalzustand zur Zeit t kann nicht definiert werden!

➥ Zustande der Prozesse beziehen sich immer auf lokale

(und damit unterschiedliche) Zeiten

➥ Frage: Bedingung an die lokalen Zeiten? ⇒ konsistenteSchnitte

1.3 Middleware


Verteilte Anwendung (VA)

Verteiltes System (VS)

Netz

VA−

VS−KnotenMiddlewareKomponente

VA−

VS−KnotenMiddlewareKomponenteKomponente

VA−

VS−Knoten

KomponenteVA−

VS−Knoten

Verteilte Anwendung (VA)

Verteiltes System (VS)

Netz

➥ VA nutzt VS fur Kommunikation zwischen ihren Komponenten

➥ VSe bieten i.a. nur einfache Kommunikationsdienste an

➥ direkte Nutzung: Netzwerkprogrammierung

➥ Middleware bietet intelligentere Schnittstellen

➥ verbirgt Details der Netzwerkprogrammierung

1.3 Middleware ...


➥ Middleware ist Schnittstelle zwischen verteilter Anwendung und

verteiltem System

➥ Ziel: Verbergen der Verteilungsaspekte vor der Anwendung

➥ u.a. Zugriffs- und Orts-Transparenz

➥ Middleware kann auch Zusatzdienste fur Anwendungen bieten

➥ starke Unterschiede bei existierender Middleware

➥ Unterscheidung:

➥ kommunikationsorientierte Middleware

➥ (nur) Abstraktion von der Netzwerkprogrammierung

➥ anwendungsorientierte Middleware

➥ neben Kommunikation steht Unterstutzung verteilter

Anwendungen im Mittelpunkt

1.3.1 Kommunikationsorientierte Middleware


➥ Fokus: Bereitstellung einer Kommunikationsinfrastruktur fur

verteilte Anwendungen

➥ Aufgaben:

➥ Kommunikation

➥ Behandlung der Heterogenitat

➥ Fehlerbehandlung

Anwendung

KommunikationsorientierteMiddleware

Betriebssystem / verteiltes System

1.3.1 Kommunikationsorientierte Middleware ...


Entfernter Prozeduraufruf (RPC, Remote Procedure Call)

➥ Ermoglicht einem Client den Aufruf einer Prozedur in einementfernten Server-Prozeß

...P(a) {

return b;}

y = P(x);Eingabeparameter

ProzeßClient−

ProzeßServer−

Resultate

➥ Kommunikation nach Anfrage / Antwort-Prinzip

Entfernter Methodenaufruf (RMI, Remote Method Invocation)

➥ Ermoglicht einem Objekt, Methoden eines entfernten Objektsaufzurufen

➥ Prinzipiell sehr ahnlich zu RPC



Gemeinsame Grundkonzepte entfernter Aufrufe

➥ Client und Server werden durch Schnittstellendefinition entkoppelt

➥ legt Namen der Aufrufe, Parameter und Ruckgabewerte fest

➥ Einfuhrung von Client-Stubs und Server-Stubs (Skeletons) als

Zugriffsschnittstelle

➥ werden automatisch aus Schnittstellendefinition generiert

➥ IDL-Compiler, Interface Definition Language

➥ sind verantwortlich fur Marshalling / Unmarshalling

sowie fur die eigentliche Kommunikation

➥ realisieren Zugriffs- und Ortstransparenz



Funktionsweise der Client- und Server-Stubs (RPC)

Client−Stub Server−Skeleton

P(a) {y=P(x)

...P(a) {

return b;}

; ;

Client−Prozeß

return b;}

receive(m1);

client=sender(m1);

Argumente x aus Nach−richt m1 auspacken

y = P(x)

}

Argumente a inNachricht m1 packen

send(Server, m1);

receive(Server, m2)

Ergebnis b aus Nach−richt m2 auspacken

while (true) {

send(client, m2);

richt m2 packenErgebnis y in Nach−

Server−Prozeß



Basis von RMI: Das Proxy-Pattern

➥ Client arbeitet mit Stellvertreterobjekt (Proxy) des eigentlichen

Serverobjekts

➥ Proxy und Serverobjekt implementieren dieselbe Schnittstelle

➥ Client kennt / nutzt lediglich diese Schnittstelle

Client Proxy Objekt

Schnittstelle<<interface>>



Ablauf eines entfernten Methodenaufrufs

Proxy

Skeleton ruftdieselbeMethode fürdas Objekt auf

Objektstelle wie beimSelbe Schnitt−

Objekt

Status

Methode

Schnitt−stelle

Client−BS

Client

Netzwerk

Server−BS

Server

Skeleton

Server−RechnerClient−Rechner

Client rufteineMethodeauf

Verpackter Aufruf wird über das Netzwerk weitergegeben(Objekt−ID, Methodenname, Parameter)



Erstellung eines Client/Server-Programms

Server

Client

Schnittstellen−beschreibung

Client−Programm

Compiler

Compiler

Client−Stubs

IDL−Compiler

Server−Skel.

Laufzeit−Bibliothek

RPC/RMI

Server−Prozeduren

➥ Gilt prinzipiell fur alle Realisierungen entfernten Aufrufe

1.3.2 Anwendungsorientierte Middleware


➥ Setzt auf kommunikationsorientierter Middleware auf

➥ Erweitert diese um:

➥ Laufzeitumgebung

➥ Dienste

➥ Komponentenmodell

DiensteDienste Laufzeitumgebung

Anwendungs−komponente



Komponentenmodell

Kommunikationsinfrastruktur

Betriebssystem / verteiltes System

1.3.2 Anwendungsorientierte Middleware ...


Laufzeitumgebung

➥ Ressourcenverwaltung

➥ Pooling von Prozessen, Threads, Verbindungen

➥ Steuerung der Nebenlaufigkeit

➥ Verbindungsverwaltung

➥ Verbesserung der Verfugbarkeit

➥ Replikation, Clustering

➥ Sicherheitsmechanismen

➥ Authentifizierung und Autorisierung

➥ Vertraulichkeit und Integritat

1.3.2 Anwendungsorientierte Middleware ...


Dienste

➥ Namensdienst (Verzeichnisdienst)

➥ Zuordnung von Namen zu Referenzen (Adressen)

➥ Sitzungsverwaltung

➥ Transaktionsverwaltung

➥ Persistenzdienst

➥ z.B. objektrelationaler Mapper (OR-Mapper)

Komponentenmodell

➥ Komponentenbegriff, Schnittstellenvertrage, Laufzeitumgebung

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (2/15) iii

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

16.10.2017

1.4 Java RMI


➥ Java RMI ist fester Bestandteil von Java

➥ erlaubt Nutzung entfernter Objekte

➥ Wichtige elemente von Java RMI (im Paket java.rmi):

➥ entfernte Objektimplementierungen

➥ Client-Schnittstellen (Stubs) zu entfernten Objekten

➥ Namensdienst, um Objekte im Netz ausfindig zu machen

➥ Stub- und Skeleton-Klassen werden automatisch aus Schnittstel-

lendefinition (Java Interface) generiert

➥ ab JDK 1.5 dynamisch zur Laufzeit

➥ Namensdienst: RMI Registry

➥ Verteilte Garbage-Collection

1.4 Java RMI ...


1.4.1 Hello World mit Java RMI

Client−JVM Server−JVM

class HelloClient {

s = h.sayHello();

Client−Klasse

...

Hello h;...

...

Server−Klasseclass HelloServer

String sayHello() {

return "Hello World";}

...

Interface

interface Hello {

String sayHello();}

implements Hello {

1.4.1 Hello World mit Java RMI ...


Ablauf der Entwicklung:

1. Entwurf der Schnittstelle fur das Server-Objekt

2. Implementierung der Server-Klasse

3. Entwicklung der Server-Anwendung zur Aufnahme des

Server-Objekts

4. Entwicklung der Client-Anwendung mit Aufrufen des

Server-Objekts

5. Ubersetzen und Starten des Systems



Entwurf der Schnittstelle fur das Server-Objekt

➥ Wird als normale Java-Schnittstelle spezifiziert

➥ Muß von java.rmi.Remote abgeleitet werden

➥ kein Erben von Operationen, nur Markierung als

Remote-Interface

➥ Jede Methode muß die Ausnahme java.rmi.RemoteException

(oder eine Basisklasse davon) auslosen konnen

➥ Basisklasse fur alle moglicherweise auftretenden Fehler

➥ im Client, bei der Ubertragung, im Server

➥ Keine Einschrankungen gegenuber lokalen Schnittstellen

➥ aber: semantische Unterschiede (Parameterubergabe!)



Hello-World Interface

RemoteException zeigt

Fehler im entfernten

Objekt bzw. bei Kommu−

nikation an

Marker−Schnittstelle ,

enthält keine Methoden,

markiert Interface als

RMI−Schnittstelle

public interface Hello extends Remote {

String sayHello() throws RemoteException;

import java.rmi.RemoteException;

import java.rmi.Remote;

}



Implementierung der Server-Klasse

➥ Eine Klasse, die remote nutzbar sein soll, muß:

➥ ein festgelegtes Remote-Interface implementieren

➥ i.d.R. von java.rmi.server.UnicastRemoteObject abgeleitet

werden

➥ definiert Aufrufsemantik: Punkt-zu-Punkt

➥ einen Konstruktor besitzen, der RemoteException werfen kann

➥ Erzeugung des Objekts muß in try-catch-Block stehen

➥ Methoden brauchen throws RemoteException nicht nochmals

anzugeben

➥ ausser sie werfen diese Exception explizit selbst



Hello-World Server (1)

Remote Methode

import java.rmi.*;

import java.rmi.server.UnicastRemoteObject;

public class HelloServer extends UnicastRemoteObject

implements Hello {

super();

}

return "Hello World!";

}

public HelloServer() throws RemoteException {

public String sayHello() {



Entwicklung der Server-Anwendung zur Aufnahme desServer-Objekts

➥ Aufgaben:

➥ Erzeugen eines Server-Objekts

➥ Registrieren des Objekts beim Namensdienst

➥ unter einem festgelegten, offentlichen Namen

➥ Typischerweise keine neue Klasse, sondern main-Methode der

Server-Klasse



Hello-World Server (2)

Server−Objekts

Erzeugen des Registrieren des Server−Objekts

unter dem Namen "Hello−Server"

beim Name−Server (RMI−Registry,

lokaler Rechner, Port 1099)

public static void main(String args[]) {

try {

HelloServer obj = new HelloServer();

catch (Exception e) {

System.out.println("Error: " + e.getMessage());

e.printStackTrace();

}

}

}

Naming.rebind("rmi://localhost/Hello−Server", obj);

}



Entwicklung der Client-Anwendung mit Aufrufen desServer-Objekts

➥ Client muß sich zunachst beim Namensdienst uber den Namen

eine Referenz auf das Server-Objekt holen

➥ Type cast auf den korrekten Typ erforderlich

➥ Dann: beliebige Methodenaufrufe moglich

➥ syntaktisch kein Unterschied zu lokalen Aufrufen

➥ Anmerkung: Client kann Remote-Referenzen auch auf anderen

Wegen erhalten

➥ z.B. als Ruckgabewert einer Remote-Methode



Hello-World Client

Objektreferenz vomName−Server holen

Aufruf der Methodedes entfernten Objekts


public class HelloClient {

try {

import java.rmi.*;

(Hello)Naming.lookup("rmi://bspc02/Hello−Server");

String message = obj.sayHello();

System.out.println(message); } catch (Exception e) { ...

} } }

Hello obj =



Ubersetzen und Starten des Systems

➥ Ubersetzen der Java-Quellen

➥ Quelldateien: Hello.java, HelloServer.java,HelloClient.java

➥ Aufruf: javac *.java

➥ erzeugt: Hello.class, HelloServer.class,HelloClient.class

➥ Erzeugen des Client-Stubs (Proxy-Objekt)

➥ fur Clients bis JDK 1.4:

➥ Aufruf: rmic -v1.2 HelloServer

➥ erzeugt HelloServer Stub.class

➥ ab JDK 1.5: Client erzeugt Proxy-Klasse zur Laufzeit

➥ durch java.lang.reflect.Proxy



Ubersetzen und Starten des Systems ...

Client−Seite Server−Seitebi

s JD

K 1

.4

HelloServer.java

HelloClient.class Hello.class Hello.class HelloServer.class

javac javac

HelloClient.java Hello.java

HelloServer_Stub.class

rmic



Ubersetzen und Starten des Systems ...

➥ Starten des Namensdienstes

➥ Aufruf: rmiregistry [port]

➥ erlaubt aus Sicherheitsgrunden nur die Registrierung von

Objekten auf dem lokalen Host

➥ d.h. RMI-Registry muß auf Server-Rechner laufen

➥ Standard-Port: 1099

➥ Starten des Servers

➥ Aufruf: java HelloServer

➥ Starten des Clients

➥ Aufruf: java HelloClient

1.4 Java RMI ...


1.4.2 Parameterubergabe

➥ Ubergabe von Parametern an Remote-Methoden erfolgt

➥ entweder uber call-by-value

➥ fur Werttypen und serialisierbare Objekte

➥ oder uber call-by-reference

➥ fur Objekte, die Remote implementieren

➥ Entscheidung wird z.T. erst zur Laufzeit getroffen!

➥ Ruckgabe des Ergebnisses folgt selben Regeln wie Parameter-

ubergabe

1.4.2 Parameterubergabe ...


Ubergabe eines serialisierbaren Objekts

param

Original

Client−Objekt param Stub−

ObjektServer−Objekt

verbindungNetz−

unabhängigeKopie

<<create>>

op(param)

Skele−ton

op(param) paramserialisieren

paramdeserialisieren

m()

1.4.2 Parameterubergabe ...


Ubergabe eines Remote-Objekts

paramStub

Stub−Objekt

paramClient−Objekt

paramStub

Netz−verbindung

Server−Objekt

<<create>>

op(paramStub)

Skele−ton

op(param)

toStub(param)

paramStubparamStubserialisieren

paramStubdeserialisieren

m()



2 Java Database Connectivity (JDBC)

2 Java Database Connectivity (JDBC) ...


2.1 Uberblick

➥ Java-API zum portablen Zugriff auf relationale Datenbank-

Systeme

➥ Unabhangig von konkreter Datenbank-Implementierung

➥ Funktionen:

➥ Verbindung zur Datenbank herstellen

➥ Ausfuhrung von SQL-Anweisungen

➥ Zugriff auf Abfrage-Ergebnisse

➥ Vergleichbar mit ODBC, aber einfachere Schnittstelle

➥ Anschluß zur Datenbank uber herstellerspezifische Treiber



2.2 Relationale Datenbanken und SQL

➥ Relationale Datenbank = Menge von Tabellen

➥ jede Spalte hat Namen und Datentyp

➥ jede Zeile enthalt i.a. ein Feld, dessen Wert die Zeile eindeutig

identifiziert (Primarschlussel)

➥ Aufbau festgelegt in Datenbank-Schema

➥ Beispiel:

Primär−schlüssel

AG_ID AG_NAME

2

1

3

BMW

Siemens

Thyssen

ag_name

ID AG_ID DAY VALUE

212

9 1

37

9

9

8

102.30

99.10

30.45

ag_data

2.2 Relationale Datenbanken und SQL ...


SQL

➥ Standardisierte Abfragesprache fur relationale Datenbanken

➥ Erlaubt u.a.:

➥ Abfrage von Daten (SELECT)

➥ Erzeugung neuer Tabellen (CREATE TABLE)

➥ Einfugen von Datensatzen (Zeilen) (INSERT)

➥ Loschen von Datensatzen (DELETE)

➥ Andern von Datensatzen (UPDATE)

➥ Auswahl der Datensatze i.d.R. uber deren Inhalt

➥ haufig uber Primarschlussel

2.2 Relationale Datenbanken und SQL ...


Beispiele fur SQL-Anfragen

➥ SELECT AG_ID, AG_NAME

FROM ag_name

WHERE AG_NAME = ’Siemens’

➥ liefert die Zeile fur Siemens aus der ag name-Tabelle

➥ SELECT ag_name.AG_NAME, ag_data.VALUE

FROM ag_name, ag_data

WHERE VALUE > 90 AND ag_name.AG_ID = ag_data.AG_ID

➥ liefert Name und Kurs aller Aktien mit Kurs uber 90

➥ gibt Information aus zwei Tabellen zuruck

➥ Verbindung der Eintrage uber den Primarschlussel

(Natural Join)



2.3 Architektur von JDBC

SQL−ServerMS mySQL Oracle

Java Anwendung

JDCB Treiber Manager

JDBC/ODBCBrücke

Treiber fürmySQL Oracle

Treiber für

ODBCTreiber

2.3 Architektur von JDBC ...


Klassen des JDBC-Kerns

Statement

PreparedStatement

CallableStatement

<<interface>>

<<interface>>

<<interface>>

ResultSet

ResultSetMetaData

<<interface>>

<<interface>>

Connection

<<interface>>Driver

<<interface>>

DriverManager

DriverPropertyInfo

java.sql



Klassen des JDBC-Kerns ...

➥ Interface Driver

➥ Schnittstelle, die alle JDBC-Treiber implementieren mussen

➥ neu geladener Treiber registriert sich bei DriverManager

➥ Klasse DriverManager

➥ verwaltet Driver-Objekte

➥ erzeugt Datenbank-Verbindungen (Connection)

➥ Klasse DriverPropertyInfo

➥ erlaubt Definition spezieller Parameter beim Aufbau der

Datenbank-Verbindung




➥ Interface Connection

➥ reprasentiert Sitzung mit ausgewahlter Datenbank

➥ erlaubt Erzeugung von Statement-Objekten

➥ verwaltet Informationen zum Zustand der Datenbank

➥ erlaubt Abfrage von Metadaten der Datenbank

(Methode getMetaData(), Resultat: DatabaseMetaData)

➥ z.B. unterstutzte SQL-Versionen, Limitierungen des

Datenbank-Systems, ...

➥ Interface Statement

➥ zur Ausfuhrung einer SQL-Anfrage

➥ verwaltet auch Ergebnis der Anfrage (ResultSet)




➥ Interface PreparedStatement

➥ zur Ausfuhrung einer vorkompilierten SQL-Anfrage

➥ effizienter bei wiederholter Ausfuhrung

➥ Interface CallableStatement

➥ erlaubt Aufruf von Stored Procedures

➥ SQL-Prozeduren, die in Datenbank selbst abgelegt sind

➥ Interface ResultSet

➥ Ergebnis-Relation einer Datenbank-Anfrage

➥ Interface ResultSetMetaData

➥ Metadaten zu den Spalten der Ergebnis-Relation

➥ z.B. Name, Typ, vorzeichenbehaftet, ...



2.4 Ein Beispiel

import java.sql.*;

import java.lang.*;

public class Beispiel {

public static void main(String[] args) {

try {

// Laden des JDBC−Treibers

Class.forName("com.mysql.jdbc.Driver");

}

catch (ClassNotFoundException e) {

System.out.println("Treiber nicht ladbar:" + e);

return;

}

2.4 Ein Beispiel ...


try {

// Verbindung zur Datenbank

Connection con = DriverManager.getConnection(

"jdbc:mysql://bslabserv01.lab.bvs/cspdb","","");

// Erzeuge SQL−Anweisung und fuhre sie aus

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery(

"SELECT AG_ID, AG_NAME FROM ag_name");

// Ausgabe des Ergebnisses

while (rs.next()) {

System.out.println("" + rs.getInt("AG_ID") + ", "

+ rs.getString("AG_NAME"));

}

2.4 Ein Beispiel ...


// Alles schließen

rs.close();

stmt.close();

con.close();

}

catch (SQLException e) {

System.out.println("SQL Exception: "

+ e.getMessage());

e.printStackTrace(System.out);

}

}

}



2.5 Details zu JDBC

Laden der Treiber

➥ Vor Verwendung von JDBC mussen die Treiber geladen werden:

➥ try {

Class.forName("com.mysql.jdbc.Driver");

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");

}

catch (ClassNotFoundException e) { ... }

➥ Alternativ: Setzen der jdbc.drivers Property

➥ java -Djdbc.drivers=com.mysql.jdbc.Driver:sun.jdbc.

odbc.JdbcOdbcDriver ...

2.5 Details zu JDBC ...


Verbindung zur Datenbank herstellen

➥ Verbindung wird durch Connection-Objekt reprasentiert

➥ Mehrere Datenbank-Verbindungen pro Anwendung moglich

➥ Erzeugung uber

➥ Connection con = DriverManager.getConnection(

"url ", "user ", "password ");

➥ Variante von getConnection() erlaubt Definition von Properties

fur die Datenbank-Verbindung

➥ Wenn Verbindung nicht mehr benotigt wird:

➥ explizites Schließen mit Methode con.close()

➥ Freigabe von Netzwerk- und Speicherressourcen



Ausfuhrung einer SQL-Anweisung

➥ Erzeugung eines Statement-Objekts

➥ Statement stmt = con.createStatement();

➥ Ausfuhrung der SQL-Anweisung

➥ ResultSet rs = stmt.executeQuery("SELECT ...");

➥ Methoden executeUpdate() fur Anfragen ohne Ergebnis,

bzw. execute(), falls unbekannt, ob Ergebnis geliefert wird

➥ execute() liefert true, falls Ergebnis vorhanden

➥ Statement-Objekt reprasentiert eine einzige SQL-Anfrage

➥ ResultSet wird bei erneuter Anfrage uber selbesStatement-Objekt ungultig

➥ fur simultane Anfragen: mehrere Statement-Objekte!



Zugriff auf die Resultate

➥ Ergebnis einer SQL-Anfrage (SELECT) ist eine Tabelle

➥ Struktur gekapselt in ResultSet-Objekt

➥ Methoden u.a.:

➥ next(): setzt”Lesezeiger“ auf nachste Zeile

➥ zu Begin steht Zeiger vor der ersten Zeile

➥ Ergebnis false, falls keine Zeile mehr vorhanden

➥ get...(String name) / get...(int nr): liefert Inhalt desFeldes mit Spaltenname name bzw. Spaltennummer nr

➥ mehrere Methoden fur die verschiedenen Datentypen

➥ getString() liefert immer String-Reprasentation

➥ close(): Ressourcenfreigabe



SQL-Datentypen und Zugriffsmethoden (Auswahl)

SQL Typ(en) Java Typ Methode

CHAR, VARCHAR String getString()

NUMERIC, DECIMAL java.math.BigDecimal getBigDecimal()

BIT boolean getBoolean()

TINYINT byte getByte()

SMALLINT short getShort()

INTEGER int getInt()

BIGINT long getLong()

REAL float getFloat()

FLOAT, DOUBLE double getDouble()

BINARY, VARBINARY byte[] getBytes()

DATE java.sql.Date getDate()



Ausfuhrung vorkompilierter SQL-Anfragen

➥ Fur wiederkehrende, ahnliche Aufgaben sind vorkompilierteSQL-Anfragen (PreparedStatement) effizienter

➥ die Anfragen sind auch parametrisierbar

➥ Auch Sicherheitsvorteil gegen SQL Injection

➥ Erzeugung eines PreparedStatement-Objekts

➥ PreparedStatement stmt = con.prepareStatement("INSERT INTO Employees (Name, Phone) (?, ?)");

➥ ? als Platzhalter fur Parameter

➥ Ausfuhrung der Anfrage mit konkreten Parametern

➥ stmt.clearParameters();stmt.setString(1, "Jimmy Dean"); // erster Param.stmt.setString(2, "201 555-7685"); // zweiter Param.stmt.executeUpdate(); // kein Ergebnis



Ausfuhrung von Stored Procedures

CREATE OR REPLACEPROCEDURE sp_interest(id IN INTEGERbal IN OUT FLOAT) isBEGINSELECT balanceINTO balFROM accountsWHERE account_id = id;

bal = bal + bal * 0.03;

UPDATE accountsSET balance = balWHERE account_id = id;

END;

Datenbanksystem gespeichert)Oracle PL/SQL−Prozedur (Im

CallableStatement stmt

= con.prepareCall(

stmt.registerOutParameter(2,

stmt.setFloat(2, 2343.23);

out.println("New Balance: "

stmt.execute();

stmt.setInt(1, accountID);

Aufruf der Prozedur über JDBC

+ stmt.getFloat(2));

Types.FLOAT);

"{call sp_interest(?,?)}");



Transaktionen

➥ Verantwortlich fur Transaktionen: Connection-Objekt

➥ Methoden zur Steuerung von Transaktionen:

➥ setAutoCommit() - automatisches Festschreiben?

➥ Voreinstellung: jede SQL-Anweisung wird als individuelleTransaktion ausgefuhrt

➥ commit() - Festschreiben der Transaktion

➥ rollback() - Abbruch der Transaktion

➥ setTransactionIsolation() - Isolationsebene festlegen

➥ TRANSACTION NONE, sowie die vier Isolations-Ebenen nachANSI/ISO-SQL99 (☞ VS, 7.4):

➥ read uncommitted, read commited, repeatable read,serializable

➥ Voreinstellung ist vom Treiber abhangig



Transaktionen ...

try {

// Hochste Isolationsebene

con.setTransactionIsolation(TRANSACTION_SERIALIZABLE);

// Transaktionen mit mehreren SQL−Anweisungen zulassen

con.setAutoCommit(false);

// SQL−Anweisungen

stmt.executeUpdate("UPDATE inv SET onhand = 10 WHERE id = 5");

stmt.executeUpdate("INSERT INTO shipping (qty) VALUES (5)");

// Commit aller Aktionen seit letztem Commit/Rollback

con.commit();

}

catch (SQLException e) {

// Ruckgangigmachen aller Anderungen

con.rollback();

}



2.6 Zusammenfassung

➥ JDBC erlaubt portablen Zugriff auf relationale Datenbanken

➥ Abfragen uber SQL

➥ Grundsatzlicher Ablauf:

➥ Laden des Treibers (Class.forName())

➥ Verbindung zur Datenbank herstellen (Connection)

➥ SQL-Anweisung erzeugen (Statement)

➥ SQL-Anweisung ausfuhren, Ergebnis auslesen (ResultSet)

➥ Daneben: Unterstutzung fur

➥ vorkompilierte SQL-Anweisungen und Stored Procedures

➥ Transaktionen

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (3/15) iv

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

20.10.2017



3 CORBA

3 CORBA ...


Inhalt

➥ CORBA-Architektur

➥ CORBA-Dienste

➥ Beispielprogramm

➥ CORBA im Detail

➥ IDL und IDL-Java-Mapping

➥ Namensdienst

➥ POA

➥ GIOP, IIOP und IOR

➥ Implementation- und Interface-Repository

3 CORBA ...


Literatur

➥ CORBA-Spezifikationen der OMG

➥ http://www.omg.org/technology/documents/

corba spec catalog.htm

➥ Farley / Crawford / Flanagan, Kap. 14

➥ Orfali / Harkey, Kap. 1, 4, 7-9, 17-22

➥ Hofmann / Jobst / Schabenberger, Kap. 2.2, 5, 6

➥ Michi Henning, Steve Vinoski: Advanced CORBA Programmingwith C++. Addison-Wesley, 1999.

http://www.omg.org/technology/documents/corba_spec_catalog.htm

http://www.omg.org/technology/documents/corba_spec_catalog.htm

3.1 Einfuhrung


➥ CORBA: Common Object Request Broker Architecture

➥ Ziel: Entwicklung und Integration verteilter objektorientierter

Anwendungen in heterogenen Umgebungen

➥ CORBA ist plattform- und sprachunabhangig

➥ Informeller Standard, definiert durch die OMG (Object

Management Group)

➥ 1989 gegrundet, Ziel: Forderung objektorientierter Techniken

➥ heute uber 700 Mitglieder (großtes IT-Industriekonsortium)

➥ CORBA ist nur eine Spezifikation

➥ verschiedenste Implementierungen, z.B. Orbix, ORBACUS,Java IDL (Teil des JDK), JacORB, ORBit (GNOME!) ...

3.2 CORBA Architektur


3.2.1 Object Management Architecture (OMA)

➥ Definiert Objekt- und Referenzmodell

➥ Objektmodell

➥ unterstutzt Kapselung, (Mehrfach-)Vererbung, Polymorphie

➥ Objekte bieten Dienste mit definierter Schnittstelle an

➥ Client nutzt Dienste (lokal oder entfernt) uber Schnittstelle, ist

vollstandig von Server-Implementierung unabhangig

➥ Objektimplementierung mit beliebiger Programmiersprache

➥ Referenzmodell

➥ Interaktion zw. Objekten und dazu notwendige Komponenten

➥ Herzstuck: Object Request Broker (ORB)

➥

”Software-Bus“ fur Kommunikation zw. Client und Server

3.2.1 Object Management Architecture (OMA) ...


Das OMA Referenzmodell

CORBA Services

Object Request Broker

. . .

Client Server

LifeCycle TransactionsEventNaming

Application Vertical CORBA Horizontal CORBAFacilitiesObjects Facilities



Bestandteile des OMA Referenzmodells

➥ Object Request Broker (ORB)

➥ stellt Dienstanfragen an verteilte Objekte zu

➥ realisiert Ortstransparenz fur die Client-Objekte

➥ CORBA Services (Object Services)

➥ domanenunabhangige (horizontale) Schnittstellen zu

wichtigen Basisdiensten, z.B. Namensdienst

➥ betriebssystem-ahnliche Funktion

➥ Horizontal CORBA Facilities (Common Facilities)

➥ Schnittstellen zu anwendungsorientierten, domanenuber-

greifenden Diensten

➥ z.B. Drucken, verteilte Dokumente, ...



Bestandteile des OMA Referenzmodells ...

➥ Vertical CORBA Facilities (Domain Interfaces)

➥ Schnittstellen zu anwendungsorientierten Diensten fur

bestimmte Anwendungsdomanen

➥ z.B. Finanzwesen, Medizin, Telekommunikation, ...

➥ Application Objects

➥ anwendungsspezifische Schnittstellen

➥ im Ggs. zu Services und Facilities nicht von der OMG

standardisiert

➥ OMG spezifiziert nur die Schnittstellen, nicht die Implemen-

tierungen

3.2 CORBA Architektur ...


3.2.2 Common Object Request Broker Architecture (CORBA)

➥ Zentrale Idee: transparente Kommunikation zwischen Client und

Server-Objekten uber ORB

➥ ORB bietet Client eine lokale (Proxy-)Schnittstelle

➥ Vorteile beim Einsatz eines ORB:

➥ Zugriffs- und Ortstransparenz

➥ Transparenz der Implementierungssprache

➥ Transparenz der Objektaktivierung

➥ ORB ubernimmt ggf. Aktivierung des Objekts

➥ Transparenz der Kommunikationstechnik

3.2.2 Common Object Request Broker Arch. ...


Objektreferenzen

➥ Zugriff auf Objekte erfolgt uber Objektreferenzen

➥ Objektreferenzen

➥ identifizieren genau ein Objekt

➥ aber: verschiedene Referenzen fur ein Objekt moglich

➥ konnen null sein, d.h. auf kein Objekt zeigen

➥ konnen”hangen“, wenn Objekt nicht mehr existiert

➥ konnen persistent sein

➥ sind typsicher

➥ unterstutzen spates Binden (Polymorphismus)

➥ sind interoperabel, d.h. Aufbau ist standardisiert

➥ sind opak, d.h. Client darf Inhalt nicht betrachten



OMG Interface Definition Language (OMG IDL)

➥ OMG IDL erlaubt formale Beschreibung der Objekt-Schnitt-

stellen

➥ unabhangig von Implementierung der Objekte (z.B.

Programmiersprache)

➥ Objekte konnen z.B. durch C++- oder Java-Objekte, aber auch

durch eigene Programme oder OO-Datenbanken

implementiert werden

➥ OMG definiert, wie IDL in verschiedene Sprachen abgebildet wird

(Language Mapping)

➥ derzeit fur C, C++, Java, Smalltalk, Ada, Lisp, Phyton, Cobol,

PL/1, Ruby



Modell des Object Request Brokers

��

��

��

��

��

��

��

��

DynamicSkeletonInterface

SkeletonORBInterface

DynamicInvocationInterface

Stub

Implementation RepositoryInterface Repository

Identische Schnittstelle für alle ORB−ImplementierungenEine Schnittstelle pro Objekt−TypMehrere (unterschiedliche) Objekt−Adapter möglichORB−spezifische Schnittstelle

Client Object Implementation

Rechnergrenzemögliche

ORB−Core

AdapterObject



Komponenten des ORB

➥ ORB Core

➥ stellt Basisfunktionalitat zur Verfugung

➥ Objekt-Reprasentation, Kommunikationsmechanismen

➥ ist i.d.R. verteilt implementiert

➥ Stub und Skeleton

➥ fur entfernten Methodenaufruf

➥ vom IDL-Compiler aus Schnittstellendefinition erzeugt

➥ Dynamic Invocation Interface und Dynamic Skeleton Interface

➥ erlauben dynamische Methodenaufrufe/-implementierungen

➥ d.h. Schnittstelle muß zur Ubersetzungszeit des Clients bzw.

Servers noch nicht festgelegt sein



Komponenten des ORB ...

➥ Object Adapter

➥ stellt Objektimplementierung Dienste des ORB zur Verfugung

➥ Funktionen u.a.:

➥ Methodenaufrufe (uber Skeletons)

➥ Abbildung von Referenzen auf Impementierungen

➥ Registrierung von Implementierungen

➥ Generierung und Interpretation von Objektreferenzen

➥ Objektaktivierung und -deaktivierung

➥ unterschiedliche Objektadapter moglich

➥ ab CORBA 2.2: Portable Object Adapter (POA) als

Standard-Schnittstelle zum Objektadapter



Komponenten des ORB ...

➥ ORB Interface

➥ Schnittstelle fur Dienste, die der ORB dem Client und allenObjektimplementierungen zur Verfugung stellt

➥ Interface Repository

➥ Dienst, der zur Laufzeit persistente Information zu denregistrierten Objektschnittstellen zur Verfugung stellt

➥ Nutzung ggf. durch ORB und / oder Clients

➥ allgemein: jegliche Information zu Objekt-Schnittstellen

➥ Implementation Repository

➥ enthalt Information, die es dem ORB erlaubt, Objekte zulokalisieren und zu aktivieren

➥ allgemein: jegliche Information zu Objekt-Implementierungen

3.2 CORBA Architektur ...


3.2.3 CORBA-Dienste

➥ Von der OMG spezifiziert, erweitern ORB-Funktionalitat

➥ realisiert durch CORBA-Objekte mit IDL-Schnittstelle

➥ Anbieter von ORB und Diensten konnen unterschiedlich sein

➥ Collection Service

➥ Container -Objekte, z.B. Map, Set, Queue

➥ Concurrency Control Service

➥ realisiert Sperren fur wechselseitigen Ausschluß

➥ Event Service

➥ verteilt Ereignisse an interessierte Objekte

➥ Externalization Service

➥ (De-)Serialisierung von Objekten

3.2.3 CORBA-Dienste ...


➥ Licensing Service

➥ erfaßt Nutzung von Objekten fur Abrechnung

➥ Life Cycle Service

➥ Erzeugen, Loschen, Kopieren und Verschieben von Objekten

➥ Naming Service

➥ Zuordnung von Namen zu Objektreferenzen

➥ Notification Service

➥ Event Service-Erweiterung: beliebige Daten als Ereignisse

➥ Persistent Object Service

➥ persistentes Speichern von Objekten in Datenbanken

➥ Property Service

➥ Verwaltet Name/Wert-Paare

3.2.3 CORBA-Dienste ...


➥ Query Service

➥ Anfrageoperationen an verteilte Objekte (SQL-Obermenge)

➥ Relationship Service

➥ Erzeugung / Traversierung von Assoziationen zw. Objekten

➥ Security Service

➥ Authentifizierung, Zugriffskontroll-Listen, Rechteweitergabe

➥ Time Service

➥ Zeit-Synchronisation

➥ Trading Service

➥ erlaubt CORBA-Objekte anhand ihrer Fahigkeiten zu finden

➥ Object Transaction Service

➥ flache und verschachtelte verteilte Transaktionen

3.3 Hello World mit CORBA


Vorbemerkungen

➥ In der Vorlesung und Ubung:Verwendung zweier CORBA-Implementierungen

➥ Java IDL

➥ Seit JDK 1.2 fester Bestandteil der Java Entwicklungsum-gebung

➥ wenig Dienste (nur Namensdienst)

➥ JacORB 2.3.1

➥ frei verfugbarer ORB, in Java implementiert

➥ mehr Dienste (u.a. Naming, Event, Notification, Trans-action, Trading), sowie Interface- und Implementation Re-pository

➥ Wegen POA: Anwendungs-Quellcode ist fur alle Implementierun-gen gleich

3.3 Hello World mit CORBA ...


ServerClientIDL−zu−JavaCompiler

IDL−zu−JavaCompiler

javacCompiler

javacCompiler

1

25

6 7 4 3

Hilfs−Klassen

Client−StubsInterfaces

Java Hilfs−Klassen

Objekt−Skeletons

POAInterfaces

Java

Objekt−Implementierung

POAStub

Objekt−Impl.codeCode

Client−

Client−Anwendung

Object Request Broker

Schnittstellen−definitionen in IDL

Vor

gehe

n zu

r E

rste

llung

der

Anw

endu

ng

Skeleton



IDL-Beschreibung der Schnittstelle

Paketname

Schnittstelle

Methode

Eingabeparameter

module HelloWorld

interface Hello {

};

{

string sayHello(in string name); };

➥ CORBA definiert eigene, C++/Java-ahnliche Sprache

➥ IDL-Compiler erzeugt Schnittstellen fur jeweilige Implemen-

tierungssprache

➥ kann fur Client und Server verschieden sein



Vom IDL-Compiler generierte Dateien

Hello.java HelloPOA.java_HelloStub.java

HelloOperations.java

HelloHelper.java

HelloHolder.java

HelloPOATie.java

Hilfsfunktionenfür Client/Server

Hello.idl

ClientServer

Client−Stub

Schnittstelle

Hilfsklasse fürAusgabeparameter

idlj

(JacOrb)idl

(Java IDL)

Basisklasse f. Impl.

Tie−Klasse f. Impl.



Aufruf des IDL-Compilers

➥ Java IDL:

➥ idlj -fall – erzeugt alle Dateien

➥ idlj -fclient – erzeugt Dateien fur Client

➥ idlj -fserver – erzeugt Dateien fur Server

➥ ohne Helper-Klassen!

➥ idlj -fallTie – erzeugt alle Dateien incl. Tie-Klassen

➥ JacORB:

➥ idl – erzeugt alle Dateien incl. Tie-Klassen

➥ idl -noskel – erzeugt Dateien nur fur Client

➥ idl -nostub – erzeugt Dateien nur fur Server

➥ Weiteres Argument: Name der IDL-Datei



Vom IDL-Compiler erzeugte Java-Schnittstelle

➥ HelloWorld/Hello.java:

package HelloWorld;

public interface Hello extends HelloOperations,

org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity

{

}

➥ HelloWorld/HelloOperations.java:

package HelloWorld;

public interface HelloOperations

{

String sayHello (String name);

}



Objektimplementierung

// vom IDL−Compiler erzeuges Paket mit Hilfsklassen

import HelloWorld.*;

public class HelloImpl extends HelloPOA

{

public String sayHello(String name)

{

return "The world says HELLO to " + name;

}

}



Server-Programm

// vom IDL−Compiler erzeuges Paket mit Hilfsklassen

import HelloWorld.*;

// CORBA Namensdienst

import org.omg.CosNaming.*;

// Fur Exceptions, die Namensdienst werfen kann

import org.omg.CosNaming.NamingContextPackage.*;

// Alle CORBA−Server benotigen diese Klassen

import org.omg.CORBA.*;

import org.omg.PortableServer.*;



public class HelloServer {


try {

// Erzeuge und Initialisiere den ORB

ORB orb = ORB.init(args, null);

// Erzeuge das Servant−Objekt

HelloImpl helloRef = new HelloImpl();

// Aktivierung des POA

POA rootpoa = POAHelper.narrow(

orb.resolve_initial_references("RootPOA"));

rootpoa.the_POAManager().activate();



// Registriere Servant und erzeuge (CORBA) Objektreferenz

org.omg.CORBA.Object ref =

rootpoa.servant_to_reference(helloRef);

// Typ−Konvertierung

Hello href = HelloHelper.narrow(ref);

// Registriere Objektreferenz beim Namensdienst

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");

NamingContextExt ncRef =

NamingContextExtHelper.narrow(objRef);

NameComponent path[] = ncRef.to_name("HelloWorld");

ncRef.rebind(path, href);

System.out.println("HelloServer is running...");



// Starte ORB

orb.run();

} catch(Exception e) {

System.err.println("ERROR: " + e);


}

}

}



Client-Programm

import HelloWorld.*; // Client Stubs

import org.omg.CosNaming.*; // Namensdienst

import org.omg.CORBA.*; // CORBA Klassen



try {

// Erzeuge und Initialisiere den ORB


// Aufsuchen des Objekts beim Namensdienst

org.omg.CORBA.Object objRef =




NamingContextExt ncRef =

NamingContextExtHelper.narrow(objRef);


Hello helloRef =

HelloHelper.narrow(ncRef.resolve(path));

// Aufruf der Methode des CORBA−Objekts

System.out.println(helloRef.sayHello("Peter"));

} catch(Exception e) {

System.out.println("ERROR : " + e);


}

}

}



Anmerkungen zum Code

➥ resolve initial references() dient der initialen Auflosung von

Namen, insbesondere:

➥ RootPOA: der Wurzel-POA des Servers (☞ 3.4.6)

➥ NameService: der Namensdienst

Ergebnis ist org.omg.CORBA.Object

➥ CORBA Objektreferenz

➥ narrow() dient zum Umwandeln einer Referenz vom Typ

org.omg.CORBA.Object in einen konkreten Typ (downcast)

➥ to name() wandelt String in strukturierten Namen fur Namens-

dienst um (s. spater)

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (4/15) v

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

27.10.2017



Starten der Anwendung (Java IDL)

➥ Starten des ORB-Daemons (Namensdienst)

➥ orbd -ORBInitialPort 12345 [ -port <port> ]

➥ startet Daemon auf Port 12345 (-port legt Port fur

Objektaktivierung fest)


➥ java HelloServer -ORBInitialPort 12345

[ -ORBInitialHost <addr> ]

➥ Angabe von Host und Port des ORB-Daemons


➥ java HelloClient -ORBInitialPort 12345

[ -ORBInitialHost <addr> ]



Zur Nutzung von JacORB im Labor H-A 4111

➥ Umgebungsvariablen setzen (ggf. in $HOME/.profile):

➥ export JACORB_HOME=/opt/dist/JacORB

➥ export PATH=$JACORB_HOME/bin:$PATH

➥ Konfigurationsdatei einrichten:

➥ cp $JACORB_HOME/etc/jacorb_properties.template

$HOME/orb.properties

➥ in $HOME/orb.properties alle cspXXX durch eigenes Login

ersetzen

➥ JacORB verwendet bei uns eine Datei unter $HOME zum

Auflosen der initialen Referenzen➥ setzt Netzwerk-Dateisystem (NFS) voraus

➥ auch moglich: Nutzung eines WWW-Servers



Starten der Anwendung (JacORB)

➥ Starten des Namensdienstes

➥ ns

➥ startet auf beliebigem freiem Port

➥ schreibt eigene Objektreferenz in Datei $HOME/.jaco_ns


➥ jaco HelloServer

➥ jaco ist ein Hilfsskript von JacORB

➥ startet JVM mit notigen Properties und Classpath


➥ jaco HelloClient

3.4 CORBA im Detail


3.4.1 OMG IDL und Java-Mapping

➥ Struktur einer IDL-Datei:

module Identifikator {Typ-Deklarationen;

Konstanten-Deklarationen;

Exception-Deklarationen;

interface Identifikator [ :Vererbung ] {Typ-Deklarationen;

Konstanten-Deklarationen;Exception-Deklarationen;

Attribut-Deklarationen;

Methoden-Deklarationen;

};...

};

3.4.1 OMG IDL und Java-Mapping ...


module und interface

➥ module definiert einen neuen Namensraum

➥ ahnlich wie C++ Namespaces bzw. Java Packages

➥ verschachtelte Namensraume moglich

➥ interface definiert neue Schnittstelle

➥ ahnlich wie Java-Schnittstellen

➥ Schnittstelle kann Methoden und Attribute enthalten

➥ Attribute werden uber automatisch generierte

Deklarationen von Get- und Set-Methoden realisiert

➥ Vererbung ist moglich, auch Mehrfachvererbung

➥ vererbt werden nur Schnittstellen, keine Implementierungen



Methoden-Deklarationen

➥ Syntax:

➥ [ oneway ] Typ Identifikator ( Parameterliste )

[ raises ( Exceptions ) ] [ Kontext ]

➥ Parameterliste: Liste von Parameterdeklarationen:

➥ { in | out | inout } Typ Identifikator

➥ Klassifikation nach Ein- und Ausgabeparametern

➥ Kontext : Liste von Kontextvariablen

➥ ahnlich UNIX Umgebungsvariablen, werden an Server

ubergeben

➥ oneway: asynchroner Methodenaufruf

➥ ohne Ergebnis / Ausgabeparameter

➥ Uberladen von Methoden ist nicht erlaubt



Wichtige Basis-Datentypen und ihre Java-Entsprechungen

IDL Datentyp Beschreibung Java Datentyp

[unsigned] short Ganzzahl, 16 Bit short

[unsigned] long Ganzzahl, 32 Bit int

[unsigned] long long Ganzzahl, 64 Bit long

float Gleitkomma, 32 Bit float

double Gleitkomma, 64 Bit double

char Zeichen, 8 Bit char

string Zeichenkette String

boolean (TRUE, FALSE) Boole’scher Wert boolean (true, false)

octet Byte byte

any beliebiger Typ org.omg.CORBA.Any



Beispiel

module Beispiel {

interface Test1 {

void setName(in string name);

double getXY(out double y);

long encrypt(in string key, inout string msg);

};

interface Test2 {

string charToString(in char c1, in char c2);

};

};



Vom IDL-Compiler erzeugte Klassen und Interfaces

Test1Operations<<interface>>

setName()getXY()encrypt()

Test1<<interface>>

_Test1Stub

Test2Holder

_Test2Stub

Test1Holder

Beispiel

<<interface>> Test2Helper

charToString()

<<interface>>Test2

Test1Helpernarrow() narrow()insert()extract()

insert()extract()

Test2Operations



Erzeugte Java-Schnittstellen

➥ Beispiel/Test1Operations.java:

package Beispiel;

public interface Test1Operations {

void setName (String name);

double getXY (org.omg.CORBA.DoubleHolder y);

int encrypt (String key,

org.omg.CORBA.StringHolder msg);

}

➥ Beispiel/Test2Operations.java:

package Beispiel;

public interface Test2Operations {

String charToString (char c1, char c2);

}



Holder-Klassen

➥ Java unterstutzt keine Ausgabeparameter

➥ daher: Ubergabe eines Objekts (per Referenz!), das denParameter enthalt (Holder -Klasse)

➥ Z.B. Code fur DoubleHolder:

public final class DoubleHolder ... {

public double value;

public DoubleHolder() {

}

public DoubleHolder(double initialValue)

value = initialValue;

}

...

}



Helper-Klassen

➥ Hilfsmethoden fur CORBA-Objekte

➥ Ausschließlich static-Methoden:

➥ narrow(): Typumwandlung (Down cast), wandelt generische

CORBA Objektreferenz in konkrete Java Objektreferenz um

➥ insert(): packt Objekt in Datentyp org.omg.CORBA.Any

➥ extract(): extrahiert Objekt aus org.omg.CORBA.Any

➥ id(): Schnittstellen-ID fur Interface-Repository

➥ read(): Lesen eines Objekts aus einem Eingabestrom

➥ write(): Schreiben eines Objekts in einen Ausgabestrom



Abgeleitete Datentypen

➥ OMG IDL erlaubt Definition abgeleiteter Datentypen

➥ Interfaces (Objekte)

➥ Sequenzen und Arrays

➥ Strukturen (Struct)

➥ Aufzahlungen (Enum)

➥ Vereinigungen (Union)

➥ Daneben: Typdefinitionen (Typedefs)

➥ Syntax / Semantik stark an C/C++ angelehnt



Typdefinitionen (Typedefs)

➥ IDL erlaubt es, neue Namen fur existierende Typen zu definieren

➥ auf allen Ebenen (global, Modul, Schnittstelle)

➥ Beispiele:

typedef short Temperatur; // neuer Typname: Temperatur

typedef Test2 MyTest;

➥ CORBA legt nicht fest, ob neuer Typname nur Alias fur

existierenden Typ ist, oder ob neuer Typ erzeugt wird



Sequenzen

➥ Vektoren (eindimensionale Felder) variabler Lange

➥ beliebige IDL-Elementtypen

➥ Lange kann begrenzt oder unbegrenzt sein

➥ Beispiel: IDL

typedef sequence<Dog> MySeq;

typedef sequence<Dog, 60> MyBoundedSeq;

void seqtest(in MySeq par1, in MyBoundedSeq par2,

out MySeq par3);

➥ Umsetzung in Java:

void seqtest(Beispiel.Dog[] par1, Beispiel.Dog[] par2,

Beispiel.Test2Package.MySeqHolder par3);



Arrays

➥ Ein- oder mehrdimensionale Felder fester Lange

➥ Beispiel: IDL

typedef Dog MyArray[60];

typedef Dog My2DArray[60][10];

void arraytest(in MyArray par1, in My2DArray par2,

out MyArray par3);


void arraytest(Beispiel.Dog[] par1,

Beispiel.Dog[][] par2,

Beispiel.Test2Package.MyArrayHolder par3);



Strukturen (Structs)

➥ Zusammenfassung von mehrerer Variablen

➥ entspricht Klasse mit public-Attributen ohne Methoden

➥ Beispiel: IDL

struct MyStruct {

short age;

string name;

};


public final class MyStruct {

public short age = (short)0;

public String name = null;

public MyStruct() {}

public MyStruct(short _age,

String _name) {

age = _age; name = _name;

}

}



Aufzahlungen (Enums)

➥ Neuer Typ mit explizit aufgezahlten Werten

➥ Beispiel: IDL

enum Color { red, green, blue };


➥ Klasse Color mit

➥ static final-Attributen fur die Werte➥ als int-Wert (z.B. red) und als Color-Objekt (z.B. red)

➥ Methode value(), liefert int-Wert zuruck

➥ static-Methode from int() als Factory

➥ Verwendung z.B.:

Color mycol = Color.red;



Vereinigungen (Unions)

➥ Beschreibt Daten, die verschiedene Typen haben konnen

➥ Typ wird durch Diskriminator zur Laufzeit festgelegt

➥ Beispiel: IDL

union Animal switch (short) {

case 1: Dog dog;

case 2: Cat cat;

default: Mouse mouse;

};

➥ Umsetzung in Java: Klasse Animal mit

➥ Methode discriminator() fur Diskriminator

➥ Get- und Set-Methoden fur die Felder des Union➥ prufen bzw. setzen auch Diskriminator-Wert



Attribute

➥ In einem Interface konnen auch Attribute definiert werden:

➥ attribute string name;

readonly attribute long age;

➥ deklariert werden damit letztendlich nur Zugriffsmethoden zum

Lesen und ggf. auch zum Schreiben

➥ Erzeugte Java-Schnittstelle im Beispiel:

String name ();

void name (String newName);

int age ();



Konstanten

➥ Konstanten konnen auf globaler, auf Modul- oder aufInterface-Ebene definiert werden

➥ unterschiedlicher Gultigkeitsbereich

➥ Beispiel zur Syntax:

interface Test2 {const short maxItems = 40;const string myName = "Roland";

...

➥ Abbildung nach Java:

public interface Test2 extends Test2Operations ... {

public static final short maxItems = (short)(40);public static final String myName = "Roland";

}



Exceptions

➥ IDL erlaubt Definition eigener Exceptions

➥ daneben: jede Methode kann (implizit) eine Reihe vonSystem-Exceptions werfen, z.B. Marshaling-Fehler

➥ Beispiel:

exception SyntaxError {

unsigned short position;

};

void parse(in string command) raises (SyntaxError);


void parse (String command)

throws Beispiel.Test2Package.SyntaxError;

➥ plus Exception-Klasse SyntaxError, analog zu Struct



Vererbung

➥ Methoden und Attribute von Schnittstellen konnen vererbt werden

➥ auch Mehrfachvererbung moglich

➥ kein Uberladen / Uberschreiben von Methoden erlaubt

➥ Beispiel:

interface Animal {

attribute short age;

void eat(in string what);

};

interface Dog : Animal {

string bark();

};


short age()void age(short)void eat(String)

AnimalOperations

Animal

String bark()

DogOperations

Dog



Vererbung ...

➥ Methoden der Basisklasse org.omg.CORBA.Object (Java

Bindings):

➥ _is_a(): implementiert Objekt gegebenes Interface?

➥ _non_existent(): zugehoriges Server-Objekt zerstort?

➥ _is_equivalent(): verweisen zwei Referenzen auf dasselbe

Objekt? (soweit ORB das einfach bestimmen kann)

➥ _hash(): Hashwert der Objektreferenz

➥ _duplicate() / _release(): Kopie bzw. Freigabe einer

Objektreferenz (i.a. keine Garbage Collection im ORB)

➥ _get_interface_def(): liefert Schnittstellenbeschreibung aus

Interface Repository

➥ _create_request(): erzeugt Request fur DII



Parameterubergabe-Semantik

➥ Alle Parametertypen außer Interfaces: call-by-value

➥ Methoden durfen in-Parameter jedoch nicht verandern

➥ Verhalten ist sonst undefiniert

➥ IDL unterstutzt spezielle Typdeklarationen (valuetype), umObjekte zu definieren, die per Wert ubergeben werden

➥ analog zu interface, aber mit Angabe echter Attribute(State Variables)

➥ Interfaces: call-by-reference

➥ ubergeben wird die Objektreferenz (kein narrow() notig)

➥ IDL unterstutzt auch abstrakte Interfaces

➥ konnen von valuetype und interface geerbt werden

➥ damit: Ubergabesemantik erst zur Laufzeit festgelegt

3.4 CORBA im Detail ...


3.4.2 Name Service

➥ Der CORBA Namensdienst definiert einen hierarchischen

Namensraum

Object Name

Naming Context

Ixtapa Playa BlancaCancun

Resorts

Greece HawaiiMexico

Hyatt Club Med

➥ Aufbau eines Namens:

Context Name Simple NameContext Name Context NameResorts CancunClub MedMexico

3.4.2 Name Service ...


➥ Darstellung von Namen (in IDL):

struct NameComponent {

string id; // Eigentlicher Name

string kind; // Typ (analog zu Dateiendungen)

};

typedef sequence<NameComponent> Name;

➥ Wichtige Methoden des Namensdienstes (NamingContext)

➥ bind() / rebind() : Binden von Objektnamen

➥ bind_context() / rebind_context() : Binden eines NamingContext unter einem (Kontext-)Namen

➥ new_context() : Erzeugen eines Naming Context

➥ unbind() : Namen entfernen

➥ list() : Ausgabe aller Namen

➥ resolve() : Namen in Objekt auflosen



➥ Erweiterte Schnittstelle NamingContextExt

➥ von NamingContext abgeleitet

➥ erlaubt u.a. Verwendung von Pfadnamen in Stringform

➥ z.B.: a/.c /d.e kind

id

NameComponent

➥ wichtige Methoden:

➥ to_name() : wandelt Namen in Stringform in eine Sequenzvon NameComponents um

➥ resolve_str() : entspricht resolve(to_name("name"))

➥ (Java-)Referenz auf Wurzel-Naming Context :

NamingContextExt nc = NamingContextExtHelper.narrow(

orb.resolve_initial_references("NameService"))



Beispiel

➥ Registrierung eines Objekts in einem neuen Kontext:

NamingContextExt nc = NamingContextExtHelper.narrow(


// Erzeugen und Binden des Naming Contexts

nc.rebind_context(nc.to_name("Hello"),

nc.new_context());

// Binden der Objektreferenz an hierarchischen Namen

nc.rebind(nc.to_name("Hello/HelloWorld"), objRef);

➥ Auflosen des Namens (ohne NamingContextExt):

NameComponent path[] = { new NameComponent("Hello",""),

new NameComponent("HelloWorld", "") };

Hello obj = HelloHelper.narrow(nc.resolve(path));



3.4.3 Factories

➥ Eine Factory kann auch eine Referenz auf ein neues CORBA-Objekt zuruckliefern, das durch einen eigenen Servant

implementiert wird

➥ Die Factory-Methode muß dazu:

➥ einen neuen Servant erzeugen

➥ diesen mit servant to reference() beim POA registrieren

➥ die CORBA-Referenz mit narrow() in eine Java-Referenz

umwandeln und als Ergebnis zuruckliefern

➥ Eine Referenz auf den POA kann man u.a. uber die von derKlasse org.omg.PortableServer.Servant geerbten Methoden

default POA() oder poa() erhalten

➥ Beispiel: siehe WWW

http://www.bs.informatik.uni-siegen.de/web/wismueller/vl/gen/csp/code/CORBA/HELLO_FACTORY.zip

3.4.3 Factories ...


Beispiel: IDL-Datei

module HelloWorld

{

// Schnittstelle der Objekte, werden vom Client uber Factory erzeugt

interface Hello

{

string sayHello();

};

// Schnittstelle des Factory−Objekts

interface HelloFactory

{

Hello createHello(in string name);

};

};

3.4.3 Factories ...


Beispiel: Client (Ausschnitt)

// Resolve the object reference in naming


HelloFactory fact = HelloFactoryHelper.narrow(

ncRef.resolve(path));

// Erzeuge Objekte uber Factory

Hello helloRef = fact.createHello("Klaus");

Hello helloRef2 = fact.createHello("Uwe");

// Rufe Methode fur jedes Objekt auf

System.out.println(helloRef.sayHello());

System.out.println(helloRef2.sayHello());

3.4.3 Factories ...


Beispiel: Factory-Implementierung im Server

class HelloFactoryServant extends HelloFactoryPOA {

public HelloFactoryServant() {

}

public Hello createHello(String name) {

try {

HelloServant helloRef = new HelloServant(name);

org.omg.CORBA.Object ref =

_poa().servant_to_reference(helloRef);

return HelloHelper.narrow(ref);

} catch(...) { ... }

}

}



3.4.4 Delegation und Tie-Klassen

➥ In der Regel: Objekt-Implementierung erweitert die vom

IDL-Compiler erzeugte POA-Klasse, z.B.:

public class HelloImpl extends HelloPOA {

public String sayHello(String Name) {

...

➥ Falls dies nicht moglich ist: IDL-Compiler kann Tie-Klasse

erzeugen, die Aufrufe delegiert

➥ Objekt-Implementierung muß nur noch die Schnittstelle

implementieren, z.B.:

public class HelloImpl implements HelloOperations {

public String sayHello(String Name) {

...

3.4.4 Delegation und Tie-Klassen ...


Aufbau der Tie-Klasse

public class HelloPOATie extends HelloPOA{

private HelloOperations _delegate;public HelloPOATie(HelloOperations delegate) {_delegate = delegate;

}// this() registriert den Servant auch beim RootPOA

public HelloWorld.Hello _this() {return HelloWorld.HelloHelper.narrow(_this_object());

}...public java.lang.String sayHello(java.lang.String Name) {return _delegate.sayHello(Name);

}}



Server-Programm mit Tie-Klasse


HelloImpl helloImpl = new HelloImpl();

HelloPOATie helloTie = new HelloPOATie(helloImpl);

Hello href = helloTie._this();

POA rootpoa = POAHelper.narrow(

orb.resolve_initial_references("RootPOA"));

rootpoa.the_POAManager().activate();

NamingContextExt ncRef = NamingContextExtHelper.narrow(

orb.resolve_initial_references("NameService"));

ncRef.rebind(ncRef.to_name("HelloWorld"), href);

orb.run();



Beispiel: Vererbung der Implementierung

➥ IDL-Schnittstelle:

module HelloWorld

{

interface Hello

{

string myName();

string sayHello(in string Name);

};

interface HelloToo : Hello

{

string sayHelloToo();

};

};



Beispiel: Vererbung der Implementierung ...

➥ Klassendiagramm der Implementierung:

String sayHello(String)

String myName()

HelloOperations

HelloHelloPOA

HelloToo

String sayHelloToo()

HelloTooOperations

HelloTooPOA

_delegate

_delegateHelloPOATie

HelloImpl

HelloTooImpl

HelloTooPOATie



3.4.5 Statische und dynamische Aufrufe

➥ Statische Aufrufe:

➥ schnittstellenspezifische Stubs und Skeletons werden zur

Ubersetzungszeit aus IDL generiert

➥ Dynamic Invocation Interface (DII):

➥ erlaubt dem Client Methoden aufzurufen, ohne daß

Schnittstelle zur Ubersetzungszeit bekannt sein muß

➥ fur generische Clients, z.B. Property-Editor, graphische

Entwicklungsumgebung

➥ Information zur Schnittstelle kann zur Laufzeit z.B. uber

Interface Repository gewonnen werden

➥ Client muß Request explizit erzeugen und absenden

➥ auch asynchrone Aufrufe moglich

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (5/15) vi

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

30.10.2017

3.4.5 Statische und dynamische Aufrufe ...


➥ Dynamic Skeleton Interface (DSI):

➥ ermoglicht Objekt-Implementierungen, die zur Ubersetzungs-

zeit die Schnittstelle nicht kennen, z.B.:

➥ Interpreter, Debugger, dynamisch getypte Sprachen wie

Lisp

➥ generische CORBA-Schnittstelle fur Objekte einer

objektorientierten Datenbank

➥ generische Proxies (in Verbindung mit DII)

➥ Objektadapter reicht alle Aufrufe an dieselbe Methode

invoke() der Objektimplementierung weiter

3.4.5 Statische und dynamische Aufrufe ...


Beispiel fur dynamischen Methodenaufruf uber DII

NVList argList = orb.create_list(1); // Argumentliste aufbauen

Any arg = orb.create_any();arg.insert_string("Roland");NamedValue nv = argList.add_value("name", arg, ARG_IN.value);

Any res = orb.create_any(); // Ergebnisobjekt erzeugen

res.insert_string("");NamedValue resv = orb.create_named_value("result", res,

ARG_OUT.value);

// Request erzeugen: result = sayHello(name)

Request req = helloRef._create_request(null, "sayHello",argList, resv);

req.invoke(); // Request ausfuhren

// Alternativ: req.send deferred(); ...; req.get response();

String s = res.extract_string(); // Ergebnis extrahieren



3.4.6 Portable Object Adapter (POA)

➥ Komponenten des POA-Modells:

➥ Servant :

➥ laufende Instanz einer Objektimplementierung

➥ Lebenszeit von Servant und Objekt entkoppelt, Objekt ggf.

nacheinander durch mehrere Servants realisiert➥ Servant kann mehrere Objekte implementieren

➥ Objekt-ID:

➥ im Bereich eines POA eindeutige ID

➥ zur Zuordnung von Anfragen an Servants

➥ Objektreferenz:

➥ enthalt eindeutige ID des POA und Objekt-ID

➥ zusatzlich ggf. Ort des Servers / POAs, ...

3.4.6 Portable Object Adapter (POA) ...


➥ Komponenten des POA-Modells: ...

➥ POA:

➥ Namensraum fur Objekt-IDs

➥ bildet Objekt-IDs auf Servants ab

➥ bestimmt uber POA Policies das Verhalten der von ihm

verwalteten Servants

➥ Active Object Map:

➥ Abbildung von Objekt-IDs auf Servants

➥ aktives Objekt: Objekt-ID steht in Active Object Map

➥ aktiver Servant : ist in Active Object Map eingetragen

➥ Default Servant :

➥ bearbeitet Anfragen fur inaktive Objekte

➥ muß bei Bedarf von der Anwendung registriert werden



➥ Komponenten des POA-Modells: ...

➥ Servant Manager :

➥ kann bei Bedarf von der Anwendung registriert werden

➥ ubernimmt bei Anfragen an inaktive Objekte ggf.:

➥ Aktivierung eines neuen Servants

➥ Zuordnung der Objekt-ID zu vorhandenem Servant

➥ POA Manager :

➥ kapselt Zustand von POAs

➥ kann POA aktivieren oder veranlassen, daß Anfragen

(temporar) zwischengespeichert oder verworfen werden

➥ Adapter Activator :

➥ aktiviert (Kind-)POA, wenn Server Anfrage an nichtexistie-

renden POA erhalt



POA-Architektur

Servant−ZeigerObjektreferenz

Servant

ServantManager

Default Servant

Object IDObject IDObject ID

POA A

Servant

Servant

Servant

Servant

DefaultServant

POAManager

AdapterActivator Adapter Activator

Servant

Object IDActive Object Map

POARoot

Servant Manager

Object IDObject ID

POA B

POA CObject ID



POA Policies

➥ Thread Policy : Multithreading im Server?

➥ SINGLE THREAD MODEL: POA ruft Methoden eines Servants

sequentiell auf

➥ ORB CRTL MODEL: implementierungsspezifisch, mehrere

Threads erlaubt

➥ Lifespan Policy : Lebensdauer der Objekte

➥ TRANSIENT: Objekte leben nur so lange wie POA

➥ PERSISTENT: Objekte konnen langer leben wie POA

➥ POA mit gegebenem Namen; bei Server-Neustart:

➥ Server muß wieder ursprunglichen Port benutzen

➥ Server muß POA gleichen Namens erzeugen

➥ (nicht: Objektzustand wird persistent gespeichert)



POA Policies ...

➥ Object ID Uniqueness Policy

➥ UNIQUE ID: nur eine Objekt-ID pro Servant

➥ MULTIPLE ID: mehrere Objekt-IDs pro Servant erlaubt

➥ ID Assignment Policy : wer erzeugt Objekt-IDs?

➥ USER ID: Anwendung, SYSTEM ID: POA

➥ Request Processing Policy

➥ USE ACTIVE OBJECT MAP ONLY: Objekt-IDs werden nur uberActive Object Map (AOM) auf Servants umgesetzt

➥ USE DEFAULT SERVANT: Wenn Objekt-ID nicht in AOM ist:Anfrage an registrierten Default Servant leiten

➥ USE SERVANT MANAGER: Wenn Objekt-ID nicht in AOM ist: uberregistrierten Servant Manager neuen Servant erzeugen



POA Policies ...

➥ Servant Retention Policy

➥ [NON ]RETAIN: Servants werden [nicht] in AOM aufgenommen

➥ Implicit Activation Policy

➥ IMPLICIT ACTIVATION: implizite Aktivierung von Servants

durch POA, z.B. bei

➥ POA.servant to reference(), POA.servant to id()

➥ ggf. Typkonvertierung von Servant nach Objektreferenz

➥ NO IMPLICIT ACTIVATION: Servant muß explizit aktiviert

werden

➥ POA.activate object(): POA generiert Objekt-ID

➥ POA.activate object with id(): Anwendung generiert

Objekt-ID



Standard-Policy des Root-POA

➥ Thread Policy : ORB CRTL MODEL

➥ Lifespan Policy : TRANSIENT

➥ Object ID Uniqueness Policy : UNIQUE ID

➥ ID Assignment Policy : SYSTEM ID

➥ Request Processing Policy : USE ACTIVE OBJECT MAP ONLY

➥ Servant Retention Policy : RETAIN

➥ Implicit Activation Policy : IMPLICIT ACTIVATION

➥ Policy kann nicht geandert werden, ggf. muß neuer POA erzeugt

werden



Beispiel: Leichtgewichtige Objekte ...

➥ Objekte mit”kleinem“ Zustand

➥ Attribute konnen in Objekt-ID eincodiert werden

➥ Alle Objekte werden durch einen einzigen (Default-)Servant

realisiert

➥ Vorteil: Skalierbarkeit

➥ geringer Ressourcenverbrauch beim Server

➥ Anmerkung: mit DSI kann ein einziger Servant sogar Objekte

unterschiedlicher Klassen implementieren ...

➥ Vollstandiger Code: siehe WWW

http://www.bs.informatik.uni-siegen.de/web/wismueller/vl/gen/csp/code/CORBA/DEF_SERVANT.zip



3.4.7 GIOP, IIOP und IOR

➥ Seit CORBA 2.0: Kommunikationsprotokoll zwischen Objekten

bzw. ORBs ist standardisiert

➥ GIOP: General Inter-ORB Protocol

➥ Spezifikation, wie Protokolle auszusehen haben

➥ IIOP: Internet Inter-ORB Protocol

➥ konkretes Protokoll auf Basis von TCP/IP

➥ Damit: Interoperabilitat zwischen verschiedenen ORB-Implemen-

tierungen

➥ IOR: Interoperable Object Reference

➥ Aufbau von Objektreferenzen ist ebenfalls standardisiert

3.4.7 GIOP, IIOP und IOR ...


GIOP

➥ Spezifiziert unter anderem:

➥ Annahmen uber Transportschicht

➥ verbindungsorientiert, duplex, zuverlassig, stromorientiert

➥ binares Ubertragungsformat fur IDL-Datentypen

➥ CDR: Common Data Representation

➥ unterstutzt Little-Endian und Big-Endian

➥ uber Tag, Empfanger konvertiert bei Bedarf

➥ keine Typ-Tags, d.h. Empfanger muß Datentyp kennen

(Problem ggf. bei dynamischen Aufrufen)

➥ acht Nachrichtenformate

➥ Request, Reply, CloseConnection, ...



IIOP und IOR

➥ Implementierung des GIOP auf Basis von TCP/IP

➥ Hauptaufgabe: Festlegung des konkreten Aufbaus von IORs

➥ Genereller Aufbau einer IOR:

Verb. ...Obj.KeyRepository ID(standardisiert)

Verbindungsendpunkt(standardisiert) (proprietär)

Object−Key

➥ Object-Key enthalt Objekt-ID und POA-Namen

➥ mehrere Eintrage fur Verbindungsendpunkt / Object-Key

moglich, damit z.B.

➥ Objekt uber verschiedene GIOP-Protokolle erreichbar

➥ Objekt mehrfach vorhanden (Lastausgleich, Fehlertoleranz)



IIOP und IOR ...

➥ Verbindungsendpunkt bei IIOP: Host / IP-Adresse und Port

➥ Beispiel fur Inhalt einer IOR

Host: 141.99.179.102 Port: 33523 Object key (URL): StandardNS/NameServer−POA/_root Object key (hex): 0x53 74 61 6E 64 61 72 64 4E 53 2F 4E 61 6D 65 53 65 72 76 65 72 2D 50 4F 41 2F 5F 72 6F 6F 74

TypeId : IDL:omg.org/CosNaming/NamingContextExt:1.0TAG_INTERNET_IOP Profiles: Profile Id: 0 IIOP Version : 1.2

➥ Formatiert mit dem dior-Tool des JacORB



Nutzung von IORs

➥ IORs in String-Form konnen beliebig zwischen Objekten

ausgetauscht werden, z.B.

➥ als Methoden-Parameter oder -Ergebnis

➥ uber Dateien, WWW, ...

➥ Damit: Objekte konnen auch ohne Name Service bekanntgege-

ben werden

➥ Relevante Methoden (in Klasse ORB):

➥ object_to_string() : Erzeugt String-Form einer CORBA-

Objektreferenz

➥ string_to_object() : Wandelt String wieder in CORBA-

Objektreferenz um



3.4.8 Implementation Repository (IMR)

➥ ORBs unterstutzen typischerweise zwei Methoden, wie IORs an

Servants gebunden werden:

➥ direktes Binden: IOR enthalt Host/Port des Servers, in dem

Servant lauft

➥ indirektes Binden: IOR enthalt Host/Port eines externen

Brokers, d.h. des IMR

➥ IMR kennt Ort (Host/Port) des Servers

➥ IMR unterstutzt u.a.:

➥ automatischer Server-Startup

➥ Migration von Servern bzw. Objekten

➥ automatischer Lastausgleich

3.4.8 Implementation Repository (IMR) ...


➥ CORBA Spezifikation standardisiert nur Interaktion zwischen

Clients und IMR

➥ ausreichend um Interoperabilitat zu sichern

➥ Realisierung und Funktionsumfang des IMR sowie Schnittstelle

zu Servern ist ORB-spezifisch



Beispiel: Automatischer Server-Start

Objektreferenz

Client

23

7

5

6IDL:HelloWorld/Hello:1.0 frodo:2133 myPOA:hello1

4

LOCATION_FORWARD

[bilbo:1799]

1sayHello()

[myPOA:hello1]

hello1

myPOA

Server (bilbo: 1799)

rsh bilbo java HelloServer

ready

Reply von

sayHello()

[myPOA:hello1]

sayHello()

[myPOA,

bilbo: 1799]

HelloWorld

gandalf: 1234

Server−Tabelle

Implementation Repository (frodo:2133)

myPOA rsh bilbo java HelloServer

PrintTest

bilbo:1799



Beispiel: Automatischer Server-Start ...

1. Client ruft Methode uber IOR auf, Anfrage wird an IMR geleitet

2. IMR sieht in Server-Tabelle nach, ob POA existiert.

Falls nicht, wird Server (mit POA) gestartet

3. Server sendet Fertig-Meldung an IMR, mit Host/Port.

IMR tragt Information in Server-Tabelle ein

4. IMR konstruiert neue IOR, die Host/Port des Servers enthalt

und sendet LOCATION FORWARD-Nachricht an Client

5. Client sendet Anfrage zum zweiten Mal, diesmal an Server

6. Server findet POA uber POA-Namen. POA findet passenden

Servant uber Objekt-ID und ruft Methode auf

7. Ergebnis wird an Client zuruckgegeben



3.4.9 Interface Repository (IR)

➥ Online”Datenbank“ mit Schnittstellenbeschreibungen

➥ CORBA spezifiziert nur Zugriffsmethoden (lesen / schreiben)

➥ Implementierung ist ORB-spezifisch

➥ ebenso, wie IDL-Spezifikationen in das IR kommen

➥ IR nutzlich u.a. fur:

➥ Typprufung der Parameter durch den ORB (auch bei DII)

➥ Verbindung mehrerer ORBs

➥ Metadaten fur Clients und Server (fur DII, DSI)

➥ z.B. Klassenbrowser, Anwendungsgeneratoren, ...

➥ selbstbeschreibende Objekte (Introspection)

3.4.9 Interface Repository (IR) ...


Wichtige Klassen und Methoden

➥ IR definiert Klassen (genauer: Schnittstellen) fur alle

IDL-Konstrukte, z.B.:

➥ ModuleDef, InterfaceDef, OperationDef, ParameterDef, ...

➥ Objekte der Klassen enthalten einander, entsprechend der

Verschachtelung in der IDL

➥ Basisklassen Container und Contained

➥ InterfaceDef enthalt mehrere OperationDefs, ...

➥ Von Contained erbt jede Klasse die Methode describe()

➥ liefert Beschreibung des IDL-Konstrukts als Struct

➥ z.B. struct OperationDescription enthalt Name, Re-

pository-ID, Ergebnistyp, Parameterliste, Exceptions, ...

3.4.9 Interface Repository (IR) ...


Startpunkte fur die IR-Information

➥ Methode _get_interface_def() liefert InterfaceDef einesObjekts:

Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));

org.omg.CORBA.Object c = helloRef._get_interface_def();

org.omg.CORBA.InterfaceDef id =

org.omg.CORBA.InterfaceDefHelper.narrow(c);

➥ Methode lookup_id() des IR liefert IR-Objekt zu einer

Repository-ID

➥ Repository-ID beschreibt IDL-Element eindeutig, z.B. im

Hello-World-Beispiel:

➥ IDL:HelloWorld/Hello:1.0 fur Interface Hello

➥ IDL:HelloWorld/Hello/sayHello:1.0 fur Operation



3.4.10 Sicherheit

➥ CORBA-Spezifikation enthalt Security Attribute Service

➥ Basis ist GIOP uber (z.B.) SSL/TLS

➥ sichert Vertraulichkeit/Integritat der Nachrichten

➥ sichert Authentifizierung des Servers

➥ Security Attribute Service realisiert zusatzlich:

➥ Authentifizierung des Clients

➥ u.a. uber Benutzername und Paßwort

➥ Weitergabe von Sicherheitsattributen (z.B. Identitat,

Privilegien) des Clients an den Server

➥ damit: Delegation von Rechten moglich, d.h. Server kann

fur Benutzer agieren

3 CORBA ...


3.5 Zusammenfassung

➥ CORBA definiert ein verteiltes, sprach- und plattform-unabhangi-

ges Objektmodell

➥ standardisiertes Protokoll (GIOP, IIOP) stellt Interoperabilitat

sicher

➥ Zentral: Schnittstellenbeschreibung uber OMG IDL

➥ automatische Erzeugung von Stubs und Skeletons

➥ Keine 1-zu-1 Beziehung zwischen Objekten und Objektimple-

mentierungen (Servants)

➥ POA kann unterschiedliche Policies realisieren

➥ CORBA spezifiziert Schnittstellen zu etlichen Diensten

➥ Namensdienst, Ereignisdienst, Lebenszyklus, ...



4 RMI / IIOP

4 RMI / IIOP ...


Inhalt

➥ RMI uber IIOP

➥ Farley, Crawford, Flanagan: S. 88ff, Kap. 7

➥ http://java.sun.com/j2se/1.5.0/docs/guide/rmi-iiop

http://java.sun.com/j2se/1.5.0/docs/guide/rmi-iiop

4 RMI / IIOP ...


RMI uber IIOP

➥ Ziel:

➥ Verbindung von Java-RMI Objekten mit nicht-Java (CORBA)

Objekten

➥ Vorgehensweise:

➥ RMI nutzt CORBA IIOP-Protokoll zur Kommunikation

zwischen Objekten

➥ Damit:

➥ Java-Client kann CORBA Objekt uber RMI nutzen

➥ CORBA-Client kann RMI-Objekt uber CORBA nutzen

4 RMI / IIOP ...


Vorgehen zur Nutzung von RMI/IIOP

➥ Basisklasse: Remote-Objekte mussen von

javax.rmi.PortableRemoteObject erben statt von

java.rmi.server.UnicastRemoteObject

➥ RMI Compiler: Stubs und Skeletons mussen uber rmic -iiop

erzeugt werden

➥ Option -idl erzeugt zusatzlich OMG IDL Datei

➥ Namensdienst: statt RMI Registry muß JNDI benutzt werden,

um auf CORBA-Namensdienst zuzugreifen

➥ Downcast: vom Namensdienst erhaltene Objektreferenzen

mussen uber PortableRemoteObject.narrow() in gultige

Referenzen umgewandelt werden

4 RMI / IIOP ...


Beispiel:”Gemischtes“ Hello World

➥ Server mit RMI realisiert

➥ Schnittstelle:

import java.rmi.Remote;

import java.rmi.RemoteException;

public interface Hello extends Remote

{

String sayHello(String to) throws RemoteException;

}

➥ Client wahlweise mit RMI oder CORBA

4 RMI / IIOP ...


Server-Code

import javax.naming.*;import java.rmi.*;import java.util.*;import javax.rmi.PortableRemoteObject;

public class HelloServer extends PortableRemoteObjectimplements Hello {

public HelloServer() throws RemoteException {super();

}

public String sayHello(String to) {System.out.println("Hello-Server called");return "Hello World to " + to + "!";

}

4 RMI / IIOP ...


Server-Code ...

public static void main(String args[]) {try {

// Server−Objekt erzeugen

HelloServer obj = new HelloServer();

// Referenz uber JNDI beim Namensdienst registrieren

Properties props = new Properties();props.put("java.naming.factory.initial",

"com.sun.jndi.cosnaming.CNCtxFactory");props.put("java.naming.provider.url",

"iiop://bspc02:5555");Context ctx = new InitialContext(props);ctx.rebind("HelloWorld", obj);

}catch (Exception e) { ... }

} }

4 RMI / IIOP ...


RMI Client

public static void main(String args[]) {try {

// Obektreferenz uber JNDI vom Namensdienst besorgen

Properties props = new Properties();props.put(Context.INITIAL_CONTEXT_FACTORY,

"com.sun.jndi.cosnaming.CNCtxFactory");props.put(Context.PROVIDER_URL, "iiop://bspc02:5555");Context ctx = new InitialContext(props);Hello obj = (Hello)

PortableRemoteObject.narrow(ctx.lookup("HelloWorld"),Hello.class);

// Remote Methode aufrufen

System.out.println(obj.sayHello("Roland"));}catch (Exception e) { ...}

}

4 RMI / IIOP ...


CORBA Client

public static void main(String args[]) {try{

// ORB erzeugen und initialisieren


// Root naming context holen

org.omg.CORBA.Object ns =orb.resolve_initial_references("NameService");

NamingContextExt ncRef = NamingContextExtHelper.narrow(ns);// Objektreferenz vom Namensdienst besorgen

NameComponent path[] = ncRef.to_name("HelloWorld");Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));

System.out.println(helloRef.sayHello("Peter"));}catch(Exception e) { ... }

}

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (6/15) vii

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

03.11.2017

4 RMI / IIOP ...


Code-Erzeugung mit RMI-Server / CORBA-Client

Client−Seite Server−Seite

javac

Hello.class HelloServer.class

HelloServer.javaHello.java

javac

HelloClient.class

HelloClient.java

HelloOperations.java

HelloHolder.java

_HelloStub.java

idlj

_HelloServer_Tie.class

_Hello_Stub.class

HelloHelper.java

Hello.java

rmic −iiop −idl

...

Hello.idl



5 Java Komponenten-Modelle

5 Java Komponenten-Modelle ...


Inhalt

➥ Komponenten-Modelle

➥ Java Beans

➥ Enterprise Java Beans (EJB 3)

➥ Burke / Monson-Haefel

➥ Farley / Crawford / Flanagan, Kap. 6 (EJB 2.1!)

➥ Orfali / Harkey, Kap. 27-34 (EJB 2.1!)

➥ Sriganseh / Brose / Silverman

➥ http://docs.oracle.com/javase/7/docs/api/java/beans/

package-summary.html

➥ http://docs.oracle.com/javaee/6/tutorial/doc

http://docs.oracle.com/javase/7/docs/api/java/beans/package-summary.html

http://docs.oracle.com/javase/7/docs/api/java/beans/package-summary.html

http://docs.oracle.com/javaee/6/tutorial/doc



5.1 Komponenten-Modelle

➥ Was sind Software-Komponenten?

Software-Komponenten sind ausfuhrbare Software-Einheiten,die unabhangig hergestellt, erworben und konfiguriert werden undaus denen sich funktionierende Gesamtsystemezusammensetzen lassen.

➥ Im Vordergrund: Zusammensetzungsaspekt

➥ Eine Komponente ist:

➥ eine funktional und technisch abgeschlossene, ausfuhrbare

Einheit

➥ unabhangig als Einheit entwickelbar und konfigurierbar

➥ wiederverwendbar

➥ nur uber genau festgelegte Schnittstellen ansprechbar

5.1 Komponenten-Modelle ...


Begriffe

➥ Visuelle Komponente

➥ stellt etwas auf dem Bildschirm (der Anwendung) dar

➥ Nichtvisuelle Komponente

➥ ist fur Benutzer der Anwendung nicht sichtbar

➥ Komponentenmodell: definiert

➥ Architektur der Komponenten u. Struktur ihrer Schnittstellen

➥ Mechanismen zur Zusammenarbeit mit Container undanderen Komponenten

➥ Container: Ausfuhrungsumgebung fur Komponenten

➥ Kontext, in dem Komponenten gruppiert und miteinanderverbunden werden

➥ stellt Management- und Kontroll-Dienste zur Verfugung



Software-Entwicklung mit Komponenten

➥ Zwei Arten von Programmierern:

➥ Komponenten-Entwickler (component developer )

➥ implementiert eine Komponente

➥ Komponenten-Anwendungsentwickler (component assembler )

➥ entwickelt eine Anwendung (oder neue Komponenten)

durch Zusammenfugen existierender Komponenten

➥ i.d.R. mit (graphischer) Werkzeug-Unterstutzung!

➥ Bei Komponenten daher zwei verschiedene Nutzungsphasen:

➥ Design Time: wahrend der Anwendungsentwicklung

➥ Run Time: wahrend der Ausfuhrung der Anwendung



Software-Entwicklung mit Komponenten: Beispiel

➥ Zusammenbau einer Komponente aus Teilkomponenten:

public class MyEventAdapter {

MyEventAdapter(TaextBean t) {

public void actionPerformed(

ActionEvent e) {

private TextBean target;

target.setValue(val);

{

target = t;

}

if (x < max)

val = x;

}

}

➥ Verwendung der Komponente in einer Anwendung:



Werkzeug-Unterstutzung (Bsp: Visual Cafe)

Anwendung mitKomponenten

Verknüpfung

Wizard zurKomponenten−

Komponenten−auswahl

Editor fürKomponenten−Eigenschaften



Vorteile eines Komponenten-Modells

➥ Wiederverwendung von Software

➥ Vereinfachte Designphase fur Anwendungen

➥ Vereinfachte Implementierungsphase fur Anwendungen

➥”Zusammenstecken“ von Komponenten

➥ Bessere Skalierbarkeit

➥ Unterstutzung durch Entwicklungswerkzeuge

➥ Ziel: Aufbau eines Markts von Komponenten



5.2 Komponentenmodelle in Java EE

➥ Java EE: Java Enterprise Edition

➥ Java EE definiert Familie von Komponentenmodellen:

➥ fur Client-Tier : JavaBeans, Applets

➥ fur Webserver-Tier : Servlets, JSP

➥ fur Anwendungsserver-Tier : Enterprise JavaBeans (EJB)

➥ Daneben bietet Java EE weitere Dienste, z.B.

➥ Namensdienst (JNDI)

➥ Nachrichten-Infrastruktur (Java Messaging Service, JMS)

➥ Datenbank-Zugriff (JDBC)

➥ Transaktionsdienste, Sicherheitsdienste, ...

5.2 Komponentenmodelle in Java EE ...


Verteilte Anwendungen mit Java EE

HTTP/SSL

HTTP/SSL

IIOPRMI/

JDBC

JDBC

RMI/IIOP

JDBC Database

Applet−Container

Standard Services

Client

Application−Client−Container

Applet Web−Container

JSP

Servlet

Standard Services Standard Services

EJB−Container

EJBJava SE

Java SE

Java SE Java SE



5.3 JavaBeans

➥ JavaBeans ist Spezifikation eines Komponentenmodells fur Java

➥ definiert mehrere neue Java-Klassen und Schnittstellen

➥ besteht aber i.W. nur aus Namenskonventionen bzw.

Entwurfsmustern

➥ Ziel: Zusammenfugen von Komponenten mit Hilfe von visueller

Programmierung

➥ graphische Werkzeuge zur Anwendungserstellung

➥ Im Prinzip ist jede Java-Klasse eine JavaBean!

➥ Kompositions- und Anpassungsfahigkeit aber nur garantiert,

wenn Konventionen eingehalten werden

➥ I.d.R. besteht eine Bean aber aus mehreren Klassen

5.3 JavaBeans ...


Was bietet eine JavaBean?

➥ Methoden

➥ wie jede andere Java-Klasse auch ...

➥ Eigenschaften (Properties)

➥ Attribute, uber die mit Get- und Set-Methoden zugegriffen

werden kann

➥ Ereignisse (Events)

➥ werden von der Bean erzeugt

➥ konnen uber Event Listener an andere Beans weitergegeben

werden

5.3 JavaBeans ...


Was bietet eine JavaBean? ...

➥ Introspektion

➥ Bean stellt uber eine BeanInfo-Klasse Information uber ihre

Methoden, Eigenschaften und Ereignisse bereit

➥ automatisch oder manuell erzeugt

➥ Anpassung (Customization)

➥ erlaubt Konfiguration der Properties uber graphische

Werkzeuge

➥ Persistenz

➥ Properties der Bean konnen dauerhaft gespeichert und bei

Erzeugung der Bean geladen werden

➥ serialisiertes Objekt in .ser-Datei

5.3 JavaBeans ...


Black-Box Sicht einer JavaBean

JavaBeanKomponenteProperties

Methoden

BeanInfo

Ereignisse

Customizer

JAR−Archiv(incl. .ser−Dateien)

5.3 JavaBeans ...


Design-Time und Run-Time-Beans

➥ Run-Time-Bean:

➥ Sammlung von Klassen mit Programmlogik

➥ plus ggf. serialisierte Objektzustande (.ser-Dateien)

➥ Design-Time-Bean:

➥ zusatzliche Klassen fur

➥ Customizer bzw. Property -Editoren

➥ Introspektion (BeanInfo)

➥ Icons fur die Bean

➥ diese Klassen und Icons werden nur von graphischenEntwicklungsumgebungen benotigt

➥ Klassen (und .ser-Dateien) sind typischerweise in einemJava-Archiv abgelegt

5.3 JavaBeans ...


JDK als Komponenten-Framework

➥ Fur JavaBeans ubernimmt JDK die Rolle des Komponenten-

Frameworks

➥ Dienste fur JavaBeans:

➥ Graphisches Layout und Darstellung

➥ fur visuelle Komponenten: AWT bzw. Swing

➥ visuelle Bean erbt von AWT Component;

AWT Container dient als Komponenten-Container

➥ Ereignismodell, Properties, Introspektion, Persistenz,

Customization

➥ Bereitstellung der benotigten Klassen / Interfaces

5.3 JavaBeans ...


Beispiel: Smiley-Bean

public class SmileyBean extends Canvas {private boolean smile = true;...public SmileyBean() {setSize(250,250);

}public synchronized void toggleSmile() {smile = !smile;repaint();

}public void paint(Graphics g) { ... }

}

➥ Vollstandiger Code: Orfali / Harkey, Kap. 28 bzw. CD-ROM

➥ SmileyBean ist lediglich eine normale Java-Klasse

5.3 JavaBeans ...


Beispiel: Container fur Smiley-Bean

public class SmileyPlace extends Frame ... {SmileyPlace() {SmileyBean smiley = null;

// instantiiere die Bean

try {smiley = (SmileyBean)Beans.instantiate(null,

"SmileyBean");}catch (Exception e) { ... }

// fuge Bean in Container ein

add(smiley);...

}static public void main(String args[]) { ... }...

5.3 JavaBeans ...


Konventionen fur Beans

➥ Beans durfen nicht mit new erzeugt werden

➥ stattdessen: Beans.instantiate(classloader, name)

➥ Beans mussen einen Default-Konstruktor (ohne Argumente)besitzen

➥ Visuelle Beans sollten von java.awt.Component (oder einerUnterklasse) abgeleitet werden

➥ Als Komponenten-Container sollte ein AWT Container dienen

➥ Hinzufugen der Beans uber die Methode add()

➥ Cast-Operationen oder instanceof sollten nicht verwendetwerden

➥ stattdessen: Beans.getInstanceOf(obj, class) bzw.Beans.isInstanceOf(obj, class)

5.3 JavaBeans ...


5.3.1 Ereignisse

➥ JavaBeans konnen Ereignisse erzeugen bzw. Ereignissebehandeln

➥ Ereignismodell: Publish-Subscribe-Modell

➥ identisch mit dem Ereignismodell des AWT

➥ Beans geben (uber Introspection) bekannt, welche Ereignissesie auslosen konnen

➥ interessierte Beans registrieren sich bei der Ereignisquelle

➥ Ereignisse sind Objekte, die von EventObject abgeleitet sind

➥ beinhalten Ereignisquelle sowie beliebige andere Parameterdes Ereignisses

➥ Namenskonvention: Klassenname muß mit Event enden

➥ z.B. ButtonEvent

5.3.1 Ereignisse ...


Ereigniskonsumenten (Event Listener)

➥ Erhalten Ereignisbenachrichtigungen

➥ Mussen Schnittstelle implementieren, die von

java.util.EventListener abgeleitet ist

➥ Namenskonvention: Ereignisname mit Endung Listener

➥ pro Ereignistyp eine Methode, ohne Namenskonvention

➥ Methode erhalt Ereignisobjekt als Parameter

➥ Beispiel (fur Ereignis ButtonEvent):

public interface ButtonListener extends EventListener {

public void onPress(ButtonEvent e);

public void onRelease(ButtonEvent e);

}



Ereignisquellen (Event Sources)

➥ Sind Beans, die Ereignisse erzeugen

➥ Ereignisse werden fur Listener uber zwei Methoden verfugbar

gemacht (Namenskonvention!):

➥ addListenerType (): Anmelden eines Listeners

➥ removeListenerType (): Abmelden eines Listeners

➥ z.B. fur ButtonEvent:

void addButtonListener(ButtonListener l)

void removeButtonListener(ButtonListener l)

➥ Ereignisquelle ist fur Verwaltung der Listener und Aufruf der

Methode zur Ereignismeldung (z.B. onPress()) verantwortlich

➥ typisch mittels Vector und Schleife uber alle Listener



Beispiel: Smiley und Button

➥ Button ist AWT-Element und auch JavaBean

➥ stellt Ereignis ActionEvent zur Verfugung:public interface ActionListener extends EventListener {

public void actionPerformed(ActionEvent e);

}

➥ Button-Ereignis soll zum Umschalten des Smiley fuhren

➥ Einfachste Realisierung:”direkte Verdrahtung“

➥ SmileyBean implementiert ActionListener-Interfacepublic class SmileyBean extends Canvas

implements ActionListener {

...

public void actionPerformed(ActionEvent e) {

toggleSmile();

}



Beispiel: Container

public class SmileyPlace extends Frame ... {

SmileyPlace() {

SmileyBean smiley = null;

Button button = null;

try { // instantiiere die Beans

smiley = (SmileyBean)Beans.instantiate(null, "SmileyBean");

button = (Button)Beans.instantiate(null, "java.awt.Button");

}

catch (Exception e) { ... }

add(smiley, "North"); // fuge Beans in Container ein

add(button, "South");

button.addActionListener(smiley); // verbinde die Beans

...

}



Ereignis-Adapter

➥ Nachteil der direkten Verdrahtung:

➥ Listener muß passende Schnittstelle implementieren

➥ widerspricht Idee, Beans uber Werkzeuge zu”verdrahten“

➥ Bean kann Ereignisse nicht a-priori kennen

➥ Code der Bean kann nicht geandert werden

➥ Abhilfe: Verwendung eines Adapters (Indirektion)

➥ Adapter implementiert passende Listener -Schnittstelleund ruft Methode in der Ziel-Bean auf

➥ Vorteile (u.a.):

➥ Beans bleiben vollstandig unabhangig voneinander

➥ Adapter kann Schnittstellen ggf. anpassen

➥ Adapter kann Ereignis auch an Remote-Objekt leiten



Beispiel: Smiley und Button

SmileyEventAdapter SmileyBean

Performed()action toggle

Smile()Toggle

Button

addActionListener()

public class SmileyEventAdapter implements ActionListener {

private SmileyBean target;

SmileyEventAdapter(SmileyBean t) {

target = t;

}

public void actionPerformed(ActionEvent e) {

target.toggleSmile();

}

}

5.3 JavaBeans ...


5.3.2 Properties

➥ Eigenschaften einer Komponente

➥ konnen zur Design-Zeit mit Entwicklungswerkzeugen

verandert werden

➥ und werden dann persistent gespeichert

➥ konnen zur Laufzeit abgefragt und/oder gesetzt werden

➥ Zugriff ausschließlich uber Get- und Set-Methoden

➥ d.h. Implementierung nicht unbedingt 1-zu-1 als Attribut

➥ Arten von Properties:

➥ einfache und Indexed Properties (d.h. Arrays)

➥ Bound und Constrained Properties

➥ Benachrichtigungs-Ereignisse bei Anderungen

5.3.2 Properties ...


Namenskonventionen fur Get- und Set-Methoden

➥ Einfache Properties (Beispiel: int Age)

➥ public int getAge();

➥ public void setAge(int value);

➥ Einfache Boole’sche Properties

➥ public boolean isMarried();

➥ public void setMarried(boolean value);

➥ Indexed Properties (Beispiel: short[] TabStops)

➥ public short[] getTabStops();

➥ public short getTabStops(int index);

➥ public void setTabStops(short[] value);

➥ public void setTabStops(int index, short value);

➥ Alle Methoden sind optional



Bound Properties

➥ Eine Bean kann Anderungen von Properties als Ereignisse an

interessierte Beans weitermelden

➥ Dazu: Bean muß Ereignis PropertyChangeEvent unterstutzen

public interface PropertyChangeListener extends EventListener {

public void propertyChange(PropertyChangeEvent e);

}

➥ D.h. Bean muß folgende Methoden besitzen:

void addPropertyChangeListener(PropertyChangeListener l)

void removePropertyChangeListener(PropertyChangeListener l)

➥ JDK bietet Klasse PropertyChangeSupport zur Verwaltung und

Benachrichtigung der Listener



Constrained Properties

➥ Wie Bound Properties, aber Listener haben die Moglichkeit, der

Anderung zu widersprechen (Veto)

➥ Dazu: Ereignis VetoableChangeEvent

public interface VetoableChangeListener extends EventListener {

public void vetoableChange(VetoableChangeEvent e);

}

➥ Listener kann in vetoableChange() eine PropertyVeto-

Exception werfen, um der Anderung zu widersprechen

➥ Hilfsklasse VetoableChangeSupport zur Verwaltung undBenachrichtigung der Listener

➥ bei Veto: Benachrichtigung abbrechen, alle Listener mitursprunglichem Wert erneut benachrichtigen, liefertPropertyVetoException an Aufrufer

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (7/15) viii

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

10.11.2017

5.3 JavaBeans ...


5.3.3 Persistenz

➥ Beans konnen wie normale Objekte serialisiert und in Dateiengespeichert werden

➥ Bean (bzw. Oberklasse) muß Schnittstelle Serializable

implementieren

➥ Beispiel:FileOutputStream fos = new FileOutputStream("Smiley.ser");

ObjectOutputStream oos = new ObjectOutputStream(fos);

oos.writeObject(smiley);

➥ Beans.instantiate(classloader, name) sucht .ser-Datei mitgegebenem Namen

➥ falls erfolgreich: erzeuge Bean mit dem serialisierten Zustandaus der Datei

➥ sonst: erzeuge”frische“ Bean der angegebenen Klasse

5.3 JavaBeans ...


5.3.4 Introspektion

➥ Uber Methode java.beans.Introspector.getBeanInfo() kannInformation uber eine Bean abgefragt werden:

➥ Methoden, Properties, Ereignisse, ...

➥ Information wird in BeanInfo-Objekt zuruckgeliefert

➥ Bean kann Information explizit bereitstellen

➥ uber eine Klasse BeanName BeanInfo (Namens-

konvention!), die BeanInfo-Schnittstelle implementiert➥ z.B. SmileyBeanBeanInfo fur SmileyBean

➥ sonst: Introspector erzeugt die Information dynamisch

➥ setzt voraus, daß sich die Bean genau an die Namens-konventionen halt

➥ Erweiterung des Java Reflection-Mechanismus

5.3.4 Introspektion ...


Information in der BeanInfo

➥ BeanDescriptor: Bean-Klasse und Customizer -Klasse

➥ Customizer ist optional; implementiert Bean-spezifische GUI

(fur Entwicklungswerkzeuge), um Eigenschaften der Bean

anzupassen

➥ PropertyDescriptor: Beschreibung der Properties

➥ Name, Typ (Klasse), Get- und Set-Methode,

Bound /Constrained Property?, ...

➥ Property Editor : optional; implementiert Bean-spezifische

Editor-Komponente (fur Entwicklungswerkzeuge) fur eine

Property (z.B. Farbe)

5.3.4 Introspektion ...


Information in der BeanInfo ...

➥ EventSetDescriptor: Beschreibung der Ereignisse

➥ Listener -Klasse, Listener -Methoden, Add und

Remove-Methoden fur Listener, ...

➥ MethodDescriptor: Beschreibung der Methoden

➥ Name, Method-Objekt (Java Reflection), Beschreibung der

Parameter, ...

➥ Icon zur Darstellung der Bean in Entwicklungswerkzeugen

➥ Default-Property und Default-Ereignis

➥ die am wahrscheinlichsten vom Benutzer eines

Entwicklungswerkzeugs ausgewahlt werden

5.3 JavaBeans ...


5.3.5 Zusammenfassung

➥ Komponentenmodell fur Java

➥ vorwiegend fur clientseitige, visuelle Komponenten

➥ Ziel: werkzeugunterstutzte Erstellung von Anwendungen

➥ Java Beans unterstutzt:

➥ Methoden

➥ Eigenschaften (Properties)

➥ auch mit Ereignismeldung/Veto bei Anderung

➥ Ereignisse (uber Listener -Interface)

➥ Introspektion (fur Werkzeuge)

➥ Anpassung (Customization) (fur Werkzeuge)

➥ Persistenz (Speicherung der konfigurierten Properties)



5.4 Enterprise Java Beans (EJB 3)

➥ Was sind Enterprise Java Beans?

➥ serverseitige Komponenten-Architektur fur Entwicklung undDeployment von komponenten-basierten verteilten

Geschaftsanwendungen

➥ d.h.: Komponenten-Modell fur Anwendungslogik einer

verteilten Anwendung

➥ EJBs werden immer in speziellem EJB-Container ausgefuhrt

➥ anwendungsunabhangiger Anwendungsserver

➥ Implementierungen von verschiedenen Anbietern

➥ z.B. JBoss, OpenEJB, IBM WebSphere, BEA WebLogic

➥ Schnittstelle zu EJBs ist standardisiert

➥ Zugriff auf EJBs erfolgt immer uber EJB-Container

5.4 Enterprise Java Beans (EJB 3) ...


Ziel der EJB-Architektur

➥ Anwendungsprogrammierer erstellt nur Anwendungslogik

➥ und zwar komponentenbasiert ...

➥ Alle wichtigen, anwendungsunabhangigen Dienste werden vom

EJB-Container realisiert

➥ Nutzung der Dienste ist implizit

➥ wird nicht ausprogrammiert

➥ Spezifikation und Konfiguration der Dienste bei Erstellung

und/oder beim Deployment der EJB

➥ EJB-Container ubernimmt Rolle eines Component Transaction

Monitors

➥ realisiert Komponentenmodell, Transaktions- und

Ressourcen-Management



Component Transaction Monitor

➥ Vereinigung von Transaktionsmonitor und ORB

➥ Aufgabe: automatisches Management von

➥ Transaktionen

➥ Persistenz von Objekten

➥ Sicherheit (insbes. Zugriffskontrolle)

➥ Ressourcenverwaltung (z.B. Pooling)

➥ Objektverteilung

➥ Nebenlaufigkeit

➥ Fokus: zuverlassige, transaktionsorientierte Anwendungen mitvielen Nutzern



Grundlegende Elemente in einer EJB-Umgebung

Anwendungs−Methoden

Antwort

EJBClient

(Anwendungs−Methoden)

Persistenz)Ressourcen−Pooling

Zugriffskontrolle(Transaktionsmanagement

EJB Container

EJB Instanzen

BusinessInterface



Das EJB 3 Programmiermodell

BusinessInterface

LokalerClient

DiensteContainer−

KlasseWrapper−

RemoteClient

EJBKlasse

SichtLokale

RemoteSicht

in der Wrapper Klasse

(1)

(1) Methoden−(8)aufruf

(8)

(2) Aufruf der Methode

(7)

EJB Container

(4) Aufruf der Methodein der Bean Klasse

(3) API−Aufrufe für Dienstevor Methodenaufruf

nach Methodenaufruf

*

i.a. als EJB Objekt bezeichnet* vom Container generiert

(6) API−Aufrufe für Dienste(5)



5.4.1 Arten von EJBs

➥ Entity Beans

➥ Daten-Objekte, die persistent (in Datenbank) gespeichert undvon mehreren Clients genutzt werden

➥ d.h. Objekte bzw. Beziehungen der Anwendungsmodellierung

➥ z.B. Kunde, Konto, Aktie, ...

➥ in EJB 3 nicht weiterentwickelt, aber weiterhin unterstutzt

➥ (im folgenden nicht mehr behandelt, siehe Skript WS07/08)

➥ Entities (ab EJB 3.0, Java Persistence API)

➥ Ziele und Aufgaben wie bei Entity Beans, aber nur lokalzugreifbar, leichtgewichtiger und besser standardisiert

➥ Persistenz wird automatisch durch Container realisiert

➥ auch unabhangig von Java EE verwendbar

5.4.1 Arten von EJBs ...


➥ Session Beans

➥ realisieren Aktionen, die mehrere Anwendungsobjekte(Entities bzw. Entity Beans) betreffen

➥ d.h. die Geschaftslogik

➥ zustandslos (stateless) oder zustandsbehaftet (stateful)

➥ d.h. merkt sich die Bean Daten zwischen zwei Aufrufeneines Clients?

➥ stateful Session Beans reprasentieren Client-Sitzungen

➥ kein persistenter Zustand

➥ Message Driven Beans (ab EJB 2.0)

➥ ahnlich wie Session Beans, aber asynchrone Schnittstelle

➥ Operationen werden uber JMS-Nachrichten aufgerufenstatt uber (entfernte) Methodenaufrufe

➥ (im folgenden nicht mehr behandelt)



5.4.2 Anatomie einer EJB-Anwendung

➥ Eine EJB-Anwendung besteht aus:

➥ Session (bzw. Message Driven) Beans fur die Anwendungs-logik

➥ Session Beans sind normale Java-Klassen mitAnnotationen

➥ Local und Remote Business Interfaces der Session Beans➥ normale Java-Interfaces, mit Annotationen➥ i.d.R. durch zugehorige Session Bean implementiert

➥ Entities (bzw. Entity Beans) fur das Datenmodell

➥ Entities sind normale Java-Klassen mit Annotationen

➥ Deployment-Deskriptoren

➥ XML-Dokumente➥ beschreiben Beans und vom Container benotigte Dienste

5.4.2 Anatomie einer EJB-Anwendung ...


➥ Mehrere Beans werden mit gemeinsamen Deployment-Deskripto-

ren in ein JAR-Archiv gepackt

➥ Deployment-Deskriptoren im Verzeichnis META-INF

➥ META-INF/ejb-jar.xml kennzeichnet Archiv als EJB Archiv

➥ EJB-Anwendung besteht aus ein oder mehreren JAR-Archiven

➥ Alle weiteren benotigten Klassen werden zur Laufzeit generiert

➥ z.B.:

➥ Wrapper -Klassen fur EBJ-Klassen bzw. Implementierungs-

klassen der Business Interfaces➥ Stub-Klassen fur die Clients

➥ Basis: generische Proxy-Klasse java.lang.reflect.Proxy

5.4.2 Anatomie einer EJB-Anwendung ...


Deployment-Deskriptoren

➥ ejb-jar.xml: fur Session Beans (und andere)

➥ kann Annotationen in den EJB-Klassen uberschreiben bzw.

erganzen

➥ z.B. Kennzeichnung als EJB, Art der EJB, Verwaltung der

EJB zur Laufzeit (Transaktionen, Zugriffskontrolle), ...

➥ Arbeitsaufteilung zwischen EJB-Entwickler (Annotationen)

und Anwendungsentwickler (Deployment-Deskriptor)

➥ persistency.xml: fur Entities

➥ analog zu ejb-jar.xml

➥ spezifiziert zusatzlich die Verbindung zur Datenbank

➥ Zusatzlich Container-spezifische Deskriptoren moglich



5.4.3 Einschub: Java Annotationen

➥ Eingefuhrt mit Java 5 (JDK 1.5)

➥ Erlauben die Spezifikation von beliebigen Metadaten fur

Programm-Elemente

➥ z.B. fur Typen, Methoden, Attribute, Parameter, Annotationen

➥ Annotationen werden vom Compiler ubersetzt und sind getypt

➥ Typdefinition ahnlich wie bei Schnittstellen

➥ Die Annotationen eines Elements konnen zur Laufzeit uber das

Reflection API abgefragt werden

➥ bei entsprechender Definition der Annotation

➥ Neben Annotationen des Java-Standards konnen auch eigene

Annotationen definiert werden

5.4.3 Einschub: Java Annotationen ...


Beispiel

➥ Definition einer Annotation:

import java.lang.annotation.*;

// Meta−Annotation: Annotation soll auch zur Laufzeit verfugbar sein

@Retention(RetentionPolicy.RUNTIME)

// Meta−Annotation: Annotation ist auf Klassen und Interfaces anwendbar

@Target(ElementType.TYPE)

// Definition der Annotation

public @interface CodeCategory {

boolean isTested();

String[] tester() default {};

boolean isReviewed() default false;

}



Beispiel ...

➥ Verwendung der Annotation:

@CodeCategory(isTested = true, tester = {"joe","max"})

public class MyClass {

// ...

}

➥ Zugriff auf die Annotation zur Laufzeit:

MyClass obj = new MyClass();

CodeCategory cat =

obj.getClass().getAnnotation(CodeCategory.class);

System.out.println("is tested: " + cat.isTested());



Anmerkungen zum Beispiel

➥ Bei Verwendung einer Annotation mussen die”Attribut“-Werte mit

der Syntax <Name: > = <Wert> angegeben werden

➥ die Reihenfolge ist dabei beliebig

➥ Ausnahme: die Annotation hat nur ein (oder gar kein) Attribut

➥ z.B. @Retention und @Target

➥ Attribute konnen auch mit Default-Werten definiert werden

➥ z.B. tester und isReviewed

➥ bei Verwendung der Annotation brauchen dann keine Werteangegeben zu werden

➥ eine leere Parameterliste kann auch ganz weggelassen werden

➥ Attribute konnen auch Arrays sein

➥ z.B. tester



5.4.4 Beispiel Hello World

Remote Business Interface

package org.Hello;

import javax.ejb.Remote;

// Java Annotation: markiert Schnittstelle als Remote EJB Interface

@Remote

public interface HelloRemote

{

public String sayHello();

}

5.4.4 Beispiel Hello World ...


EJB-Klasse

package org.Hello;

import javax.ejb.Stateless;

// Java Annotation: markiert Klasse als Stateless Session Bean

@Stateless

public class HelloImpl implements HelloRemote

{

public String sayHello()

{

return "Hallo? Jemand da?";

}

}



Deployment Deskriptor (ejb-jar.xml)

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar/>

➥”Leerer“ Deskriptor

➥ Zeigt lediglich an, daß es sich um eine EJB handelt



Client (OpenEJB)

import org.Hello.*;

import java.util.Properties;

import javax.naming.InitialContext;



try {

// Properties fur JNDI (hier: Nutzung von OpenEJB)

Properties p = new Properties();

p.put("java.naming.factory.initial",

"org.apache.openejb.client" +

".RemoteInitialContextFactory");

p.put("java.naming.provider.url",

"ejbd://127.0.0.1:4201");



Client (OpenEJB) ...

// User und Passwort sind optional!

p.put("java.naming.security.principal", "user");

p.put("java.naming.security.credentials", "password");

InitialContext ctx = new InitialContext(p);

Object obj = ctx.lookup("HelloImplRemote");

HelloRemote hello = (HelloRemote)obj;

System.out.println(hello.sayHello());

System.out.println(hello.sayHello());

}

catch (Exception e) { ... }

}

}

5.4.5 Einschub: OpenEJB


Nutzung von OpenEJB im Labor H-A 4111

➥ Private Installation (i.w. Konfigurationsdateien):

➥ Auf einem Rechner im Labor H-A 4111: Aufruf des Skripts

/opt/dist/tools/openejb_install.sh

➥ erzeugt private Verzeichnisse fur Deployment der EJBs

➥ editiert Konfigurationsdateien so, daß jeder Benutzer

unterschiedliche Ports nutzt

➥ Umgebungsvariable und Pfad setzen (in $HOME/.profile):

export OPENEJB_HOME=$HOME/Soft/openejb-7.0.2

export PATH=$OPENEJB_HOME/bin:$PATH

➥ Start des Containers: openejb start

➥ Stoppen des Containers: ^C oder kill

5.4.5 Einschub: OpenEJB ...


Ubersetzung / Deployment des Servers

➥ Ubersetzung

➥ javac -cp $OPENEJB_HOME/lib/javaee-api-7.0-1.jar:.

org/Hello/*.java

➥ CLASSPATH muß nur gesetzt werden, wenn Java EE nicht

installiert ist (wegen EJB-Klassen)

➥ Erzeugung der JAR-Datei fur die EJB

➥ jar cvf myHelloEjb.jar org/Hello/*.class META-INF

➥ Verzeichnis META-INF muß Deployment-Deskriptor

ejb-jar.xml enthalten



Ubersetzung / Deployment des Servers ...

➥ Deployment der EJB

➥ openejb deploy -s ejbd://localhost:4201 myHelloEjb.jar

➥ OpenEJB-Container muß bereits laufen

➥ ggf. vorher starten: openejb start

➥ Optionen:

➥ -s: Angabe der URL des OpenEJB-Daemons

➥ z.Zt. nur localhost erlaubt➥ kann entfallen, wenn Standard-Port 4201 benutzt wird

➥ -u: Undeploy und anschließendes Deploy

➥ -o: offline-Modus (wenn OpenEJB-Container nicht lauft)



Ubersetzung / Deployment des Servers ...

➥ Was passiert beim Deployment?

➥ JAR-Datei mit Bean wird in apps-Verzeichnis von OpenEJBkopiert (damit Container sie findet)

➥ Business-Interface der Bean wird beim Namensdienstregistriert

➥ genauer: Objekt einer Klasse, die Interface implementiert

➥ Stub- und Implementierungsklassen werden dynamisch zurLaufzeit erzeugt

➥ Undeployment

➥ openejb undeploy -s ejbd://localhost:4201

$OPENEJB_HOME/apps/myHelloEjb.jar

➥ bzw. falls Container nicht lauft:rm $OPENEJB_HOME/apps/myHelloEjb.jar



Ubersetzung / Start des Clients

➥ Vorbereitung

➥ Java-Datei fur Business-Interface muß beim Client vorhanden

sein!

➥ Ubersetzung

➥ javac -cp $OPENEJB_HOME/lib/javaee-api-7.0-1.jar:.

HelloClient.java

➥ Start

➥ java -cp $OPENEJB_HOME/lib/javaee-api-7.0-1.jar:

$OPENEJB_HOME/lib/openejb-client-7.0.2.jar:.

HelloClient



Ablauf des Programms

Container−SystemClient Container

sayHello()

Bean−Instanz

sayHello()Class.newInstance()

lookup()

NameService

Class.newInstance()

bind()ObjektEJB−

sayHello()sayHello()



Weitere Informationen

➥ OpenEJB Home Page

➥ http://openejb.apache.org/

➥ Beispiele zu OpenEJB

➥ http://openejb.apache.org/examples/

➥ Dokumentation zu OpenJPA

➥ http://openjpa.apache.org/builds/2.4.1/

apache-openjpa/docs/

➥ OpenJPA ist der Standard Persistence Provider von OpenEJB

➥ fur Entities

➥ EJB 3.0 Spezifikationen

➥ http://jcp.org/aboutJava/communityprocess/final/

jsr220/

http://openejb.apache.org/

http://openejb.apache.org/examples/

http://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/

http://openjpa.apache.org/builds/2.4.1/apache-openjpa/docs/

http://jcp.org/aboutJava/communityprocess/final/jsr220/

http://jcp.org/aboutJava/communityprocess/final/jsr220/



5.4.6 Dienste des EJB-Containers

➥ Ressourcen-Management

➥ Pooling: Container halt einen Pool von Bean-Instanzen vor

➥ z.B. bei stateless Session Beans: Aufrufe gehen an

beliebige Instanz im Pool

➥ Ziel u.a.: vermeide teuren Auf- und Abbau von Datenbank-

Verbindungen

➥ Passivierung und Aktivierung von stateful Session Beans

➥ Container kann Session Beans temporar passivieren➥ z.B. wenn zuviele Bean-Instanzen vorhanden sind➥ bei Passivierung wird Zustand der Bean auf Festplatte

gesichert und Bean-Instanz geloscht

➥ bei nachster Client-Anfrage: neue Bean-Instanz wirderzeugt und initialisiert

5.4.6 Dienste des EJB-Containers ...


➥ Namensdienst: Zugriff uber JNDI-Schnittstelle

➥ Nebenlaufigkeit

➥ Session Beans: immer nur von einem Client genutzt

➥ Entities: optimistisches Locking

➥ setzt Versions-Attribut in der Entity voraus

➥ Alternative: explizite Read und Write-Locks

➥ Persistenz (☞ 5.4.9)

➥ Datenfelder einer Entity werden automatisch mit dem Inhalt

einer Datenbank synchronisiert

➥ Transaktionen (☞ 5.4.10)

➥ Methoden von Session Beans konnen automatisch als

Transaktionen ausgefuhrt werden

5.4.6 Dienste des EJB-Containers ...


➥ Sicherheit

➥ Authentifizierung

➥ Vorgehen abhangig von EJB-Container-Implementierung

➥ oft: Benutzername / Paßwort als Properties uber JNDI

ubergeben

➥ Autorisierung

➥ Festlegung, wer welche Methoden aufrufen darf

➥ uber Deployment-Deskriptor (☞ 5.4.7) oder

Annotationen➥ rollenbasierte Zugriffskontrolle

➥ sichere Kommunikation

➥ abhangig von EJB-Container-Implementierung

➥ meist: Nutzung von TLS/SSL

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (8/15) ix

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

17.11.17



5.4.7 Der Deployment-Deskriptor ejb-jar.xml

➥ Beschreibt

➥ aus welchen Klassen die EJB besteht

➥ wie die EJB zur Laufzeit verwaltet werden soll, z.B.:

➥ Art der EJB➥ Transaktionsmanagement

➥ Zugriffskontrolle

➥ Ab EJB 1.1 ist der Deployment-Deskriptor in XML codiert

➥ wird als META-INF/ejb-jar.xml in JAR-Datei der EJBabgelegt

➥ wird beim Deployment vom Container gelesen

➥ Ab EJB 3.0 kann Deployment-Deskriptor auch leer sein

➥ Metadaten auch als Annotationen im Java-Code moglich

5.4.7 Der Deployment-Deskriptor ejb-jar.xml ...


Aufbau des Deployment-Deskriptors

➥ Prinzipieller Aufbau:


<ejb-jar>

<enterprise-beans>

...

</enterprise-beans>

<assembly-descriptor>

...

</assembly-descriptor>

</ejb-jar>



Elemente innerhalb von <ejb-jar>

➥ <enterprise-beans>

➥ Beschreibung der einzelnen EJBs innerhalb der JAR-Datei

➥ ab EJB 3.0 besser durch Annotationen

➥ <assembly-descriptor>

➥ Konfiguration der zusammengestellten Beans fur eine

Anwendung

➥ z.B. Transaktionsverhalten, Zugriffskontrolle

➥ <description>

➥ Beschreibung der Beans-Sammlung in der JAR-Datei

➥ und noch einige weitere ...



Elemente innerhalb von <assembly-descriptor>

➥ <container-transaction>

➥ Transaktions-Attribute fur einzelne Methoden (☞ 5.4.10)

➥ ab EJB 3.0 auch besser durch Annotationen

➥ <security-role>

➥ Definiert Rollennamen fur rollenbasierte Zugriffskontrolle

➥ Unterelemente: <description> und <role-name>

➥ <method-permission>

➥ legt fest, welche Rollen welche Methoden aufrufen durfen

➥ Unterelemente: <description>, <role-name>, <method>

➥ statt <role-name> auch Element <unchecked> moglich: keine

Zugriffskontrolle



Zur Zugriffskontrolle bei EJBs

➥ Deployment-Deskriptor (bzw. Annotationen) legt nur Abbildung

zwischen Rollennamen und aufrufbaren Methoden fest

➥ Verwaltung von Benutzern und Paßworten sowie Abbildung von

Benutzern auf Rollen muß durch EJB-Container erfolgen

➥ abhangig von jeweiliger Implementierung

➥ in OpenEJB:

➥ conf/users.properties: Benutzer und Paßwort

➥ z.B.: roland=myPassWd

➥ conf/groups.properties: Zuordnung Benutzer zu Rollen

➥ z.B.: Admin=roland



Beispiel

➥ Session Bean zur Vorlesungsverwaltung

➥ jeder darf die Daten lesen, nur Administrator darf andern

➥ Deployment-Deskriptor:

<ejb-jar>

<assembly-descriptor>

<security-role>

<description>Rolle fuer Administratoren</description>

<role-name>Admin</role-name>

</security-role>

<method-permission>

<role-name>Admin</role-name>

<method>

<ejb-name>VorlesungEJB</ejb-name>

<method-name>*</method-name>



</method>

</method-permission>

<method-permission>

<unchecked/>

<method>

<ejb-name>VorlesungEJB</ejb-name>

<method-name>getInfos</method-name>

</method>

</method-permission>

</assembly-descriptor>

</ejb-jar>

➥ Anmerkungen:

➥ der Deployment-Deskriptor wird i.d.R. uber ein Konfigurations-

werkzeug erstellt

➥ Rollen und Zugriffsrechte konnen auch uber Annotationen

festgelegt werden



5.4.8 Session Beans: Details

Stateless Session Beans

➥ Container verwaltet Pool

identischer Bean-Instanzen

➥ Erzeugung / Loschung

nur durch Container

➥ Aufrufe von Anwendungs-

methoden werden an

beliebige Bean-Instanz im

Pool geleitet

➥ keine Passivierung /

Aktivierung

Stateful Session Beans

➥ Erzeugung / Loschung (indirekt)

auf Veranlassung des Clients

➥ Bean-Instanzen werden Client-

Sitzungen (und damit EJB-

Objekten) fest zugeordnet

➥ Aufrufe eines Clients gehen

an dieselbe Bean-Instanz

➥ bei Bedarf: Passivierung /

Aktivierung durch Container

5.4.8 Session Beans: Details ...


Annotationen fur Schnittstellen und Bean-Implementierungen

➥ @Local und @Remote (aus javax.ejb)

➥ markieren ein Java-Interface als lokale bzw. remote

Schnittstelle einer EJB

➥ lokale Schnittstelle kann nur innerhalb des Containers (von

anderen EJBs) genutzt werden

➥ Zuordnung zur Bean-Klasse uber implements-Beziehung

➥ @Stateless und @Stateful (aus javax.ejb)

➥ markieren eine Java-Klasse als entsprechende Session Bean

➥ @Remove (aus javax.ejb)

➥ markiert eine Methode in einer (stateful) Session Bean-

Klasse, nach deren Ausfuhrung die Bean-Instanz geloscht

werden soll



Beispiel

➥ RemIf.java:

@Remote

public interface RemIf {


public void bye();

}

➥ LocIf.java:

@Local

public interface LocIf {


public void doIt();

}

➥ MyBean.java:

@Stateful

public class MyBean implements LocIf, RemIf {

public String sayHello() { ... }

@Remove public void bye() { ... }

public void doit() { ... }

}



Lebenszyklus-Callbacks

➥ @PostConstruct bzw. @PreDestroy (aus javax.annotation)

➥ markiert Methode in einer Bean-Klasse, die nach Erzeugung

bzw. vor Loschung einer Bean-Instanz aufgerufen werden soll

➥ aber: keine Garantie, daß Bean-Instanz jemals geloscht wird

➥ @PrePassivate bzw. @PostActivate (aus javax.ejb)

➥ markiert Methode, die vor Passivierung bzw. nach Aktivierung

einer Bean-Instanz aufgerufen werden soll

➥ Alle Callback-Methoden sollten wie folgt deklariert werden:

➥ public void name () { ... }

➥ Auch moglich: Definition einer eigenen Klasse fur die Callbacks



Interceptor-Methoden

➥ @AroundInvoke (aus javax.interceptor)

➥ markiert Methode, die alle Methodenaufrufe einer Bean

abfangt

➥ Deklaration der Methode:

➥ public Object name (InvocationContext c)

throws Exception { ... }

➥ InvocationContext erlaubt u.a.:

➥ Abfrage von Zielobjekt, Methodenname und Parameter

➥ Ausfuhrung des abgefangenen Methodenaufrufs

➥ Einsatz z.B. Protokollierung, Zugriffskontrolle, ...

➥ Auch moglich: Definition einer eigenen Klasse fur den Interceptor



Dependency Injection

➥ Aufgabe: Beschaffung von Referenzen auf Ressourcen, die der

Container bereitstellt

➥ Losung: passendes Attribut wird mit einer Annotation versehen

➥ Attribut wird dann automatisch vom Container initialisiert

➥ @Resource (aus javax.annotation)

➥ fur beliebige Resourcen des Containers

➥ z.B. SessionContext: erlaubt Zugriff auf Benutzer-Name,

aktuelle Transaktion, ...

➥ @EJB (aus javax.ejb)

➥ speziell, um Referenzen auf EJBs zu holen

➥ (Alternative: explizite Nutzung von JNDI)



Beispiel

➥ MyBeanLocal.java:

@Local public interface MyBeanLocal {

public String getName();

}

➥ MyBean.java:

@Stateful

public class MyBean implements MyBeanLocal {

// Attribut wird vom Container initialisiert!

@Resource private SessionContext context;

public String getName() {

return context.getCallerPrincipal().getName();

}

}



Beispiel ...

➥ HelloRemote.java:

@Remote public interface HelloRemote {


public String sayGoodBye();}

➥ HelloImpl.java:

@Stateful

public class HelloImpl implements HelloRemote {// Referenz auf MyBean wird vom Container eingetragen!

@EJB private MyBeanLocal myBean;

public String sayHello() {return "Hallo " + myBean.getName();

}@Remove public String sayGoodBye() { ... }



Beispiel ...

➥ HelloImpl.java ...:

@PostConstruct public void start() {System.out.println("@PostConstruct HelloImpl");

}@PreDestroy public void stop() {System.out.println("@PreDestroy HelloImpl");

}

@AroundInvokepublic Object inv(InvocationContext c)

throws Exception {

System.out.println("HelloImpl: Calling "+ c.getMethod().getName());

return c.proceed();}

}



Lebenszyklus einer Stateless Session Bean

Container entscheidet,daß nicht mehr soviele Bean−Instanzenbenötigt werden

Bean−Instanzexistiert nicht

Pool äquivalenterInstanzen, bereit

für Methodenaufrufe

um Clients zu bedienen

daß mehr Bean−Instanzen

im Pool benötigt werden,

Container entscheidet,

Beliebiger Clientruft Anwendungs−methode auf. Abar−beitung in beliebigerEBJ.

methodeAnwendungs−

1. Class.newInstance()

@PreDestroy

3. @PostConstruct

2. Injections



Typische Ablaufe bei Stateless Session Beans

Hinzufügen einerneuen Instanzzum Pool

Methodenaufrufedurch Client

Löscheneiner Instanz aus dem Pool

Container−System

@PreDestroy

ObjektEJB−

Bean−Instanz

Client Container

Class.newInstance()

Injections

@PostConstruct

businessMethod()businessMethod()



Lebenszyklus einer Stateful Session Bean

Client ruft Methodeder passiviertenBean. Container mußBean wieder einlagern

Limit instantiierterBeans ist erreicht.Container mußBean auslagern

Client ruftAnwendungs−methode derSession Bean

Bean−Instanzexistiert nicht

PassivBereit

methodeAnwendungs−

1. Class.newInstance()

2. Injections

3. @PostConstruct

Referenz auf einInterface der

Client holt/nutzt

@PreDestroy

@PrePassivate

@PostActivate

Session Bean

Client ruft Methodeauf, die mit @Removeannotiert istoder: Timeout

Timeout



Erzeugung/Loschung einer Stateful Session Bean

Löschung

Erzeugung

Container−System

Bean−Instanz

EJB−Objekt

Client

lookup()

EJB−Objekt

Name Service

@PostConstruct

Class.

newInstance()

Injections

Container

businessMethod()

businessMethod2()

Class.newInstance()

businessMethod()

@Remove businessMethod2()

@ PreDestroy



Passivierung/Aktivierung einer Stateful Session Bean

Container − System

Bean−Inst.Client FestplatteContainerEJB−Objekt

@PrePassivate

Bean−Inst.

Passivierung

Aktivierung

businessMethod() Class.newInstance()

serialisiere Bean−Instanz

speichere Zustand ab

Lies Zustand ein

deserialisiere Bean−Instanz

@PostActivate

businessMethod()



5.4.9 Entities: Details

➥ Entities realisieren persistente Datenobjekte einer Anwendung

➥ Basis: Java Persistence API (JPA)

➥ unabhangig von EJB und Java EE nutzbar

➥ Eigenschaften (Abgrenzung zu Session Beans):

➥ fur den Client sichtbare, persistente Identitat (Primarschlussel)

➥ unabhangig von Objektreferenz

➥ persistenter, fur Client sichtbarer Zustand

➥ nicht entfernt zugreifbar

➥ Lebensdauer vollig unabhangig von der der Anwendung

➥ Persistenz der Entities wird automatisch durch Persistence

Provider gesichert

5.4.9 Entities: Details ...


Beispiel

➥ Entity Account.java:

import javax.persistence.*;

@Entity // Markiert Klasse als Entity

public class Account implements java.io.Serializable {

@Id // Markiert Attribut als Primarschlussel

private int accountNo;private String name;

public int getAccountNo() { return accountNo; }public String getName() { return name; }public void setName(String nm) { name = nm; }public Account(int no, String nm) {accountNo = no; name = nm;

}}



Beispiel ...

➥ Deployment-Deskriptor META-INF/persistence.xml:

<persistencexmlns="http://java.sun.com/xml/ns/persistence"version="1.0"><persistence-unit name="intro"><jta-data-source>My DataSource</jta-data-source><non-jta-data-source>My Unmanaged DataSource</non-jta-data-source><class>org.Hello.Account</class><properties><property name="openjpa.jdbc.SynchronizeMappings"

value="buildSchema(ForeignKeys=true)"/></properties>

</persistence-unit></persistence>



Beispiel ...

➥ OpenEJB Konfigurationsdatei conf/openejb.xml:

<Resource id="My DataSource" type="DataSource">JdbcDriver org.hsqldb.jdbcDriverJdbcUrl jdbc:hsqldb:file:data/hsqldb/hsqldbUserName saPasswordJtaManaged true

</Resource>

<Resource id="My Unmanaged DataSource" type="DataSource">JdbcDriver org.hsqldb.jdbcDriverJdbcUrl jdbc:hsqldb:file:data/hsqldb/hsqldbUserName saPasswordJtaManaged false

</Resource>




➥ Eine Entity -Klasse muss Serializable nicht implementieren

➥ falls Sie es tut, konnen Objekte auch als Parameter / Ergebnis

von Remote-Methoden einer Session Bean auftreten

➥ ubergeben wird dabei eine Kopie, die nicht mit der

Datenbank synchronisiert wird

➥ Abbildung von Klasse auf Datenbank-Tabelle und von Attributen

auf Spalten wird vom Persistence Provider vorgenommen

➥ kann durch Annotationen genau gesteuert werden

➥ Entity -Klasse muß ein Primarschlussel-Attribut deklarieren (@Id)

➥ Primarschlussel kann auch eigene Klasse sein

➥ Entity -Klasse darf auch Geschaftsmethoden besitzen



Anmerkungen zum Beispiel ...

➥ Beispiel verwendet Field Access

➥ Persistence Provider greift direkt auf die Attribute zu

➥ Mapping-Annotationen (hier: @Id) bei den Attributen

➥ Alternative: Property Access

➥ Persistence Provider greift auf den Zustand nur uber get- und

set-Methoden zu

➥ Mapping-Annotationen bei den get-Methoden

➥ Achtung: es mussen immer get- und set-Methoden

implementiert werden

➥ Pro Entity ist nur eine der Alternativen erlaubt



Anmerkungen zum Beispiel ...

➥ Deployment-Deskriptor legt fest:

➥ Name der Persistence Unit (zum Zugriff durch Session Bean)

➥ Persistence Unit : Einheit fur Kapselung und Deploymentvon Entities

➥ Namen der Datenquellen mit bzw. ohne Support fur JavaTransaction API (JTA, ☞ 5.4.10, verteilte Transaktionen)

➥ Properties fur den Persistence Provider

➥ hier: OpenJPA passt Datenbank-Schema zur Laufzeit an

➥ OpenEJB-Konfiguration legt fest:

➥ JDBC Treiber und URL der Datenbank (☞ 2)

➥ Login-Name und Passwort

➥ Unterstutzung fur JTA

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (9/15) x

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

24.11.2017



Beispiel zur Nutzung der Entity in einer Session Bean

➥ Remote-Schnittstelle BankRemote.java:

import javax.ejb.Remote;

@Remote

public interface BankRemote

{

public Account create(int n, String name);

public String getName(int n);

public void close(int n);

}



Beispiel zur Nutzung der Entity in einer Session Bean ...

➥ Bean-Implementierung BankImpl.java:

import javax.ejb.*;

import javax.persistence.*;

@Stateless

public class BankImpl implements BankRemote {

// Dependency Injection: Entity Manager fur Persistenz−Einheit ’intro’

@PersistenceContext(unitName="intro")

private EntityManager manager;

public Account create(int n, String name) {

Account acc = new Account(n, name);

// Objekt ab jetzt durch Persistence Provider verwalten

manager.persist(acc);




➥ Bean-Implementierung BankImpl.java:

// Ruckgabewert ist eine losgeloste Kopie des Objekts!

return acc;}public String getName(int n) {

// Findet Objekt mit gegebenem Primarschlussel

Account acc = manager.find(Account.class, n);return acc.getName();

}public void close(int n) {Account acc = manager.find(Account.class, n);// Datenbank−Eintrag loschen

manager.remove(acc);}

}




➥ Client BankClient.java:

...

Object obj = ctx.lookup("BankImplRemote");

BankRemote bank = (BankRemote)obj;

// Erzeugt neue Entity (und Datenbankeintrag)

Account acc = bank.create(n, args[1]);

// acc ist eine Kopie des Eintrags, lokale Methodenaufrufe

System.out.println(acc.getName());

acc.setName("Niemand");

// Remote−Aufrufe der Entity Bean

System.out.println(bank.getName(n));

bank.close(n);



Persistence Context

➥ Verbindung zwischen Instanzen im Speicher und der Datenbank

➥ Methoden der Schnittstelle EntityManager u.a.:

➥ void persist(Object entity)

➥ Instanz verwalten und persistent machen

➥ <T> T find(Class<T> entityClass, Object primaryKey)

➥ Instanz zu gegebenem Primarschlussel suchen

➥ void remove(Object entity)

➥ Instanz aus der Datenbank loschen

➥ void refresh(Object entity)

➥ Instanz aus Datenbank neu laden

➥ <T> T merge(T entity)

➥ Zustand der Instanz in Persistence Context hineinmischen



Lebenszyklus einer Entity

Instanz hat Datenbank−Eintrag,ist aber nicht mit PersistenceContext verbunden (z.B.Kopie einer managed Entity)

Instanz wird mit Daten−bank konsistent gehalten

merge()

PersistenceContext

endet

persist()

remove()

persist()

new

refresh()

detached

managed removed

new



Lebenszyklus einer Entity ...

➥ Persistence Context endet per Voreinstellung mit dem Ende deraktuellen Transaktion

➥ Einstellung uber Attribut type von @PersistenceContext

➥ Synchronisation mit Datenbank i.a. am Ende jeder Transaktion

➥ einstellbar uber setFlushMode() Methode von EntityManager

➥ ggf. auch explizite Synchronisation durch Methode flush()

➥ JPA verwendet standardmaßig ein optimistisches Sperrprotokoll

➥ Datensatze werden nicht gesperrt

➥ bei gleichzeitigen Anderungen durch zwei Transaktionen wirdeine davon zuruckgesetzt

➥ dazu notwendig: Versionsattribut (Annotation @Version)

➥ Lebenszyklus-Callbacks analog zu Session Beans moglich



Finden von Entities

➥ EntityManager erlaubt das Finden von Datensatzen uber

Queries in SQL und EJB-QL

➥ EJB-QL ist SQL-ahnlich, aber portabel

➥ Beispiel:

Query query

= manager.createQuery("SELECT a FROM Account a");

List<Account> result = query.getResultList();

➥ Queries konnen auch mit Namen vordefiniert werden

➥ uber Annotation @NamedQuery der Entity

➥ als named-query Element im Deskriptor META-INF/orm.xml

➥ Nutzung: query = manager.createNamedQuery("myQuery");



Abbildung zwischen Objekten und Relationen (OR-Mapping)

➥ Default-Verhalten:

➥ jede Entity bekommt eine Tabelle

➥ jedes Attribut bekommt eine Tabellen-Spalte

➥ Namen werden in Großbuchstaben umgewandelt

➥ Verhalten anpaßbar uber Annotationen (bzw. XML-Deskriptor), z.B.:

➥ @Table(name="..."): Tabellenname fur Entity

➥ @Column(name="..."): Spaltenname fur Attribut

➥ @Transient: Attribut wird nicht persistent gemacht

➥ Auch Abbildung von Assoziationen zwischen Klassen durchentsprechende Annotationen moglich

➥ u.a. @OneToMany, @ManyToOne, @JoinColumn, siehe Beispiel



Beispiel zum OR-Mapping

➥ Datenbank-Tabellen fur Konto und Zahlungen:

BUCHUNG

KONTO

KONTO_NR: INTEGER

ID: INTEGER DATUM: TIMESTAMPBETRAG: NUMERIC

NAME: VARCHAR(255)

KONTO: INTEGER

➥ Klassendiagramm fur die Entities:

payments

*

accountNo: int

name: String

Account

1

id: int

amount: double

date: Date

Payment



Beispiel zum OR-Mapping ...

➥ Entity -Klasse Account.java

@Entity@Table(name="KONTO")public class Account {

@Id@Column(name="KONTO_NR")private int accountNo;private String name;@OneToMany(fetch=FetchType.LAZY, mappedBy="account")private Set<Payment> payments;

public int getAccountNo() { return accountNo; }public Set<Payment> getPayments() { return payments; }public void addPayment(Payment p) { payments.add(p); }...



Beispiel zum OR-Mapping ...

➥ Entity -Klasse Payment.java

@Entity@Table(name="BUCHUNG")public class Payment {

@Idprivate int id;@ManyToOne@JoinColumn(name="KONTO", nullable=false)private Account account;@Column(name="DATUM")private Date date;@Column(name="BETRAG")private double amount;...




➥ Bedeutung des Parameters type bei @OneToMany:

➥ EAGER: Payments werden beim Laden eines Account-Objekts

sofort mitgeladen

➥ LAZY: Payments werden erst beim Zugriff geladen

➥ Zugriff muß uber get-Methode (getPayments()) erfolgen!

➥ mappedBy-Parameter von @OneToMany realisiert eine bidirektionale

Assoziation

➥ @JoinColumn definiert, welche Spalte der Tabelle BUCHUNG den

Primarschlussel des zugehorigen Eintrags in KONTO enthalt

➥ nullable gibt an, ob der Spalteneintrag leer sein darf

➥ Deskriptor META-INF/persistence.xml muss <class>-Tags fur

beide Entities enthalten



5.4.10 Transaktionen

➥ EJB-Container bieten Unterstutzung fur flache (evtl. verteilte)

Transaktionen

➥ EJB-Container kann

➥ automatisch Transaktionen um Client-Anfragen generieren

➥ vom Client oder einer EJB explizit definierte Transaktions-

Grenzen erkennen und an EJBs weitergeben

➥ EJB-Container regelt Weitergabe von Transaktionen bei

Methodenaufrufen

➥ z.B. wenn innerhalb einer Transaktion eine Methode gerufen

wird, die neue Transaktion definiert

➥ verschachtelte Transaktionen sind nicht erlaubt

5.4.10 Transaktionen ...


Arten des Transaktions-Managements

➥ Festlegung durch Annotation der Session Bean

➥ @TransactionManagement (aus javax.ejb)

➥ Argument: TransactionManagementType.BEAN bzw.CONTAINER

➥ Bean Managed Transactions

➥ Session Bean legt Transaktionsgrenzen selbst fest

➥ Container Managed Transactions

➥ Container legt Grenzen und Weitergabe von Transaktionen fest

➥ Verhalten durch Annotation der Methoden spezifiziert

➥ @TransactionAttribute (aus javax.ejb)

➥ Client Initiated Transactions

➥ Transaktionsgrenzen werden vom Client bestimmt



Bean Managed und Client Initiated Transactions mit JTA

➥ Verwendung des Java Transaction API (JTA)

➥ Klasse javax.transaction.UserTransaction

➥ Methoden begin(), commit(), rollback()

➥ Erzeugung eines UserTransaction-Objekts

➥ Im Client (oder einer Session Bean): uber JNDI

➥ ut = (UserTransaction)ctx.lookup(

"java:comp/env/UserTransaction");

➥ In einer Session Bean:

➥ uber SessionContext: Methode getUserTransaction()

➥ oder direkt uber Dependency Injection:

➥ @Resource private UserTransaction ut;



Container Managed Transactions: Beispiel Ticket-Buchung

import javax.ejb.*;

@Stateless@TransactionManagement(TransactionManagementType.CONTAINER)public class TravelAgentBean implements TravelAgentRemote {

...@TransactionAttribute(TransactionAttributeType.REQUIRED)public Ticket bookPassage(CreditCard card, double price) {

try {Reservation res = new Reservation(customer, cruise, price);entityManager.persist(res);

pay.byCredit(customer, card, price);

return new Ticket(customer, cruise, price);}catch (Exception e) { throw new EJBException(e); }

}



Transaktionsverhalten des Beispiels

➥ Abarbeitung von bookPassage() soll immer innerhalb einer

Transaktion erfolgen

➥ Transaktionsattribut Required

➥ wenn Aufruf nicht in einer Transaktion erfolgt, wird automatisch

neue Transaktion erzeugt

➥ Transaktion wird an die Methoden der genutzten EJBs weiter-

gegeben

➥ gemaß Transaktionsattribut der gerufenen Methode

➥ Falls bookPassage() eine System-Exception wirft: Rollback,

sonst: Commit am Ende der Methode

➥ alle Unterklassen von RuntimeException sind System-

Exceptions, insbes. EJBException



Container Managed Transactions: Transaktionsattribute

➥ NOT_SUPPORTED

➥ Methode unterstutzt keine Transaktionen

➥ ggf. bereits existierende Transaktion wird bei Aufruf

suspendiert

➥ SUPPORTS

➥ Methode unterstutzt Transaktionen, erzeugt aber keine eigene

Transaktion

➥ ggf. bei Aufruf existierende Transaktion wird ubernommen

➥ REQUIRED

➥ Methode muß innerhalb einer Transaktion ausgefuhrt werden

➥ ggf. wird beim Aufruf eine neue Transaktion erzeugt



Container Managed Transactions: Transaktionsattribute ...

➥ REQUIRES_NEW

➥ beim Methodenaufruf wird immer eine neue Transaktion

erzeugt

➥ ggf. bereits existierende Transaktion wird suspendiert

➥ MANDATORY

➥ Methode muß innerhalb einer Transaktion ausgefuhrt werden

➥ ansonsten wird Exception geworfen

➥ NEVER

➥ Methode darf nicht innerhalb einer Transaktion ausgefuhrt

werden

➥ ansonsten wird Exception geworfen



Container Managed Transactions: Transaktionsattribute ...

AufrufersTransaktions−

AttributTransaktion der

gerufenen MethodeTransaktion des

keinekeinekeine

keine

keine

keine

keine

keine

keine

keineT1

T1

T1

T1

T1

T1

Exception

Exception

T2T2

T2T1

T1

T1

NOT_SUPPORTED

REQUIRED

REQUIRES_NEW

MANDATORY

NEVER

SUPPORTS



5.4.11 Zusammenfassung

➥ EJBs: Komponentenmodell fur Anwendungsserver

➥ Entities fur Datenmodell

➥ Persistenz und Transaktionen durch Container verwaltet

➥ Session Beans fur Client-Sitzungen

➥ Transaktionen durch Client, Bean oder Container verwaltet

➥ Container realisiert daneben u.a. Ressourcenmanagement,Namens- und Sicherheitsdienste

➥ Nicht besprochen: Entity Beans, Message Driven Beans, undvieles andere mehr ...

➥ Web Services kommt spater noch



6 Servlets und JSP

6 Servlets und JSP ...


Inhalt

➥ Servlets

➥ Java Server Pages (JSP)

➥ Hunter / Crawford

➥ Farley / Crawford / Flanagan, Kap. 5 und 6

➥ Langner (Verteilte Anwendungen mit Java), Kap. 6

➥ Orfali / Harkey, Kap. 12

➥ http://docs.oracle.com/javaee/5/tutorial/doc/bnadp.html

➥ http://docs.oracle.com/javaee/6/tutorial/doc/bnafd.html

➥ http://www.oracle.com/technetwork/java/javaee/tech

http://docs.oracle.com/javaee/5/tutorial/doc/bnadp.html

http://docs.oracle.com/javaee/6/tutorial/doc/bnafd.html

http://www.oracle.com/technetwork/java/javaee/tech



6.1 Servlets

➥ Java Software-Komponenten zur dynamischen Erweiterung vonWeb-Servern

➥ Erzeugung dynamischer HTML-Seiten, z.B. ausDatenbank-Inhalten

➥ Typische Architektur:

JDBCServlet−Container

Servlet

ServletDatenbank

HTTP GET

HTML−Seite

Web−Browser

HTTP−Server

Web−Server

6.1 Servlets ...


6.1.1 Grundlagen

➥ Servlets sind Java-Klassen, die innerhalb eines Web-Servers

ausgefuhrt werden

➥ Web-Server muß servlet-fahig sein, d.h. uber einen

Servlet-Container verfugen (z.B. Tomcat)

➥ Container ladt Servlets bei Bedarf dynamisch nach

➥ (HTTP-)Servlets werden (u.a.) uber die HTTP-Anfragen GET bzw.

POST angesprochen

➥ Servlet bearbeitet die Anfrage und erzeugt eine HTML-Seite

➥ Bearbeitung erfolgt durch eigenen Thread im Adreßraum des

Web-Servers

➥ (Generische Servlets werden hier nicht behandelt)

6.1.1 Grundlagen ...


Die HTTP-Methoden GET und POST

➥ Teil des HTTP-Protokolls: Browser-Anfragen an den Server

➥ Auch verwendet in HTML-Formularen

➥ GET-Methode

➥ zum Holen von Dokumenten uber eine URL bestimmt

➥ URL kann auch weitere Parameter beinhalten, z.B.

➥ GET /buy.html?what=shoe&price=50.00 HTTP 1.0

➥ begrenzte Lange der URL!

➥ POST-Methode

➥ zum Senden von Daten an den Web-Server

➥ Parameter werden im Rumpf der HTTP-Anfrage ubertragen,

sind in der URL nicht sichtbar

6.1.1 Grundlagen ...


Implementierung von HTTP-Servlets

➥ Ableiten einer Klasse von javax.servlet.http.HttpServlet

➥ I.d.R. Uberschreiben einer der Methoden

➥ void doGet(HttpServletRequest request,

HttpServletResponse response)

throws IOException, ServletException

➥ Behandlung von HTTP-GET-Anfragen

➥ void doPost(...): analog fur HTTP-POST-Anfragen

➥ Bei Bedarf Uberschreiben der Methoden

➥ void init() : gerufen, wenn Servlet geladen wird

➥ void destroy() : gerufen, wenn Servlet entfernt wird

➥ Einige weitere Methoden, siehe API-Dokumentation

6.1 Servlets ...


6.1.2 Einschub: Web-Server im Labor

➥ Im Labor H-A4111 kann/soll jeder Student einen eigenen

Web-Server verwenden

➥ tomcat-Server (fur Servlets, Web-Services, ...)

➥ Private Installation (i.w. Konfigurationsdateien):

➥ Aufruf des Skripts

/opt/dist/tools/tomcat_install.sh

auf einem Rechner im Labor H-A 4111

➥ konfiguriert fur jeden Benutzer eigene Ports

➥ Umgebungsvariablen setzen (in $HOME/.profile):

export CATALINA_BASE=$HOME/Soft/apache-tomcat-6.0.18

export CATALINA_HOME=/opt/dist/apache-tomcat-6.0.18

export PATH=$CATALINA_HOME/bin:$PATH

6.1.2 Einschub: Web-Server im Labor ...


Nutzung von Tomcat

➥ Start des tomcat-Servers mit catalina.sh run

➥ benutzte Port-Nummer wird beim Start ausgegeben:

INFO: Initializing Coyote HTTP/1.1 on http-8080

➥ Web-Seiten konnen unter $CATALINA_BASE/webapps/ROOT

angelegt werden

➥ Erreichbar dann unter der URL

http://rechnername:port/dateiname

➥ Im Labor H-A 4111 muß wegen des voreingestellten Web-

Proxies immer der vollstandige Rechnername (FQDN)

angegeben werden

➥ z.B. bslab01.lab.bvs

6.1 Servlets ...


6.1.3 Beispiel: Hello-World Servlet

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class HelloSrv extends HttpServlet {

private int counter = 0;

// Wird bei HTTP−Get−Anfrage aufgerufen

public void doGet(HttpServletRequest request,


throws IOException, ServletException {

counter++;

6.1.3 Beispiel: Hello-World Servlet ...


// Extrahiert Parameter ’name’ aus URL

String name = request.getParameter("name");

response.setContentType("text/html");

// Ausgabestrom fur die erzeugte HTML−Seite

PrintWriter out = response.getWriter();

out.println("<html>");

out.println("<head><title>Hallo World</title></head>");

out.println("<body><b>" + counter + ". Hello to " + name +

"!</b></body>");

out.println("</html>");

out.close();

}

}



HTML-Seite zum Aufruf des Servlets

<HTML>

<HEAD><TITLE>Hello-World</TITLE></HEAD>

<BODY>

<P>

<A HREF="http://localhost:8080/test/hello?name=Roland">

Say Hello to Roland</A>

</P>

<P> Say Hello to:

<FORM METHOD="GET"

ACTION="http://localhost:8080/test/hello">

<INPUT TYPE="text" NAME="name" SIZE="10">

<INPUT TYPE="submit" VALUE="Submit">

</FORM>

</P>

</BODY>

</HTML>



Deployment mit Tomcat-Server

➥ Ubersetzen des Servlets

➥ javac -cp $CATALINA_HOME/lib/servlet-api.jar:.

HelloSrv.java

➥ CLASSPATH nur notwendig, wenn J2EE nicht installiert ist

➥ Erstellen eines Deployment-Deskriptors unter WEB-INF/web.xml

➥ Kopieren der class-Datei(en) nach WEB-INF/classes

➥ cp HelloSrv.class WEB-INF/classes

➥ Erzeugen eines WAR Archivs

➥ jar -cvf test.war WEB-INF

➥ Kopieren des WAR Archivs in das Tomcat-Verzeichnis

➥ cp test.war $CATALINA_BASE/webapps



Deployment-Deskriptor fur das Servlet

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app PUBLIC

"-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"

"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">

<web-app>

<servlet>

<servlet-name>HelloWorld</servlet-name>

<servlet-class>HelloSrv</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>HelloWorld</servlet-name>

<url-pattern>/hello</url-pattern>

</servlet-mapping>

</web-app>

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (10/15) xi

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

01.12.2017



Deployment mit Tomcat-Server ...

➥ Servlet ist nun unter dieser URL ansprechbar:

➥ http://localhost:8080/test/hello

➥ HTML-Datei zum Aufruf des Servlets kann z.B. nach$CATALINA_BASE/webapps/ROOT/hello.html kopiert werden

➥ URL dann http://localhost:8080/hello.html

➥ Anmerkungen:

➥ Servlet-Klassen durfen nicht im CLASSPATH von Tomcat sein!➥ Tomcat nie im Verzeichnis starten, in dem die Servlet-

Klassen liegen!

➥ Tomcat 6.0 kann beim Deployment auch laufen

➥ WAR Archiv wird bei Anderung erneut ausgepackt, Klassenwerden neu geladen

6.1 Servlets ...


6.1.4 Lebenszyklus eines Servlets

➥ Beim Start des Servers oder durch Client-Anfrage:

➥ Servlet-Klasse wird in Web-Server geladen

➥ eine Instanz der Servlet-Klasse wird erzeugt

➥ die init()-Methode wird aufgerufen

➥ Bei einer HTTP-Anfrage:

➥ Erzeugung eines neuen Threads, der die Methode doGet()

bzw. doPost() ausfuhrt

➥ Implementierung der Methoden muß thread-sicher sein!

➥ Bei Entfernung des Servlets aus dem Server

➥ Aufruf der Methode destroy()

6.1 Servlets ...


6.1.5 Wichtige Klassen und Methoden

➥ HttpServletRequest: HTTP-Anfrage

➥ String getParameter(String name)

➥ liefert Wert des genannten Anfrage-Parameters

➥ z.B. bei GET /buy.html?what=shoe HTTP 1.0

➥ HttpSession getSession()

➥ liefert bzw. erzeugt Sitzungs-Objekt (☞ 6.1.6)

➥ HttpServletResponse: HTTP-Antwort

➥ void setContentType(String type)

➥ setzt MIME-Typ der Antwort (i.d.R. "text/html")

➥ PrintWriter getWriter()

➥ liefert PrintWriter zum Schreiben der Ausgabe

6.1 Servlets ...


6.1.6 Sitzungs-Management

➥ Methode getSession() erlaubt Management von

Client-Sitzungen

➥ erzeugt neue Sitzung, falls noch keine existiert

➥ liefert Sitzungs-Objekt HttpSession als Ergebnis

➥ Verfolgung von Sitzungen:

➥ Server erzeugt eindeutige Sitzungs-ID

➥ Sitzungs-ID wird als Cookie im Client gespeichert

➥ Cookie wird bei jeder erneuten Anfrage an Server ubertragen

➥ (Alternativ kann Sitzungs-ID auch an URLs angefugt werden)

6.1.6 Sitzungs-Management ...


Das HttpSession-Objekt

➥ Identifiziert eindeutig eine Client-Sitzung

➥ Erlaubt, beliebige Information sitzungs-lokal zu speichern

➥ Wichtige Methoden:

➥ String getId(): liefert Sitzungs-ID

➥ boolean isNew(): neue Sitzung?

➥ void setAttribute(String name, Object value)

➥ Speichern sitzungslokaler Daten unter gegebenem Namen

➥ Object getAttribute(String name)

➥ Auslesen sitzungslokaler Daten mit gegebenem Namen

➥ setMaxInactiveInterval(int interval)

➥ Einstellen des Sitzungs-Timeouts



Beispiel: Hello-World mit sitzungslokalem Zahler

public void doGet(HttpServletRequest request,


throws IOException, ServletException {

Integer counter;

HttpSession session = request.getSession();

response.setContentType("text/html");

PrintWriter out = response.getWriter();

out.println("<html>");

out.println("<head><title>Hallo World</title></head>");

out.println("<body>");

if (session.isNew()) {

out.println("<b>Welcome to new session</b><br>");

}



Beispiel: Hello-World mit sitzungslokalem Zahler ...

counter = (Integer)session.getAttribute("HelloSession.cntr");

if (counter == null) {

counter = 1;

}

else {

counter++;

}

session.setAttribute("HelloSession.cntr", counter);


out.println("<b>" + counter + ". Hello to " + name + "!</b>");

out.println("<br>Session ID: " + session.getId() + "</body>");

out.println("</html>");

out.close();

}



6.2 Java Server Pages (JSP)

➥ Ziel: einfachere Generierung dynamischer HTML-Seiten

➥ Probleme von Servlets:

➥ Ausgabe von HTML-Code in println()-Anweisungen istumstandlich / fehleranfallig

➥ der großte Anteil davon ist statisch

➥ Installation und Deployment von Servlets ist schwierig

➥ verglichen mit statischen HTML-Seiten

➥ Losungsidee:

➥ Einbetten von Java-Servlet-Code in statische HTML-Seiten

➥ beim ersten Aufruf der Seite wird uber JSP-Compiler auto-matisch ein Servlet erzeugt und in WWW-Server geladen

➥ spatere Aufrufe nutzen dann direkt das Servlet

6.2 Java Server Pages (JSP) ...


6.2.1 Spezielle Tags fur JSP

➥ Tag fur Ausdrucke: <%= Ausdruck %>

➥ Wert des Java-Ausdrucks erscheint in HTML-Ausgabe

➥ Beispiel:

➥ <html><body> 17 + 4 = <%= 17+4 %> </body></html>

➥ Ergebnis: <html><body> 17 + 4 = 21 </body></html>

➥ Tag fur Java-Code: <% Java-Code %>

➥ angegebener Java-Code wird in doGet() bzw. doPost()

Methode eines Servlets ausgefuhrt

➥ Ausgabe wird in HTML-Ausgabe eingefugt

➥ Java-Code kann auch mit regularem HTML-Code gemischtwerden

➥ z.B. fur bedingte HTML-Ausgaben

6.2.1 Spezielle Tags fur JSP ...


➥ Tag fur Java-Code: <% Java-Code %> ...

➥ Beispiel:

<html>

<body>

<%

java.util.Date date = new java.util.Date();

if (date.getHours() < 12) {

%>

Guten Morgen!

<% } else { %>

Guten Tag!

<% } %>

Es ist jetzt <%= date.toString() %>.

</body>

</html>

6.2.1 Spezielle Tags fur JSP ...


➥ Tag zur Deklaration globaler Variablen: <%! Deklaration %>

➥ globale Variable = Attribut der erzeugten Servlet-Klasse

➥ Wert bleibt uber alle Aufrufe der JSP-Seite hinweg erhalten

➥ auch uber verschiedene Client-Sitzungen hinweg

➥ Beispiel: Hit-Counter

<html>

<body>

<%! int hitCount = 0; %>

Hit Count: <%= ++hitCount %>

</body>

</html>



6.2.2 Vordefinierte Variablen

➥ Java-Code in JSP-Seiten kann u.a. folgende vordefinierte

Variablen nutzen:

➥ request

➥ HttpServletRequest-Parameter der Servlet-Methoden

doGet() bzw. doPost()

➥ response

➥ HttpServletResponse-Parameter

➥ out ( ≈ response.getWriter() )

➥ JSPWriter (≈ PrintWriter) fur HTML-Ausgabe

➥ session ( = request.getSession() )

➥ HttpSession-Objekt fur aktuelle Client-Sitzung



6.2.3 Beispiele

➥ Hello-World (funktional identisch mit Beispiel aus 6.1.3)

<html>

<body>

<%! int counter = 0; %>

<%

counter++;


%>

<b><%= counter%>. Hello to <%= name%>!</b>

</body>

</html>

6.2.3 Beispiele ...


➥ Hello-World mit sitzungslokalem Zahler(funktional identisch mit Servlet-Beispiel aus 6.1.6)

<html>

<body>

<%

Integer counter;

if (session.isNew()) {

out.println("<b>Welcome to new session</b><br>");

}

counter = (Integer)

session.getAttribute("HelloSession.cntr");

if (counter == null) {

counter = 1;

}

6.2.3 Beispiele ...


else {

counter++;

}

session.setAttribute("HelloSession.cntr", counter);


out.println("<b>" + counter + ". Hello to "

+ name + "</b>");

out.println("<br>Session ID: " + session.getId());

%>

</body>

</html>



6.2.4 JSP Direktiven

➥ JSP bietet einige Direktiven, die das Verhalten der JSP-Seite

kontrollieren

➥ Allgemeine Syntax: <%@ Direktive %>

➥ Wichtige Beispiele:

➥ <%@ include file="copyright.html" %>

➥ Einfugen der Datei copyright.html in die JSP-Seite

➥ <%@ page import="javax.rmi.*, javax.naming.*" %>

➥ Importieren von Java-Paketen (komma-separierte Liste)



6.2.5 JSP und Java Beans

➥ JSP-Seiten konnen auch auf Java Beans zuruckgreifen:

➥ <jsp:useBean id="product"

class="com.company.ProductBean"/>

➥ Erzeugt eine Bean-Instanz fur alle Aufrufe der JSP-Seite

➥ Referenz in der globalen Variable product gespeichert

➥ Abfrage von Properties der Bean:

➥ <jsp:getProperty name="product" property="Price"/>

➥ entspricht <%= product.getPrice() %>

➥ Setzen von Properties der Bean:

➥ <jsp:setProperty name="product" property="Price"

value="12.50"/>

➥ Vorteil: Modularitat, weniger / kein Java-Code in der JSP-Seite



6.3 Zusammenfassung

➥ Servlets: Java-Klassen zur Bearbeitung von HTML-Anfragen in

WWW-Servern

➥ Erzeugung dynamischer HTML-Seiten

➥ Klassen: HttpServlet, HttpServletRequest,

HttpServletResponse

➥ Im Server: genau eine Instanz der Servlet-Klasse

➥ Sitzungs-Management kann/muß explizit programmiertwerden (HttpSession)

➥ JSP: Vereinfachter Umgang mit Servlets

➥ Mischung von statischem HTML-Code und Servlet-Code

➥ Servlet wird dynamisch aus JSP-Seite genieriert



7 Web Services

7 Web Services ...


Inhalt

➥ Einfuhrung

➥ Web-Service-Standards

➥ XML, SOAP, WSDL, UDDI

➥ Web Services mit Axis2

➥ Sicherheit von Web Services

7 Web Services ...


Literatur

➥ Hammerschall, Kap. 7

➥ Langner: Web Services mit Java

➥ Hein, Zeller: Java Web Services

➥ A. Eberhart, S. Fischer: Web Services, Hanser, 2003.

➥ M. P. Papagoglou: Web Servces: Principles and Technology,

Pearson, 2008.

➥ T. Frotscher, M. Teufel, D. Wang: Java Web Services mit Apache

Axis2, Entwickler.press, 2007

➥ Zu XML auch: Horstmann / Cornell, Kap. 12

7 Web Services ...


7.1 Einfuhrung

➥ Im Web heute: Mensch-Maschine-Kommunikation

➥ statische und dynamische Web-Seiten (Servlets, JSP, ...)

➥ Ziel von Web-Services: Maschine-Maschine-Kommunikation

➥ Vision: Web-Services bieten komplexe Dienste an, suchendazu eigenstandig nach Teildiensten im Netz

InternetInternet

Web Service

Web Service

Web Service

Web Service

Hotel−Service

ServiceFlugbuchungs−

ServiceAutobuchungs−

Client−Anwendung

Reise−Service

7.1 Einfuhrung ...


➥ Ziel von Web Services:

➥ plattform- und sprachunabhangige Nutzung von Diensten auf

entfernten Rechnern

➥ Modell ist dienst-orientiert, nicht objekt-orientiert

➥ Web Services definieren kein verteiltes Objektmodell

➥ Dienste sind als zustandslos angenommen

➥ aber: Erweiterungen fur Sitzungsbehandlung moglich

➥ Web Services kommunizieren durch den Austausch von XML-

Dokumenten

➥ I.a. synchrone Kommunikation mit Anfrage/Antwort-Muster

➥ aber auch allgemeinere Kommunikationsmuster moglich

➥ Anfragen ohne Antwort, Ereignismeldungen, ...

7.1 Einfuhrung ...


➥ Web Services sind zunachst nur uber zwei Standards definiert:

➥ das Kommunikationsprotokoll (SOAP)

➥ die Schnittstellenbeschreibung (WSDL)

➥ Diese reichen aus, um Interoperabilitat zu gewahrleisten

➥ vgl. IIOP und OMG-IDL bei CORBA

➥ Web Service Frameworks (z.B. Axis2) bieten daruberhinaus

(proprietare) Werkzeuge und APIs fur z.B.

➥ die Erzeugung von Client- und Server-Stubs

➥ die Erzeugung / Manipulation von SOAP-Nachrichten

➥ das Deployment von Web Services

7 Web Services ...


7.2 Web-Service-Standards

➥ Grundelemente zur Realisierung von Web Services:

➥ SOAP (ursprunglich Simple Object Access Protocol)

➥ zum Nachrichtenaustausch

➥ legt i.w. Codierung von Datenstrukturen fest

➥ WSDL (Web Service Description Language)

➥ Dienst- und Schnittstellenbeschreibung

➥ enthalt u.a. auch”Ort“ des Dienstes (Host / Port)

➥ UDDI (Universal Description and Discovery Interface)

➥ zur Registrierung und zum Auffinden von Diensteanbietern

und Diensten

➥ Alle drei Elemente basieren auf XML

7.2 Web-Service-Standards ...


7.2.1 XML (Extensible Markup Language)

➥ Deskriptive Sprache zur Beschreibung komplexer Datenstruktu-

ren in einem Dokument

➥ vorwiegend zum Datenaustausch zwischen Systemen

➥ d.h. XML liefert ein vereinheitlichtes Datenfomat

➥ Technisch:

➥ XML-Dokument ist ein Textdokument mit Tags, die Nutzinfor-

mation umschließen (Elemente)

➥ Elemente konnen verschachtelt werden

➥ hierarchische Dokumenten-Struktur (mit Verweisen)

➥ Syntax ahnlich wie bei HTML, jedoch strikter

➥ aber: bei XML legen Tags die Bedeutung der Information

fest, bei HTML die Formatierung

7.2.1 XML (Extensible Markup Language) ...


Aufbau eines XML-Dokuments

➥ Ein XML-Dokument besteht aus zwei Teilen:

➥ Kopf (Header ): XML Version, Zeichensatz, ggf. Angabe des

Dokumententyps (DTD bzw. XML-Schema, s. Folie 348ff)

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE addressbook SYSTEM ¨addressbook.dtd¨>

➥ Rumpf (Body ): verschachtelte Folge von Elementen

<addressbook>

<mail-address category="professor">

<name>Roland Wismuller</name>

<email>[email protected]</email>

</mail-address>

</addressbook>



Wohlgeformte XML-Dokumente

➥ Ein XML-Dokument ist wohlgeformt, wenn es die syntaktischen

Regeln von XML einhalt, u.a.:

➥ Struktur eines Elements: <name> ... </name>

➥ Ende-Tag muß immer vorhanden sein

➥ Abkurzung fur leere Elemente: <leeresElement/>

➥ korrekte Verschachtelung der Elemente in Baumstruktur

➥ nicht: <name>...<email> </name>...</email>

➥ XML-Dokument muß genau ein Wurzelelement besitzen

➥ offnende (und leere) Tags konnen auch Attribute besitzen

➥ z.B. <person name="Heinz" age="9">... </person>

➥ Kommentare: 



Gultige XML-Dokumente

➥ Nicht jedes wohlgeformte XML-Dokument beschreibt eine gultige

Datenstruktur

➥ der Datentyp muß ebenfalls berucksichtigt werden

➥ z.B. im Beispiel von Folie 344: ein Adreßbucheintrag muß aus

Name und Email-Adresse bestehen

➥ Dazu: XML erlaubt die Definition eines Dokumententyps bzw.

Schemas

➥ legt Namen, Verschachtelung, Abfolge, und moglichen Inhalt

der Elemente fest

➥ DTD (Document Type Definition): alte Methode

➥ XML Schema: aktuelle Methode



Namensraume in XML

➥ Um Tag-Namen aus verschiedenen DTDs bzw. Schematas

unterscheiden zu konnen, fuhrt XML Namensraume ein

➥ Namensraum wird durch URI (meist: URL) identifiziert

➥ URI garantiert weltweite Eindeutigkeit

➥ Beispiel:

<bsp:myElem xmlns:bsp="http://www.uni-siegen.de/bsp">

<bsp:mySubElem>Hallo</bsp:mySubElem>

</bsp:myElem>

➥ der String bsp ist ein Alias fur den Namensraum

➥ wird allen Elementen des Namensraums vorangestellt

➥ Ein Dokument kann auch mehrere Namensraume nutzen



XML Schema

➥ Ein XML Schema ist ein XML-Dokument, das den Aufbau vonXML-Dokumenten beschreibt

➥ Prinzip: zulassige Struktur und Inhalt eines XML-Dokuments wirdals Datentyp beschrieben

➥ Bausteine:

➥ vordefinierte, einfache Datentypen

➥ ggf. mit Einschrankung von Wertebereich bzw. Syntax

➥ selbst definierte, einfache Datentypen (z.B. Aufzahlung)

➥ komplexe (zusammengesetzte) Datentypen

➥ Sequenzen (feste Folge von Unterelementen)

➥ Alternativtypen (alternativ wahlbare Unterelemente)

➥ Kardinalitats-Angabe (wie oft muß/darf Element auftreten?)



Beispiel: XML Schema fur das Adressbuch

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xsd:element name="addressbook" type="AddressBookType"/>

<xsd:element name="mail−address" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType name="AddressBookType">

<xsd:complexType name="MailAddressType"> <xsd:sequence>

<xsd:element name="email" type="xsd:string"

</xsd:sequence>

<? xml version="1.0" encoding="UTF−8" ?>

Root−Element Namensraum

AddressBookType be−steht aus 0 oder mehr<mail−address> Elementen

Die Elemente <name> und <email> enthalten Textund dann ein oder mehr <email> Elemente

<mail−address> enthält erst ein <name> Element

<xsd:element name="name" type="xsd:string"/>

maxOccurs="unbounded"/>

"http://www.w3.org/2001/XMLSchema"

"addressbook" "AddressBookType"

"AddressBookType"

"mail−address" "0" "unbounded" "MailAddressType"

"name" "xsd:string" "email" "xsd:string" "unbounded"

"1.0" "UTF−8" xml version

xsd:schema

xsd:element

xsd:complexType

xsd:element

xsd:complexType xsd:sequence xsd:element xsd:element

xsd:sequence



Beispiel: XML Schema fur das Adressbuch ...

<xsd:attribute name="category" type="CategoryType" use="optional"/>

</xsd:complexType>

</xsd:element>

</xsd:complexType>

<xsd:enumeration value="assistant"/>

</xsd:simpleType>

</xsd:schema>

<xsd:enumeration value="professor"/>

<xsd:simpleType name="CategoryType" base="xsd:string">

<mail−address> kannein Attribut vom TypCategoryType haben

CategoryType ist einString, der nur die Werte"professor" oder "assistant"haben kann

xsd:schema

xsd:enumeration

xsd:enumeration

xsd:simpleType

xsd:complexType

xsd:element

xsd:complexType

xsd:attribute "category" "CategoryType" "optional"

"CategoryType" "xsd:string"

"professor"

"assistant"

xsd:simpleType



Beispiele fur XML-Dokumente (nur Rumpf)

Gültig: Ungültig:

<addressbook> <mail−address> <name>Hugo</name>

</mail−address> <mail−address category="assistant"> <name>Fritz</name>

</mail−address>

<email>[email protected]</email>

<email>Hallo</email> <email>fr@home</email>

</addressbook>

<addressbook> <mail−address>

</mail−address> <mail−address category="assistant"> <name>Fritz</name> </mail−address>

<email>[email protected]</email> <name>Hugo</name>

<name>Hans</name></addressbook>



XML Parser

➥ Fur XML existieren generische Parser, die zusatzlich auch die

Gultigkeit des Dokuments prufen konnen

➥ Vorteil von XML gegenuber anderen Beschreibungssprachen

➥ Es gibt zwei Parsertypen:

➥ SAX-Parser erzeugen fur jedes auftretende XML-Primitiv ein

Ereignis

➥ Anwendung muß zugehorige Handler definieren

➥ DOM-Parser setzen Dokument komplett in Datenstruktur um

➥ DOM: Document Object Model

➥ vorteilhaft, wenn Dokument manipuliert werden soll

➥ nachteilig bei großen Dokumenten (Speicherbedarf)



7.2.2 SOAP

➥ XML-basiertes Protokoll zum Austausch strukturierter Daten

➥ Unabhangig vom darunterliegenden Transportprotokoll

➥ Bindungen fur HTTP, SMTP, FTP, etc. moglich

➥ SOAP ist ein allgemeines Nachrichtenprotokoll

➥ SOAP 1.2 definiert mehrere Nachrichtenaustausch-Muster, u.a.:

➥ dialogorientierter (freier) Nachrichtenaustausch

➥ Anfrage/Antwort-Muster (fur RPC)

➥ SOAP definiert i.W. ein Nachrichtenformat

➥ SOAP ist erweiterbar

➥ z.B. fur Sicherheit (Verschlusselung etc.)

➥ Aktuelle Version: 1.2 (April 2007)

7.2.2 SOAP ...


Das SOAP-Nachrichtenformat

<?xml version="1.0" ?>

<env:Envelope

</env:Envelope>

</env:Header>

<env:Header>

<env:Body>

xmlns:env="http://www.w3.org/2003/05/soap−envelope">

SOAP Body

SOAP Header

SOAP Envelope

Header Block (anwendungsspezifisch)

Header Block (anwendungsspezifisch)

Nachrichten−Rumpf (anwendungsspezifisch)

</env:Body>

7.2.2 SOAP ...


Das SOAP-Nachrichtenformat ...

➥ SOAP legt i.W. nur Struktur der Nachrichten fest

➥ Inhalt von Header und Body sind anwendungsspezifisch

➥ d.h. Schema laßt beliebige Elemente zu

➥ Header ist optional, enthalt Metadaten

➥ z.B. Transaktionsnummern, Authentifizierungsdaten

➥ Body muß vorhanden sein, enthalt Anwendungsdaten

➥ Elemente des Envelope liegen in eigenem Namensraum

➥ typisch: eigene Namensraume fur Header -Blocke und Body

➥ Hinzufugen weiterer Elemente im Envelope moglich

7.2.2 SOAP ...


Der SOAP-Header

➥ Enthalt Anweisungen, die festlegen, wie ein SOAP-Knoten die

Nachricht verarbeiten soll

➥ SOAP-Knoten: Sender, Empfanger und Zwischenknoten (z.B.

Weiterleitung, Signierung, ...)

➥ Beispiele:

➥ Sicherheits-Header

➥ Zertifikat und Signatur fur einige Body -Elemente

➥ anwendungsspezifische Metadaten

➥ z.B. Kundendaten des Clients

➥ Die Elemente des Headers werden von SOAP nicht festgelegt,es gibt aber vorgeschriebene Attribute der Header -Elemente

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (11/15) xii

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

08.12.2017

7.2.2 SOAP ...


Der SOAP-Header ...

➥ Attribute von SOAP Header -Elementen:

➥ role: fur wen ist der Header gedacht?

➥ Kodierung der Rollen durch URI (wg. Eindeutigkeit)

➥ einige vordefinierte URIs, u.a. fur beliebige Empfangs-

knoten und endgultigen Empfanger

➥ mustUnderstand: der Knoten, fur den der Header -Block

gedacht ist, muß ihn verstehen oder eine Fehlernachricht

zuruckgeben

➥ relay: soll der Header -Block weitergereicht werden, falls er

nicht verarbeitet wurde?

➥ verarbeitete Header -Blocke werden nie weitergereicht

(konnen aber erneut eingefugt werden)

7.2.2 SOAP ...


Der SOAP Body

➥ Aufbau ist abhangig von Kommunikationsstil und Codierungsstil

➥ Kommunikationsstil (communication style / binding style):

➥ RPC: SOAP-Nachrichten speziell fur RPCs

➥ Prozeduraufruf mit Parametern bzw. Ruckgabewerte

➥ Aufbau des Body ist i.w. durch SOAP festgelegt

➥ document : SOAP-Nachrichten fur allgemeine Dokumente

➥ fur nachrichtenorientierte Kommunkation, wird aber auch

fur RPCs verwendet➥ Body kann beliebige XML-Daten enthalten

➥ Aufbau des Body ist nur durch XML-Schema im WSDL-

Dokument festgelegt

7.2.2 SOAP ...


Der SOAP Body ...

➥ Codierungsstil (encoding style / use):

➥ encoded :

➥ SOAP-spezifische Typen

➥ Werte in der SOAP-Nachricht haben explizite Typangabe

➥ literal :

➥ Datentypen werden durch XML-Schema beschrieben

➥ bei RPC-Stil nur Parameter, bei document gesamter Body

➥ Definition eigener Datentypen mit XML-Schema moglich

➥ z.B. auch zusammengesetzte Datenstrukturen

➥ Relevante Kombinationen: RPC/encoded und document/literal

➥ encoded nicht konform zu WS-I (Web Services-Interoperability )

7.2.2 SOAP ...


Aufbau des SOAP Body beim RPC Stil

➥ Body enthalt immer nur genau ein Element

➥ Bei Anfragenachricht:

➥ Name = Name der aufzurufenden Operation

➥ Kindelemente: Parameter der Operation (mit Namen)

➥ Bei Antwortnachricht:

➥ Name ist frei wahlbar (meist: Operationsname + Response)

➥ Kindelemente:

➥ Ruckgabewert (meist result), falls Ergebnistyp 6= void

➥ Ausgabeparameter der Operation (mit Namen)

➥ zum Melden von Fehlern: spezielles <fault>-Element

➥ Unterelemente fur Fehlercode und -beschreibung

7.2.2 SOAP ...


Beispiel einer SOAP-Nachricht (RPC/encoded)

➥ Request-Nachricht fur einen Aufruf der Java-MethodeString reserviere(String flugNr, int sitze, Date datum);

<?xml version=’1.0’ encoding=’UTF-8’?><env:Envelopexmlns:env="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><env:Body><ns1:reserviereenv:encodingStyle="http://schemas.xmlsoap.org/soap/encodingxmlns:ns1="http://www.web-air.de/axis/Buchung.jws"><flugNr xsi:type="xsd:string">WA417</flugNr><sitze xsi:type="xsd:int">3</sitze><datum xsi:type="xsd:dateTime">2003-07-11</datum>

</ns1:reserviere></env:Body>

</env:Envelope>

7.2.2 SOAP ...


Aufbau des SOAP Body beim document Stil

➥ Nach WS-I sollte Body nur ein Element enthalten

➥ ggf.”Einwickeln“ der Argumente in ein neues Element

(wrapped Konvention)

➥ Problem bei RPCs: Name der Operation geht aus SOAP-Nach-

richt nicht zwangslaufig hervor

➥ Mogliche Abhilfen:

➥ bei document/wrapped : Elementname = Operationsname

➥ Spezifikation uber das Transportprotokoll

➥ z.B. im HTTP-Header: SOAPAction (SOAP 1.1) bzw.

action Attribut von Content-Type (SOAP 1.2)

➥ WS-Addressing: Spezifikation im SOAP Header

7.2.2 SOAP ...


Beispiel einer SOAP-Nachricht (document/literal/wrapped)

➥ Request-Nachricht fur einen Aufruf der Java-Methode

String reserviere(String flugNr, int size, Date datum);

<?xml version=’1.0’ encoding=’UTF-8’?><soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><reserviere xmlns="http://ws.apache.org/axis2"><flugNr>WA417</flugNr><sitze>3</sitze><datum>2003-07-11</datum>

</reserviere></soapenv:Body>

</soapenv:Envelope>

7.2.2 SOAP ...


Beispiel einer SOAP-Nachricht (document/literal/wrapped) ...

➥ Antwortnachricht

<?xml version=’1.0’ encoding=’UTF-8’?><soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Body><reserviereResponse xmlns="http://ws.apache.org/axis2"><return>GHFTR89</return>

</reserviereResponse></soapenv:Body>

</soapenv:Envelope>

7.2.2 SOAP ...


Die SOAP-HTTP-Bindung

➥ SOAP-Standard definiert zwei Methoden:

➥ Verwendung von HTTP POST:

➥ SOAP-Anfrage-Nachricht wird im Rumpf der HTTP-Anfrage

an den Server gesendet

➥ Antwort als SOAP-Nachricht in der HTTP-Antwort

➥ Verwendung von HTTP GET:

➥ Operation und Parameter werden in URL der HTTP-Anfrage

codiert (ohne SOAP)

➥ Antwort als SOAP-Nachricht in der HTTP-Antwort

➥ Empfehlung des Standards:

➥ GET-Methode (nur) verwenden bei Aufrufen ohne Seiteneffek-

te und ohne SOAP-Header



7.2.3 WSDL

➥ XML-basierte Sprache zur Beschreibung von Diensten

➥ also u.a. Schnittstellen-Beschreibungssprache

➥ zusatzlich aber auch: Ort (URL) des Dienstes und zu verwen-

dendes Protokoll

➥ Eigenschaften von WSDL

➥ unabhangig von Programmiermodell, Implementierungsspra-

chen und Transportprotokoll

➥ WSDL ist auch unabhangig von SOAP

➥ Unterstutzung von XML Schema zur Definition von Typen

➥ WSDL ist selbst uber XML Schema definiert

➥ Aktuelle Version: 2.0 (Juni 2007), verwendet haufig noch 1.1

7.2.3 WSDL ...


Aufbau eines WSDL-Dokuments

targetNamespace="http://www.web−air.de/Buchung/"...

xmlns:wsdl="http://www.w3.org/2003/06/wsdl">

</wsdl:definitions>

Beschreibung der Nachrichtenformate

Beschreibung der Schnittstellen

Beschreibung der Bindungen

Beschreibung des Dienstes

Wurzelelement

Spezifikation von Datentypen

<?xml version="1.0" ?>

<wsdl:definitions

(WSDL 1.1)

7.2.3 WSDL ...


Zur Struktur eines WSDL-Dokuments

➥ Ein WSDL-Dokument beschreibt Dienste

➥ Ein Dienst wird uber ein oder mehrere Endpunkte erreicht

➥ Ein Endpunkt beschreibt den Ort (URI) des Dienstes und ist mit

genau einer Bindung assoziiert

➥ Eine Bindung bindet die Operationen einer Schnittstelle an ein

bestimmtes Protokoll

➥ Eine Schnittstelle beschreibt mehrere Operationen

➥ Fur jede Operation werden die Nachrichtenformate fur Ein- und

Ausgabeparameter festgelegt (WSDL 1.1)

➥ Ein Nachrichtenformat besteht aus einer Sequenz von Feldern

mit gegebenen Datentypen

7.2.3 WSDL ...


Beispiel zur allgemeinen Struktur eines Dienstes

Dienst

Endpunktmit URI 1(SOAP) (HTTP GET)

mit URI 2Endpunkt

(HTTP POST)mit URI 3Endpunkt Endpunkt

mit URI 4(SOAP) (HTTP GET)

mit URI 5Endpunkt

Operation 1Operation 2Operation 3

Schnittstelle 1

Operation 4Operation 5

Schnittstelle 2

7.2.3 WSDL ...


Spezifikation von Datentypen

➥ Element <types>

➥ Erlaubt Definition eigener komplexer Datentypen

➥ Nutzung von XML Schema

➥ Beispiel: Datentyp fur Parameter einer Flugreservierung

<wsdl:types>

<xs:schema targetNamespace="http://www.web-air.de/Buchung/">

<xs:element name="reservierung">

<xs:complexType>

<xs:sequence>

<xs:element name="flugNr" type="xs:string"/>

<xs:element name="sitze" type="xs:int"/>

<xs:element name="date" type="xs:date"/>

...

</wsdl:types>

7.2.3 WSDL ...


Beschreibung der Nachrichtenformate (WSDL 1.1)

➥ Element <message>

➥ Fur jede vom Dienst verwendete Nachricht (Anfrage, Antwort, ...)wird das Format definiert:

➥ eine Nachricht besteht aus beliebig vielen Teilen mit festgeleg-tem Datentyp

➥ Standard XML-Datentyp oder in <types> definiert

➥ ublich: nur ein Teil mit einem complexType als Typ

➥ Beispiel (ohne Namensraumangabe fur WSDL-Elemente):

<message name="reserviereRequest"><part name="parameters" type="ns:reservierung"/>

</message><message name="reserviereResponse">

<part name="parameters" type="ns:reserviereResponse"/></message>

7.2.3 WSDL ...


Beschreibung der Schnittstellen

➥ Element <portType> (WSDL 2.0: <interface>)

➥ Beschreibt beliebig viele Operationen mit

➥ ihren Eingabe-, Ausgabe- und ggf. Fehlernachrichtentypen

➥ ihrem Interaktionsmuster

➥ z.B. nur Eingabenachricht, Request /Response, ...

➥ definiert durch Reihenfolge der Nachrichtenspezifikationen


<portType name="BuchungPortType"><operation name="reserviere"><input message="ns:reserviereRequest" /><output message="ns:reserviereResponse" />

</operation></portType>

7.2.3 WSDL ...


Beschreibung der Bindungen

➥ Element <binding>

➥ Zu jeder Schnittstelle kann es eine oder mehrere Bindungen

geben

➥ Die Bindung legt fest

➥ das Transportprotokoll (z.B. SOAP, HTTP PUT, HTTP GET)

➥ den Kommunikationsstil (rpc oder document)

➥ fur jede Operation:

➥ URI fur den Aufruf der Operation

➥ wird bei HTTP in das SOAPAction-Element bzw. action-

Attribut im HTTP-Header ubernommen➥ wichtig bei document, vgl. Folie 362

➥ Codierung der Ein- und Ausgabe (encoded oder literal)

7.2.3 WSDL ...


Beschreibung der Bindungen ...

➥ Beispiel (ohne Namensraumangabe fur WSDL-Elemente):<binding name="BuchungSoapBinding" type="ns:BuchungPortType">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />

<operation name="reserviere"><soap:operation soapAction="urn:reserviere" /><input>

<soap:body use="literal" /></input><output>

<soap:body use="literal" /></output>

</operation></binding>

7.2.3 WSDL ...


Beschreibung des Dienstes

➥ Beschreibung besteht aus Liste von Endpunkten

➥ Element <port> (WSDL 2.0: <endpoint>)

➥ jeweils mit Ortsangabe (URI) und zugehoriger Bindung


<service name="Buchung">

<port name="BuchungHttpSoapEndpoint"

binding="s0:BuchungSoapBinding">

<soap:address

location="http://www.web-air.de/Buchung/Buchung.asmx" />

</port>

</service>

7.2.3 WSDL ...


Vollstandiges Beispiel eines WSDL-Dokuments (WSDL 1.1)

➥ Dienst mit zwei Operation (als Java-Interface beschrieben):public interface Test {

public String getIt();

public void putIt(String it);

}

➥ WSDL-Dokument fur den entsprechenden Web-Service:


<wsdl:definitions xmlns:axis2="http://ws.apache.org/axis2"

xmlns:ns="http://ws.apache.org/axis2/xsd"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

targetNamespace="http://ws.apache.org/axis2">

7.2.3 WSDL ...


<wsdl:types><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"attributeFormDefault="qualified" elementFormDefault="qualified"targetNamespace="http://ws.apache.org/axis2/xsd"><xs:element name="getItResponse"><xs:complexType><xs:sequence><xs:element name="return" nillable="true" type="xs:string"/>

</xs:sequence></xs:complexType>

</xs:element><xs:element name="putIt"><xs:complexType><xs:sequence><xs:element name="param0" nillable="true" type="xs:string"/>

</xs:sequence></xs:complexType>

</xs:element></xs:schema>

</wsdl:types>

7.2.3 WSDL ...


<wsdl:message name="getItMessage" /><wsdl:message name="getItResponseMessage"><wsdl:part name="part1" element="ns:getItResponse" />

</wsdl:message><wsdl:message name="putItMessage"><wsdl:part name="part1" element="ns:putIt" />

</wsdl:message><wsdl:portType name="TestPortType"><wsdl:operation name="getIt"><wsdl:input xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdlwsaw:Action="urn:getIt" message="axis2:getItMessage"/>

<wsdl:output xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdlmessage="axis2:getItResponseMessage" wsaw:Action="urn:getIt"/>

</wsdl:operation><wsdl:operation name="putIt"><wsdl:input xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdlwsaw:Action="urn:putIt" message="axis2:putItMessage"/>

</wsdl:operation></wsdl:portType>

7.2.3 WSDL ...


<wsdl:binding name="TestSOAP11Binding" type="axis2:TestPortType"><soap:binding transport="http://schemas.xmlsoap.org/soap/http"style="document" />

<wsdl:operation name="getIt"><soap:operation soapAction="urn:getIt" style="document" /><wsdl:input><soap:body use="literal" />

</wsdl:input><wsdl:output><soap:body use="literal" />

</wsdl:output></wsdl:operation><wsdl:operation name="putIt"><soap:operation soapAction="urn:putIt" style="document" /><wsdl:input><soap:body use="literal" />

</wsdl:input></wsdl:operation>

</wsdl:binding>

7.2.3 WSDL ...


<wsdl:binding name="TestSOAP12Binding" type="axis2:TestPortType"><soap12:binding transport="http://schemas.xmlsoap.org/soap/http"style="document" />...

</wsdl:operation></wsdl:binding><wsdl:service name="Test"><wsdl:port name="TestSOAP11port"binding="axis2:TestSOAP11Binding"><soap:addresslocation="http://localhost:8080/axis2/services/Test" />

</wsdl:port><wsdl:port name="TestSOAP12port"binding="axis2:TestSOAP12Binding"><soap12:addresslocation="http://localhost:8080/axis2/services/Test" />

</wsdl:port></wsdl:service>

</wsdl:definitions>



7.2.4 Nutzung von SOAP und WSDL

➥ Programmierer von Web Services hat i.a. nicht direkt mit SOAPund WSDL zu tun

➥ Web Service Frameworks enthalten Werkzeuge, die

➥ Stubs und Skeletons zum Erzeugen und Interpretieren vonSOAP-Nachrichten generieren

➥ WSDL-Beschreibungen aus z.B. Java Interfaces erzeugen(und umgekehrt)

➥ Aber: Grundkenntnisse nutzlich fur

➥ Verstandnis von Web Services

➥ Fehlersuche / Nutzung der Frameworks

➥ spezielle Funktionen wie z.B. Sicherheit

➥ benotigen Manipulation der SOAP-Nachrichten

7.2.4 Nutzung von SOAP und WSDL ...


Werkzeuge und Java-APIs fur SOAP und WSDL

➥ Java-APIs

➥ JAXM: Erstellung, Verarbeitung und Versand von SOAP-

Nachrichten

➥ javax.xml.soap.*, javax.xml.messaging.*

➥ JAX-RPC: API und Werkzeuge fur RPCs uber SOAP

➥ javax.rpc.*

➥ u.a. auch Erstellung von WSDL und Stubs/Skeletons

➥ Frameworks fur Web-Services

➥ in der Vorlesung: EJB 3 (☞ 7.3) und Axis2 (☞ 7.4)

➥ weitere z.B. IBM Web-Sphere, Microsoft Visual Studio .NET,

BEA WebLogic, Borland JBuilder, ...

➥ integrierte Programmentwicklungs-Umgebungen

7 Web Services ...


7.3 Web-Services und EJB

➥ Eine stateless Session Bean kann durch einfache Annotation zu

einem Web-Service gemacht werden:

@Stateless

@WebService

public class HelloImpl implements HelloRemote {

@WebMethod

public String sayHello() {

return "Hallo? Jemand da?";

}

}

➥ WSDL-Datei bei OpenEJB dann unter folgender URL verfugbar:

➥ http://<host> :<httpejbd-port> /HelloImpl?WSDL

7 Web Services ...


7.4 Web Services mit Axis2

➥ Axis2: Framework fur Entwicklung und Deployment Java-basierterWeb Services

➥ Bestandteile von Axis2

➥ Web Service-Container

➥ Java API

➥ Werkzeuge fur WSDL-Unterstutzung und Deployment

➥ Funktionsumfang von Axis2

➥ Unterstutzung von SOAP 1.1/1.2, WSDL 1.1/2.0

➥ Flexibles Deployment (Hot Deployment / Hot Update)

➥ WSDL-Unterstutzung (Ubersetzung WSDL ↔ Java)

➥ Fehlerbehandlung (Java Exception → <fault>-Nachricht)

➥ Erweiterbarkeit durch Plug-In Module

7.4 Web Services mit Axis2 ...


7.4.1 Technisches zu Axis2

➥ Der Web-Service-Container von Axis2 ist als Servlet realisiert

➥ meist in Verbindung mit dem Tomcat-Server

➥ Im Folgenden wird Kombination Axis2/Tomcat vorausgesetzt

➥ entspricht Installation im Labor H-A 4111

➥ Verzeichnisstruktur von Axis2 (wichtig fur das Deployment)

$CATALINA_BASE

webapps

ROOT

WEB−INF

services Zielverzeichnis für Deployment

Wurzelverzeichnis von tomcat

axis2

7.4.1 Technisches zu Axis2 ...


Start des Axis2 Web-Service-Containers

➥ Wenn Axis2 korrekt installiert ist, muß nur der Tomcat-Server

gestartet werden:

➥ $CATALINA_HOME/bin/catalina.sh run

➥ Wenn Hot Update in Axis2 nicht aktiviert ist, muß Tomcat bei

einer Anderung deployter Web Services neu gestartet werden!

➥ alternativ: Reload von Axis2 im Tomcat-Manager

➥ Funktionstest:

➥ Aufruf der Axis2-Startseite im Browser

➥ URL: http://localhost:8080/axis2/

➥ enthalt u.a. Links zu Validierungsseite und Liste deployter

Web Services



7.4.2 Beispiel: Hello-World mit Axis2

➥ Schritte zur Erstellung der WSDL-Beschreibung

1. Erstellung der Java-Schnittstelle HelloWorld.java

2. Ubersetzen der Schnittstelle:javac HelloWorld.java

3. Erzeugung einer WSDL-Datei aus dieser Schnittstelle:

java2wsdl.sh

-l http://localhost:8080/axis2/services/HelloWorld

-cn HelloWorld

➥ Schritte zur Erstellung des Web Services

1. Erzeugung von Implementierungsrahmen, Hilfsklassen,

Service-Deskriptor und Build-Skript aus der WSDL-Datei:wsdl2java.sh -d adb -uw -ss -p hello -sd

-uri HelloWorld.wsdl

7.4.2 Beispiel: Hello-World mit Axis2 ...


➥ Schritte zur Erstellung des Web Services ...

2. Editieren von src/hello/HelloWorldSkeleton.java

➥ Implementieren der Operationen (Methoden)

3. ggf. Anpassen des Service-Deskriptors (☞ S. 400)

4. Ubersetzen und Packen des Services:

ant jar.server

5. Kopieren des Archivs in das Axis2-Verzeichnis:

cp build/lib/HelloWorld.aar

$CATALINA_BASE/webapps/axis2/WEB-INF/services/

➥ Erster Test kann uber folgende URL erfolgen:

➥ http://localhost:8080/axis2/services/HelloWorld/

sayHello?args0=Roland



➥ Schritte zur Erstellung des Clients

1. Erstellung einer Java-Schnittstelle fur den aufzurufenden Web

Service:

wsdl2java.sh -uri

http://localhost:8080/axis2/services/HelloWorld?wsdl

-d adb -uw -p hello

2. Erstellung des Client-Programms

src/hello/HelloClient.java

3. Ubersetzung und Packen des Client-Programms:ant jar.client

4. Start des Client-Programms:

axis2.sh -cp build/lib/HelloWorld-test-client.jar

HelloClient

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (12/15) xiii

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

15.12.2017



➥ Die Schnittstelle HelloWorld.java:

public interface HelloWorld {

public String sayHello (String name);

}

➥ Der von Hand erganzte Implementierungsrahmensrc/hello/HelloWorldSkeleton.java:

package hello;

public class HelloWorldSkeleton {

int cnt = 0;

public java.lang.String sayHello(java.lang.String args0)

{

return "Hello to " + args0 + " (" + ++cnt + ")";

}

}



➥ Das Client-Programm HelloClient.java:

import hello.*;

public class HelloClient

{

public static void main(String[] args) throws Exception

{

HelloWorldStub stub;

// Referenz auf Stub holen

stub = new HelloWorldStub();

// Methoden des Dienstes aufrufen

System.out.println(stub.sayHello("Roland"));

System.out.println(stub.sayHello("Frank"));

}

}

➥ Vollstandiger Beispielcode: siehe WWW



7.4.3 Details zu den Axis2-Werkzeugen

axis2.sh

➥ ruft java mit notigem CLASSPATH und Java Properties auf

➥ nutzlich zum Start von Clients

java2wsdl.sh

➥ erzeugt WSDL-Dokument aus Java-Schnittstelle

➥ wichtige Optionen:

➥ -l: gewunschte URL des Web Services (Endpunkt)

➥ -cn: (qualifizierter) Name der Klasse

➥ -of: Name der Ausgabedatei

7.4.3 Details zu den Axis2-Werkzeugen ...


java2wsdl.sh: Beispiel

...

−l http://localhost:8080/axis2/services/Hello

public interface HelloWorld { public String sayHello (String name);}

java2wsdl.sh −cn HelloWorld

...

...

<wsdlsoap:address location="http://localhost:8080/axis2/services/Hello"/>

<wsdl:port name="HelloWorldHttpSoap11Endpoint" binding="ns:HelloWorldSoap11Binding">

<wsdl:service name="HelloWorld">

type="ns:HelloWorldPortType">

...

...

</wsdl:message>

<wsdl:message name="sayHelloRequest"> <wsdl:part name="parameters" element="ns:sayHello"/>

<wsdl:portType name="HelloWorldPortType"> <wsdl:operation name="sayHello">

<wsdl:binding name="HelloWorldSoap11Binding"



wsdl2java.sh

➥ erzeugt aus einem WSDL-Dokument u.a.:

➥ Rahmen fur die Java-Implementierungsklasse:

src/Paket /Service Skeleton.java

➥ Service-Deskriptor resources/services.xml

➥ Build-Skript build.xml fur ant

➥ Target jar.server fur Server-Archiv

➥ Target jar.client fur Client-Archiv

➥ Client-Stub fur den Web-Service:

src/Paket /Service Stub.java

➥ Default-Konstruktor: Endpunkt aus WSDL-Dokument

➥ weiterer Konstruktor erlaubt Angabe der Endpunkt-URL als

String



wsdl2java.sh ...

➥ wichtige Optionen:

➥ -d: Festlegung des Data Binding

➥ wie erfolgt die Umwandlung von XML-Dokumenten inJava-Objekte? (adb, jibx, xmlbeans, jaxbri)

➥ -uw: Einschalten des Unwrapping

➥ das (einzige) XML-Element des SOAP-Body wird ineinzelne Parameter zerlegt

➥ -ss: Code-Erzeugung fur Serverseite

➥ -sd: erzeuge Service-Deskriptor

➥ -p: Festlegung des Paketnamens

➥ -uri: Ort des WSDL-Dokuments

➥ -sn: Auswahl eines Services aus dem WSDL-Doument

➥ -pn: Auswahl eines Ports aus dem WSDL-Doument



Konstruktoren der Klasse Service Stub

➥ Service Stub()

➥ erzeugt Stub, der sich mit dem Endpunkt aus der WSDL-Datei

verbindet

➥ Festlegung ggf. uber Option -pn von wsdl2java.sh

➥ Service Stub(String targetEndpoint)

➥ erzeugt Stub, der sich mit dem (als URL) gegebenen

Endpunkt verbindet

(Service ist der Name der Services aus der WSDL-Datei)



Abbildung von Datentypen von XML auf Java durch Axis2

➥ XML-Schema aus WSDL muß in Java-Klassen umgesetzt werden

➥ prinzipiell: je eine Klasse fur Anfrage- und Ergebnisnachricht

➥ mit get- und set-Methoden fur einzelne Komponenten

➥ zusatzlich moglich: unwrapping

➥ entfernt Wrapper-Klasse von document/literal/wrapped

➥ Argumente konnen einzeln an Operation ubergeben

werden

➥ wsdl2java.sh unterstutzt mehrere Moglichkeiten (data bindings):

➥ adb: beste Integration mit Axis2

➥ xmlbeans: vollstandigste Unterstutzung von XML-Schema

➥ jibx: kann mit existierenden Java-Klassen arbeiten, besteUnterstutzung fur unwrapping



Abbildung von Datentypen von XML auf Java durch Axis2 ...

➥ Falls WSDL-Datei durch java2wsdl.sh erzeugt wird:

wsdl2java.sh liefert auch mit unwrapping evtl. nicht mehr die

ursprungliche Schnittstelle

➥ Umsetzung ist i.a. problemlos fur

➥ einfache Datentypen (int, double, boolean, ...)

➥ Arrays und Strings

➥ Remote-Referenzen auf Objekte sind mit Axis2 (und SOAP) nicht

moglich!

➥ im Bedarfsfall muß ggf. mit selbst implementierten Objekt-IDs

gearbeitet werden

➥ Server muß Abbildung von Objekt-ID auf Objekt pflegen

➥ besser: WS-Resource Standard verwenden



Service-Deskriptor

<serviceGroup><service name="HelloWorld">

<messageReceivers><messageReceiver mep="http://www.w3.org/ns/wsdl/in-out"class="hello.HelloWorldMessageReceiverInOut"/>

</messageReceivers><parameter name="ServiceClass">hello.HelloWorldSkeleton</parameter<parameter name="useOriginalwsdl">true</parameter><parameter name="modifyUserWSDLPortAddress">true</parameter><operation name="sayHello"mep="http://www.w3.org/ns/wsdl/in-out"namespace="http://ws.apache.org/axis2"><actionMapping>urn:sayHello</actionMapping><outputActionMapping>urn:sayHelloResponse</outputActionMapping

</operation></service>

</serviceGroup>



Wichtige Elemente im Service-Deskriptor

➥ Parameter modifyUserWSDLPortAddress

➥ falls true: Axis2-Container ersetzt angegebene Port-Adresse

durch seine eigene

➥ Probleme z.B. mit NAT und Web-Proxies

➥ im Labor H-A 4111 auf false setzen

➥ Attribut scope des service-Tags

➥ fur Sitzungsverwaltung

➥ mogliche Werte: request, soapsession, transportsession,

application

➥ siehe Abschnitt 7.4.4



Ablauf der Kommunikation

"Hello to Roland"

<?xml version<soapenv:Env<sayHello ...>...

<?xml version<soapenv:Env<sayHelloRes...

"Roland"

...

<sayHello ...><args0>Roland</args0></sayHello>

POST /axis2/services/HelloWorld HTTP/1.1

<soapenv:Envelope ...>...<soapenv:Body>

...

...

Content−Type: application/soap+xml;

<?xml version="1.0" encoding="UTF−8"?>

charset=UTF−8; action="urn:sayHello"

HTTP/1.1 200 OKServer: Apache−Coyote/1.1Content−Type:application/soap+xml;action=

<?xml version="1.0" encoding="UTF−8"?><soapenv:Envelope ...>...<soapenv:Body>

... "urn:sayHelloResponse";charset=UTF−8

<sayHelloResponse ...><return>Hello toRoland</return></sayHelloResponse>

Client

ServerWeb−

Tomcat

Server

HelloWorld

doPost()

sayHello()

ServletAxis2



7.4.4 Sitzungs-Management mit Axis2

➥ Sitzungs-Management ermoglicht, in einem Web-Service einenclient-spezifischen Zustand zu verwalten

➥ Manuell programmiertes Sitzungs-Management:

➥ es gibt genau eine Instanz der Implementierungs-Klasse

➥ jede Operation erhalt Sitzungs-ID als zusatzlichen Parameter

➥ Abbildung der Sitzungs-ID auf Sitzungsdaten z.B. uberHash-Tabelle

➥ zusatzliche Methode zum Erzeugen einer Sitzungs-ID

➥ Sitzungs-Management mit Hilfe von Axis:

➥ eine Instanz der Implementierungs-Klasse pro Sitzung

➥ automatische Verfolgung der Sitzungen uber generierteSitzungs-IDs in HTTP-Cookies oder im SOAP-Header

7.4.4 Sitzungs-Management mit Axis2 ...


Realisierung des Sitzungs-Managements

➥ Spezifikation des Session Scopes im Deployment-Deskriptor desDienstes, z.B.:

<serviceGroup><service name="HelloWorld" scope="soapsession">...

➥ Mogliche Werte:

➥ request: keine Sitzungen, Dienst ist zustandslos

➥ transportsession: verwende Sitzung der Transport-Ebene

➥ soapsession: Sitzung durch SOAP realisiert

➥ application: genau eine Instanz fur alle Nachrichten

➥ Einschalten des Sitzungs-Managements im Client:

HelloWorldStub stub = new HelloWorldStub();

stub._getServiceClient().getOptions().setManageSession(true);



Beispiel zum Sitzungs-Management

➥ Implementierung des Dienstes:

public class HelloWorldSkeleton {

int cnt = 1; // Zahlervariable als (sitzungslokaler) Zustand

public String sayHello(String to) {

return "Hello to " + to + " (" + cnt++ + ")";

}

// Lebenszyklus−Methoden: werden von Axis2 (uber Reflection)

// aufgerufen, wenn Session erzeugt bzw. geloscht wird

public void init(ServiceContext context) { ... }

public void destroy(ServiceContext context) { ... }

}

➥ Deployment-Deskriptor:

<serviceGroup><service name="HelloWorld" scope="transportsession">...



Beispiel zum Sitzungs-Management ...

➥ Implementierung des Clients:


public static void main(String[] args) throws Exception {


// Sitzungs-Verfolgung einschalten

stub. getServiceClient().getOptions()

.setManageSession(true);

System.out.println(stub.sayHello("Roland"));

System.out.println(stub.sayHello("Adrian"));

System.out.println(stub.sayHello("Andreas"));

}

}

➥ Vollstandiges Beispiel im WWW



Sitzungs-Management mit HTTP-Cookies

➥ Eintrag im Deployment-Deskriptor:<service name="HelloWorld" scope="transportsession">

➥ Axis-Server setzt bei jeder Antwort uber HTTP ein Cookie, das

der Client beim nachsten Aufruf zuruckschickt

➥ Problem: Interoperabilitat

➥ HTTP als Transportprotokoll vorausgesetzt

➥ Nicht-Java-Client kann evtl. Cookie nicht zurucksenden

➥ kein direkter Zugriff auf HTTP-Anfrage

➥ Vorteil: Sitzungen uber Dienstgruppen hinweg moglich



Ablauf der Kommunikation im Beispiel

HelloWorldHelloWorld. . .

. . .

. . .

. . .

. . .

1

2

Client

ServerWeb−

Tomcat

HTTP/1.1 200 OK

<?xml . . .

<?xml . . .

<?xml . . .

HTTP/1.1 200 OK

<?xml . . .



Set−Cookie: JSESSIONID=66CFAB...; Path=/axis2

Cookie: JSESSIONID=66CFAB...; Path=/axis2

Server

doPost()

HelloWorld

ServletAxis2



Sitzungs-Management uber SOAP-Header

➥ Eintrag im Deployment-Deskriptor:<service name="HelloWorld" scope="soapsession">

➥ Zusatzlich muß WS-Addressing Modul im Server und im Client

aktiviert sein (Standard bei Axis2)

➥ Handler modifizieren bzw. analysieren den SOAP-Header

➥ Server fugt bei jeder Antwort ServiceGroupId ein

➥ Client sendet diese bei Folgeanfragen zuruck

➥ Vorteile:

➥ unabhangig vom Transportprotokoll

➥ Auslesen und Einfugen des SOAP-Headers notfalls per Hand

im Client implementierbar



Ablauf der Kommunikation im Beispiel

HelloWorldHelloWorld

. . .

1

2

Client

<wsa:ReplyTo>...<wsa:ReferenceParameters><axis2:ServiceGroupId ...>urn:uuid:4DE801025.... . .

. . .

<?xml ...><Envelope ...><Header ...>

HTTP/1.1 200 OK

<wsa:ReplyTo>...<wsa:ReferenceParameters><axis2:ServiceGroupId ...>urn:uuid:4DE801025.... . .

. . .

<?xml ...><Envelope ...><Header ...>

HTTP/1.1 200 OK

ServerWeb−

Tomcat

. . .POST /axis2/services/HelloWorld HTTP/1.1

<?xml ...><Envelope ...><Header ...><axis2:ServiceGroupId ...>urn:uuid:4DE801025.... . .

<?xml . . .

Server

doPost()

HelloWorld

ServletAxis2




7.4.5 Axis2 Module

➥ Bearbeitung von SOAP-Nachrichten in Axis2 ist uber Module

erweiterbar

➥ Modul enthalt einen oder mehrere Handler

➥ Handler inspizieren bzw. manipulieren SOAP-Nachrichten

➥ Anwendungen z.B.

➥ Sicherheit (WS-Security, Rampart-Modul)

➥ Authentifizierung, Verschlusselung

➥ Adressierung (WS-Addressing)

➥ Zuverlassige Kommunikation (WS-ReliableMessaging)

➥ Debugging / Monitoring / Logging / Accounting ...

➥ Vorteil: Trennung von Verwaltungs-Aufgaben und Anwendungs-logik

7.4.5 Axis2 Module ...


➥ Module konnen zur Laufzeit eingebunden (engaged) werden

➥ global

➥ fur Dienstgruppen und einzelne Dienste

➥ fur einzelne Operationen

➥ Definition uber Axis2 Konfigurationsdatei, Deployment-Deskriptoroder Axis2 Web Admin

➥ $CATALINA BASE/webapps/axis2/WEB-INF/conf/axis2.xml

➥ resources/services.xml

➥ http://localhost:8080/axis2/axis2-admin/

➥ Beim Engagement eines Moduls werden dessen Handler indefinierte Phasen der Nachrichtenverarbeitung eingebunden

➥ Spezifikation uber Modul-Deskriptor META INF/module.xml

➥ Phasen sind in Axis2 Konfigurationsdatei festgelegt



Nachrichtenverarbeitung in Axis2

Tra

nspo

rtS

ende

r

Clie

nt−

AP

I

Clie

nt SOAP

Tra

nspo

rtLi

sten

er

Handler Mes

sage

Rec

eive

r

Web

Ser

vice

Handler

In PipeOut Pipe

➥ Vier Datenflusse: InFlow, OutFlow, InFaultFlow, OutFaultFlow

➥ Jeder Datenfluss wird in mehreren Phasen bearbeitet

➥ z.B. Transport, Pre-Dispatch, Dispatch, Message Processing

fur InFlow

➥ Jede Phase besteht aus beliebig vielen Handlern

➥ Phasen legen Ausfuhrungsreihenfolge der Handler fest



Beispiel: Hello World mit Logging

➥ Vollstandiger Code: siehe WWW

➥ Dienst-Implementierung bleibt unverandert

➥ Aber: Einfuhrung eines Moduls mit Handler fur Anfrage- und

Antwort-Nachrichten

➥ LOGHANDLER/logger/LogModule.java

➥ i.w. leere Implementierung der Axis2-Schnittstelle Module

➥ LOGHANDLER/logger/LogHandler.java

➥ gibt SOAP-Nachrichten auf Konsole aus

➥ Parameter im Deployment-Deskriptor gibt Prafix an, das

jeder Ausgabe vorangestellt wird



Beispiel: Hello World mit Logging ...

➥ Code des Handlers LOGHANDLER/logger/LogHandler.java:

public class LogHandler extends AbstractHandler {

public InvocationResponse invoke(MessageContext context)

throws AxisFault {

// Parameter aus Deployment−Deskriptor holen

String pre = "";

Parameter p = getParameter("prefix");

if (p != null)

pre = (String)p.getValue();

// SOAP−Nachricht ausgeben

System.out.println(pre + context.getEnvelope());

return InvocationResponse.CONTINUE;

}

}




➥ Deployment-Deskriptor des Moduls(LOGHANDLER/META-INF/module.xml):

<module name="logger" class="logger.LogModule"><InFlow><handler name="InFlowLogHandler" class="logger.LogHandler"><order phase="loggingPhase" /><parameter name="prefix">IN: </parameter>

</handler></InFlow>...

➥ Voraussetzung: loggingPhase ist in Axis2 Konfiguration definiert($CATALINA BASE/webapps/axis2/WEB-INF/conf/axis2.xml):

<phaseOrder type="InFlow"><phase name="Transport"> ... </phase>...<phase name="loggingPhase"/>...




➥ Deployment des Moduls: Packen des Deployment-Deskriptorsund der Klassen in ein Archiv logger.mar und Kopie nach$CATALINA BASE/webapps/axis2/WEB-INF/modules

➥ Engagement des Moduls im Deployment-Deskriptor des Services(SERVER/resources/services.xml):

➥ fur den kompletten Dienst:...

<service name="HelloWorld"><module ref="logger"/>...

➥ fur eine spezifische Operation:...<operation name="sayHello" mep="http://www.w3..." ...><module ref="logger"/>...




➥ Handler erbt von org.apache.axis2.handlers.AbstractHandler

und uberschreibt invoke(MessageContext context)

➥ Methode getParameter() von AbstractHandler erlaubt

Zugriff auf die im Deployment-Deskriptor gesetzten Parameter

➥ Methoden von org.apache.axis2.context.MessageContext:

➥ getEnvelope(): liefert Objekt-Reprasentation der SOAP

Nachricht

➥ getProperty(String name): liefert Wert einer gegebenen

Property aus MessageContext

➥ getPropertyNames(): liefert Iterator fur alle Property-Namen

➥ etliche weitere Verwaltungsmethoden

➥ i.w. undokumentiert ...

7 Web Services ...


7.5 Web Services und Sicherheit

➥ Mogliche Maßnahmen zur Absicherung von Web Services:

➥ Nutzung von HTTP uber TLS/SSL

➥ Verschlusselung (⇒ Vertraulichkeit, Integritat)

➥ Authentifizierung des Servers uber Zertifikat

➥ Authentifizierung des Clients (durch den Web-Server!)

➥ uber Zertifikat moglich

➥ meist aber nur uber Name und Paßwort

➥ Nutzung der WS Security Paradigmen

➥ Verschlusselung von Teilen einer SOAP-Nachricht

➥ digitale Signatur uber Teile einer SOAP-Nachricht

7.5 Web Services und Sicherheit ...


7.5.1 Nutzung von Tomcat6 mit TLS/SSL

➥ Zunachst: Erstellung eines Server-Zertifikats

➥ einfachste Moglichkeit: Verwendung des Java keytools:

➥ keytool -genkey -alias tomcat -keyalg RSA

➥ Key Paßwort und Keystore Paßwort mussen gleich sein!

➥ erzeugt selbstsigniertes Zertifikat (fuhrt zu Warnung im

Web Browser)

➥ i.d.R. muß das Zertifikat von einer Zertifizierungsstelle signiert

werden

➥ dazu: Verwendung der OpenSSL Werkzeuge und

Exportieren des Zertifikats im PKCS12-Format

➥ siehe Dokumentation von Tomcat und OpenSSL

7.5.1 Nutzung von Tomcat6 mit TLS/SSL ...


➥ Anpassen der Datei $CATALINA_BASE/conf/server.xml:

➥ Einfugen eines <Connector>-Elements fur den SSL Port:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="/home/wismueller/.keystore"

keystorePass="passwd1" />

➥ Vorlage bereits als Kommentar vorhanden

➥ Evtl. Loschen des <Connector>-Elements fur den nicht-SSL

Port

➥ Web Services nun uber https://host :8443/axis2/...

erreichbar



7.5.2 Passwort-Authentifizierung mit Tomcat6 und Axis2

➥ Zugriff auf Web-Service in Axis2 einschranken($CATALINA BASE/webapps/axis2/WEB-INF/web.xml):

<security-constraint><web-resource-collection><web-resource-name>Axis services</web-resource-name><url-pattern>/services/HelloWorld</url-pattern>

</web-resource-collection><auth-constraint><role-name>manager</role-name>

</auth-constraint></security-constraint><login-config><auth-method>BASIC</auth-method><realm-name>Axis Services</realm-name>

</login-config><security-role>

<role-name>manager</role-name></security-role>

7.5.2 Passwort-Authentifizierung mit Tomcat6 und Axis2 ...


➥ Rolle und Benutzer in Tomcat konfigurieren

($CATALINA BASE/conf/tomcat-users.xml):

<tomcat-users><role rolename="manager"/><user username="admin" password="s3cret" roles="manager"/>

</tomcat-users>

➥ Benutzer und Paßwort im Client ubergeben:


HttpTransportProperties.Authenticator auth= new HttpTransportProperties.Authenticator();

auth.setUsername("admin");auth.setPassword("s3cret");auth.setPreemptiveAuthentication(true);stub._getServiceClient().getOptions()

.setProperty(HTTPConstants.AUTHENTICATE, auth);

Roland WismullerBetriebssysteme / verteilte Systeme Client/Server-Programmierung (13/15) xiv

Roland Wismuller


[email protected]

Tel.: 0271/740-4050, Buro: H-B 8404



WS 2017/2018

12.01.2018



7.5.3 Nutzung der WS Security Paradigmen

➥ Probleme bei Verwendung von HTTP/SSL:

➥ keine Verbindlichkeit (keine digitale Signatur)

➥ Verschlusselung der gesamten SOAP-Nachricht oft unnotig

➥ keine Ende-zu-Ende-Sicherheit (Verschlusselung) beiSOAP-Nachrichten uber Zwischenknoten moglch

➥ Losung: Verschlusselung / Signierung von Teilen der SOAP-Nachricht mittels XML Encryption bzw. XML Signature

➥ WS Security ist ein Standard, der u.a. festlegt, wie

➥ kryptographische Information (z.B. Schlussel, Zertifikate,digitale Signaturen)

➥ Authentifizierungsinformation (z.B. Benutzername/Paßwort)

im SOAP-Header abgelegt werden

7.5.3 Nutzung der WS Security Paradigmen ...


Verschlusselung von SOAP-Nachrichten

➥ Basis: XML Encryption, erlaubt die Verschlusselung verschiede-

ner Teile eines XML-Dokuments:

➥ das komplette XML-Dokument,

➥ einzelne Elemente mit ihren Unterelementen

➥ oder nur der Inhalt einzelner Elemente

➥ Verschlusselte Teile werden durch <EncryptedData>-Elemente

ersetzt

➥ mogliche Unterelemente u.a. fur Name des Verschlusselungs-

algorithmus, Schlusselinformation, Chiffretext

➥ SOAP-Header enthalt Referenzen auf alle verschlusselten Teile

des Body



Beispiel fur eine verschlusselte SOAP-Nachricht

Schlüsselname

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis−open.org/wss/2004/01/oasis−200401− wss−wssecurity−secext−1.0.xsd" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <env:Header> <wsse:Security> <xenc:ReferenceList> <xenc:DataReference URI="#bodyID"/> </xenc:ReferenceList> </wsse:Security> </env:Header> <env:Body> <xenc:EncryptedData Id="bodyID"> <ds:KeyInfo>

</ds:KeyInfo>

zeigt an, daß InhaltSecurity−Header−Block

des SOAP−Bodiesverschlüsselt ist

<xenc:EncryptionMethod Algorithm="..."/>

<ds:KeyName>CN=Ali Baba, C=DE</ds:KeyName>

Chiffretext

Verschlüsselungsalgorithmus <xenc:CipherData> <xenc:CipherValue>39kDeFAl...</xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </env:Body></env:Envelope>

Verschlüsselter Element−Inhalt



Signierung von SOAP-Nachrichten

➥ Basis: XML Signature, erlaubt das (gemeinsame) Signieren ver-

schiedener Teile eines XML-Dokuments

➥ Signatur-Element wird in SOAP-Header eingebettet und verweist

auf signierte Elemente im Body

➥ Body bleibt unverandert, d.h. SOAP-Knoten konnen digitale

Signatur auch ignorieren

➥ Signatur-Element enthalt u.a.:

➥ Referenz auf die signierte Information

➥ Angabe der verwendeten Algorithmen

➥ Zertifikat, einschließlich des offentlichen Schlussels

➥ die digitale Signatur selbst



Beispiel fur eine signierte SOAP-Nachricht

<ds:SignatureMethod Algorithm= ".../xmldsig#rsa−sha1"/>

<ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="..."/>

<ds:Reference URI="#myBody"> <ds:Transforms> <ds:Transform Algorithm="..."/> </ds:Transforms>

EncodingType="...#Base64Binary" wsu:Id="X509Token"> MIIEZzCCA9CgAwIBA... </wsse:BinarySecurityToken>

<wsse:BinarySecurityToken ValueType="...#X509v3"X509−Zertifikat, binär, Base64−codiert

<env:Envelope ...> <env:Header> <wsse:Security>

Referenz auf signiertesElement



Beispiel fur eine signierte SOAP-Nachricht ...

Signatur für dieses Element

</env:Header> <env:Body wsu:Id="myBody"> <tru:StockSymbol xmlns:...">IBM</tru:StockSymbol> </env:Body></env:Envelope>

</wsse:Security> </ds:Signature>

<ds:SignatureValue>BL8jdfTPOV...</ds:SignatureValue>

<ds:DigestMethod Algorithm=".../xmldsig#sha1"/> <ds:DigestValue>EULddytSo1...</ds:DigestValue> </ds:Reference> </ds:SignedInfo>

<ds:KeyInfo> <wsse:SecurityTokenReference>

</wsse:SecurityTokenReference> </ds:KeyInfo>

<wsse:Reference URI="#X509Token"/>

obiges Zertifikat)

Hashwert für dieses Element

schlüssel (Verweis aufAngaben zum Signatur−



Praktische Nutzung von WS Security mit Axis2

➥ Erweiterungs-Modul Rampart

➥ Definiert Axis2 Handler, die ein- und ausgehende SOAP-Nach-

richten bearbeiten

➥ Ver- bzw. Entschlusselung von Elementen

➥ Erzeugung bzw. Prufung von Signaturen

➥ Rampart nutzt dazu die Bibliotheken der Apache-Projekte

➥ WSS4J (WS Security )

➥ XML Security (XML Encryption und XML Signature)

7 Web Services ...


7.6 Zusammenfassung

➥ Grundlage von Web Services: RPC-Mechanismus

➥ XML-basiertes Kommunikationsprotokoll: SOAP

➥ WSDL als IDL, definiert zusatzlich Adresse des Dienstes

➥ kein verteiltes Objektmodell

➥ unabhangig von Plattform, Implementierungssprache und

Transportprotokoll

➥ Axis2 als verbreitetes Web Service Framework

➥ automatische Erzeugung von WSDL-Dokumenten undClient-Stubs

➥ Axis2 Handler erlauben direkten Zugriff auf SOAP-Nachrichten

➥ z.B. fur Logging, Accounting, Sitzungsverwaltung,Verschlusselung und Signierung, ...



8 Weitere Client/Server-Technologien

8 Weitere Client/Server-Technologien ...


8.1 Technologien zur Netzwerkprogrammierung

➥ Sockets: plattform- und netzwerkunabhangiges Kommunikations-API (Basis jeglicher Client/Server-Kommunikation)

➥ Socket = Abstraktion fur Kommunikations-Endpunkt

➥ Datagramm- und Stream-Sockets

➥ bei Verwendung der IP-Protokolle: direkte Kommunikationuber UDP bzw. TCP

➥ Java bietet vereinfachtes API zur Socket-Kommunikation

➥ Literatur:

➥ Folien-Skript ”Rechnernetze II”, Kap. 8.1

➥ W.R. Stevens: Programmieren von UNIX-Netzen, Hanser /Prentice Hall, 1992.

➥ T. Langner: Verteilte Anwendungen mit Java, Markt + Tech-nik, 2002. Kap. 3

8.1 Technologien zur Netzwerkprogrammierung ...


➥ Sun RPC: einfache RPC-Implementierung

➥ einfache IDL, Bindung i.W. nur fur C

➥ sehr eingeschrankt (z.B. nur ein Parameter pro Prozedur)

➥ Literatur:

➥ Folien-Skript”Rechnernetze II“ (WS 08/09), Kap. 9.2

➥ W.R. Stevens: Programmieren von UNIX-Netzen, Hanser /

Prentice Hall, 1992.

➥ DCE RPC: Weiterentwicklung, Basis von Microsoft DCOM

➥ IDL mit Bindung an verschiedene Programmiersprachen

➥ Schnittstellen an Objekte statt Maschinen gebunden

➥ weltweit eindeutige ID (UUID) fur jede Schnittstelle

➥ Literatur: A. Tanenbaum, M. van Steen: Verteilte Systeme,

Pearson Studium, 2003, Kap. 2.2



8.2 Technologien fur dynamische WWW-Seiten

➥ CGI-Skripten (Common Gateway Interface)

➥ ausfuhrbare Programme (in beliebigen Sprachen) werden

beim Web-Server fur bestimmte URLs registriert

➥ bei Aufruf der URL startet Web-Server das CGI-Programm als

eigenen Prozeß

➥ Standard-Eingabe: Rumpf der HTTP-Anfrage

➥ d.h. Anfrage-Parameter bei POST-Methode

➥ Standard-Ausgabe: Rumpf der HTTP-Antwort

➥ Zusatzliche Information durch Umgebungsvariablen, z.B.

QUERY_STRING: Parameterstring in der URL nach dem ?

➥ Vorlaufer von Servlets

➥ Literatur: Orfali/Harkey, Kap. 11

8.2 Technologien fur dynamische WWW-Seiten ...


➥ PHP (PHP: Hypertext Preprocessor )

➥ Skript-Sprache, in HTML-Dokumente eingebettet

➥ innerhalb von Tags <?php ... ?>

➥ ab PHP 4 mit objektorientierten Konzepten

➥ ahnlich zu JSP, aber interpretierte Abarbeitung

➥ Literatur: http://www.php.net/

➥ ASP (Active Server Pages)

➥ Integration verschiedener Skript-Sprachen (u.a. VB Script,

JScript) in HTML-Dokumente

➥ innerhalb von Tags <% ... %> (Vorbild fur JSP)

➥ ASP zunachst interpretiert, bei ASP.NET Vorkompilation des

Codes analog zu JSP

➥ Literatur: http://www.asp.net/

http://www.php.net/

http://www.asp.net/



8.3 Microsoft .Net und DCOM

➥ Konkurrenz / Analogie zu J2EE von Oracle

➥ Das .Net-Framework definiert:

➥ einheitliche Laufzeitumgebung fur alle Microsoft-Sprachen(z.B. Visual Basic, Visual C++, C#)

➥ einheitliche Zwischensprache (CIL) mit JIT-Ubersetzung

➥ einheitliches Typsystem, Garbage Collection, Threads,Sandboxing, Ausnahmen ...

➥ gemeinsame Klassenbibliothek (etwa analog zu J2EE)

➥ u.a. Realisierung von ASP.Net und ADO.Net (Daten-bank-Zugriff, vergleichbar zu JDBC)

➥ Zusatzlich: Komponentenmodell, Weiterentwicklung von COM+

➥ COM+ = DCOM + MS Transaction + Message Queue Server

➥ Kommunikation: u.a. DCOM, Web Services, .Net-Remoting

8.3 Microsoft .Net und DCOM ...


COM / DCOM (Distributed Component Object Model)

➥ Sprachunabhangiges Komponentenmodell

➥ COM-Schnittstelle:

➥ binares API einer Komponente (Array von Funktionszeigern)

➥ identifiziert durch GUID (Globally Unique Identifier )

➥ identisch mit UUID von DCE-RPC

➥ beschrieben in DCOM IDL

➥ unveranderbar, ggf. muß neue Schnittstelle erzeugt werden

➥ COM-Objekt:

➥ Instanz einer Komponente

➥ implementiert eine oder mehrere COM-Schnittstellen



COM / DCOM (Distributed Component Object Model) ...

➥ Die Schnittstelle IUnknown:

➥ muß von jeder COM-Schnittstelle geerbt werden

➥ definiert die Methoden

➥ QueryInterface(): liefert zu einer uber die GUID

gegebene Schnittstelle den Zeiger auf diese Schnittstelle

zuruck

➥ bzw. Fehler, falls Schnittstelle nicht unterstutzt wird

➥ AddRef() / Release(): Referenz-Zahler

➥ Fur jede COM-Komponente muß eine Factory realisiert werden

➥ u.a. Methode CreateInstance() zur Erzeugung neuer

Komponenten-Instanzen




➥ Aufbau einer COM-Schnittstelle:

"gee

rbt"

von

IUnk

now

n

Client

Methoden−Tabelle

Interner Zeiger aufMethoden−Tabelle

COM−Objekt

Zeiger auf Methode 1





Methoden−Code

QueryInterface() { ... }

AddRef() { ... }

Release() { ... }

sayHello() { ... }

sayGoodby() { ... }

Schnittstellen−Zeiger




➥ COM-Server: ”Verpackungseinheit” von COM-Komponenten

➥ DLL, ausfuhrbare Datei (*.exe), Java-Klasse, ...

➥ enthalt Code einer / mehrerer Komponenten, Factories,

Registrierungs- und Verwaltungsinformation

➥ COM-Server kann lokalisiert sein:

➥ im lokalen Prozeß (realisiert als DLL)

➥ in eigenem Prozeß auf dem lokalen Rechner (COM-Server ist

ausfuhrbares Programm)

➥ in eigenem Prozeß auf entferntem Rechner (bei DCOM)

➥ auch Remote-Instantiierung moglich

➥ DCOM realisiert Zugriffs- und Ortstransparenz



Unterschiede zw. COM-Objekten und ublichen Objekten

➥ In COM existiert keine Objekt-ID

➥ COM-Client erhalt Referenz auf eine (zustandslose) Schnitt-stelle, nicht auf ein Objekt

➥ Client kann sich nicht mit bestimmter Instanz einer Kompo-nente verbinden (Problem, falls Instanz Zustand hat)

➥ Abhilfe durch COM Monikers

➥ In COM gibt es keine Mehrfach-Vererbung von Schnittstellen

➥ stattdessen: Komponente bietet mehrere Schnittstellen

➥ Wiederverwendung von Komponenten durch

➥ Containment /Delegation: Weitergabe von Aufrufen

➥ Aggregation: QueryInterface() gibt Schnittstellen derinneren Objekte nach außen bekannt



Containment/Delegation und Aggregation

B

C

Äußeres Objekt AA

B

C

B

C

Äußeres Objekt AA

B

C

IUnknown IUnknown

Containment/Delegation: Aggregation:

Aufrufe an B bzw. C weiter.stellen B und C der innerenObjekte zurück.

Implementierung von A gibt

QueryInterface() gibt Schnittstel−len des äußeren Objekts zurück. le A des äußeren und Schnitt−

QueryInterface() gibt Schnittstel−



➥ Literatur:

➥ Hammerschall, Kap. 10

➥ Orfali / Harkey, Kap. 15

➥ Hofmann / Jobst / Schabenberger, Kap. 3 und 4

➥ http://www.microsoft.com/com/

Documents

Client/Server-Programmierung · Zu meiner Person Roland Wismu¨ller Betriebssysteme / verteilte Systeme Client/Server-Programmierung (1/15) 3 Studium der Informatik an der Techn