WEBVTT

00:14.750 --> 00:15.990
Hören Sie mich?

00:16.350 --> 00:16.970
Ah ja, jetzt.

00:17.570 --> 00:19.270
Habe ich so viele vertrieben das letzte Mal?

00:19.610 --> 00:20.750
So wenig sind...

00:24.530 --> 00:25.050
Nein.

00:25.810 --> 00:26.250
Ist okay?

00:26.630 --> 00:26.930
Der Ton?

00:28.710 --> 00:29.050
Okay.

00:30.730 --> 00:36.350
Ja, also, ich begrüße Sie zur angewandten Informatik und werde

00:36.350 --> 00:39.290
versuchen Ihnen heute etwas über Business Objects zu erzählen.

00:40.390 --> 00:43.090
Und bei Business Objects, was ist das, haben Sie wahrscheinlich schon

00:43.090 --> 00:47.450
gehört, handelt es sich zunächst einmal um Softwarekomponenten.

00:48.790 --> 00:51.850
Die haben natürlich gewisse Eigenschaften und im Falle von Business

00:51.850 --> 00:59.410
Objects sind das grundsätzlich Dinge, die das Geschäftsleben

00:59.410 --> 01:00.830
betreffen.

01:01.570 --> 01:05.410
Also zum Beispiel Rechnungen, Gehaltsabrechnungen, Lagerverwaltung,

01:06.710 --> 01:11.510
Tarife und zwar nicht nur Daten, die damit zu tun haben, sondern auch

01:11.510 --> 01:15.270
die ganzen Berechnungen, Datenverwaltung, die dazugehört.

01:15.430 --> 01:18.810
Also zum Beispiel, wie sich eine Rechnung zusammensetzt, wie die Daten

01:18.810 --> 01:20.990
zusammengestellt werden, wie sie berechnet werden.

01:21.770 --> 01:25.490
Das wäre also auch ein Geschäftsprozess, der in einem Business Object

01:25.490 --> 01:27.270
repräsentiert wird.

01:28.610 --> 01:32.370
Technisch sind es aber trotzdem Objekte mit allem, was dazugehört.

01:32.530 --> 01:35.190
Also wer von Ihnen schon mal objektorientiert programmiert hat, wird

01:35.190 --> 01:35.590
es kennen.

01:35.730 --> 01:40.890
Also Datenkapselung, Sie haben Polymorphie, Sie haben Vererbung, Sie

01:40.890 --> 01:46.810
haben dynamische Bindung von Attributen, Sie haben Referenzen auf

01:46.810 --> 01:51.450
Objekten und in der Realität wird es tatsächlich auch so gemacht.

01:51.570 --> 01:53.910
Die Sachen, die ich Ihnen dann vorstelle, das sind tatsächlich Java

01:53.910 --> 01:56.130
-Objekte oder .NET-Objekte.

01:58.330 --> 02:01.890
Was auch noch typisch ist für ein Business Object, wir haben keinerlei

02:01.890 --> 02:04.050
Anbindung an eine technische Plattform.

02:04.410 --> 02:07.610
Das heißt, wir sind plattformunabhängig, meistens auf jeden Fall die

02:07.610 --> 02:11.210
Hardware, im Idealfall auch noch Betriebssystem-Umgebung, wie Sie es

02:11.210 --> 02:12.450
bei Java zum Beispiel haben.

02:14.030 --> 02:16.510
Und wenn es richtig gut ist, dann sind Sie auch noch von der

02:16.510 --> 02:17.970
Programmiersprache unabhängig.

02:18.870 --> 02:22.430
Das heißt, Sie sind nicht an Java gebunden oder an C oder sonst

02:22.430 --> 02:26.630
irgendwas, sondern Sie sind unabhängig von der Sprache.

02:26.950 --> 02:29.970
Auch da werde ich etwas vorstellen, wie das realisiert wird in der

02:29.970 --> 02:30.390
Praxis.

02:31.430 --> 02:32.950
Und Sie sind beliebig verteilbar.

02:33.190 --> 02:35.810
Das heißt jetzt nicht, dass man die Dinge einfach von einem Ort auf

02:35.810 --> 02:39.730
den anderen kopieren kann, sondern dass der Benutzer im Idealfall

02:39.730 --> 02:43.610
nicht weiß, dass das Objekt verteilt ist.

02:43.990 --> 02:48.150
Also er spricht vielleicht eine Komponente an und im Laufe der

02:48.150 --> 02:49.590
Benutzung wechselt der Ort.

02:50.070 --> 02:52.830
Also er weiß nicht, wo sich die Komponente letztendlich befindet.

02:53.210 --> 02:55.910
Vielleicht befinden sich ja auch die Komponenten verteilt auf mehreren

02:55.910 --> 02:56.370
Rechnern.

02:56.770 --> 02:58.010
Das ist also damit gemeint.

02:59.830 --> 03:02.270
Und im Idealfall hat man alle diese Eigenschaften.

03:02.430 --> 03:05.370
Ich habe also Geschäftsprozesse, ich habe Objekte mit allem, was

03:05.370 --> 03:05.970
dazugehört.

03:05.970 --> 03:10.290
Ich bin plattform-, sprach- und hardwareunabhängig und ich habe

03:10.290 --> 03:11.370
beliebige Verteilung.

03:11.830 --> 03:14.490
Und in der Praxis hat man mal das eine oder mal das andere, aber

03:14.490 --> 03:16.870
leider nicht immer alles gleichzeitig.

03:18.930 --> 03:20.550
So, worum geht es in dem Kapitel?

03:21.330 --> 03:26.190
Ich werde Ihnen also verschiedene Sachen vorstellen, wie diese

03:26.190 --> 03:29.090
Business -Objects dann in der Praxis realisiert sind.

03:29.710 --> 03:31.810
Das eine ist eine rudimentäre Realisierung.

03:31.810 --> 03:33.570
Das sind Java Beans.

03:33.910 --> 03:35.990
Haben Sie vielleicht schon mit zu tun gehabt oder mal was damit

03:35.990 --> 03:36.390
gemacht.

03:37.630 --> 03:40.290
Das ist im Wesentlichen eine Java-Klasse, die ein paar besondere

03:40.290 --> 03:41.110
Eigenschaften hat.

03:42.190 --> 03:45.030
Dann wesentlich wichtiger und weiter verbreitet sind Enterprise Java

03:45.030 --> 03:45.510
Beans.

03:46.710 --> 03:50.890
Das sind Sachen, die also typischerweise in die IT-Infrastruktur von

03:50.890 --> 03:52.510
Unternehmen eingegliedert sind.

03:53.050 --> 03:54.710
Die sind vor allem kommunikationsfähig.

03:54.790 --> 03:57.890
Die können Sie aus der Entfernung, also von einem anderen Rechner aus

03:57.890 --> 03:58.410
ansprechen.

03:59.690 --> 04:02.790
Und sind in die Enterprise Java Edition eingegliedert.

04:03.010 --> 04:04.370
Auch dazu werde ich Ihnen was erzählen.

04:04.530 --> 04:05.810
Dann erzähle ich Ihnen was zu CORBA.

04:07.250 --> 04:11.410
CORBA ist ein Standard, der von der OMG verabschiedet wurde.

04:12.390 --> 04:16.070
Da geht es also darum, objektorientierte, verteilte kleinen Server

04:16.070 --> 04:17.550
-Systeme zu kuppeln.

04:18.710 --> 04:22.470
CORBA zeichnet sich also dadurch aus, dass es sprachunabhängig ist.

04:22.790 --> 04:26.430
Also bei Java Beans oder Enterprise Java Beans sind sie an die Sprache

04:26.430 --> 04:27.150
Java gebunden.

04:27.730 --> 04:31.410
Und mit allem, was eben dazugehört, auch kommunikationstechnisch.

04:32.090 --> 04:33.930
Und bei CORBA sind sie sprachunabhängig.

04:35.070 --> 04:38.390
Dann COM und Distributed COM, das ist Component Object Model.

04:39.090 --> 04:41.330
Das ist eine Komponentenarchitektur von Microsoft.

04:41.910 --> 04:44.610
Mit der haben sie bestimmt schon mal was zu tun gehabt.

04:44.930 --> 04:48.690
Also wer schon mal Visual Basic programmiert hat, der hat ja also mit

04:48.690 --> 04:49.390
COM zu tun.

04:50.530 --> 04:53.190
Oder was man auch typisch sieht, wer von Ihnen vielleicht so

04:53.190 --> 04:55.190
Filesharing -Programme oder sowas nutzt.

04:58.230 --> 05:03.530
Und da hat man oft, dass Infoseiten in HTML zum Beispiel angezeigt

05:03.530 --> 05:03.850
werden.

05:04.030 --> 05:05.470
Bei solchen Programmen.

05:05.930 --> 05:09.270
Und da benutzt eben das Programm eine fremde DLL oder eine fremde

05:09.270 --> 05:09.850
Komponente.

05:10.090 --> 05:12.230
In dem Fall die HTML Engine des Internet Explorer.

05:12.430 --> 05:13.830
Das ist also ein typisches Beispiel für COM.

05:16.030 --> 05:19.370
Und der Nachfolger von COM, da werden wir, wenn wir noch Zeit haben,

05:19.430 --> 05:21.090
am Ende noch ein bisschen was dazu erzählen.

05:21.190 --> 05:22.110
Das ist dieses .NET.

05:23.010 --> 05:26.810
Das ist also eine neue Technologie, die Microsoft entwickelt hat, um

05:26.810 --> 05:30.690
COM eben mindestens zu ergänzen und auf längere Sicht auch abzulösen.

05:31.610 --> 05:35.030
Das ist also was, um ganz normale Standalone-Anwendungen, aber auch

05:35.030 --> 05:36.990
verteilte Web-Anwendungen zu bauen.

05:39.190 --> 05:42.810
.NET hat wie Corbar auch die Eigenschaft, dass es sprachunabhängig

05:42.810 --> 05:43.170
ist.

05:47.370 --> 05:49.710
Kommen wir zu J2EE.

05:52.190 --> 05:52.750
Na?

05:54.390 --> 05:55.450
Ja, das kennen wir schon.

05:58.130 --> 06:00.810
Weiß einer von Ihnen, warum PowerPoint immer abstürzt?

06:01.410 --> 06:03.150
Auf der Tablet PC Edition?

06:05.470 --> 06:06.030
Nicht?

06:07.190 --> 06:08.910
Auf einem normalen Rechner passiert das nämlich nicht.

06:17.520 --> 06:18.500
Ah, ok.

06:19.220 --> 06:21.180
Also das ist die Architektur von J2EE.

06:21.800 --> 06:23.740
Haben Sie mit Sicherheit schon was davon gehört.

06:24.080 --> 06:25.920
Vielleicht auch weniger damit selber gearbeitet.

06:25.920 --> 06:29.000
Das ist eine typische Drei-Schichten-Architektur, die Sie oft bei

06:29.000 --> 06:31.440
Unternehmens -Servern haben.

06:32.180 --> 06:33.460
Das haben wir also auf der linken Seite.

06:33.920 --> 06:35.060
Normalerweise hat man es oben.

06:36.000 --> 06:36.680
Die Darstellung.

06:37.060 --> 06:38.140
Hier ist es zweigeteilt.

06:38.260 --> 06:39.680
Das haben Sie einmal die Kleinteilung.

06:49.320 --> 06:51.020
Hier haben Sie dann die Kleinteilung.

06:52.080 --> 06:54.980
Das ist normalerweise ein Web-Browser, der Ihnen irgendwelche HTML

06:54.980 --> 06:55.740
-Seiten anzeigt.

06:55.840 --> 06:58.020
Vielleicht haben Sie auch eine eigenständige Java-Anwendung.

06:58.900 --> 07:01.980
Oder irgendein anderes J2EE-Gerät.

07:02.480 --> 07:07.040
Das könnte auch vielleicht so ein Handy sein, das diese Micro-Edition

07:07.040 --> 07:07.280
hat.

07:08.000 --> 07:11.220
Auf jeden Fall haben Sie hier den Teil, der also dem Benutzer

07:11.220 --> 07:11.940
präsentiert wird.

07:12.020 --> 07:14.880
Hier haben Sie Anwendungen, die das zusammenbauen oder anzeigen, was

07:14.880 --> 07:16.020
Sie als Benutzer sehen.

07:17.080 --> 07:19.940
Und mit dem Sie als Benutzer das bedienen müssen.

07:20.140 --> 07:22.620
Also irgendwelche Buttons zum Klicken oder irgendwelche Informationen.

07:23.420 --> 07:25.120
Auf der Server-Seite haben Sie das Gegenstück.

07:26.320 --> 07:30.250
Also der Teil, der Ihnen Ihre Sicht auf die Daten präsentiert.

07:30.980 --> 07:35.320
Also zum Beispiel die ESP-Seiten oder Surflets, die also HTML-Seiten

07:35.320 --> 07:36.020
zusammenbauen.

07:36.560 --> 07:40.280
Oder die Kommunikationsschnittstelle, wenn Sie einen eigenständigen

07:40.280 --> 07:42.440
Client haben, der sich selbst um die Darstellung kümmert.

07:43.020 --> 07:47.280
Dann brauchen Sie hier eine Kommunikationsschnittstelle, mit der Sie

07:47.280 --> 07:48.000
dann kommunizieren.

07:48.060 --> 07:51.240
Das ist also die serverseitige Präsentationsschicht.

07:52.100 --> 07:55.480
Dann getrennt davon haben Sie die sogenannte Business-Logic.

07:56.400 --> 08:00.540
Business-Logic können Sie sich vielleicht so vorstellen, wenn Sie bei

08:00.540 --> 08:01.700
Amazon ein Buch bestellen.

08:02.500 --> 08:04.620
Und Sie klicken dann sich Ihren Warenkorb zusammen.

08:05.220 --> 08:08.680
Und dann läuft irgendwo ein Prozess ab, der nachguckt, ob die Waren

08:08.680 --> 08:10.180
alle im Lager sind.

08:10.620 --> 08:12.500
Und stellt Ihnen dann die Preisliste zusammen.

08:12.840 --> 08:15.220
Stellt Ihnen auch noch zusammen, wie lange die Lieferzeiten sind und

08:15.220 --> 08:17.240
ob Sie vielleicht noch einen Gutschein haben oder solche Sachen.

08:18.020 --> 08:23.280
Und diese Prozesse würden von der Business-Logic dann ausgeführt.

08:23.480 --> 08:26.100
Die serverseitige Präsentation würde Ihnen dann die HTML-Seite

08:26.100 --> 08:29.300
generieren aus den Daten, die Sie dann hier mit dem Browser angucken

08:29.300 --> 08:29.600
können.

08:30.280 --> 08:33.920
Aber die Business-Logic wäre das Stück Software, das Ihnen die Daten

08:33.920 --> 08:34.600
zusammenbaut.

08:35.420 --> 08:37.800
Natürlich dann dahinter irgendwie eine Datenhaltung, eine Datenbank

08:37.800 --> 08:39.240
oder ein File-System oder sonst was.

08:41.140 --> 08:44.120
Da gehen wir noch ein bisschen genauer auf J2E ein.

08:45.280 --> 08:48.060
J2E kann also erstmal das, was die Standard Edition auch kann.

08:48.200 --> 08:50.940
Sie haben XML-Processing, Sie haben verschiedene Namens- und

08:50.940 --> 08:52.140
Verzeichnisdienste.

08:52.620 --> 08:55.320
Sie haben Schnittstellen zu Datenbanken, wie JDBC.

08:56.340 --> 08:57.880
Sie haben verschiedene Verschlüsselungssachen,

08:58.740 --> 09:00.080
Identifizierungsmechanismen.

09:00.200 --> 09:01.400
Sie haben eine Schnittstelle zu CoreBar.

09:02.420 --> 09:05.480
Und auf der Client-Seite haben Sie dann die Darstellung mit Applets

09:05.480 --> 09:06.460
oder Java Beans.

09:07.780 --> 09:11.420
Dann da oben gibt es also Tutorials oder irgendwelche

09:11.420 --> 09:13.620
Dokumentationsgeschichten, die dazu gehören.

09:13.620 --> 09:15.380
Natürlich auch Entwicklungsumgebung hier.

09:16.680 --> 09:20.800
Und dann das Eigentliche, was J2E ausmacht, ist dieser Container in

09:20.800 --> 09:23.700
der Mitte, der dann alle möglichen Komponenten beinhaltet.

09:24.000 --> 09:27.020
Das sind einmal diese Enterprise Java Beans, zu denen ich dann gleich

09:27.020 --> 09:27.620
noch kommen werde.

09:28.160 --> 09:30.780
Dann Surflets, wie wir es aus der letzten Vorlesung kennen.

09:30.920 --> 09:33.080
Also dynamische Generierung von Webseiten haben Sie hier.

09:34.580 --> 09:37.440
Webservices, auch dazu werde ich noch einiges erzählen.

09:38.500 --> 09:42.040
JSP-Seiten, also die ganze Darstellung, die dann mit dem Client auch

09:42.040 --> 09:42.580
kommuniziert.

09:42.580 --> 09:47.300
Und dann haben Sie einige Klassen oder einige Komponenten im Innern

09:47.300 --> 09:52.180
dieses Containers, der sich dann um Sachen wie Sicherheit, Verteilung,

09:52.460 --> 09:57.160
Management, E-Mail, Transaktionsverwaltung und solche Sachen kümmert.

09:57.200 --> 09:58.220
Das ist relativ komplex.

09:58.980 --> 10:02.200
Und hier haben Sie Konnektoren, um den Server mit einem anderen Server

10:02.200 --> 10:03.440
zu verbinden.

10:06.820 --> 10:08.160
So, Java Beans.

10:08.480 --> 10:09.700
Was ist eine Java Bean?

10:10.620 --> 10:12.040
Hat jemand schon mal was damit zu tun gehabt?

10:13.780 --> 10:14.780
Sehen Sie, ich auch nicht.

10:16.480 --> 10:21.100
Aber es ist im Wesentlichen eine einzelne Klasse, wie man es von Java

10:21.100 --> 10:25.140
her kennt, mit dem Unterschied, dass es eine abgeschlossene,

10:25.200 --> 10:27.720
wiederverwendbare Softwareeinheit ist, mit der Sie sich dann in

10:27.720 --> 10:32.360
Entwicklungsumgebungen zusammengesetzte Anwendungen zusammen klicken

10:32.360 --> 10:32.720
können.

10:33.540 --> 10:36.980
Jetzt haben Sie schon mal mit Visual Studio gearbeitet und da visuelle

10:36.980 --> 10:40.760
Komponenten zusammengebaut, wie zum Beispiel Buttons oder Timer oder

10:40.760 --> 10:41.400
solche Sachen.

10:41.900 --> 10:43.240
Genauso muss man sich das vorstellen.

10:44.180 --> 10:48.940
Das heißt, das ist eine abgeschlossene Komponente, die Sie dann in

10:48.940 --> 10:50.260
eine andere Software integrieren können.

10:51.120 --> 10:53.700
Das ist jetzt im Wesentlichen nichts Besonderes, das kennt man von

10:53.700 --> 10:57.040
einer normalen Java-Klasse eigentlich auch, aber bei einer normalen

10:57.040 --> 10:59.900
Java -Klasse legen Sie zur Entwicklungszeit alles fest, was Sie wissen

10:59.900 --> 11:00.180
müssen.

11:01.480 --> 11:05.120
Zur Entwicklungszeit der Klasse selber legen Sie natürlich alles fest,

11:05.120 --> 11:08.100
aber vor allem, wenn Sie sie benutzen wollen, bei einer normalen Java

11:08.100 --> 11:12.100
-Klasse, da wissen Sie, zur Entwicklungszeit müssen Sie alles wissen.

11:12.300 --> 11:14.920
Sie müssen wissen, wie die Methoden heißen, wie sie angesprochen

11:14.920 --> 11:18.420
werden, was für Parameter Sie brauchen, was für Werte Sie

11:18.420 --> 11:24.260
zurückliefern und bei einer Java Bean, das ist ein bisschen was

11:24.260 --> 11:27.760
anderes, da können Sie die Module zur Laufzeit ansprechen.

11:28.080 --> 11:31.600
Also Sie können zur Laufzeit Sachen benutzen, von denen Sie zur

11:31.600 --> 11:35.500
Entwicklungszeit noch nicht wissen, wie sie heißen und wie sie benutzt

11:35.500 --> 11:35.820
werden.

11:36.600 --> 11:39.320
Das heißt, der Aufruf von Methoden, die eine Klasse selbst nicht

11:39.320 --> 11:42.680
bearbeiten kann, kann dann an andere Sachen weitergeleitet werden, die

11:42.680 --> 11:44.200
erst zur Laufzeit bekannt werden.

11:44.360 --> 11:48.600
Das heißt, Sie haben dafür eine Möglichkeit, zur Laufzeit eine Klasse

11:48.600 --> 11:52.200
abzufragen, welche Methoden zur Verfügung stehen, wie die Methoden

11:52.200 --> 11:56.000
heißen und können Sie sie dann ansprechen, ohne dass Sie das zur

11:56.000 --> 11:57.380
Entwicklungszeit schon wissen müssen.

11:59.300 --> 12:01.380
So, da ist noch was zur Kommunikation.

12:01.800 --> 12:03.540
Das sind also Events und Methodenkopplung.

12:04.180 --> 12:08.280
Das heißt, eine Bean kann ein sogenanntes Event auslösen, bei dem man

12:08.280 --> 12:13.300
sich registrieren kann und aufgrund dieses Events wird dann eine

12:13.300 --> 12:14.640
andere Methode ausgelöst.

12:15.760 --> 12:19.080
Wenn Sie selber mal programmieren oder damit was zu tun haben, wenn

12:19.080 --> 12:22.620
Sie damit mehr zu tun haben, das sind aber Sachen, die Sie eigentlich

12:22.620 --> 12:25.280
für die Klausur dann auch nicht brauchen und nicht wissen müssen.

12:25.280 --> 12:29.760
Aber wesentlich ist, dass Sie den Unterschied zwischen der normalen

12:29.760 --> 12:31.700
Java -Klasse und einer Java-Bean kennen.

12:32.140 --> 12:35.960
Also dieses Wiederverwenden zur Laufzeit, dass Sie Sachen ansprechen

12:35.960 --> 12:37.840
können, die Sie zur Entwicklungszeit noch nicht wissen.

12:40.120 --> 12:42.580
Also hier steht es, Wiederverwendung zur Laufzeit.

12:46.560 --> 12:48.580
Dann gibt es Enterprise Java Beans.

12:49.480 --> 12:52.440
Enterprise Java Beans, das ist im Wesentlichen eine Java-Bean, die ein

12:52.440 --> 12:56.180
bisschen mehr kann, die wird typischerweise in so einem Container hier

12:56.180 --> 12:59.820
eingebettet, auf einem AJB-Server.

13:00.260 --> 13:05.440
Da hat man einen Container, der diese Beans beheimatet sozusagen, also

13:05.440 --> 13:09.640
die leben da drin und können über diverse Schnittstellen angesteuert

13:09.640 --> 13:09.940
werden.

13:10.240 --> 13:12.820
Das heißt, Sie haben links den Client und haben auf der Serverseite

13:12.820 --> 13:15.660
die Bean und der Client hat jetzt die Möglichkeit über einen

13:15.660 --> 13:18.400
entfernten Prozeduraufruf diese Bean anzusprechen.

13:18.400 --> 13:22.260
Das heißt, der Server erzeugt die, der Client hat dann die

13:22.260 --> 13:25.960
Möglichkeit, entfernt Methoden auszuführen, was auch immer das sein

13:25.960 --> 13:29.760
wird, und das Ergebnis zurückerhalten und dann verarbeiten.

13:30.020 --> 13:33.700
Und wie das technisch funktioniert, das erkläre ich Ihnen jetzt.

13:36.440 --> 13:40.040
Also eine Java Bean ist erstmal eine Komponente, die innerhalb so

13:40.040 --> 13:41.100
eines Containers läuft.

13:41.240 --> 13:43.140
Und dieser Container wieder sitzt in einem Server.

13:46.220 --> 13:49.540
Eine Enterprise Java Bean ist also eine Klasse, die typische Business

13:49.540 --> 13:54.980
Logic, also Sachen, die mit dem Geschäftsleben zu tun haben,

13:55.040 --> 13:55.580
implementiert.

13:55.720 --> 13:58.080
Also hier zum Beispiel Warenkorb, Bankkonto und solche Sachen.

13:59.220 --> 14:02.480
Also weniger für wissenschaftliche oder numerische Berechnungen oder

14:02.480 --> 14:03.100
solche Sachen.

14:03.740 --> 14:06.060
Das ist immer irgendwie im Geschäftsleben verankert.

14:09.120 --> 14:13.960
Und dann gibt es eben zwei Möglichkeiten, dass eine Enterprise Java

14:13.960 --> 14:16.440
Bean selber einige Dienste implementiert.

14:21.000 --> 14:24.380
Also im EJB-Container haben es noch andere Klassen, die fest

14:24.380 --> 14:25.020
dazugehören.

14:25.200 --> 14:27.560
Also nicht zu einer bestimmten Bean, sondern fest zu diesem Container

14:27.560 --> 14:27.880
gehören.

14:29.640 --> 14:32.920
Und Dienste an diese EJB-Komponenten ausliefern.

14:32.920 --> 14:38.260
Also zum Beispiel, dass der Container sich darum kümmert, dass Daten,

14:38.500 --> 14:41.820
die von einer Enterprise Java Bean erzeugt werden, auch persistent

14:41.820 --> 14:42.660
gespeichert werden.

14:42.740 --> 14:48.180
Das ist so ein typischer Dienst, den ein Java Bean Container an die

14:48.180 --> 14:49.940
Bean selber erbringen kann.

14:50.320 --> 14:52.060
Also eine persistente Speicherung von Daten.

14:52.620 --> 14:55.000
Da gehört dann zum Beispiel dazu, wenn der Server abstürzt, dass diese

14:55.000 --> 14:59.300
Daten wieder aus dem Log-File regeneriert werden oder wieder erzeugt

14:59.300 --> 14:59.560
werden.

15:00.200 --> 15:05.800
Oder eben auch die Verbindung zu anderen Servern oder die Möglichkeit,

15:06.440 --> 15:08.280
vom Client angesprochen zu werden.

15:09.740 --> 15:15.040
Genau das ist nochmal der Container.

15:15.940 --> 15:18.500
Also hier die Dienste, die im Container liefern, was ich eben erzählt

15:18.500 --> 15:18.700
habe.

15:18.900 --> 15:21.760
Also sie haben Transaktions- und Ressourcenmanagement, sie haben

15:21.760 --> 15:26.060
verschiedene Mechanismen zur Versionskontrolle, sie haben persistente

15:26.060 --> 15:31.300
Speicherung, sie haben Verschlüsselungs- und Identifizierungsdienste.

15:32.780 --> 15:36.420
Und welche Dienste jetzt die Enterprise Java Bean selber erledigt und

15:36.420 --> 15:39.600
welche Dienste sie vom Container in Anspruch nimmt, das wird in einen

15:39.600 --> 15:41.940
sogenannten Vertrag geregelt.

15:42.120 --> 15:46.280
Das heißt, da wird festgelegt, was die Komponente selber tut, welche

15:46.280 --> 15:51.300
Schnittstellen sie selber implementiert und was der Container für die

15:51.300 --> 15:52.740
Komponente erledigen muss.

15:52.740 --> 15:55.200
Also zum Beispiel das Transaktionsmanagement.

15:58.000 --> 16:01.680
Dann haben sie die Möglichkeit, dass sie eine EOP-Komponente mehrfach

16:01.680 --> 16:03.720
im gleichen Container verwenden können.

16:04.660 --> 16:06.260
Über Schlüssel wird es dann identifiziert.

16:07.760 --> 16:10.880
Und jetzt kommen wir eben zu der ganz interessanten Geschichte, wie

16:10.880 --> 16:14.920
ich so eine Bean von entfernt, von remote her, von meinem Client her

16:14.920 --> 16:15.780
ansprechen kann.

16:17.700 --> 16:20.080
Also stellen Sie sich vor, Sie haben einen Client, Sie brauchen einen

16:20.080 --> 16:22.480
bestimmten Dienst und Sie wissen, auf dem und dem Server liegt genau

16:22.480 --> 16:27.220
diese Bean, die mir genau diesen Dienst erbringt, den ich erledigen

16:27.220 --> 16:27.520
kann.

16:27.840 --> 16:31.900
Dann macht man also jetzt folgendes, das Client-Programm erzeugt

16:31.900 --> 16:37.200
praktisch ein Duplikat zu dieser EOP-Komponente beim Client.

16:37.580 --> 16:39.100
Das sogenannte Home-Interface.

16:40.200 --> 16:44.440
Das ist dann wie ein Gegenstück zu der Bean, das beim Client

16:44.440 --> 16:45.080
existiert.

16:45.790 --> 16:51.000
Dieses wird erzeugt und ein sogenanntes Remote-Interface nennt man

16:51.000 --> 16:51.300
das.

16:52.360 --> 16:54.940
Also Sie müssen sich das vorstellen, Sie haben die Bean, die hat eine

16:54.940 --> 17:02.100
bestimmte Methode und Sie haben beim Client das Remote-Objekt, das

17:02.100 --> 17:06.680
genau die gleichen Methoden anbietet, wie diese Bean, allerdings mit

17:06.680 --> 17:10.480
dem Unterschied, dass es die Methode nicht selber implementiert.

17:10.480 --> 17:14.120
Das heißt, sie nimmt die Daten an der Methode entgegen, führt die

17:14.120 --> 17:17.800
Methode dann aber nicht aus, kann sie gar nicht, sondern leitet die

17:17.800 --> 17:22.440
Daten über einen Remote-Mechanismus an den Server weiter.

17:23.380 --> 17:29.060
Der dann an der Bean selber die Algorithmik oder was auch immer

17:29.060 --> 17:32.020
ausführt und auf dem gleichen Weg geht das Ergebnis dann wieder

17:32.020 --> 17:32.420
zurück.

17:34.580 --> 17:38.520
Technisch funktioniert das über Java Remote Method Invocation.

17:38.520 --> 17:43.260
Das ist also ein Mechanismus, wie man unter Java entfernte Klassen

17:43.260 --> 17:45.160
oder entfernte Komponenten ansprechen kann.

17:45.700 --> 17:47.460
Das weiß der Client hier allerdings gar nicht.

17:47.620 --> 17:53.340
Der Client hat hier nur sein Home-Interface, hat die Methoden, weiß

17:53.340 --> 17:56.120
wie er sie anspricht, aber dass das dann eine Schicht darunter über

17:56.120 --> 17:58.980
Netzwerk an den Server geschickt wird, das weiß er gar nicht, das muss

17:58.980 --> 17:59.620
er auch gar nicht wissen.

18:01.340 --> 18:05.020
Das sind also getrennte Klassen, aber das Interface, die Schnittstelle

18:05.020 --> 18:07.520
oder Methodensignatur, die ist genau der gleiche.

18:07.560 --> 18:10.520
Die sind also völlig identisch.

18:12.240 --> 18:13.520
So, genau das habe ich ja gesagt.

18:15.040 --> 18:17.600
Da kann man sich vielleicht ein bisschen wie eine Art Fernsteuerung,

18:18.060 --> 18:22.000
wie Sie es zum Beispiel beim Fenster oder Videorecorder haben, können

18:22.000 --> 18:23.440
Sie sich das im Wesentlichen vorstellen.

18:23.560 --> 18:26.140
Sie haben die Fernsteuerung, drücken auf den Knopf, aber die Funktion

18:26.140 --> 18:27.660
wird natürlich am Fenster ausgeführt.

18:27.980 --> 18:30.260
Und die Funktion selber können Sie am Fenster natürlich auch wieder

18:30.260 --> 18:30.960
direkt ausführen.

18:30.960 --> 18:33.340
Da gibt es die Knöpfe ja auch, also kann man sich das in etwa

18:33.340 --> 18:33.860
vorstellen.

18:36.380 --> 18:40.040
Wie werden jetzt diese Beans und das Home-Interface erzeugt?

18:42.200 --> 18:46.960
Das ist also folgendermaßen, das Client-Programm weiß, dass der Server

18:46.960 --> 18:51.320
diese Bean besitzt und weiß, dass die und diese Funktionen beim Server

18:51.320 --> 18:52.460
angeboten werden.

18:52.940 --> 18:53.400
Woher das?

18:53.460 --> 18:54.200
Da komme ich noch dazu.

18:55.200 --> 18:58.180
Aber der Server hat jetzt eine feste Schnittstelle, das ist dieses

18:58.180 --> 18:59.460
Home -Interface hier.

19:01.060 --> 19:04.180
Über diese Schnittstelle, die fest definiert ist, kann der Client den

19:04.180 --> 19:06.900
Server bitten, erzeuge mir mal die und die Java-Bean.

19:07.780 --> 19:11.120
Okay, der Server tut es dann und liefert dann dem Client eben nicht

19:11.120 --> 19:15.260
nur ein Okay oder ein Nicht-Okay zurück, sondern genau dieses

19:15.260 --> 19:18.440
Stellvertreterobjekt, mit dem der Client dann arbeitet.

19:19.140 --> 19:21.940
Also Sie müssen sich vorstellen, da wird hier ein Objekt erzeugt und

19:21.940 --> 19:24.600
an der Stelle wird ein Objekt erzeugt, die nach außen hin völlig

19:24.600 --> 19:28.320
gleich sind, wobei dieses Objekt, das an der Stelle erzeugt wird, die

19:28.320 --> 19:31.060
Methoden nicht ausführen kann, sondern Kommunikation übernimmt.

19:31.420 --> 19:33.340
Dieses Objekt wird dann zum Client geschickt.

19:33.540 --> 19:36.080
Das kann man technisch machen, Serialisierung heißt das, wenn Sie

19:36.080 --> 19:37.100
vielleicht schon mal was davon gehört.

19:37.760 --> 19:42.260
Also ein Objekt komplett in die Repräsentation eines Objekts im

19:42.260 --> 19:46.360
Speicher wirklich auf die Leitung schicken kann und der Client aus

19:46.360 --> 19:51.860
diesem serialisierten Daten wieder ein benutzbares Objekt erzeugen

19:51.860 --> 19:52.380
kann.

19:52.820 --> 19:54.060
Genau das passiert da.

19:54.560 --> 19:57.120
Also können Sie sich wirklich vorstellen, der Server erzeugt die

19:57.120 --> 19:59.200
Fernbedienung und schickt sie dem Client.

20:00.660 --> 20:03.680
Und der Client benutzt das dann wie ein rein lokales Objekt.

20:04.960 --> 20:09.040
Und eben über dieses Home-Interface, das der Server bereitstellt, über

20:09.040 --> 20:12.760
genau dieses, wird diese Erzeugung, später wenn wir fertig sind, auch

20:12.760 --> 20:15.880
die Zerstörung solcher Objekte, abgewickelt.

20:18.240 --> 20:21.240
Und natürlich auch die eigentliche Methode, also die eigentliche

20:21.240 --> 20:23.240
Arbeit, die da abläuft.

20:23.840 --> 20:27.980
Woher weiß der Client jetzt, was für Dienste der Server anbietet, was

20:27.980 --> 20:29.720
für Beans da zur Verfügung stehen?

20:30.980 --> 20:34.120
Da gibt es eine spezielle Schnittstelle, das ist JND, das Java Naming

20:34.120 --> 20:35.380
and Directory Interface.

20:35.380 --> 20:40.280
Und über diese Schnittstelle kann der Client Informationen über die

20:40.280 --> 20:43.160
verfügbaren Container Dienste, über die Komponenten abfragen.

20:46.680 --> 20:51.100
So, jetzt gibt es zwei Typen von Enterprise Java Beans.

20:52.260 --> 20:54.340
Das sind die Session und die Entity Beans.

20:54.740 --> 20:55.480
Was ist jetzt der Unterschied?

20:56.420 --> 21:00.440
Eine Session Bean, das können Sie sich vorstellen, die wird mit einem

21:00.440 --> 21:03.920
einzigen Client erzeugt und ist dann nur für diesen Client zur

21:03.920 --> 21:04.320
Verfügung.

21:04.320 --> 21:06.980
Also wie eine Session, die Sie zum Beispiel auch bei dynamischen

21:06.980 --> 21:07.780
Webseiten haben.

21:08.560 --> 21:11.720
Oder wie es bei dynamischen Webseiten mit Cookies realisiert wird.

21:12.460 --> 21:15.780
Solche Bean würde also erzeugt werden, wenn Sie mit Ihrem Client den

21:15.780 --> 21:17.000
Befehl zum Erzeugen geben.

21:18.120 --> 21:22.460
Und wenn Sie mit Ihrem Client den Server wieder verlassen, dann wird

21:22.460 --> 21:26.040
diese Bean dann auch wieder zerstört.

21:26.820 --> 21:31.200
Beispiel steht hier, könnte zum Beispiel eine Bean sein, die für genau

21:31.200 --> 21:35.660
Ihren Serverbesuch protokolliert, welche Seiten Sie zum Beispiel

21:35.660 --> 21:36.140
angucken.

21:37.180 --> 21:38.620
Oder so etwas wie eine Bestellung.

21:39.840 --> 21:42.340
Wenn Sie zum Beispiel bei Amazon ein Buch bestellen, können Sie sich

21:42.340 --> 21:44.740
vorstellen, dass dabei am Anfang der Bestellung eine Bean erzeugt

21:44.740 --> 21:44.860
wird.

21:45.680 --> 21:49.540
Die ist für die Dauer Ihres Einkaufs zuständig, aber wenn der Einkauf

21:49.540 --> 21:51.900
dann abgewickelt ist und die Bestellung vermerkt ist, dann brauchen

21:51.900 --> 21:52.720
wir die Bean ja nicht mehr.

21:53.140 --> 21:54.540
Und dann werde ich wieder zerstört.

21:58.080 --> 22:02.720
Zweite Beansorte ist die Entity Bean, die ist dauerhaft verfügbar.

22:02.840 --> 22:04.920
Das heißt, die wird nicht zerstört, wenn Sie mit Ihrem Client

22:04.920 --> 22:05.600
weggehen.

22:06.400 --> 22:09.140
Und sie wird auch nicht erzeugt, wenn Sie mit Ihrem Client rankommen,

22:09.480 --> 22:11.220
weil sie nämlich vermutlich schon existiert.

22:11.900 --> 22:15.320
Also das ist zum Beispiel eine Bean, die eine feste Datenbank

22:15.320 --> 22:16.060
repräsentiert.

22:16.200 --> 22:21.900
Oder Daten, die für alle Clients die gleichen sein sollen.

22:25.840 --> 22:32.600
Oder stellen Sie sich vor, Sie haben einen Server, wo Sie eine

22:32.600 --> 22:34.500
Schnittstelle haben, um den Zähler hochzuzählen.

22:35.280 --> 22:38.060
Jetzt kommen zwei Clients und jeder Client zählt den Zähler hoch.

22:38.060 --> 22:42.320
Wenn Sie also das mit einer Session Bean realisieren würden, dann

22:42.320 --> 22:44.700
würde jeder Client also seinen eigenen Zähler haben.

22:45.160 --> 22:46.500
Und der eine Client erhöht den Zähler um 1.

22:47.260 --> 22:49.720
Und dann kommt der zweite Client und erhöht den Zähler um 1.

22:49.920 --> 22:52.300
Und jeder fragt danach seinen Zählerstand wieder ab.

22:52.920 --> 22:55.060
Dann würde jeder genau seine 1 zurückkriegen.

22:55.620 --> 22:58.640
Wenn Sie das mit der Entity Bean machen, dann wird einer von beiden

22:58.640 --> 22:59.660
eine 2 zurückkriegen.

23:00.040 --> 23:03.180
Weil beide das gleiche Objekt benutzen.

23:08.060 --> 23:11.000
Entity Beans sind persistent.

23:11.820 --> 23:16.420
Das heißt, wenn der Server mal abstürzt, kann man den Inhalt wieder

23:16.420 --> 23:18.540
rekonstruieren und diese Bean wieder erzeugen.

23:19.660 --> 23:21.680
Das ist also bei Geschäftsprozessen durchaus wichtig.

23:23.420 --> 23:26.840
Message Stiften Beans, das ist eine dritte Art.

23:28.280 --> 23:30.060
Das ist eine asynchrone Kommunikation.

23:30.920 --> 23:34.440
Das kann man sich etwa so vorstellen, dass Sie eine Funktion aufrufen

23:35.720 --> 23:38.600
und Ihr Client an der Stelle nicht warten muss, bis das Ergebnis

23:38.600 --> 23:39.320
zurückliefert.

23:39.960 --> 23:41.940
Also so eine Art Multi-Threading.

23:42.120 --> 23:46.280
Sie rufen eine Methode auf und nehmen sie an, die die Methode braucht

23:46.280 --> 23:48.760
und braucht ihre Zeit, weil sie vielleicht irgendwas ausrechnet oder

23:48.760 --> 23:52.320
ein langwieriger Datenbankzugriff stattfindet.

23:52.780 --> 23:55.100
Und Sie sind als Client aber gar nicht am Ergebnis interessiert.

23:55.180 --> 23:59.080
Sie wollen bloß den Prozess anstoßen und sonst wollen Sie nichts mehr

23:59.080 --> 23:59.740
mit zu tun haben.

24:00.200 --> 24:02.140
Dann kann man das über Message Stiften Beans machen.

24:03.080 --> 24:05.440
Das ist also asynchron eben.

24:06.380 --> 24:11.120
Sie stoßen den Prozess an und warten nicht auf einen Rückgabewert.

24:15.640 --> 24:17.860
Was macht man mit diesen Sachen?

24:19.000 --> 24:20.460
Also es gibt diese Anwendungsserver.

24:20.520 --> 24:23.300
Haben Sie vielleicht schon davon gehört.

24:23.620 --> 24:27.280
Application Server, Java J3 Application Server.

24:27.440 --> 24:28.320
Liest man immer mal wieder was.

24:28.440 --> 24:31.220
Das sind riesige Server, die eben diese ganzen Dienste und diese

24:31.220 --> 24:37.740
Container realisieren und eben solche Beans beheimaten können.

24:37.960 --> 24:41.860
Also das ist so ein Server, das Dienste und Methoden zur Laufzeit

24:41.860 --> 24:42.940
erweiterbar sein sollen.

24:43.480 --> 24:45.240
Und das eine Dienste zuverlässig anbietet.

24:45.400 --> 24:48.120
Das wird eben mit solchen Sachen wie Persistenz, wie

24:48.120 --> 24:49.900
Transaktionsverwaltung realisiert.

24:50.740 --> 24:54.960
Und eben die Bean Technologie sorgt dafür, dass ich Funktionen

24:54.960 --> 24:58.120
dazufügen kann, entfernen kann, den Server um Funktionen erweitern

24:58.120 --> 25:00.860
kann, ohne dass ich den Server neu starten muss.

25:00.860 --> 25:04.060
Oder vielleicht sogar die Client Software neu übersetzen muss.

25:04.380 --> 25:07.620
Ich hänge das also praktisch so zur Laufzeit, kann ich Funktionen

25:07.620 --> 25:09.020
dazuhängen und wieder rausnehmen.

25:11.180 --> 25:13.440
Das ist also ein laufender Server, der das gemacht.

25:14.200 --> 25:18.700
Dafür gibt es ein spezielles Remote Interface, mit dem ich solche

25:18.700 --> 25:21.060
Beans nachträglich installieren kann.

25:21.420 --> 25:22.300
Oder dazufügen kann.

25:22.960 --> 25:24.820
Genauso andere Management Funktionen.

25:27.840 --> 25:30.880
Bei diesem ganzen Betriebsmodell gibt es verschiedene Rollen.

25:31.660 --> 25:34.100
Da gibt es die Entwickler von solchen Beans.

25:34.860 --> 25:38.480
Dann gibt es die Leute, die diese Beans zusammenstellen zu solchen

25:38.480 --> 25:40.620
Servern oder in solche Server eingliedern.

25:41.500 --> 25:46.300
Ich habe eine spezielle Umgebung, die ich mir aufbauen will.

25:46.360 --> 25:49.080
Da brauche ich eben so ein paar Beans, die mir meine Sachen

25:49.080 --> 25:49.900
realisieren.

25:50.600 --> 25:53.640
Die kann man selber entwickeln, nach Bedarf.

25:53.740 --> 25:56.540
Oder es gibt da einen gewissen Komponentenmarkt, wo Sie sich solche

25:56.540 --> 25:59.120
fertigen Business Komponenten einkaufen können.

26:00.480 --> 26:02.740
Dann brauchen Sie natürlich einen Container-Anbieter.

26:02.940 --> 26:06.640
Das sind meistens sehr große Softwarefirmen, wie Oracle, IBM oder Sun

26:06.640 --> 26:10.120
selbst, die solchen großen Servern anbieten, die dann solche J2E

26:10.120 --> 26:13.280
-Laufzeitumgebungen fahren können.

26:13.280 --> 26:16.760
Dann natürlich der Betreiber und zu guter Letzt der

26:16.760 --> 26:17.700
Anwendungsentwickler.

26:18.060 --> 26:21.840
Das ist derjenige, der den Client schreibt, um diesen Server zu

26:21.840 --> 26:22.320
benutzen.

26:24.480 --> 26:28.060
Das war es zu Enterprise Java Beans, J2E.

26:29.980 --> 26:35.520
Da müssen Sie für die Klausur oder für die Übungsaufgaben verstanden

26:35.520 --> 26:39.160
haben, wie dieser Remote-Mechanismus funktioniert, was da passiert,

26:39.160 --> 26:43.820
wenn ein Client remote solche Beans ansteuern will, das sollten Sie

26:43.820 --> 26:44.100
wissen.

26:45.020 --> 26:47.760
Was Sie noch wissen sollten, ist der Unterschied zwischen einer Java

26:47.760 --> 26:50.960
Bean und einem ganz normalen Java Objekt.

26:52.440 --> 26:55.700
Das sind so die zwei wesentlichen Sachen, dass Sie den Unterschied

26:55.700 --> 26:56.480
verstanden haben.

26:57.300 --> 27:01.360
Und eben diesen Mechanismus der Fernsteuerung, den Remote-Zugriff auf

27:01.360 --> 27:04.480
so eine Enterprise Java Bean, dass Sie sowas erklären können, zum

27:04.480 --> 27:04.800
Beispiel.

27:05.140 --> 27:06.980
Das ist das, was Sie aus dem Kapitel mitnehmen sollten.

27:08.000 --> 27:09.460
Kommen wir zu CORBA.

27:11.140 --> 27:14.520
CORBA ist etwas ganz Ähnliches.

27:16.180 --> 27:21.440
Es dient also wie J2E ebenfalls dazu, dass ich eine Mittelware

27:21.440 --> 27:25.520
-Architektur habe, mit der ich zwischen verteilten Objekten

27:25.520 --> 27:29.340
kommunizieren kann und verteilte Dienste ausführen kann.

27:30.500 --> 27:34.360
Anders als J2E ist CORBA standardisiert von der Object Management

27:34.360 --> 27:41.140
Group und wesentlicher Unterschied, es ist nicht sprachabhängig.

27:41.720 --> 27:45.020
Das heißt, es gibt eine Sprache, die Interface Definition Language,

27:46.420 --> 27:49.280
mit der werden Objektschnittstellen definiert.

27:50.160 --> 27:54.220
Also, wie heißt eine Methode, welche Parameter braucht sie, welche

27:54.220 --> 27:55.980
Reihenfolge braucht sie, diese Parameter.

27:57.400 --> 28:02.340
Was für Ergebnissystem gibt es, das wird über IDL definiert und das

28:02.340 --> 28:03.440
ist sprachunabhängig.

28:05.260 --> 28:07.980
Wenn natürlich etwas sprachunabhängig ist, dann will man natürlich

28:07.980 --> 28:10.740
auch, dass verschiedene Sprachen miteinander kommunizieren können.

28:11.280 --> 28:13.480
Dann braucht man natürlich ein Zwischenstück, das die ganze Geschichte

28:13.480 --> 28:14.060
übersetzt.

28:14.280 --> 28:17.240
Meinetwegen von C++ auf Java übersetzt oder so.

28:19.120 --> 28:22.320
Dafür gibt es den ORB, das ist der Object Request Broker.

28:23.520 --> 28:24.640
Also, dieses Teil hier.

28:25.900 --> 28:29.100
Was der macht, ist, er nimmt an der einen Stelle eben Funktionen

28:29.100 --> 28:35.900
entgegen, Funktionsaufrufe, übersetzt sie dann in die Zielsprache bzw.

28:36.160 --> 28:38.400
in die Zwischensprache und auf der anderen Stelle wird es dann wieder

28:38.400 --> 28:40.140
in die Zielsprache übersetzt.

28:40.480 --> 28:43.540
Damit kriegen sie diese Entkoppelung von der Sprache hin.

28:45.900 --> 28:50.160
Dann transparente Verteilung von Objekten, das heißt eben, dass sie

28:50.160 --> 28:54.300
durchaus ein Objekt ansprechen können, von dem sie nicht wissen, wo es

28:54.300 --> 28:55.340
sich überhaupt befindet.

28:55.340 --> 29:00.940
Also nicht wissen, auf welchem Rechner es liegt und nicht wissen, wie

29:00.940 --> 29:01.660
sie da hinkommen.

29:02.840 --> 29:06.740
Da gibt es einen speziellen Namensdienst bei CORBA, der ihnen diese

29:06.740 --> 29:08.620
Zuordnung abnimmt.

29:09.000 --> 29:12.380
Das heißt, sie haben eine völlige Transparenz von der Ortschaft oder

29:12.380 --> 29:13.420
vom Rechner selber.

29:13.580 --> 29:16.840
Sie rufen einfach eine Funktion auf und wo das letzte Objekt, das sie

29:16.840 --> 29:18.840
da benutzen, sich befindet, das brauchen sie gar nicht wissen.

29:20.220 --> 29:22.760
Okay, jetzt haben wir von der Object Management Group geredet.

29:24.200 --> 29:25.740
Das sind also einige Unternehmen.

29:27.840 --> 29:30.680
Das ist hier natürlich nicht vollständig, aber es sind relativ große

29:30.680 --> 29:31.180
Unternehmen.

29:31.920 --> 29:34.520
Und erstaunlicherweise nicht nur Unternehmen, die Software bauen.

29:34.900 --> 29:38.080
Also wenn Sie hier zum Beispiel mal gucken, hier haben Sie Ford, hier

29:38.080 --> 29:39.520
haben wir Pfizer.

29:41.840 --> 29:45.180
Also Firmen, die nicht unbedingt mit Software-Systemen in Verbindung

29:45.180 --> 29:46.620
gebracht werden.

29:46.620 --> 29:49.260
Natürlich haben sie auch große Software-Unternehmen wie Microsoft,

29:49.420 --> 29:52.780
Rechner, Sun, SAP natürlich.

29:53.600 --> 29:57.720
Aber es sind nicht nur Software-Firmen in dieser Gruppe.

29:58.180 --> 30:01.020
Die OMG standardisiert auch noch weit mehr als nur CORBA.

30:01.420 --> 30:04.280
Wenn Sie schon mal von UML was gehört haben, von der Unified Modeling

30:04.280 --> 30:04.800
Language.

30:05.560 --> 30:10.700
Das ist eine Sprache, mit der sie Software modellieren können.

30:11.120 --> 30:13.180
Also Klassendiagramme und solche Sachen.

30:13.900 --> 30:16.180
Das ist auch von der Object Management Group standardisiert.

30:16.960 --> 30:19.120
Haben Sie vielleicht schon mal was gehört oder damit zu tun gehabt?

30:23.020 --> 30:24.740
So, da haben wir jetzt mal ein Architekturbild.

30:26.600 --> 30:30.600
In CORBA gibt es also die Object Management Architektur.

30:30.780 --> 30:33.900
Und da sind drei Arten, drei verschiedene Arten von Objekten werden da

30:33.900 --> 30:35.000
standardisiert.

30:36.060 --> 30:38.840
Das eine sind CORBA Services, heißt das.

30:39.320 --> 30:43.140
Das sind also Standardobjekte, die man immer mal wieder braucht.

30:43.140 --> 30:45.740
Also typische allgemeine Zwecke, wie zum Beispiel

30:45.740 --> 30:50.520
Transaktionsverwaltung, Persistenz oder Verschlüsselung zum Beispiel.

30:51.280 --> 30:55.720
Immer mal wieder völlig anwendungsunabhängig an jeder Situation

30:55.720 --> 30:56.680
gebraucht werden können.

30:57.600 --> 31:01.000
Das sind also Dinge, die durch CORBA Services standardisiert sind.

31:02.200 --> 31:04.420
Zweite Art von Objekten sind die Facilities.

31:05.380 --> 31:06.360
Da gibt es zwei Standards.

31:06.500 --> 31:09.820
Das eine sind funktionsspezifische Sachen, wie Schnittstellen,

31:09.900 --> 31:14.280
Anwendungs - und Systemmanagement und branchenspezifische.

31:14.360 --> 31:16.620
Also das sind Sachen standardisiert, die ganz typisch für das

31:16.620 --> 31:20.220
Finanzwesen sind oder ganz typisch für Telekommunikation oder für den

31:20.220 --> 31:21.940
Büchermarkt oder sonstige Sachen.

31:22.680 --> 31:25.020
Das ist bei den vertikalen Sachen.

31:25.160 --> 31:30.140
Also es gibt branchenspezifische Standards und funktionsspezifische,

31:30.300 --> 31:32.560
eben allgemeine Zwecke.

31:33.280 --> 31:35.020
Und dann gibt es noch benutzerdefinierte Sachen.

31:35.020 --> 31:37.200
Das heißt, Sie können natürlich als Anwendungsprogrammierer selber

31:37.200 --> 31:38.700
solche Sachen entwickeln.

31:40.840 --> 31:46.860
Und diese ganzen Objekte werden eben über diesen Request-Programm

31:46.860 --> 31:49.020
gekapselt oder verbunden.

31:52.860 --> 31:54.520
Kommen wir zu den CORBA Services.

31:54.720 --> 32:00.760
Da ist nur mal aufgelistet, welche Dienste diese allgemeinen, für alle

32:00.760 --> 32:03.860
möglichen Zwecke einsetzbaren Dienste, was da spezifiziert ist, was es

32:03.860 --> 32:04.280
da gibt.

32:04.960 --> 32:09.240
Da haben Sie also Dienste für Parallelbetrieb.

32:09.740 --> 32:12.620
Sie haben verschiedene Sachen zur Zeit- und Datumsberechnung.

32:12.820 --> 32:16.280
Sie haben hier Query-Service, damit können Sie dann Datenbanken

32:16.280 --> 32:16.900
ansprechen.

32:19.180 --> 32:21.560
Sicherheitsdienste natürlich, Namensauflösung, dann

32:21.560 --> 32:22.600
Lizenzierungssachen.

32:23.780 --> 32:26.560
All solche Dinge, die man grundsätzlich mal wieder braucht.

32:26.660 --> 32:29.320
Oder hier Nachrichtendienst, dass ein Dienstendienst eine E-Mail

32:29.320 --> 32:29.940
verschicken kann.

32:32.440 --> 32:35.080
Im Gegensatz zu eben diesen Facilities, das sind also die

32:35.080 --> 32:38.040
branchenspezifischen Sachen.

32:38.980 --> 32:42.200
Da gibt es noch nicht so viel, aber da gibt es zwei verfügbare

32:42.200 --> 32:43.100
Spezifikationen.

32:43.300 --> 32:48.320
Das ist Internalization and Time und die Mobile Agent Facility.

32:49.100 --> 32:52.540
Das sind aber Sachen, die Sie eigentlich nicht groß auswendig lernen

32:52.540 --> 32:53.520
müssen oder wissen müssen.

32:54.140 --> 32:56.020
Was halt der Vollständigkeit hier dann auch aufführt.

32:57.180 --> 32:58.600
Aber das ist jetzt wieder interessanter.

32:59.360 --> 33:01.500
Wie funktioniert denn so ein Methodenaufruf in CORBA?

33:01.500 --> 33:04.220
Also Sie stellen sich vor, Sie haben einen Client und rufen irgendeine

33:04.220 --> 33:06.060
Methode auf, wie Sie es von jedem Programm her kennen.

33:09.000 --> 33:11.580
Der Methodenaufruf soll einen entfernten Server ansprechen und soll

33:11.580 --> 33:13.380
dort eine entfernte Methode aufrufen.

33:13.980 --> 33:18.200
Und zur Übertragung der Daten, zur Koppelung von Client und Server

33:18.200 --> 33:19.500
wird eben CORBA eingesetzt.

33:21.340 --> 33:24.540
Da werden also die Aufrufinformationen im Client-Stub der Methode

33:24.540 --> 33:26.480
eingetragen.

33:26.480 --> 33:31.240
Der Client-Stub, das ist praktisch das Gegenstück, mit dem Ihr Client

33:31.240 --> 33:31.680
spricht.

33:32.240 --> 33:35.540
Der verhält sich also gegenüber Ihrem Client so wie das reale Objekt

33:35.540 --> 33:39.860
auf dem Server, bietet die gleiche Schnittstelle an, führt die Methode

33:39.860 --> 33:41.340
allerdings dann natürlich nicht aus.

33:41.920 --> 33:46.340
Das ist also so etwas wie dieses Home-Objekt bei Enterprise Java

33:46.340 --> 33:46.760
Beans.

33:47.180 --> 33:48.220
Genau so müssen Sie es sich vorstellen.

33:48.700 --> 33:52.960
Oder denken Sie an HTTP-Protokoll, Proxy.

33:54.120 --> 33:59.500
Sie reden lokal mit etwas, lokal wird aber dann nichts ausgeführt,

33:59.600 --> 34:02.500
sondern das Ganze nur an eine entfernte Stelle übertragen und dort

34:02.500 --> 34:03.080
ausgeführt.

34:04.160 --> 34:07.060
Da haben Sie einen lokalen Ort und haben den Zielserver.

34:07.540 --> 34:10.960
Das ist hier der CORBA-Teil.

34:13.000 --> 34:15.740
Auf dem Server gibt es auch so etwas wie ein Stub, das heißt dann

34:15.740 --> 34:16.140
Skeleton.

34:16.760 --> 34:18.420
Das ist eben der Rückweg.

34:19.900 --> 34:22.140
Und erst hier an der Stelle haben Sie eine tatsächliche

34:22.140 --> 34:23.200
Methodenausführung.

34:23.580 --> 34:29.560
Der Client denkt an der Stelle, dass es ausgeführt wird, wobei es erst

34:29.560 --> 34:30.460
hier ausgeführt wird.

34:32.180 --> 34:35.180
Wenn wir dann fertig sind, geht es mit dem Ergebnis natürlich den

34:35.180 --> 34:36.420
gleichen Weg gerade wieder zurück.

34:39.520 --> 34:42.600
Das Problem, das wir jetzt haben, was man sich jetzt ein bisschen

34:42.600 --> 34:45.640
denken kann, wenn man das sieht, ist, dass wir einen ziemlichen

34:45.640 --> 34:46.480
Overhead haben.

34:46.480 --> 34:50.480
Allein durch die Sprachunabhängigkeit und diese Übersetzung hier bei

34:50.480 --> 34:54.540
den Orbs haben Sie einen ziemlichen Overhead.

34:55.200 --> 34:58.800
Deswegen lohnt sich der Einsatz von CORBA eigentlich nur dann, wenn es

34:58.800 --> 34:59.500
nicht anders geht.

35:00.840 --> 35:04.720
Es hat sich auch nicht so richtig durchgesetzt, man hört relativ wenig

35:04.720 --> 35:07.240
davon und so verbreitet ist es auch nicht.

35:09.400 --> 35:13.900
Letztendlich hat es Handy-Probleme oder die Komplexität von CORBA dazu

35:13.900 --> 35:17.560
geführt, dass man so etwas wie Web-Services sich ausgedacht hat und

35:17.560 --> 35:18.400
standardisiert hat.

35:19.180 --> 35:21.180
Was ein Web-Service ist, da kommen wir auch noch dazu.

35:25.290 --> 35:28.450
Das ist jetzt die Interface Definition Language, die Sie bei CORBA

35:28.450 --> 35:28.750
haben.

35:29.250 --> 35:35.090
Das ist also die Sprache, mit der eben beschrieben wird, was ein

35:35.090 --> 35:35.950
Objekt eigentlich kann.

35:35.950 --> 35:40.170
Also die typischen Methoden und die Attribute, also welche Methoden

35:40.170 --> 35:43.330
gibt es, welche Parameter braucht es.

35:45.350 --> 35:48.570
Dann über sogenannte Getter und Setter-Methoden können Sie Attribute

35:48.570 --> 35:49.010
verändern.

35:49.770 --> 35:51.610
Wer schon einmal Java programmiert hat von Ihnen wird es

35:51.610 --> 35:52.330
wahrscheinlich kennen.

35:53.390 --> 35:57.290
Also dass Sie ein Attribut nicht direkt modifizieren können, sondern

35:57.290 --> 35:59.200
über sogenannte Get- und Set-Methoden.

35:59.990 --> 36:02.510
Das ist einfach eine Programmierkonvention auch.

36:02.510 --> 36:05.790
Das können Sie über die Interface Definition Language spezifizieren.

36:07.090 --> 36:10.310
Dann diese Schnittstellen sind vererbbar, Sie können sie voneinander

36:10.310 --> 36:10.770
erben.

36:12.210 --> 36:16.350
Und aus dieser Definition Language wird dann dieses Gegenstück beim

36:16.350 --> 36:18.390
Client, dieser Stub, erzeugt.

36:18.570 --> 36:20.330
Das ist praktisch die Beschreibung dessen.

36:21.250 --> 36:24.050
Aus dieser Beschreibung wird praktisch der Client-Proxy erzeugt, mit

36:24.050 --> 36:25.690
dem dann Ihr Client selbst kommuniziert.

36:26.450 --> 36:28.590
Auf Serverseite natürlich dann genauso.

36:28.590 --> 36:28.770
So,

36:32.390 --> 36:34.530
jetzt ist Corva in der Erweiterung.

36:35.610 --> 36:38.870
Das heißt, es gibt jetzt Corva 3 oder Corva Component Model, wie man

36:38.870 --> 36:39.270
es nennt.

36:39.650 --> 36:42.010
Das ist also ein Vorschlag für eine Rahmenarchitektur für Business

36:42.010 --> 36:42.990
Objects.

36:43.230 --> 36:47.050
Da soll also diese ganze Geschichte mehr an die Enterprise Java Beans

36:47.050 --> 36:49.490
Architektur angegliedert und enger damit verzahnt werden.

36:50.950 --> 36:54.190
Da gibt es dann natürlich ein paar mehr Sprachen, also zum Beispiel

36:54.190 --> 36:56.090
die Implementation Definition Language.

36:56.090 --> 37:01.410
Dann gibt es eine Sprache, die die Semantik dieses Component Models

37:01.410 --> 37:02.030
beschreibt.

37:02.470 --> 37:05.410
Dann haben Sie ein Framework, das also das Programmiermodell

37:05.410 --> 37:09.090
beschreibt, wie solche Komponenten implementiert werden müssen.

37:09.730 --> 37:13.510
Dann haben Sie ein Programmiermodell, das beschreibt, wie Sie also

37:13.510 --> 37:16.550
Enterprise Java Beans durch Corva Clients und Corva Komponenten

37:16.550 --> 37:18.350
ansprechen können, wie Sie die verwenden können.

37:19.750 --> 37:22.750
Dann haben Sie eine Architektur des Component Container aus Sicht des

37:22.750 --> 37:23.910
Container Providers.

37:23.910 --> 37:29.330
Und Sie haben eine Definition in XML DDTs von diesen Corva

37:29.330 --> 37:30.230
Komponenten.

37:30.410 --> 37:32.350
Daran sieht man eigentlich schon, dass es wieder ein bisschen veraltet

37:32.350 --> 37:32.650
ist.

37:33.130 --> 37:35.730
Es werden nämlich DDTs verwendet zur Definition.

37:36.250 --> 37:40.050
Das ist ja eigentlich schon veraltet, kann man sagen.

37:40.150 --> 37:41.730
Man verwendet ja heutzutage eigentlich eher Schema.

37:45.130 --> 37:49.830
Wenn Sie also mehr zu Corva wissen und sich informieren wollen, gibt

37:49.830 --> 37:50.570
es da noch ein paar Links.

37:53.130 --> 37:57.290
Jetzt haben wir ein bisschen was über verteilte Systeme erzählt.

37:59.190 --> 38:01.990
Ein grundsätzliches Problem bei den verteilten Systemen ist

38:01.990 --> 38:02.890
Heterogenität.

38:03.550 --> 38:05.950
Also wenn man sich jetzt zum Beispiel das mit den Enterprise Java

38:05.950 --> 38:11.830
Beans, das ist eine tolle Sache, aber sie sind auf Java angewiesen.

38:12.430 --> 38:14.770
Wenn Sie das nicht mögen oder nicht können oder es sich aus

38:14.770 --> 38:18.230
irgendwelchen anderen Gründen nicht anbietet, sei es beim Server, sei

38:18.230 --> 38:21.130
es beim Client, dann können Sie sowas zum Beispiel nicht verwenden.

38:22.210 --> 38:27.110
Dann haben Sie zig verschiedene stationäre Rechner, Laptops, PDAs,

38:27.230 --> 38:29.890
also eine unheimliche Vielfalt von Endgeräten.

38:30.910 --> 38:33.890
Eine noch größere Vielfalt von Programmiersprachen, die Sie vielleicht

38:33.890 --> 38:38.770
alle irgendwie die Möglichkeit haben wollen, das verwenden zu wollen.

38:39.230 --> 38:43.090
Dann haben Sie natürlich einige höhere Protokollschichten zur

38:43.090 --> 38:47.250
Datenübertragung, HTTP, FTP, E-Mail, solche Sachen.

38:47.250 --> 38:50.050
Dann auf den niedrigeren Transportschichten haben Sie auch zig

38:50.050 --> 38:55.910
verschiedene Varianten über ATM bis Ethernet, UMTS, Funktechnik und

38:55.910 --> 38:58.690
natürlich zu guter Letzt eine ganze Latte an Betriebssystemen.

38:59.950 --> 39:03.090
Und das Problem ist eben, wie kann man das miteinander verheiraten.

39:03.090 --> 39:14.050
Wie kann ich zum Beispiel dafür sorgen, dass mir ein PDA, ein Programm

39:14.050 --> 39:19.190
läuft, das in Visual Basic geschrieben ist und eine Funktion auf einem

39:19.190 --> 39:24.930
Server aufruft, der unter Linux läuft und die Funktion mit Java

39:24.930 --> 39:25.650
geschrieben ist.

39:25.870 --> 39:30.370
Und das Ganze geht dann noch über Funk, Ethernet und sonstige

39:30.370 --> 39:30.990
Protokolle.

39:30.990 --> 39:32.490
Wie können Sie sowas machen?

39:33.470 --> 39:38.110
Sowas will man eigentlich haben und sowas ist technisch möglich und

39:38.110 --> 39:40.670
zwar mit sogenannten Web-Services.

39:42.530 --> 39:46.410
Web-Services bieten zum Beispiel eben diese Sachen, die Sie bei Java,

39:46.550 --> 39:47.790
RMI und Cobra nicht haben.

39:48.590 --> 39:54.250
Also Java ist kein allgemeines, freies und verbreitet ist es, aber es

39:54.250 --> 39:56.330
ist kein allgemeines und offenes Protokoll.

39:57.030 --> 40:02.070
Das ist von Sun, die haben da den Daumen drauf und es ist also nicht

40:02.070 --> 40:08.230
so einfach, einen Java J2E Server anzusprechen, ohne dass Sie auch

40:08.230 --> 40:12.730
dieses Java Protokoll verwenden oder einen Java Client benutzen.

40:13.870 --> 40:17.130
Das hier, dass Sie die Partner im Normalfall kennen, das ist also die

40:17.130 --> 40:19.830
recht enge Kupplung an der Sprache.

40:21.090 --> 40:26.730
Meistens ist es so, dass das Ganze Cobra und Java RMI gut im Intranet

40:26.730 --> 40:29.350
funktioniert, aber wenn Sie mal über ein paar Routern und ein paar

40:29.350 --> 40:32.030
Firewalls weg müssen im Internet, dann funktioniert es schon mal nicht

40:32.030 --> 40:32.510
mehr so gut.

40:33.110 --> 40:34.710
Und Sie haben keine Suchmaschinen.

40:35.410 --> 40:38.530
Das heißt, stellen Sie sich vor, Sie haben einen Client, der

40:38.530 --> 40:40.010
irgendeinen Dienst braucht.

40:40.850 --> 40:43.310
Und da wissen Sie nicht, wo Sie suchen müssen.

40:43.510 --> 40:46.770
Wo kriegen Sie jetzt einen Dienst her, den Sie über RMI ansprechen

40:46.770 --> 40:48.670
können und der Ihnen genau Ihr Problem löst.

40:48.670 --> 40:50.610
Es gibt also keine Suchmaschine für sowas.

40:52.510 --> 40:58.530
Und genau aus diesen Mängeln hat man sich zusammengesetzt und hat sich

40:58.530 --> 41:00.450
eben das Prinzip der Web Services überlegt.

41:01.030 --> 41:03.510
Hat man sich überlegt, wie kann ich das machen, dass ich ein offenes

41:03.510 --> 41:06.830
Protokoll habe, mit dem ich über heterogene

41:06.830 --> 41:12.530
Kommunikationsinfrastrukturen, heterogene Betriebssysteme, heterogene

41:12.530 --> 41:16.570
Programmiersprachen und möglichst viele Clients verteilte Systeme

41:16.570 --> 41:17.450
realisieren kann.

41:18.810 --> 41:21.630
Dann hat man sich eben zusammengesetzt und hat sich Web Services

41:21.630 --> 41:23.070
überlegt.

41:23.550 --> 41:24.610
Was ist ein Web Service?

41:25.670 --> 41:29.630
Ein Web Service ist also ein Dienst, der mithilfe von XML auf der

41:29.630 --> 41:32.110
Basis von Internetnetzwerkprotokollen erbracht wird.

41:33.390 --> 41:39.170
Das kann man sich vorstellen als eine Methode, die Sie auf einem

41:39.170 --> 41:43.150
entfernten Rechner ausführen können und die Ihnen dann aber lokal das

41:43.150 --> 41:44.510
Ergebnis wieder zur Verfügung stellt.

41:44.630 --> 41:48.730
Also das, was Sie bei J2E und diesen Enterprise Java Beans auch haben,

41:49.410 --> 41:51.230
allerdings technisch etwas anders realisiert.

41:51.530 --> 41:53.450
Vor allem was die Kommunikation dazwischen angeht.

41:54.870 --> 41:57.290
Es gibt die drei wichtigsten Teile dieser Zusammenarbeit.

41:57.290 --> 41:59.130
Das ist also eben das Zusammenfinden.

41:59.510 --> 42:01.850
Bei Web Services haben Sie nämlich so eine Suchmaschine oder so einen

42:01.850 --> 42:04.170
Suchmechanismus, mit dem Sie diese Dienste finden können.

42:05.310 --> 42:11.050
Das Binden, das kann man sich so vorstellen, wie wenn Sie bei CORPA

42:11.050 --> 42:13.870
aus der Interface Definition Language so einen kleinen Stab

42:13.870 --> 42:14.430
generieren.

42:15.110 --> 42:16.130
Das ist also das Binden.

42:17.050 --> 42:21.150
Da geht es also darum, wie der Service selbst beschrieben wird und der

42:21.150 --> 42:22.890
eigentliche Datenaustausch natürlich auch.

42:25.450 --> 42:27.190
Hier haben wir also nochmal die Architektur.

42:27.590 --> 42:30.830
Stellen Sie sich vor, Sie haben hier einen Client, der sucht

42:30.830 --> 42:31.470
irgendeinen Dienst.

42:31.790 --> 42:35.010
Da gibt es also einen Service Broker, bei dem er anfragen kann, ich

42:35.010 --> 42:36.990
suche diesen und diesen Dienst, gibt es da was?

42:37.750 --> 42:41.430
Und der Service Broker kann also nachgucken in der Datenbank, da sind

42:41.430 --> 42:44.650
alle Dienste eingetragen, die die verschiedenen Servicebereiter bei

42:44.650 --> 42:46.730
diesem Broker veröffentlicht haben.

42:46.730 --> 42:50.210
Also wie eine Suchmaschine, nur dass der nicht selber sucht, sondern

42:50.210 --> 42:53.410
das anbietet, was ein Service Provider veröffentlichen will.

42:54.270 --> 42:59.410
Dann gibt es vom Service Broker eben zurück, ja es gibt einen Dienst,

42:59.870 --> 43:02.110
dann kann man da und da den Dienst ansprechen.

43:02.690 --> 43:06.590
Und dann spricht der Service Client, der Client spricht dann dem

43:06.590 --> 43:09.070
Provider, dessen Adresse er von dem Broker erhält.

43:09.070 --> 43:14.990
Also praktisch hier, die Adresse, die Sie zurückkriegen.

43:16.610 --> 43:20.890
Dann wird er über diese Adresse der eigentliche Provider angesprochen.

43:21.550 --> 43:26.990
Das nennt man also Binding, das Systemmodell.

43:27.330 --> 43:30.310
Also um sowas machen zu können, wenn Sie sich vorstellen, Sie haben

43:30.310 --> 43:33.490
ein paar Programmiersprachen, Sie haben ein paar verschiedene Clients,

43:33.590 --> 43:37.170
Sie haben ein paar Betriebssysteme, da muss man sich dann auf

43:37.170 --> 43:38.470
irgendwelche Protokolle einigen.

43:38.810 --> 43:41.630
Und da haben sich also die größten Softwarehersteller, also hier jetzt

43:41.630 --> 43:45.270
Microsoft, IBM, Sun, die haben sich zusammengesetzt und haben sich auf

43:45.270 --> 43:46.810
gewisse Standards geeinigt.

43:47.990 --> 43:51.570
Und das sind die drei wichtigsten, es gibt einige Standards im

43:51.570 --> 43:54.110
Zusammenhang mit Web Service, aber das sind die drei wichtigsten, das

43:54.110 --> 43:56.190
ist SOAP, das Simple Object Access Protocol.

43:58.050 --> 44:01.510
Dieses Protokoll beschreibt Ihnen den Datenaustausch.

44:01.510 --> 44:06.690
Dann haben Sie WSDL, das ist eben die Description Language, das ist

44:06.690 --> 44:10.030
eben die Interface Definition Language für Web Services.

44:10.310 --> 44:14.270
Diese Sprache beschreibt Ihnen genau, was der Dienst anbietet, wie die

44:14.270 --> 44:16.990
Methoden heißen, wie sie angesprochen werden, wie die Daten kodiert

44:16.990 --> 44:19.210
werden müssen, wie sie übertragen werden müssen.

44:21.070 --> 44:25.590
Und zu guter Letzt UDDI, das ist der Mechanismus, der also das

44:25.590 --> 44:29.310
Veröffentlichen von Diensten und das Suchen nach Diensten unterstützt.

44:34.030 --> 44:38.370
Dafür wird XML benutzt, das heißt die ganzen Protokolle, SOAP, UDDI

44:38.370 --> 44:41.690
und WSDL, die sind allesamt XML-basiert.

44:42.590 --> 44:46.630
Also der Datenaustausch, das ist SOAP, das ist ein XML-basiertes

44:46.630 --> 44:48.850
Protokoll, das werde ich auch noch erklären, ich habe ja ein Beispiel

44:48.850 --> 44:49.230
dafür.

44:50.270 --> 44:54.230
Hier steht, mit HTTP übertragen, das muss nicht sein.

44:54.810 --> 44:57.790
Also man kann es auch über FDP, also man kann es über irgendein

44:57.790 --> 45:02.330
Protokoll übertragen, über E-Mail, SMTP können Sie auch nehmen, aber

45:02.330 --> 45:06.130
in der Praxis ist es so, dass Sie normalerweise HTTP verwenden, das

45:06.130 --> 45:09.350
kommt auch daher, dass normalerweise eine Kommunikation immer vom

45:09.350 --> 45:13.350
Client initialisiert wird, das heißt der Client will irgendwas vom

45:13.350 --> 45:16.790
Server, der Client spricht den Server an und nicht umgekehrt oder kein

45:16.790 --> 45:18.050
Peer -to-Peer oder solche Sachen.

45:18.690 --> 45:20.470
Da eignet sich HTTP eben relativ gut.

45:21.570 --> 45:25.850
Dann das Zusammenfinden, das ist eben das UDDI, das ist eben der

45:25.850 --> 45:28.690
Mechanismus, mit dem man solche Dienste sucht und findet.

45:29.650 --> 45:31.290
UDDI basiert selber auf SOAP.

45:32.990 --> 45:36.470
Und das Binden, das ist eben der WSDL-Standard.

45:37.550 --> 45:40.910
Da wird eben beschrieben, wie ich den Service ansprechen kann.

45:41.650 --> 45:43.990
Also formale Beschreibung dieses Dienstes.

45:44.330 --> 45:47.370
Das ist das, was ich als Nutzer erstmal benötige, wenn ich den Dienst

45:47.370 --> 45:48.130
ansprechen will.

45:51.870 --> 45:53.170
Also hier haben wir es nochmal.

45:53.390 --> 45:57.930
Während also bei CORPA, RMI oder DECOM meistens proprietäre binäre

45:57.930 --> 46:01.750
Standards verwendet werden, um diese entfernte Kommunikation

46:01.750 --> 46:06.370
auszuführen, haben wir bei Web-Services reines XML.

46:07.110 --> 46:11.390
Wir sind rein textbasiert, wir haben einfaches XML, das meistens über

46:11.390 --> 46:12.210
HTTP läuft.

46:14.710 --> 46:16.790
Also SOAP, was ist das?

46:18.450 --> 46:20.370
Das ist ein relativ schlankes Protokoll.

46:20.770 --> 46:24.150
Das heißt, man hat versucht, möglichst wenig Daten-Overhead da

46:24.150 --> 46:27.630
reinzubringen, um die Kommunikation möglichst effektiv, sofern es

46:27.630 --> 46:31.050
überhaupt möglich ist, Kommunikation über XML und HTTP effizient zu

46:31.050 --> 46:31.250
machen.

46:31.970 --> 46:34.050
Aber man hat versucht, das Protokoll möglichst schlank zu halten.

46:35.910 --> 46:40.690
Und SOAP dient also primär dem Informationsaustausch.

46:40.690 --> 46:45.190
In dieses Protokoll werden also die entfernten Prozedur-Aufrufe

46:45.190 --> 46:50.430
gekapselt, zum Server übertragen und vom Server wieder an den Client

46:50.430 --> 46:51.190
zurück übergeben.

46:51.510 --> 46:52.970
Es ist komplett plattformunabhängig.

46:53.350 --> 46:55.710
Es ist klar, es basiert auf XML, es ist standardisiert.

46:58.410 --> 47:02.550
Aber trotz der Einfachheit können Sie mit SOAP relativ komplexe

47:02.550 --> 47:04.930
Objekte zwischen verschiedenen Programmen austauschen.

47:04.930 --> 47:08.710
Also Sie können, wenn Sie mal Java programmiert haben und sich mal

47:08.710 --> 47:12.130
eine relativ komplexe Klasse oder ein komplexes Objekt zusammengebaut

47:12.130 --> 47:16.910
haben oder benutzen, auch sowas können Sie über SOAP verteilen.

47:17.010 --> 47:21.210
Das kann man komplett in XML umkodieren, sodass es sich durch HTTP

47:21.210 --> 47:22.130
übertragen lässt.

47:24.550 --> 47:28.710
Und die Syntax von SOAP-Nachrichten, das ist also zwei Sachen.

47:28.810 --> 47:30.790
Zum einen ist es durch den Standard festgelegt.

47:30.790 --> 47:36.810
Also gewisse Teile von SOAP sind fix, sind durch das W3C festgelegt,

47:36.890 --> 47:37.710
die können Sie nicht ändern.

47:38.390 --> 47:41.250
Das ist also der Grundaufbau einer solchen SOAP-Nachricht.

47:42.370 --> 47:46.150
Und der zweite Teil wird durch WSDL-Dateien beschrieben.

47:46.730 --> 47:50.470
Also damit wird beschrieben, wie die eigentlichen Daten kodiert

47:50.470 --> 47:50.770
werden.

47:51.290 --> 47:54.070
Wie die Methoden heißen, die Sie aufrufen, wie die Parameter heißen

47:54.070 --> 47:55.850
und natürlich auch Ihre Nutzdaten.

47:55.850 --> 48:01.690
Also einmal hier W3C-Standards und WSDL-Dateien.

48:03.230 --> 48:06.610
Und damit ist es also möglich, in diesem Protokoll ist es tatsächlich

48:06.610 --> 48:14.630
möglich, solche Plattformen, die Sie nicht so richtig mögen, und auch

48:14.630 --> 48:18.050
Firmen, die Sie nicht so richtig mögen, wie Sun, Microsoft, Java und

48:18.050 --> 48:21.370
.NET, können Sie problemlos miteinander kommunizieren lassen.

48:21.370 --> 48:22.930
Das funktioniert also tatsächlich.

48:23.330 --> 48:27.650
Was vorher mit RMI und DCOM undenkbar war, hätte nie funktioniert.

48:28.350 --> 48:31.010
Und mit Webservice können Sie eben genau das machen.

48:31.330 --> 48:35.550
Sie können sich einen Windows-Client unter .NET schreiben und damit

48:35.550 --> 48:40.410
einen Server ansprechen und eine serverseitige Funktion aufrufen, die

48:40.410 --> 48:42.650
in Java realisiert ist.

48:42.810 --> 48:44.710
Oder natürlich auch umgekehrt funktioniert.

48:47.670 --> 48:50.510
Das sind also die Standteile von SOAP.

48:52.190 --> 48:55.350
SOAP ist im Prinzip ähnlich aufgebaut wie eine E-Mail.

48:55.830 --> 49:00.150
Sie haben eine Hülle, also den sogenannten Envelope, der das Ganze

49:00.150 --> 49:00.570
enthält.

49:01.050 --> 49:06.490
Das ist nicht mehr als ein XML-Tag, der ein paar Namespaces enthält.

49:06.930 --> 49:11.490
Der enthält also den Header und den Body, wobei der Header nur

49:11.490 --> 49:12.270
optional ist.

49:12.270 --> 49:14.910
Diese zusätzlichen Informationen braucht man nicht, die da drin

49:14.910 --> 49:15.270
stehen.

49:16.130 --> 49:16.950
Da kann man z.B.

49:17.090 --> 49:20.370
Sachen reinschreiben, was passiert im Fehlerfall, wie eine

49:20.370 --> 49:21.490
Fehlerbehandlung aussieht.

49:22.170 --> 49:25.490
Im Normalfall ist es aber so, dass der Header fehlt oder gar nicht

49:25.490 --> 49:25.970
vorhanden ist.

49:26.070 --> 49:29.890
Das müssen Sie, wenn Sie sowas implementieren, Ihre Sprache oder Ihre

49:29.890 --> 49:33.450
Laufzeitumgebung oder Ihr System, mit dem Sie sowas dann bauen wollen

49:33.450 --> 49:35.190
oder nutzen wollen, müssen Sie das extra angeben.

49:36.110 --> 49:37.370
Das Interessanteste ist der Body.

49:39.250 --> 49:43.690
Im Body steht also drin, wie die Methode heißt.

49:43.890 --> 49:46.670
Da ist der eigentliche Prozeduraufruf, die Daten und die

49:46.670 --> 49:47.330
Rückgabewerte.

49:48.190 --> 49:50.950
Was SOAP nicht beschreibt, ist, was die Daten letztendlich bedeuten.

49:51.410 --> 49:53.750
Das ist Ihre Sache, was Sie als Programmierer damit machen.

49:54.010 --> 49:58.050
Im SOAP wird also nichts über Semantik ausgesagt.

49:58.150 --> 49:59.270
Das sind einfach reine Daten.

50:01.390 --> 50:02.390
Wir haben ein Beispiel.

50:02.750 --> 50:03.590
Ich hoffe, man kann es sehen.

50:05.710 --> 50:07.590
Das ist also eine SOAP-Nachricht.

50:09.010 --> 50:11.570
Stellen wir vor, wir haben einen Server, der bietet uns eine Funktion

50:11.570 --> 50:12.290
an, die heißt add.

50:13.770 --> 50:14.530
Was macht die?

50:14.710 --> 50:16.130
Oh Wunder, zwei Zahlen addiert sie.

50:16.930 --> 50:17.930
Int a und int b.

50:18.630 --> 50:25.770
Was muss ich machen, wenn ich als Client diese Funktion aufrufe?

50:25.970 --> 50:28.490
Zum einen habe ich einen ganz normalen HTTP-Aufruf.

50:28.850 --> 50:30.390
Das kennen Sie schon vom letzten Mal.

50:30.390 --> 50:34.730
Also ich habe einen HTTP-Post, wo ich die Adresse vom Server angebe.

50:35.030 --> 50:38.470
Das sind im Normalfall natürlich keine HTML-Dateien, sondern es ist je

50:38.470 --> 50:41.230
nachdem, mit was man es realisiert.

50:41.930 --> 50:45.130
In dem Fall ist es eine ASMX-Datei, weil es mit dem IS und der .NET

50:45.130 --> 50:45.750
gemacht wurde.

50:46.790 --> 50:49.090
Der Host ist in dem Fall jetzt der Localhost.

50:51.150 --> 50:55.150
Ein bisschen was über den Content-Type, die Länge und eine SOAP

50:55.150 --> 50:55.490
-Action.

50:56.170 --> 50:59.490
Das ist aber noch nichts Besonderes, das ist ganz normales HTTP.

50:59.490 --> 51:02.330
Das eigentlich Interessante sind diese SOAP-Daten hier.

51:02.370 --> 51:03.490
Das ist jetzt das Protokoll.

51:04.370 --> 51:09.130
Normalerweise steht bei einem HTTP-Post-Aufruf an der Stelle nur ein

51:09.130 --> 51:12.970
Funktions -Variable und Wert.

51:13.730 --> 51:17.250
Ein paar, wie Sie es zum Beispiel kennen, wenn Sie sich bei einem HTML

51:17.250 --> 51:18.570
-Formular anmelden irgendwo.

51:18.990 --> 51:21.750
Oder gar nichts, wenn Sie nur statische HTML-Seiten abrufen.

51:22.330 --> 51:23.970
In dem Fall stehen da eine ganze Menge Daten.

51:24.850 --> 51:26.030
Das sind also die SOAP-Daten.

51:26.030 --> 51:27.310
Dann haben wir hier den Envelope.

51:28.390 --> 51:29.030
Das ist das hier.

51:29.270 --> 51:29.930
Der muss sein.

51:31.090 --> 51:35.270
Der enthält also nichts weiter als ein paar Namespace-Angaben.

51:35.510 --> 51:41.770
Also hier, dass wir uns nach XML-Schema, das W3C, richten und solche

51:41.770 --> 51:42.110
Sachen.

51:43.070 --> 51:43.750
Der Header fehlt.

51:44.630 --> 51:46.170
Und das Entscheidende hier ist der Body.

51:47.130 --> 51:51.490
Da steht also jetzt zum Beispiel drin, sehen Sie hier, Add.

51:51.790 --> 51:53.530
Das ist die Methode hier, die wir aufrufen.

51:54.310 --> 51:56.970
Und das sind unsere beiden Parameter A und B, die wir übertragen

51:56.970 --> 51:57.250
wollen.

51:58.070 --> 51:59.270
Das steht also hier im Body.

51:59.890 --> 52:01.070
Und das sind die eigentlichen Daten.

52:02.330 --> 52:03.450
Das geht jetzt zum Server.

52:04.390 --> 52:09.010
Der Server zieht sich dann über seine Funktionalität eben diese Sachen

52:09.010 --> 52:09.310
raus.

52:09.410 --> 52:12.330
Der Server weiß, okay, das ist die Methode Add, die angesprochen wird.

52:12.730 --> 52:13.770
Hier findet er die Zahlen.

52:14.290 --> 52:15.690
Die werden in Integer umgewandelt.

52:16.230 --> 52:17.290
Dann wird das Ganze ausgeführt.

52:17.990 --> 52:20.190
Und so wird das Ergebnis dann zurück übertragen.

52:20.590 --> 52:22.090
Auch hier haben wir wieder ganz normales HTTP.

52:22.950 --> 52:23.830
Da kommt eine schöne Meldung.

52:23.890 --> 52:25.350
200, okay, hat alles geklappt.

52:26.090 --> 52:27.350
Ein bisschen die Länge der Daten.

52:27.450 --> 52:28.990
Dann haben wir wieder unseren Soap-Envelope.

52:29.910 --> 52:33.090
Und hier auch im Body wieder das Ergebnis.

52:33.490 --> 52:37.350
Also Sie haben hier die Antwort und das Resultat.

52:38.570 --> 52:41.310
Das sind also die Rückgabewerte, die dann wieder in den Soap-Daten

52:41.310 --> 52:41.590
stecken.

52:41.890 --> 52:43.770
Das ist also das, was durch die Leitung geht.

52:45.110 --> 52:47.930
Und was man jetzt hier schon sieht, das ist relativ viel Text für

52:47.930 --> 52:49.250
relativ wenig Nutzdaten.

52:50.330 --> 52:52.670
Das ist natürlich in dem Fall so, wenn Sie zwei kleine Zahlen

52:52.670 --> 52:57.110
hinschicken und nur eine Zahl zurückkriegen, ist es natürlich so, dass

52:57.110 --> 53:01.050
das Prozentual der Overhead relativ groß ist bei diesem Verfahren.

53:02.030 --> 53:04.370
Aber wie ich schon gesagt habe, mit Soap können Sie auch sehr komplexe

53:04.370 --> 53:05.250
Objekte übertragen.

53:05.410 --> 53:09.010
Und dann sinkt der Overhead verhältnismäßig wieder ab.

53:11.070 --> 53:13.930
Das ist vielleicht ein bisschen ein Nachteil von der Geschichte, dass

53:13.930 --> 53:15.530
Sie auch einen relativ großen Overhead haben.

53:16.030 --> 53:20.270
Und je nachdem, wie es implementiert ist, XML-Verarbeitung nicht

53:20.270 --> 53:22.590
unbedingt schnell ist, je nachdem, was Sie verwenden.

53:23.430 --> 53:26.270
Aber Sie haben damit eben die Möglichkeit, über diesen Standard

53:26.270 --> 53:30.170
komplett Plattformen und Sprachenunabhängig Daten auszutauschen.

53:31.590 --> 53:35.890
Jetzt haben wir gesehen, mein Client muss also hier diesen XML-Code

53:35.890 --> 53:36.150
erzeugen.

53:36.970 --> 53:39.170
Jetzt fragt man sich, woher weiß der Client denn das?

53:39.290 --> 53:41.670
Woher weiß er, dass die Funktion Add heißt?

53:42.110 --> 53:46.230
Woher weiß er, dass er die Parameter so erzeugen muss, mit diesen Tags

53:46.230 --> 53:46.430
hier?

53:47.230 --> 53:48.950
Und woher weiß er, dass die A und B heißen?

53:49.370 --> 53:52.730
Und woher weiß er, dass das Resultat dann tatsächlich in diesem Add

53:52.730 --> 53:54.150
-Result -Tag drinsteht?

53:55.630 --> 53:58.090
Das macht eben die Web-Service-Description-Language.

53:59.150 --> 54:02.870
Die beschreibt den Web-Service maschinenlesbar.

54:02.870 --> 54:05.810
Das heißt, das ist nichts, was irgendwie für Menschen gemacht ist, wie

54:05.810 --> 54:06.170
HTML.

54:07.470 --> 54:09.490
Ich habe ja auch ein Beispiel dazu, da sehen Sie es dann.

54:10.270 --> 54:15.610
Da steht eigentlich im Wesentlichen drin, die Namen der Funktionen,

54:15.670 --> 54:19.710
wie die Parameter heißen, was für Datentypen es sind und was für

54:19.710 --> 54:25.430
Rückgabewerte kommen und vor allem, wie diese Daten in XML beschrieben

54:25.430 --> 54:26.030
werden müssen.

54:27.590 --> 54:30.470
Da hat man gewisse Freiheiten als Programmierer.

54:30.470 --> 54:33.970
Das ist durch WSDL nicht unbedingt selbst festgelegt.

54:35.110 --> 54:39.190
Das kann man selber bestätigen, aber in dieser Datei steht es dann

54:39.190 --> 54:43.630
drin, wie Sie die eigentlichen Funktionsnamen und die Parameter in XML

54:43.630 --> 54:47.270
kodieren müssen, sodass der Server weiß, was Sie als Client von ihm

54:47.270 --> 54:50.130
wollen, wenn Sie ihm die SOAP-Nachricht schicken und sodass Sie als

54:50.130 --> 54:57.290
Client wissen, wie der Server die Daten kodiert und dann

54:57.290 --> 54:57.750
zurückschickt.

55:00.250 --> 55:04.390
Das beschreibt also praktisch das, dass Sie als Client wissen, so muss

55:04.390 --> 55:07.330
ich meine Nutzdaten aufbauen, damit der Server weiß, was damit gemeint

55:07.330 --> 55:07.530
ist.

55:09.310 --> 55:14.090
Und da steht dann auch drin, wie das hier aufgebaut ist, dass also der

55:14.090 --> 55:20.430
Client weiß, wo in der Antwort eigentlich die Ergebnisse stehen, wie

55:20.430 --> 55:21.610
er an die Ergebnisse drankommt.

55:22.910 --> 55:25.270
Das wird durch WSDL beschrieben, als die Schnittstelle.

55:25.270 --> 55:28.530
Selbst ist es natürlich auch XML-basiert.

55:29.810 --> 55:33.850
Wie bei SOAP ist es so, dass Teile fix sind und festgelegt sind, aber

55:33.850 --> 55:37.410
es haben einige eigene Schema-Definitionen, kann ich mir selber

55:37.410 --> 55:37.890
ausdenken.

55:38.470 --> 55:39.210
Das ist auch nötig.

55:43.550 --> 55:44.970
Wozu wird das verwendet?

55:45.250 --> 55:50.690
In der Praxis benutzt man WSDL also so, wie die IDL bei CORPA, ich

55:50.690 --> 55:53.410
erzeuge mir einen kleinen Stub, also so eine Art Proxy.

55:53.410 --> 55:56.630
Das heißt, wenn Sie das verwenden, wenn Sie es zum Beispiel mit .NET

55:56.630 --> 56:03.530
verwenden, da wird Ihnen automatisch aus der WSDL-Beschreibung eine

56:03.530 --> 56:09.210
lokale Klasse erzeugt, die Sie verwenden, wie eine lokale Klasse, die

56:09.210 --> 56:11.730
aber die Methoden nicht selber ausführt, sondern an den Server

56:11.730 --> 56:12.390
weiterleitet.

56:12.690 --> 56:14.870
Dann haben Sie also genau die Methoden, die der Server anbietet,

56:14.970 --> 56:18.830
können Sie lokal verwenden, als würden Sie die Klasse selber lokal vor

56:18.830 --> 56:19.470
sich liegen haben.

56:19.470 --> 56:22.790
Und dass das dann durch das Netz serialisiert wird und das ganze HTTP

56:22.790 --> 56:26.110
-Protokoll und die Soap-Kapseln, das kriegen Sie gar nicht mit.

56:30.690 --> 56:33.650
Also, die Dokumentstruktur von so einem WSDL-Dokument.

56:35.030 --> 56:38.950
Das ist zweigeteilt, fünfgeteilt kann man eigentlich sagen.

56:39.710 --> 56:41.270
Sie haben mehrere Sachen, die definiert werden.

56:42.190 --> 56:45.950
Das eine sind die Types, da haben Sie also die Datentypen und die

56:45.950 --> 56:46.570
Bezeichnung.

56:46.570 --> 56:48.110
Was für Daten haben Sie?

56:48.930 --> 56:51.210
In dem Fall zum Beispiel bei uns sind es Integer-Werte.

56:51.950 --> 56:53.090
Wie werden sie bezeichnet?

56:54.410 --> 56:59.170
Und wie muss das in XML kodiert werden?

56:59.570 --> 57:03.750
Sie haben jetzt gesehen, ich habe ein Element und zwei Subknoten, aber

57:03.750 --> 57:06.010
ich könnte mir auch vorstellen, dass ich das ganz anders kodiere in

57:06.010 --> 57:06.290
XML.

57:06.410 --> 57:07.410
Ich bin ja da nicht festgelegt.

57:08.090 --> 57:11.150
Ich könnte mir die Zahlen zum Beispiel auch als Attribut eines

57:11.150 --> 57:12.830
einzigen Knoten zum Server schicken.

57:13.810 --> 57:17.470
Deswegen habe ich eine eigene Schema-Definition, mit der ich das

57:17.470 --> 57:17.990
festlege.

57:18.690 --> 57:24.110
Diese Schema-Definition sagt also dem Client, wie die Nutzdaten

57:24.110 --> 57:26.150
letztendlich in XML übersetzt werden müssen.

57:26.950 --> 57:29.210
Dann haben wir Messages, das sind die Nachrichten selber, die

57:29.210 --> 57:30.130
verwendeten Parameter.

57:31.290 --> 57:36.570
Dann gibt es den Port-Type, der beschreibt also die Operationen und

57:36.570 --> 57:38.790
welche Nachrichten für jede Operation verwendet werden.

57:38.790 --> 57:40.710
Dann haben sie das Binding.

57:41.230 --> 57:45.950
Im Binding ist festgelegt, welches Übertragungsprotokoll verwendet

57:45.950 --> 57:46.190
wird.

57:46.490 --> 57:48.310
Also im Normalfall ist es HTTP.

57:49.310 --> 57:50.950
Und die Serialisierungsart.

57:52.430 --> 57:58.110
Serialisierungsart heißt auch wieder, in welcher Art und Weise meine

57:58.110 --> 58:00.490
Binärdaten in XML übersetzt werden.

58:01.050 --> 58:02.670
Da gibt es zwei Varianten.

58:02.950 --> 58:05.250
Das eine ist Document, das andere ist Remote Procedure.

58:05.250 --> 58:11.970
Das beschreibt also, wie ich letztendlich meine Daten in XML abbilden

58:11.970 --> 58:12.230
muss.

58:12.850 --> 58:15.590
In der Praxis wird aber meistens Document eingesetzt.

58:16.270 --> 58:17.990
Das ist auch das, was ich Ihnen jetzt vorstellen werde.

58:18.370 --> 58:20.410
Oder das, was ich vorgestellt habe in dem Beispiel.

58:21.790 --> 58:26.250
Und das letzte ist Intact, das beschreibt, wo der Server eigentlich

58:26.250 --> 58:26.550
liegt.

58:27.230 --> 58:29.090
Das weiß ich natürlich normalerweise vorher schon.

58:30.490 --> 58:31.490
Aber ich könnte mir z.B.

58:31.670 --> 58:35.790
auch vorstellen, dass ich eine WSCL-Beschreibung mir gar nicht erst

58:35.790 --> 58:36.510
vom Server hole.

58:36.850 --> 58:39.170
Sondern ich sie lokal als XML-File vorliegen habe.

58:40.030 --> 58:42.870
Da reingucke und da dann erst drinsteht, wo der eigentliche Server

58:42.870 --> 58:45.330
sich befindet, der mir diesen Dienst anbietet.

58:46.710 --> 58:48.610
Sollen wir mal einfach mal ein Beispiel, da sieht man das dann auch

58:48.610 --> 58:49.230
relativ gut.

58:53.510 --> 58:55.370
Das sind eben die WSCL-Typen.

58:55.650 --> 58:56.330
Das ist das hier.

58:59.190 --> 59:03.030
Neben einem Haufen Namespaces, die Sie zu Anfang haben.

59:03.170 --> 59:06.190
Das ist eine komplette WSCL-Datei oder der erste Anfang einer WSCL

59:06.190 --> 59:06.550
-Datei.

59:06.910 --> 59:09.550
Haben Sie hier eben eine eigene Schema-Definition.

59:10.290 --> 59:15.510
In dieser Schema-Definition wird genau das hier und das hier

59:15.510 --> 59:16.190
festgelegt.

59:17.110 --> 59:23.090
Also das ist die eigentliche Beschreibung Ihrer Methoden und Ihrer

59:23.090 --> 59:24.230
Methodenparameter.

59:24.350 --> 59:27.750
Und das Rückgabewert, genau das wird im Type-Teil einer WSCL-Datei

59:27.750 --> 59:28.310
festgelegt.

59:28.310 --> 59:31.730
Das ist ein Schema, das kennen Sie ja, das hat der Herr Schmeck ja

59:31.730 --> 59:32.350
schon erklärt.

59:32.530 --> 59:35.230
Also wir haben hier ein Element Add, zum Beispiel hier.

59:35.930 --> 59:39.090
Das ist dann das hier, das ist ein Complex-Type mit einer Sequence.

59:39.190 --> 59:41.970
Das heißt also, ich habe zwei Texte, die in einer ganz bestimmten

59:41.970 --> 59:43.950
Reihenfolge nacheinander darstehen müssen.

59:45.930 --> 59:48.390
Das ist jetzt im Fall einer Add-Methode wahrscheinlich egal.

59:48.570 --> 59:51.030
Wenn Sie aber sich vorstellen, Sie haben eine Methode, die Subtract

59:51.030 --> 59:54.530
heißt oder Divide, dann ist es nicht mehr egal, die Reihenfolge.

59:55.350 --> 59:57.670
Also das ist zum Beispiel relativ wichtig in dem Fall.

59:58.090 --> 01:00:01.270
Oder in dem Fall genau nicht, aber im Allgemeinen ist es wichtig, dass

01:00:01.270 --> 01:00:03.970
Sie eben die Reihenfolge der Parameter festlegen.

01:00:04.110 --> 01:00:05.330
Deswegen hier diese Sequence.

01:00:06.930 --> 01:00:09.530
Und was Sie dann natürlich hier noch haben, ist noch ein Element, die

01:00:09.530 --> 01:00:10.210
Add -Response.

01:00:12.350 --> 01:00:15.550
Damit wird also festgelegt, wie das Resultat letztendlich aussieht.

01:00:15.690 --> 01:00:20.150
Also dieser Type-Teil beschreibt Ihnen, wie Ihre eigentlichen

01:00:20.150 --> 01:00:22.230
Nutzdaten später in SOAP eingebettet werden.

01:00:25.170 --> 01:00:29.010
So, der zweite Teil in einem WSDL-Dokument.

01:00:30.990 --> 01:00:32.590
Fangen wir mal ein bisschen von hinten an.

01:00:32.850 --> 01:00:33.690
So steht es auch drin.

01:00:34.570 --> 01:00:35.610
Das ist also der Service.

01:00:36.470 --> 01:00:37.670
Da haben Sie also hier die Adresse.

01:00:38.690 --> 01:00:42.410
In dem Fall habe ich es halt schnell lokal eingebaut für das Beispiel.

01:00:42.710 --> 01:00:43.690
Deswegen hier der Localhost.

01:00:43.790 --> 01:00:47.270
Da steht also im Wesentlichen, unter welcher Adresse Sie ihn

01:00:47.270 --> 01:00:48.010
ansprechen können.

01:00:48.130 --> 01:00:49.590
Vielleicht noch ein bisschen Dokumentation dazu.

01:00:51.890 --> 01:00:54.250
Und dann haben Sie einen Verweis auf ein Binding.

01:00:54.790 --> 01:00:55.970
Das Binding ist das hier.

01:00:56.970 --> 01:00:58.590
Im Binding steht also Transport.

01:00:59.990 --> 01:01:00.710
Hier, HTTP.

01:01:02.850 --> 01:01:05.030
Und der Codierungsstil des Ganzen.

01:01:07.830 --> 01:01:10.590
Das Binding verweist wieder auf den sogenannten Port-Type.

01:01:11.590 --> 01:01:13.770
Im Port-Type steht dann die eigentlichen Operationen.

01:01:13.830 --> 01:01:14.950
In diesem Fall ist es nur eine.

01:01:16.050 --> 01:01:17.510
Hier steht also der Name Add.

01:01:18.510 --> 01:01:21.430
Und dieser Name, den ich hier reingeschrieben habe, das ist der Name,

01:01:21.510 --> 01:01:23.430
so wie meine Funktion auf dem Server heißt.

01:01:23.890 --> 01:01:26.110
So wie ich sie also in der Server-Implementierung genannt habe.

01:01:26.910 --> 01:01:28.230
Das steht im Port-Type drin.

01:01:28.790 --> 01:01:29.770
Hier haben wir noch ein bisschen Doku.

01:01:30.790 --> 01:01:34.430
Und vor allem steht hier mit Input und Output, welche Daten in die

01:01:34.430 --> 01:01:36.650
Funktion reingehen und was wieder rauskommt.

01:01:38.190 --> 01:01:39.670
Das ist über dieses sogenannte Messages.

01:01:40.190 --> 01:01:42.950
Über diese Tags ist das also definiert.

01:01:45.330 --> 01:01:48.050
Da haben sie also hier das AddSoapIn.

01:01:49.070 --> 01:01:51.310
Das ist hier referenziert.

01:01:52.230 --> 01:01:56.270
Damit wird also beschrieben, okay, das, was in die Methode reingeht,

01:01:57.710 --> 01:02:01.430
das ist hier durch das Element Add spezifiziert.

01:02:02.350 --> 01:02:06.690
Beziehungsweise das, was rauskommt, ist durch das Element AddResponse

01:02:06.690 --> 01:02:08.410
spezifiziert.

01:02:08.950 --> 01:02:11.490
Und wie das aussieht, das haben wir auf der vorherigen Folie gesehen.

01:02:11.490 --> 01:02:12.530
Das ist genau das.

01:02:13.690 --> 01:02:17.590
Also mit diesem Mechanismus oder mit dieser Beschreibung weiß der

01:02:17.590 --> 01:02:21.790
Client also ganz genau, welche Methoden der Server anbietet, welche

01:02:21.790 --> 01:02:26.530
Parameter er braucht, wie werde ich sie ansprechen, wie muss ich die

01:02:26.530 --> 01:02:29.870
Daten in XML übersetzen, bevor ich sie hinschicke, wie sieht das

01:02:29.870 --> 01:02:37.090
Ergebnis aus, wie ist das Ergebnis kodiert und solche Sachen.

01:02:37.270 --> 01:02:39.670
Adresse eben noch, welches Protokoll verwendet wird.

01:02:39.670 --> 01:02:43.830
Also da steht alles drin, was der Client braucht, um den Dienst

01:02:43.830 --> 01:02:44.670
ansprechen zu können.

01:02:47.470 --> 01:02:53.190
Jetzt haben wir noch etwas zur Veröffentlichung und zum Finden von

01:02:53.190 --> 01:02:53.850
solchen Diensten.

01:02:56.090 --> 01:03:00.410
Also wenn Sie zum Beispiel, stellen Sie sich vor, Sie wollen einen

01:03:00.410 --> 01:03:02.210
Client schreiben, der Bücher bestellt.

01:03:02.630 --> 01:03:04.670
Also Sie wollen ein eigenes Programm schreiben, wo Sie irgendwie eine

01:03:04.670 --> 01:03:07.310
Liste haben von Büchern, wollen anklicken und sagen, ich will das

01:03:07.310 --> 01:03:07.830
jetzt bestellen.

01:03:09.530 --> 01:03:12.750
Gut, Sie können natürlich zu Amazon gehen und das verwenden.

01:03:12.930 --> 01:03:16.250
Aber mal angenommen, Sie wüssten das nicht, dann könnten Sie unter

01:03:16.250 --> 01:03:24.730
UDDI suchen nach Diensten, die es ermöglichen, Bücher oder CDs oder

01:03:24.730 --> 01:03:27.670
was auch immer per Webservice zu bestellen.

01:03:28.370 --> 01:03:30.190
Und das würden Sie dann bei UDDI finden.

01:03:30.990 --> 01:03:34.150
Sofern der Dienstanbieter sich natürlich dort registriert hat.

01:03:34.370 --> 01:03:34.990
Das ist natürlich klar.

01:03:34.990 --> 01:03:39.170
Das ist ein webbasiertes Informationssystem für Webservices.

01:03:40.330 --> 01:03:42.990
Also im Gegensatz zu Google oder sonst etwas liefert Ihnen das keine

01:03:43.650 --> 01:03:45.190
menschenlesbaren Informationen aus.

01:03:46.110 --> 01:03:48.070
Also menschenlesbar in dem Fall schon, weil Sie natürlich eine

01:03:48.070 --> 01:03:48.890
Beschreibung brauchen.

01:03:50.310 --> 01:03:52.970
Aber es ist ein Informationssystem für Webservices.

01:03:54.550 --> 01:03:58.090
Das ist auch von den großen Softwareherstellern IBM und Microsoft und

01:03:58.090 --> 01:03:59.370
Sun ist das entwickelt worden.

01:04:01.970 --> 01:04:03.990
Selbst als Webservice realisiert.

01:04:04.930 --> 01:04:08.110
Sie werden also veröffentlichen und auffinden.

01:04:08.890 --> 01:04:14.590
Wie schon gesagt, UDDI sucht nicht selbstständig das Netz nach solchen

01:04:14.590 --> 01:04:16.910
Diensten ab, wie es eine normale Suchmaschine tut.

01:04:17.650 --> 01:04:21.250
Sondern es ist ein Katalog, wo Sie sich eintragen müssen, wenn Sie so

01:04:21.250 --> 01:04:22.730
etwas anbieten.

01:04:24.450 --> 01:04:26.030
Datenbank ist auf XML basierend.

01:04:27.170 --> 01:04:27.830
Ein Beispiel.

01:04:28.290 --> 01:04:34.950
Sie haben hier Ihren Client und Ihren UDDI Server.

01:04:36.350 --> 01:04:38.730
Sie suchen nach einem ganz bestimmten Dienst.

01:04:39.510 --> 01:04:43.210
Sie können beschreiben, was er können soll, was Sie brauchen, was Sie

01:04:43.210 --> 01:04:43.510
wollen.

01:04:44.250 --> 01:04:49.010
Und kriegen dann von dem UDDI Server die URL zurück von der WSDL

01:04:49.010 --> 01:04:51.150
Datei, die diesen Dienst beschreibt.

01:04:51.810 --> 01:04:56.010
Wir wissen, in der WSDL Datei steht drin, wie ich den Server anspreche

01:04:56.010 --> 01:04:56.970
und wo er sich befindet.

01:04:57.290 --> 01:05:02.030
Oder ich kriege gleich die URL zurück, wo Sie das Ding herkriegen.

01:05:03.850 --> 01:05:07.250
Okay, wenn Sie nur die URL von dem Server haben, dann sprechen Sie den

01:05:07.250 --> 01:05:09.430
Server an, kriegen von ihm die WSDL Datei.

01:05:10.490 --> 01:05:13.830
Und wenn Sie die WSDL Datei dann haben, dann je nachdem, was Sie für

01:05:13.830 --> 01:05:18.430
eine Programmiersprache oder was für ein System Sie verwenden, können

01:05:18.430 --> 01:05:20.570
Sie sich daran eben diesen Proxy generieren lassen.

01:05:20.870 --> 01:05:23.470
Ihr lokales Gegenstück zu dem Webservice.

01:05:24.070 --> 01:05:25.810
Und können ihn dann ganz normal benutzen.

01:05:25.810 --> 01:05:30.580
Gibt es dazu Fragen?

01:05:32.000 --> 01:05:32.680
Zu Webservices?

01:05:33.480 --> 01:05:36.300
Also was Sie da für die Klausur oder für die Übungsaufgaben wissen

01:05:36.300 --> 01:05:41.440
sollten, ist im Wesentlichen, dass es ähnliche Sachen macht oder den

01:05:41.440 --> 01:05:45.900
ähnlichen Sinn hat, wie Java, RMI und Corbar eben das verteilte,

01:05:47.240 --> 01:05:50.680
entfernte Aufrufen von Diensten und Methoden.

01:05:51.180 --> 01:05:54.940
Aber dass der Fokus vor allem darauf hin lag, das ganze heterogenen

01:05:54.940 --> 01:05:56.140
Plattformen zu ermöglichen.

01:05:56.140 --> 01:05:58.320
Dass das ganze Plattform unabhängig ist.

01:05:58.500 --> 01:06:00.720
Dass das ganze stark Internet-basiert ist.

01:06:01.040 --> 01:06:03.000
Also Sie kommunizieren hauptsächlich über HTTP.

01:06:03.940 --> 01:06:06.120
Zur Datenübertragung wird nur XML eingesetzt.

01:06:06.400 --> 01:06:10.260
Das sind so die wesentlichen Unterschiede zu Corbar und Java RMI.

01:06:10.460 --> 01:06:12.080
Das sollten Sie sich also mitnehmen und merken.

01:06:12.880 --> 01:06:15.500
Was Sie natürlich nicht wissen müssen, ist, wie eine WSDL-Datei

01:06:15.500 --> 01:06:16.700
syntaktisch aufgebaut ist.

01:06:16.900 --> 01:06:17.380
Das ist klar.

01:06:17.540 --> 01:06:18.400
Das ist auch viel zu kompliziert.

01:06:21.800 --> 01:06:23.740
Kommen wir noch zu .NET.

01:06:26.640 --> 01:06:28.080
Wir hatten schon mal was von gehört.

01:06:28.600 --> 01:06:30.180
Das gibt es seit etwa 2 Jahren.

01:06:31.460 --> 01:06:36.540
Das ist also eine Entwicklungsplattform, Laufzeitumgebung,

01:06:36.540 --> 01:06:38.880
Komponentenarchitektur, die Microsoft entwickelt hat.

01:06:41.680 --> 01:06:44.480
Hier steht Verbindung von Informationen, Personen, Systemen und

01:06:44.480 --> 01:06:44.900
Geräten.

01:06:45.100 --> 01:06:47.380
Das ist einfach zur Entwicklung von verteilten Anwendungen.

01:06:47.700 --> 01:06:48.980
Oder Standalone-Anwendungen.

01:06:50.100 --> 01:06:54.060
Wenn Sie zum Beispiel das neue Office oder wenn Sie das hier angucken,

01:06:54.060 --> 01:06:58.300
diese Kritzelei, die ich hier machen kann, das ist mit .NET gemacht.

01:07:01.500 --> 01:07:04.480
Also Software-Integration durch Verwendung von XML-Web-Services.

01:07:04.840 --> 01:07:08.740
Die haben also bei .NET darauf geachtet, dass Web-Services von

01:07:08.740 --> 01:07:11.520
vornherein tief ins System integriert werden oder die Unterstützung

01:07:11.520 --> 01:07:12.880
für Web-Services da ist.

01:07:13.580 --> 01:07:16.420
Entsprechend einfach ist es, mit dem System auch ein Web-Service zu

01:07:16.420 --> 01:07:18.600
erstellen und zu nutzen.

01:07:21.020 --> 01:07:25.720
Sie haben hier Web-Services, die also die verschiedenen Server

01:07:25.720 --> 01:07:29.080
-Clients, PDAs, Handys verbinden.

01:07:29.300 --> 01:07:31.820
Also Smart-Clients nennen sie es oder manchmal nennen sie es auch Rich

01:07:31.820 --> 01:07:32.340
-Clients.

01:07:33.080 --> 01:07:35.260
Da haben Sie die Server und natürlich diverse Entwicklungs-

01:07:35.860 --> 01:07:36.320
Entwicklerwerkzeuge.

01:07:37.020 --> 01:07:41.160
Sie müssen die einzelnen Komponenten nicht unbedingt über Web-Services

01:07:41.160 --> 01:07:41.740
verbinden.

01:07:41.880 --> 01:07:46.600
So etwas wie Java, RMI gibt es bei Microsoft auch oder bei .NET auch

01:07:46.600 --> 01:07:46.840
noch.

01:07:47.940 --> 01:07:52.720
Aber der Hauptfokus liegt eben auf der Integration mittels XML-Web

01:07:52.720 --> 01:07:53.180
-Services.

01:07:58.230 --> 01:07:59.830
Was stellt jetzt .NET bereit?

01:08:00.130 --> 01:08:03.650
Eine ganze Palette von Entwicklerwerkzeugen, Compilern, Debuggern,

01:08:04.870 --> 01:08:11.790
Ablaufumgebung für XML-Web-Dienste und ganz normale Clients und Web

01:08:11.790 --> 01:08:12.450
-Anwendungen.

01:08:13.790 --> 01:08:19.110
Ich habe letztes Mal ASP erwähnt, also diese dynamische

01:08:19.110 --> 01:08:22.130
Webseitenprogrammierung, die ähnlich wie PHP läuft.

01:08:23.010 --> 01:08:25.770
So etwas gibt es unter .NET auch, allerdings wesentlich

01:08:25.770 --> 01:08:27.450
weiterentwickelt als das alte ASP.

01:08:28.430 --> 01:08:32.250
Dann haben Sie natürlich Anwendungssoftware für diverse Clients.

01:08:34.390 --> 01:08:38.210
Sie können auf einem normalen Notebook und PC laufen lassen.

01:08:38.970 --> 01:08:42.330
Es gibt aber auch das Compact-Framework, damit können Sie es auf PDAs

01:08:42.330 --> 01:08:42.930
laufen lassen.

01:08:44.950 --> 01:08:48.250
Und es gibt inzwischen, ich weiß nicht, ob jemand von Ihnen Heisetiger

01:08:48.250 --> 01:08:52.050
gelesen hat, gestern, von Mono, was schon gehört hat.

01:08:52.790 --> 01:08:56.830
Mono ist eine Entwicklung, die es also .NET-Anwendungen erlaubt, unter

01:08:56.830 --> 01:09:01.410
allen möglichen Betriebssystemen wie Linux oder Apple oder anderen

01:09:01.410 --> 01:09:02.370
Unixen zu laufen.

01:09:02.990 --> 01:09:04.470
Es funktioniert auch tatsächlich.

01:09:04.910 --> 01:09:07.710
Es liegt daran, dass .NET standardisiert ist.

01:09:08.070 --> 01:09:10.710
Also die Ablaufumgebung und die Sprache C-Sharp, die hauptsächlich

01:09:10.710 --> 01:09:11.950
verwendet wird, ist standardisiert.

01:09:13.330 --> 01:09:17.250
Und aufgrund von dieser Standardisierung war es also möglich, der

01:09:17.250 --> 01:09:24.190
Firma Ximian eine Ablaufumgebung zu bauen, die also diese Software

01:09:24.190 --> 01:09:26.570
eben auch unter Linux laufen lassen kann.

01:09:28.490 --> 01:09:32.610
Also das Ganze hat einige Kern-XML-Dienste, wie Identifizierung,

01:09:33.290 --> 01:09:34.950
Verschlüsselung, Kalenderverwaltung.

01:09:37.190 --> 01:09:39.610
Ein Beispiel kann man sich mal angucken im Netz.

01:09:39.790 --> 01:09:40.670
Das ist MapPoint.

01:09:41.550 --> 01:09:45.450
Das ist ein Webservice, der also Kartendienste, Navigationsdienste und

01:09:45.450 --> 01:09:46.790
solche Sachen anbietet.

01:09:51.430 --> 01:09:53.270
Hier ist ein Zitat von der Webseite.

01:09:53.430 --> 01:09:54.950
Das ist natürlich ein bisschen voller Werbung.

01:09:56.790 --> 01:09:59.150
Entwicklerwerkzeuge ist hauptsächlich neben dem SDK für

01:09:59.150 --> 01:10:00.310
Kommandozeilenentwicklung.

01:10:00.550 --> 01:10:01.790
Das ist also Visual Studio.

01:10:03.070 --> 01:10:04.990
Das ist das Hauptwerkzeug.

01:10:06.210 --> 01:10:08.330
Was ich es also mal angucken will, das kriegen Sie im Zippool

01:10:08.330 --> 01:10:08.930
kostenlos.

01:10:09.330 --> 01:10:10.790
3 Euro oder was es kostet.

01:10:10.790 --> 01:10:15.110
Das ist also eine komplette Lösung, mit der Sie Web-Services oder

01:10:15.110 --> 01:10:18.650
andere verteilte Anwendungen erstellen und installieren können.

01:10:19.630 --> 01:10:20.110
Betreiben können.

01:10:21.850 --> 01:10:24.070
Es ist allerdings keine Open-Source-Technologie.

01:10:24.270 --> 01:10:24.750
Was ein Wunder.

01:10:27.630 --> 01:10:29.970
Je nachdem, ob man darauf Wert legt oder nicht.

01:10:31.610 --> 01:10:35.910
Allerdings ist es im Gegensatz zu Java standardisiert.

01:10:36.210 --> 01:10:40.930
Die Ablaufumgebung, was sie kann, was die Funktionen der

01:10:40.930 --> 01:10:44.990
Klassenbibliothek sind und der Sprachumfang von C-Sharp ist also

01:10:44.990 --> 01:10:47.970
standardisiert und kann von daher auch nicht mehr verändert werden.

01:10:50.970 --> 01:10:52.010
Dazu Fragen.

01:10:56.970 --> 01:10:59.450
So, dann sind wir auch bald am Ende des Kapitels.

01:11:01.190 --> 01:11:03.750
Noch kurz was zu Content-Management-Systemen.

01:11:05.150 --> 01:11:11.190
Da geht es also darum, dass ich ein Informationssystem habe, das mich

01:11:11.190 --> 01:11:19.470
nicht nur den Kunden informiert, sondern auch mich als Entwickler oder

01:11:19.470 --> 01:11:25.310
als Autor dabei unterstützt, diese Inhalte zu erstellen und zu

01:11:25.310 --> 01:11:25.810
verwalten.

01:11:26.330 --> 01:11:31.110
Also die ganze Organisation der Erstellung von Inhalten, also

01:11:31.110 --> 01:11:37.390
Redaktions, Freigabe, Versionsverwaltung, dann zum Beispiel auch, wer

01:11:37.390 --> 01:11:39.710
was sehen darf, also der Zugriffsschutz.

01:11:40.730 --> 01:11:44.810
Wer darf was zum Beispiel nur sehen, wer darf was ändern, wer darf

01:11:44.810 --> 01:11:49.630
vielleicht nur Funktionen am System selber ändern, nicht aber die

01:11:49.630 --> 01:11:50.450
Inhalte selber.

01:11:51.870 --> 01:11:54.410
Das regeln Content-Management-Systeme.

01:11:55.110 --> 01:11:59.150
Also die Webseite der Uni zum Beispiel, das ist so ein Content

01:11:59.150 --> 01:11:59.850
-Management -System.

01:11:59.990 --> 01:12:01.230
Red Dot heißt das.

01:12:02.170 --> 01:12:05.110
Und auch das IFB, eigene Content-Management-System.

01:12:05.310 --> 01:12:07.410
Zoop fällt also in diese Kategorie.

01:12:13.970 --> 01:12:18.130
Also das ist nochmal die grundsätzliche Architektur von solchen

01:12:18.130 --> 01:12:19.590
Content -Management-Systemen.

01:12:19.730 --> 01:12:21.430
Was also der Sinn ist.

01:12:21.710 --> 01:12:22.730
Oder was die tun.

01:12:23.470 --> 01:12:26.670
Sie haben eine Anbindung an diverse Daten, Datenbanken, an feste

01:12:26.670 --> 01:12:30.310
Dokumenten, vielleicht SQL-Datenbanken oder andere Datenbanken.

01:12:31.970 --> 01:12:36.670
Diese dann über das Intranet ihre eigene Firma oder eigene Abteilung

01:12:36.670 --> 01:12:37.570
zur Verfügung stellen.

01:12:38.830 --> 01:12:42.010
Und da schlägt eben diese Rechteverwaltung durch.

01:12:42.770 --> 01:12:45.830
Die Lagerverwaltung muss vielleicht von den ganzen Daten andere Sachen

01:12:45.830 --> 01:12:47.810
sehen, als der Vertrieb oder der Einkauf.

01:12:49.890 --> 01:12:53.190
Sie muss andere Sachen sehen oder muss auch andere Zugriffsrechte

01:12:54.270 --> 01:12:55.470
dafür haben.

01:12:56.130 --> 01:12:58.750
Das kann Ihnen eben so ein Content-Management-System realisieren.

01:12:59.170 --> 01:13:00.050
So nach außen hin.

01:13:00.050 --> 01:13:02.850
Für Lieferanten und Kunden sieht es natürlich wieder ganz anders aus.

01:13:02.950 --> 01:13:05.170
Der Lieferant muss wieder andere Sachen sehen als der Kunde.

01:13:05.610 --> 01:13:08.150
Der Kunde darf im Allgemeinen gar nichts außer Bestellzettel

01:13:08.150 --> 01:13:08.750
ausfüllen.

01:13:10.530 --> 01:13:15.610
Und dann natürlich auch hier Integration von anderer Software.

01:13:16.250 --> 01:13:17.490
Auch das ist möglich.

01:13:18.070 --> 01:13:21.250
Und natürlich dann hier Portal-Seite.

01:13:21.750 --> 01:13:25.450
Das ist also eine typische Aufgabe von Content-Management-Systemen.

01:13:25.550 --> 01:13:32.010
Dahinter hängen dann meistens größere SAP-Software oder eben auch

01:13:33.030 --> 01:13:38.530
Kommunikation mit anderen Systemen über Enterprise-Java-Beans oder

01:13:38.530 --> 01:13:39.690
Corba oder solche Sachen.

01:13:39.950 --> 01:13:41.890
Oder eben auch Web-Services zum Beispiel.

01:13:43.530 --> 01:13:46.010
Hier haben wir noch zwei Beispiele für Content-Management-Systeme.

01:13:46.110 --> 01:13:46.830
Das eine ist Zoop.

01:13:48.010 --> 01:13:48.990
Zoop ist Open-Source.

01:13:50.390 --> 01:13:53.630
Das ist also nicht nur ein Content-Management-System in dem Sinn, dass

01:13:53.630 --> 01:13:54.690
es Inhalte verwaltet.

01:13:54.690 --> 01:13:57.710
Sondern ein sogenannter Application-Service-Provider.

01:13:57.890 --> 01:14:00.590
Das heißt, sie können in Zoop auch selber Anwendungen programmieren.

01:14:00.870 --> 01:14:04.050
Wie dynamische Webseiten zum Beispiel, Anmeldesachen,

01:14:04.170 --> 01:14:05.070
Datenbankzugriff.

01:14:05.750 --> 01:14:08.250
Die sie also direkt in Zoop programmieren können.

01:14:09.250 --> 01:14:12.610
Das ist ja vor allem in Python macht man das.

01:14:13.070 --> 01:14:14.930
Skriptsprache, die da integriert ist.

01:14:16.630 --> 01:14:18.390
Zoop bringt einen eigenen Web-Server mit.

01:14:19.590 --> 01:14:21.630
Sie haben ein komplettes Web-basiertes Interface.

01:14:21.630 --> 01:14:24.670
Ein integriertes, um eben das System selbst zu managen.

01:14:25.430 --> 01:14:26.870
Benutzerrechte und solche Sachen.

01:14:28.070 --> 01:14:29.390
Sie bringen eine eigene Datenbank mit.

01:14:30.150 --> 01:14:31.090
Eine Objekt-Datenbank.

01:14:31.850 --> 01:14:37.070
Sie können aber bei Zoop auch eine externe Datenbank, wie MySQL oder

01:14:37.070 --> 01:14:37.890
auch Oracle anbinden.

01:14:38.390 --> 01:14:41.890
Also die sie dann über eine relationale Anfragesprache wie SQL

01:14:41.890 --> 01:14:42.550
ansteuern können.

01:14:42.870 --> 01:14:44.010
Das haben sie auch die Möglichkeit.

01:14:44.830 --> 01:14:48.290
Bei uns im Institute ist eine IBM DB2, die über sowas angesteuert

01:14:48.290 --> 01:14:48.470
wird.

01:14:50.890 --> 01:14:52.310
Dann gibt es noch RedDot.

01:14:52.790 --> 01:14:54.490
Zu dem kann ich Ihnen eigentlich relativ wenig sagen.

01:14:54.570 --> 01:14:55.610
Das kenne ich selber gar nicht.

01:14:55.870 --> 01:14:57.790
Außer von der Uni-Webseite.

01:14:58.090 --> 01:15:01.450
Also das Uni-Portal ist mit RedDot gemacht.

01:15:01.950 --> 01:15:05.610
Oder die Rechenzentrum-Seite ist auch damit gemacht.

01:15:06.590 --> 01:15:08.590
Und läuft auch unter diesem System.

01:15:09.690 --> 01:15:11.810
Können Sie sich dann auch mal auf der Webseite informieren, wenn es

01:15:11.810 --> 01:15:12.330
Sie interessiert.

01:15:13.230 --> 01:15:15.390
So Sachen müssen Sie aber für die Klausur zum Beispiel auch nicht

01:15:15.390 --> 01:15:15.550
wissen.

01:15:15.550 --> 01:15:16.930
Da müssen Sie im Wesentlichen wissen,

01:15:20.770 --> 01:15:24.310
was die eigentlichen Kernaufgaben von einem Content-Management-System

01:15:24.310 --> 01:15:25.850
sind.

01:15:26.050 --> 01:15:29.030
Worin sich es unterscheidet zu einer normalen Webseite, die bloß ein

01:15:29.030 --> 01:15:30.850
paar statische Inhalte ausliefert.

01:15:38.100 --> 01:15:39.440
Das war es dann auch schon.

01:15:41.500 --> 01:15:44.020
Nächstes Mal wird Herr Schmeck da sein.

01:15:45.220 --> 01:15:48.020
Und wird Ihnen dann einiges zur Sicherheit.

01:15:48.740 --> 01:15:54.900
Rechnersicherheit, Rechnersabotage, Verschlüsselung und solche Sachen

01:15:54.900 --> 01:15:55.720
wird er Ihnen erzählen.

01:15:56.300 --> 01:15:59.240
Dann danke ich für die Aufmerksamkeit und wünsche Ihnen einen schönen

01:15:59.240 --> 01:15:59.960
Tag. Dankeschön.