Verteilte Systeme_Vorschau 070403

2.5 RMI-Übung
Übung: Schreiben Sie ein RMI-Serverobjekt, das eine Funktion
String hello(String name)
{
return "Hello " + name;
}
anbietet. Es bekommt als Übergabeparameter einen Namen mitgegeben und
liefert einen String der Form "Hello Name", wobei name durch den
übergebenen Namen ersetzt wird.
Tipp:
Verwenden Sie das vorhandene RMI-Beispiel als Vorlage
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
156
→
2.5 Lösung zur RMI-Übung: Remote-Interface
import java.rmi.*;
public interface HelloRemote extends Remote
{
String hello(String name) throws RemoteException;
}
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
157
→
2.5 Lösung zur RMI-Übung: Dienstnutzer (Client)
import java.rmi.*;
public class HelloClient
{
public static void main(String args[])
{
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
try
{
String name = "//" + args[0] + "/Hello";
HelloRemote helloRemote = (HelloRemote) Naming.lookup(name);
String outputString = (helloRemote.hello(args[1]));
System.out.println(outputString);
} catch (Exception e) {
System.err.println("Hello exception: " + e.getMessage());
e.printStackTrace();
}
}
}
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
158
→
2.5 Lösung zur RMI-Übung: Diensterbringer (Serverobjekt)
import java.rmi.*;
import java.rmi.server.*;
public class HalloEngine extends UnicastRemoteObject implements Hallo
{
public HalloEngine() throws RemoteException
{
super();
}
public String hallo(String name)
{
return "Hallo " + name;
}
}
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
159
→
2.5 RMI-Übung: Lösung : Startup-Code für das Serverobjekt
import java.rmi.*;
public class HelloServerStartup
{
public static void main(String[] args)
{
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
String name = "//" + args[0] + "/Hello";
try
{
HelloServer helloServer = new HelloServer();
Naming.rebind(name, helloServer);
System.out.println("HelloServer bound");
} catch (Exception e) {
System.err.println("HalloServer exception: " + e.getMessage());
e.printStackTrace();
}
}
}
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
160
→
2.5 RMI-Beispiel: Übersetzen und Starten
Übersetzen:
• javac HelloServer.java
• rmic HelloServer
• javac HelloServerStartup.java
• javac HelloClient.java
// Server übersetzen
// Stubs und Skeletons aus dem Remote Interface erzeugen
// Startup-Code für das Server-Objekt übersetzen
// Client übersetzen
Starten der RMIRegistry (Naming Service des RMI)
• rmiregistry
// Muss auf dem Rechner mit dem Serverobjekt laufen!
Starten des Servers:
• java -Djava.rmi.server.codebase=file:/c:\Kurse\VerteilteSysteme\Beispiele\RMIHello\
-Djava.security.policy=java.policy HelloServerStartup localhost
Name des
Name des Rechners mit
policy-Files
der RMIRegistry
Starten des Clients:
• java -Djava.security.policy=java.policy HelloClient localhost Thomas
Name des Rechners mit
der RMIRegistry
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
Name
161
→
2. Verteilte Softwaresysteme
2.1
2.2
2.3
2.4
2.5
2.6
2.7
02.04.2007
Grundlagen verteilter Softwaresysteme
Kommunikation über TCP/IP-Sockets
Grundlagen des entfernten Methodenaufrufs
Basisdienste in verteilten Softwaresystemen
Remote Method Invocation (RMI)
CORBA
SOAP / WSDL
Prof. Dr. Thomas Specht: Verteilte Systeme
162
2.6 Übersicht zu den CORBA-Packages (1/2)
org.omg
OMG-Features (insbesondere CORBA)
org.omg.CORBA
CORBA-Schnittstelle im JDK
org.omg.CORBA.ORBPackage
org.omg.CORBA.portable
Klassen für ORB-unabhängige ORB-Zugriffe
org.omg.CORBA.TypeCodePackage
org.omg.CORBA_2_3
Erweiterungen von CORBA 2.3
org.omg.CORBA_2_3.portable
Erweiterungen für ORB-unabh. ORB-Zugriffe
org.omg.COSNaming
Naming Service für CORBA
org.omg.COSNaming.NamingContextExtPackage Erweiterungen des Naming Service
org.omg.COSNaming.NamingContextPackage
Exceptions für Naming Service
org.omg.Dynamic
org.omg.DynamicAny
org.omg.DynamicAny.DynAnyFactoryPackage
org.omg.DynamicAny.DynAnyPackage
org.omg.IOP
org.omg.IOP.CodecFactoryPackage
org.omg.IOP.CodecPackage
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
163
→
2.6 Übersicht zu den CORBA-Packages (2/2)
org.omg.Messaging
org.omg.PortableInterceptor
org.omg.PortableInterceptor.ORBInitInfoPackage
org.omg.PortableServer
Klassen für ORB-unabhängige Server
org.omg.PortableServer.CurrentPackage
org.omg.PortableServer.POAManagerPackage
org.omg.PortableServer.POAPackage
org.omg.PortableServer.portable
org.omg.PortableServer.ServantLocatorPackage
org.omg.SendingContext
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
164
→
2.5 CORBA im Vergleich mit anderen Middlewarestandards
RMI
CORBA
SOAP / WSDL
Objektorientiert
ja
ja
ja
Programmiersprachneutral
ja
ja
Herstellerneutral
ja
ja
ja
Betriebssysteme
alle mit JAVA VM
(alle)
alle
Netzwerkbasisprotokolle
TCP/IP
TCP/IP
HTTP …
Protokoll
RMI
IIOP
SOAP
Interfacedefinitionssprache
JAVA Interface
IDL
WSDL
Statische Schnittstellen
ja
ja
ja
Dynamische Schnittstellen
ja
Synchroner Methodenaufruf
ja
ja
ja
Asynchr. Methodenaufruf
(mit JMS)
(ab CORBA 3)
(ja)
Performance
gut
sehr gut
weniger gut
Name Service
RMI Registry
CORBA NameService
DNS
Einlernaufwand
Kompatibilität der Produkte
Im JDK enthalten
02.04.2007
mittel
hoch
ab JDK 1.1
hoch
mittel
ab JDK 1.2
Prof. Dr. Thomas Specht: Verteilte Systeme
mittel
(mittel)
ab JDK 1.6
165
→
2.6 Object Management Group (OMG)
Object Management Group (OMG)
• Gründung: 1989
• Heute: Über 800 Mitglieder (alle nennenswerten Softwarefirmen außer Microsoft)
• Rolle: Spezifikations- und Standardisierungsgremium für die Softwareindustrie
• herstellerneutral
• plattformneutral
• möglichst programmiersprachneutral
• von der Softwareindustrie mitgetragen und anerkannt
• technisch exzellente Ergebnisse
• KEINE eigenen Produkte und Implementierungen
→Softwarehersteller setzen Spezifikationen der OMG in Produkte um
Wichtige Arbeitsfelder der OMG:
• CORBA (Common Object Request Broker Architecture)
• Objektorientierter verteilter Framework (d.h. Infrastruktur für verteilte Objekte)
• Object Management Architecture (OMA)
• programmiersprach-, plattform- und herstellerneutral
• UML (Unified Modeling Language)
• Objektorientierte Software-Modellierungssprache
• MDA (Model Driven Architecture)
• Modellgetriebene Softwareentwicklung
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
166
→
2.6 OMA (Object Management Architecture)
Application
Objects
Common
Facilities
Business Objects /
Domain Services
Object Request Broker (ORB)
Corba
Object Services
•
•
•
•
ORB (Object Request Broker): Kommunikationsinfrastruktur für verteilte Objekte
Application Objects: Anwendungslogik (d.h. selbst programmierte Objekte)
Common Facilities: Normierte Standardobjekte, z.B. für mobile Agenten
Business Objects (Domain Services): Teillösungen und Frameworks für spezielle Branchen,
z.B. Manufacturing, Transportation, Finance, Healthcare, Telecom, Electronic Commerce
• CORBA Object Services (COS): Gemeinsame Dienste, z.B. Naming Service, Event Service
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
167
→
2.6 CORBA (Common Object Request Broker Architecture)
Dienstnutzer
Anwendungsebene
Objekt a
RemoteInterface
Methodenaufruf
Stub
Middlewareebene
ORB
Hardwareebene
Objekt b
Skeleton
IIOP-Verbindung
Socket
Protokollebene
Diensterbringer
ORB
Socket
TCP/IP
TCP/IP
TCP/IP-Verbindung
Hardware- schnittstelle
Hardware- schnittstelle
Ethernet
Netzwerkkabel /
Funkverbindung
Ethernet
• CORBA (Common Object Request Broker Architecture)
• Remote-Methodenaufruf beliebiger Objekte auf fremden Rechnern
(programmiersprach- und plattformneutral)
• Beschreibung der Remote-Schnittstelle als IDL (Interface Definition Language) Interface
• Name Service: CORBA Name Service
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
168
→
2.5 Statischer Methodenaufruf über CORBA
Dienstnutzer
b = ncRef.resolve(path));
name = b.getName(index)
RemoteInterface
(IDL)
1
2
Objekt a (Dienstnutzer)
Diensterbringer
class B
{
String getName(int index)
{
return names[index] 6
}
}
Objekt b (Diensterbringer)
5
9
Stub
8
02.04.2007
Object Adapter
3
4
ORB (Object Request Broker)
7
Skeleton
4
IIOP
TCP/IP
8
ORB (Object Request Broker)
Prof. Dr. Thomas Specht: Verteilte Systeme
169
→
2.6 Ablauf eines statischen Methodenaufrufs über CORBA
Ablauf eines statischen Methodenaufrufs:
1. Dienstnutzer erfragt Referenz auf Diensterbringer beim CORBA Name Service
2. Dienstnutzer ruft Methode des Diensterbringers auf
3. Stub übergibt den Methodenaufruf dem ORB
4. ORB und Object Adapter leitet Methodenaufruf zum Diensterbringerobjekt weiter
5. Skeleton des Diensterbringers ruft gewünschte Methode auf
6. Diensterbringerobjekt führt gewünschte Methode aus und gibt Ergebnis zurück
7. Ergebnis wird vom Skeleton und Object Adapter an ORB weitergegeben
8. ORB leitet das Ergebnis zum Aufrufer
9. Ergebnis wird dem Aufrufer übergeben
Der Dienstnutzer bekommt also den Eindruck vermittelt, als ob es sich um einen
Methodenaufruf eines lokalen Objektes gehandelt hätte!
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
170
→
2.6 Object Request Broker (ORB)
ORB (Object Request Broker)
• Kommunikations- und Nachrichtentransportinfrastruktur für verteilte Objekte
• Jeder beteiligte Rechner (egal ob Dienstnutzer oder Diensterbringer) benötigt einen ORB
• ORBs unterschiedlicher Rechner und Hersteller kommunizieren untereinander über IIOP
• Arbeitet als Forwarding Broker:
• Leitet entfernten Methodenaufruf vom Dienstnutzer zum Diensterbringer weiter
• Gibt das Ergebnis des Diensterbringers an den Dienstnutzer zurück
• Kernbestandteil jeder CORBA-Implementierung
IIOP (Internet Inter-ORB-Protocol)
• Normiertes Protokoll zwischen ORBs auch unterschiedlicher Hersteller und Plattformen
• Setzt auf TCP/IP auf
→kompatibel mit gängigen Internet-Standards
→über beliebige Netzwerke (z.B. Ethernet, WLAN, DSL …) mit TCP/IP
• Ermöglicht den Mischeinsatz von ORBs unterschiedlicher Hersteller
• Standard-Kommunikationsprotokoll zwischen ORBs verschiedener Rechner und Hersteller
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
171
→
2.6 Object Adapter (OA)
Object Adapter:
• Verbindungsglied zwischen Diensterbringerobjekt bzw. Skeleton mit dem ORB
• Basic Object Adapter (BOA)
• Nicht genau genug spezifiziert
→BOA-Schnittstelle ist hersteller- und ORB-abhängig
→Eingeschränkte Austauschbarkeit des ORBs
• Veraltet, sollte nicht mehr benutzt werden
• Portable Object Adapter (POA)
• CORBA 3-Feature (also nachträgliche Ergänzung des CORBA-Standards)
• Genau spezifiziert
→Herstellerunabhängig
→Austauschbarkeit des ORBs ist gewährleistet
• Aktueller Stand der Technik
• Empfehlungen
• Grundsätzlich nur noch POA benutzen
• CORBA-Produkte, die nur BOA unterstützen, sind veraltet
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
172
→
2.6 Vorgehensweise für statische Methodenaufrufe
1
Remote Interface in IDL erstellen
2 Precompiler (z.B. IdlToJava)
Stubs (auf Clientseite)
3
Codieren des Clients
5
Stubs
7
Compiler
Clientcode
Linker
Client
Dienstnutzer
02.04.2007
Skeletons (auf Serverseite)
4
Codieren des Servers
6 Compiler
Servercode
Skeletons
Linker
8
Server
Diensterbringer
Prof. Dr. Thomas Specht: Verteilte Systeme
173
→
2.6 Vorgehensweise für statische Methodenaufrufe
1. Remote-Interface in IDL erstellen
2. Precompiler erzeugt Stubs für Dienstnutzer und Skeletons für Diensterbringer
3. Manuelles Codieren des Dienstnutzers unter Nutzung der Stubs
4. Manuelles Codieren des Diensterbringers unter Nutzung des Skeletons
5. Konventionelles Compilieren des Dienstnutzers
6. Konventionelles Compilieren des Diensterbringers
7. Linken des Dienstnutzers mit den Stubs (in JAVA nicht nötig)
8. Linken des Diensterbringers mit dem Skeleton (in JAVA nicht nötig)
9. Starten des CORBA Name Service (sofern noch nicht geschehen)
10. Starten des Diensterbringers
11. Starten des Dienstnutzers
02.04.2007
Prof. Dr. Thomas Specht: Verteilte Systeme
174
→