Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung allgemeiner Middlewareansätze.

Ähnliche Präsentationen


Präsentation zum Thema: "WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung allgemeiner Middlewareansätze."—  Präsentation transkript:

1 WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung allgemeiner Middlewareansätze

2 WS06/07Prof. Dr. Andreas Schmietendorf2 RPC – Remote Procedure Call

3 WS06/07Prof. Dr. Andreas Schmietendorf3 Überblick zum RPC Entwickler nutzt selbes Paradigma für die Kommunikation auf unterschiedlichen Rechnern wie beim lokalen Prozeduraufruf Entwickler spezifiziert die Eigenschaften der Prozedurschnittstelle und implementiert die Komponenten der Anwendung Der notwendige Programmcode für die Realisierung der zur Kommunikation notwendigen Prozesse wird automatisch generiert. Wichtigste RPC-Implementierungen: -SUN Microsystems -RPC des DCE (Distributed Computing Enviroment) der OSF

4 WS06/07Prof. Dr. Andreas Schmietendorf4 Ablauf der Entwicklung 1.Spezifikation der über den RPC-Mechanismus aufzurufenden Prozeduren (vgl. C-Header-Dateien) 2.Ausprogrammierung von Client- und Server-Komponenten -Client enthält Aufrufe der zuvor spezifizierten Prozeduren -Server besteht aus Implementierungen der spezifizierten Prozeduren 3.Programmgenerator (z.B. rpcgen) erzeugt aus der Spezifikation: -Client-Stubs -Server-Stubs 4.Client, Server sowie die Stub-Komponenten übersetzen und binden 5.Start des Servers und danach des Clients

5 WS06/07Prof. Dr. Andreas Schmietendorf5 Ablauf der Kommunikation 1 1.Aufruf der spezifizierten Prozeduren durch den Client Aktivieren einer gleichnamigen Prozedur des Client-Stubs Läuft auf dem gleichen Rechner ab wie der der Client selbst 2.Client-Stub konvertiert die Eingabeparameter (Marshalling) Plattformunabhängiges Datenformat Versenden der Daten inkl. weiterer Angaben (Kennung) über das Netz 3.Empfang der Nachricht des Client-Stubs vom Server-Stub Umwandlung der Eingabeparameter in das lokale Format (Unmarshalling) Aufruf der entsprechenden Prozedur auf der Serverseite

6 WS06/07Prof. Dr. Andreas Schmietendorf6 Ablauf der Kommunikation 2 4.Ausführen der entsprechenden Prozedur auf der Server-Seite Rückkehr zum Server-Stub 5.Aufgaben des Server-Stub Umwandlung der Ausgabeparameter und Rückgabewert Rücksenden des Ergebnisses an den Client 6.Client-Stub nimmt die Antwort entgegen Umwandlung der Ausgabeparameter und Rückgabewert in das lokale Datenformat Rückkehr zum Aufrufer auf der Client-Seite

7 WS06/07Prof. Dr. Andreas Schmietendorf7 CORBA

8 WS06/07Prof. Dr. Andreas Schmietendorf8 OMG – Object Management Group 700 Unternehmen weltweit Ziel: Steigerung der Produktivität der SW-Entwicklung Definierte Standards für interoperable und unabhängig voneinander entwickelbare Applikationskomponenten Ergebnis der OMG: OMA/CORBA OMA - Object-Management-Architecture (Referenzarchitektur für verteilte heterogene objektorientierte Systeme) CORBA Standard für die Interaktion von Kompoenten in vernetzten heterogenen Systemen Ausnahme: Microsoft plaziert DCOM als konkurrierenden Objektbus. (Distributet Component Object Model)

9 WS06/07Prof. Dr. Andreas Schmietendorf9 CORBA-Merkmale Kern ist der Object Request Broker (ORB) Möglichkeit der Realisierung mehrstufiger C/S-Architekturen Unabhängigkeit von Implementierungssprache und System Interoperabilität zwischen heterogenen Systemen Verfügbar auf gängigen Betriebssystemen (UNIX, NT, MVS,...) Quasi Standard für ORB-Architekturen (Ausnahme DCOM) Nach Festlegung der Schnittstellendefinition können Aufgaben zu einem Informationssystem verteilt, d.h. strukturiert werden Server-Objekte residieren im Netzwerk, Kommunikation erfolgt über GIOP/IIOP (letzteres im Falle von TCP/IP) Angebot an CORBA-Services und CORBA-Facilities

10 WS06/07Prof. Dr. Andreas Schmietendorf10 Verteilte Informationssysteme Was ist ein ORB: Kern des Object Request Broker (ORB) ist der Objectbus Objekte können transparent mit anderen Objekten interagieren Satz von Middleware- Diensten CORBA 2.0 Inter-ORB- Kommunikation (Güte abhängig von der Implementierung!)

11 WS06/07Prof. Dr. Andreas Schmietendorf11 Verteilte Informationssysteme Vorzüge CORBA [nach Orfali 1998]: Statische und dynamische Methodenaufrufe Verknüpfung auf Hochsprachenebene Selbstbeschreibendes System (Meta-Daten zur Laufzeit) Ortstransparenz (ORB-Implementierungen lokal und verteilt) Eingebaute Sicherheit von Transaktionen Polymorphe Nachrichten (vgl. Polymorphie der Objektorientierung) Koexistenz mit existierenden Systemen RPC vs. CORBA -RPC - Aufruf einer spezifischen Funktion -CORBA - Aufruf einer Methode innerhalb einer konkreten Instanz

12 WS06/07Prof. Dr. Andreas Schmietendorf12 CORBA-Architektur

13 WS06/07Prof. Dr. Andreas Schmietendorf13 Verteilte Informationssysteme Bestandteile des ORB: Dynamic Invocation - Genormte Schnittstelle zur generischen Requesterzeugung Client IDL Stub - Generierter Code aus dem IDL-Compiler ORB-Interface - Abstrahierte Schnittstelle zum ORB Core (IIOP) Static Skeleton - Generierter Code aus dem IDL-Compiler Dynamic Skeleton - Genormte Schnittstelle zum Request-Empfang Object-Adapter - Trennt die Objectimplementation vom ORB, soll Objekte aktivieren und deaktivieren sowie Request dispatchen ORB-Core - Verteilte Komponenten zwischen Client und Server

14 WS06/07Prof. Dr. Andreas Schmietendorf14 Verteilte Informationssysteme Schritte zur CORBA-Entwicklung/Ausführung: Objektorientierte Modellierung (Identifizierung Server-Klassen) Schnittstellenspezifikation der festgestellten Klassen in IDL File *.idl mittels IDL-Compiler für Zielsprache Übersetzen -z.B. Java-Client d.h. IDL-Compiler für Java notwendig -z.B. C++ Server d.h. IDL-Compiler für C++ notwendig Stub- (Client) und Skelleton- (Server) Klassen werden generiert Implementierung eines CORBA- und des fachlichen -Servers Implementierung der Client-Anwendung Installation von Client und Server-Anwendungen Start des ORB, des Servers und der Client-Anwendung

15 WS06/07Prof. Dr. Andreas Schmietendorf15 Verteilte Informationssysteme IDL-Compiler:

16 WS06/07Prof. Dr. Andreas Schmietendorf16 Verteilte Informationssysteme Sprachanbindung CORBA-IDL (Teilmenge von C++): Spezifikation der potentiellen Schnittstelle als erster Schritt einer CORBA- Entwicklung, Vertrag zwischen Client- und Server-Implementierung CORBA-IDL ist rein deklarativ und enthält keine Implementierungsdetails CORBA-IDL definiert unterschiedliche Objekttypen, indem notwendige Methoden, deren Parameter (inkl. Transportrichtung) beschrieben werden IDL spezifizierte Methoden sind in vielen Sprachen verfügbar (Bsp.: C, C++, Cobol, Java, Smalltalk, Ada IDL stellt betriebssystem- und sprachunabhängige Schnittstellen für alle Dienste/Schnittstellen die auf den CORBA-Bus verfügbar sind zur Verfügung Verteilte Dienste (z.B. Ermittlung der aktiven Objekte im Netzwerk und welche Methoden verfügbar)

17 WS06/07Prof. Dr. Andreas Schmietendorf17 Verteilte Informationssysteme CORBA-IDL im Detail: Einfache Datentypen: long, short, unsigned long, unsigned short, float, double, char, boolean, octet und any (für jeden Wert), Komplexe Datentypen: struct, union, enum, array, string und sequence Ausnahmen/Unterschiede zu C/C++: octet: unsigned char (in C,C++), boolean: unsigned char, long double: twice a double, any: "typedef struct any { TypeCode _type; void *_value; } any;" in C und "class Any {...; };" in C++.

18 WS06/07Prof. Dr. Andreas Schmietendorf18 Verteilte Informationssysteme Operationen der IDL-Datei: Syntax (param1,...); Definition des Returnwertes der Methoden, auch void ist möglich Name der Methode param1: in, out, inout -in - Parameter vom Client zum Server -out - Parameter vom Server zum Client -inout - Parameter vom Client zum Server und zurück -param_type - Typ des Parameters -identifier - Parmetername string ma_anzeigen(in string pers_ID);

19 WS06/07Prof. Dr. Andreas Schmietendorf19 Verteilte Informationssysteme Attribute der IDL-Datei: Syntax [readonly] attribte Attribute werden mit Datentyp und Attributename definiert. Der IDL- Compiler erzeugt daraus entsprechenden set/get-Methoden. Wird das Schlüsselwort readonly angegeben werden nur get-Methoden erzeugt. Bei Attributen können keine Fehler über Exceptions abgefangen werden. Nach Möglichkeit sollte auf die Definition von Attribten verzichtet werden, da so zu viele Instanzen erzeugt werden und die Performance davon verschlechtert wird.

20 WS06/07Prof. Dr. Andreas Schmietendorf20 Verteilte Informationssysteme Beispiel einer einfachen IDL-Datei: module objectbench{ interface customer { // Attribute attribute string name; attribute long key; // Operationen //keine Methode definiert }; interface customer_easy : customer {... }; interface customer_complex : customer_easy {... }; interface warehouse { // Attribute attribute string warehouse_name; // Operationen // Methode für die Erzeugung einfacher Customer-Objekte customer_easy new_customer_easy(in string name,in long key,in boolean hash); };

21 WS06/07Prof. Dr. Andreas Schmietendorf21 Verteilte Informationssysteme Initialisierungsdienst von CORBA:

22 WS06/07Prof. Dr. Andreas Schmietendorf22 Verteilte Informationssysteme Objekt-Referenz (IOR - Interoperable Object References): Information um Objekte durch den ORB zu lokalisieren. Bestandteile einer Objekt-Referenz -Repository-ID -Hostname (IP-Adresse oder DNS-Name) -Portnummer -Objekt-key -ab Version 2.2 wird der Objekt-key durch POAID und ObjectID Ein CORBA-Client verwendet nur die ersten 3 Bestandteile, so daß die Änderungen ab Version 2.2 keine direkte Auswirkung haben. Praktische Realisierung: OSAgent beim Visibroker (Problem der Anwendung in großen Installationen/Netzwerken)

23 WS06/07Prof. Dr. Andreas Schmietendorf23 Verteilte Informationssysteme Request: Ein Request enthält die folgenden Informationen -Zielobjekt (Objekt-Referenz) -Operations-Name -Parameter -Optional - Requestkontext Parameter werden auf Strukturen gemappt, welche wiederum in CORBA- IDL definiert, das GIOP beschreiben. Das abstrakte GIOP kann über jedes verbindungsorientierte Transportprotokoll transportiert werden, wie z.B. im Falle von TCP/IP das IIOP Die Reply enthält die OUT-Parameter bzw. Exceptions

24 WS06/07Prof. Dr. Andreas Schmietendorf24 Verteilte Informationssysteme Synchronisations-Mechanismen (CORBA 2.x): Synchronous, nach einem Methoden-Aufruf ist der Client solange blockiert bis ein Ergebnis bzw. eine Exception zurückgegeben wird. (Standard-Einstellung) Defferred Synchronous, sofern das Dynamic Invocation Interface genutzt wird kann auch ein verzögertes synchrones Verhalten erzeugt werden. (es besteht keine Möglichkeit der Transaktionssicherung) Asynchronous, nach Aufruf der entfernten Methode wird die Verarbeitung beim Client sofort fortgesetzt. Dafür muß die Operation mit dem Schlüsselwort oneway ausgestattet werden.

25 WS06/07Prof. Dr. Andreas Schmietendorf25 Verteilte Informationssysteme Aufgabenstellung: Auf einem Server sollen zentral Daten gespeichert werden, speziell eine Personal-ID sowie ein dazugehörender Name. Entwicklung einer CORBA-IDL welche entsprechende Methoden für die Kommunikation zwischen Client und Server spezifiziert. Der CORBA-Server sowie die fachliche Server-Anwendung sollen ebenfalls in Java implementiert werden Über einen Java-Applet-Client sollen die Daten eingegeben und abgespeichert werden, bzw. nach Eingabe einer Personal-ID der entsprechende Name ausgegeben werden. Es sind Problembereiche einer CORBA-Kommunikation bei Java-Web- Anwendungen aufzeigen.

26 WS06/07Prof. Dr. Andreas Schmietendorf26 Verteilte Informationssysteme Beispiel einer einfachen CORBA-IDL: module swt { // (C) 1998 Andreas Schmietendorf interface Mitarbeiter { // Attributes attribute string name; attribute string pers_ID; // Operations void ma_erfassen(in string name, in string pers_ID); string ma_anzeigen(in string pers_ID); };

27 WS06/07Prof. Dr. Andreas Schmietendorf27 Verteilte Informationssysteme Ergebnisse der IDL-Compilierung (Visibroker): Aufruf des IDL-Compilers: idl2java *.idl Generierte Klassen für die Server-Seite: swt._MitarbeiterImplBase.class (Verbund Java und Corba-Objektmodell) swt._example_Mitarbeiter.class (Code-Rahmen fachl. Server-Funktionen) swt.Mitarbeiter.class (Abbildung auf Java-Interface) swt._sk_Mitarbeiter.class (Skeleton/Proxy für Mitarbeiter-Objekt) Generierte Klassen Client-Seite: swt.MitarbeiterHelper.class (Hilfsfunktionen zur Auflösung von Objektref.) swt.MitarbeiterHolder.class (Übergabe/-nahme von in/out-Parametern) swt._st_Mitarbeiter.class (Stub/Proxy für das Mitarbeiter-Objekt) swt._tie_Mitarbeiter.class (Delegation von Operationsaufrufen)

28 WS06/07Prof. Dr. Andreas Schmietendorf28 Verteilte Informationssysteme Schritte zur Implementierung Entwicklung eines CORBA-Servers (MitarbeiterServer.class) -Initialisierung des ORB und BOA (Basic Object Adapter) -Erzeugen eines Mitarbeiter-Objekt und Export zum ORB Umbenennen_example_Mitarbeiter.class nach MitarbeiterImpl -Fachliche Funktion über Ein-/Ausgaben auf Hashtabelle, eventl. Nutzung von Standard SET/GET-Funktionen für Attribute Implementierung eines Applet MitApplet.class, abgeleitet von Applet -Grafisches Layout realisieren (Eingabefelder, Buttons, Informationen...) -Eingaben verarbeiten (Plausibilitäts-Prüfungen) -Ereignisse der Eingabe-Felder bzw. Buttons verarbeiten -Verwendung von remote Methoden via CORBA

29 WS06/07Prof. Dr. Andreas Schmietendorf29 Verteilte Informationssysteme Implementierung des CORBA-Servers package swt; // MitarbeiterServer.java: Mitarbeiter-Server Hauptprogramm class MitarbeiterServer { static public void main(String[] args) { try { // Initialize the ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null); // Initialize the BOA org.omg.CORBA.BOA boa = orb.BOA_init(); // Create the Mitarbeiter object MitarbeiterImpl mitarbeiter = new MitarbeiterImpl("My Mitarbeiter"); // Export to the ORB the newly created object boa.obj_is_ready(mitarbeiter); // Ready to service requests boa.impl_is_ready(); } catch(org.omg.CORBA.SystemException e) { System.err.println(e); }}}

30 WS06/07Prof. Dr. Andreas Schmietendorf30 Verteilte Informationssysteme Implementierung der fachlichen Server-Funktionen public class MitarbeiterImpl extends swt._MitarbeiterImplBase { /** Variablen bzw. Object-Vereinbarungen */ private Hashtable mittab = new Hashtable();... public MitarbeiterImpl(java.lang.String name) { super(name);} /** Construct a transient object. */... /** Erfassen von Name und Personal-ID in einer Hashtabelle */ public void ma_erfassen(java.lang.String name, pers_ID) {mittab.put(pers_ID,name);} /** Auslesen des Namen zu einer Personal-ID aus der Hashtabelle */ public java.lang.String ma_anzeigen(java.lang.String pers_ID) {name= (String) mittab.get(pers_ID);return name;}

31 WS06/07Prof. Dr. Andreas Schmietendorf31 Verteilte Informationssysteme Implementierung der Applet-Anwendung 1 import java.awt.*;... public class MitApplet extends Applet { TextField textField2 = new TextField(); Button button1 = new Button();... //Das Applet initialisieren public void init(){ System.out.println("Initializing the ORB"); org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(this, null); // Binden des Mitarbeiter Object System.out.println("Binding to Mitarbeiter Object"); mitarb = swt.MitarbeiterHelper.bind(orb, "My Mitarbeiter"); try { jbInit(); } catch (Exception e) { e.printStackTrace(); } }...

32 WS06/07Prof. Dr. Andreas Schmietendorf32 Verteilte Informationssysteme Implementierung der Applet-Anwendung 2... //Initialisierung der Komponente public void jbInit() throws Exception{ button1.setLabel("Mitarbeiter einfügen"); label1.setText("Personal ID"); button1.addActionListener(new MitApplet_button1_actionAdapter(this)); //Event des Mitarbeiter-Einfügen-Button auswerten void button1_actionPerformed(ActionEvent e){ String na = textField2.getText(); String id = textField1.getText(); mitarb.ma_erfassen(na,id);} //Event des Mitarbeiter-Einfügen-Button auswerten void button2_actionPerformed(ActionEvent e){ String id = textField1.getText(); String na = mitarb.ma_anzeigen(id); textField2.setText(na);}...

33 WS06/07Prof. Dr. Andreas Schmietendorf33 Verteilte Informationssysteme Implementierung der HTML-Webseite HTML-Testseite MitApplet erscheint in einem Java-fähigen Browser.

34 WS06/07Prof. Dr. Andreas Schmietendorf34 Verteilte Informationssysteme Test/Ausführung der kompletten Anwendung: Sämliche Java-Quellcodedateien (*.java) müssen in Java-Bytecode (*.class) übersetzt werden. -Laufender TCP/IP Protokollstack Grundlage für IIOP -Konfiguration des Gatekeeper falls der Test über das Netz erfolgt, andernfalls genügen die Standard-Einstellungen -Start eines ORB-Agent (Visibroker Smart Agent) auf einer oder mehrerer Maschinen im Netz (Redundanz) -Start des Gatekeepers als Firewall (wenn Java-Applet) -Start der Server-Anwendung (MitarbeiterServer.class) -Start des Applet MitApplet.class im Browser bzw. Applet-Viewer im Rahmen einer HTML-Datei

35 WS06/07Prof. Dr. Andreas Schmietendorf35 Verteilte Informationssysteme Funktionalität des Gatekeeper (Visibroker): Java Sandbox-Security, Java-Applets dürfen nur mit dem Server kommunizieren, von welchem sie geladen wurde.. -Beeinträchtigt die Skalierbarkeit der Anwendung -Ermöglicht keine dynamische Lastverteilung Lösung beim Visibroker durch den Einsatz des Gatekeepers -Proxy-Objekt für die Entgegennahme von Client-Anforderungen die nicht lokal bedient werden können -Beim Start des Gatekeepers wird eine gatekeeper.ior Datei geschrieben, diese muß zwingend im gleichen Verzeichnis stehen wie die HTML-Datei mit dem entsprechenden Applet-Tag -Abspeicherung der Einstellungen unter gatekeeper.properties

36 WS06/07Prof. Dr. Andreas Schmietendorf36 Verteilte Informationssysteme Konfigurations-Dialog des Gatekeeper: Einstellungen: IP-Adressen (IN/OUT) Port-Adressen (IN/OUT) HTTP-Unterstützung Callback-Service Location-Services Socket-Security-Layer Verzeichnis für *.ior Logging-Level...

37 WS06/07Prof. Dr. Andreas Schmietendorf37 Verteilte Informationssysteme Aussehen der Applikationen (Client und Server):

38 WS06/07Prof. Dr. Andreas Schmietendorf38 Verteilte Informationssysteme Problembereiche 1: Konfiguration der Laufzeitumgebung, wobei insbesondere die Angabe- von Path bzw. Classpath-Anweisungen zu beachten sind Test von verteilten Applikationen, zum Test der Server-Komponente wird immer eine Client-Komponente benötigt die alle angebotenen Interfaces abtesten kann Verwendung der jeweils richtigen JDK/VM-Version, nur wenige Browser verfügen überhaupt über CORBA-Komponenten Beachtung der Ladezeiten für die CORBA-Umgebung zum Client beim ersten Aufruf. Inter-ORB-Kommunikation (Namen-Konventionen teilweise unterschiedlich)

39 WS06/07Prof. Dr. Andreas Schmietendorf39 Verteilte Informationssysteme Problembereiche 2: Fehler im Design der IDL können in der Implementierung nicht mehr beseitigt werden Keine Möglichkeiten der QoS-Vereinbarungen im Rahmen der IDL- Definitionen Ungenügende Toolunterstützung für die Modellierung einer CORBA- Anwendung. (Rational Rose kann IDL generieren, diese ist aber nicht direkt verwendbar durch einen IDL-Compiler) Tranparenz der generierten Dateien geht verloren, daraus ergeben sich Probleme bei der Fehlersuche bzw. Debugging Derzeit sind keine Design-Richtlinien für CORBA-Schnittstellen vorhanden, welche z.B. Performance-Aspekte berücksichtigen

40 WS06/07Prof. Dr. Andreas Schmietendorf40 Verteilte Informationssysteme Ausblick CORBA Version 3.0: Message Oriented Middleware (MOM) >> Zielstellung u.a. QoS -Erweiterung der derzeitigen Synchronisationsmechanismen -Erlaubt Clients nicht-blockierende Anfragen (Prozeß bzw. Thread) -Erlaubt Clients- und Servern zu unterschiedlichen Zeiten zu laufen -Unterstützung von Normaden-Clients über zeitunabhängige Warteschlagen Warteschlangen zur Message-Aufnahme können persistent oder transient sein Server Portablity -Zielstellung portabler Server-Implementierungen -Ablösung des BOA durch den POA (Portable Object Adapter)

41 WS06/07Prof. Dr. Andreas Schmietendorf41 Verteilte Informationssysteme Ausblick CORBA Version 3.0: Business Objects Framework (BOF) Java Bindings Pass-by-Value Mobile Agents CORBA/DCOM Interoperability Erweiterungen haben nur eine geringe industrielle Durchdringung erreicht

42 WS06/07Prof. Dr. Andreas Schmietendorf42 RMI

43 WS06/07Prof. Dr. Andreas Schmietendorf43 Ziele von Java RMI Kommunikation mit entfernten Java-Objekten soll so erscheinen als ob diese lokal vorhanden wären (zusätzliche Exceptions) Nahtloses Einbinden von Objekten aus verschiedenen Java- Umgebungen Verteiltes Objektmodell (Java Distributet Object Model DOM) Einfaches Entwerfen verteilter Applikationen Übernehmen der Sicherheitsmechanismen durch das DOM sowie Berücksichtigung der garbage Collection aller Objekte Rückruf vom Server zum Applet ermöglichen

44 WS06/07Prof. Dr. Andreas Schmietendorf44 RMI Architektur

45 WS06/07Prof. Dr. Andreas Schmietendorf45 Stärken/Schwächen von RMI :Hoher Abstraktionsgrad, Transparenz für den Entwickler :RMI ist nahtlos in Java integriert :RMI relativ einfach zu verwenden (keine Zusatzprodukte) :Dynamisches Laden von Stub/Skeletons möglich (dyn. Referenzen) :Weniger Overhead gegenüber CORBA (ggf. leicht performanter) Client und Server müssen in Java implementiert werden Keine automatische Aktivierung von Servern möglich Keine Kommunikationssicherheit


Herunterladen ppt "WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung allgemeiner Middlewareansätze."

Ähnliche Präsentationen


Google-Anzeigen