Distributed Programming in .NET

Inhaltsverzeichnis 1) Einführung 2) .NET Remoting 3) Web-Services 4) Vergleich .NET Remoting und

Web-Services 5) Fazit

Einführung (1) Distributed Programming: mehrere verschiedene physische

Komponenten arbeiten zusammen als ein einziges System. Verteilte Applikation verstreut die Arbeit auf mehrere

Prozessoren. Für die Verteilung der Arbeit muss sie speziell entwickelt sein.

Neben der schwierigen Koordination der Zusammenarbeit, muss die Applikation auch in Aufgaben (tasks) zerlegt werden, die überhaupt verteilt werden können. 

von COM zu .NET (1) COM ermöglicht Zusammenarbeit zwischen unabhängigen

Komponenten und kann in irgend einer Programmiersprache geschrieben werden.

DCOM bietet die notwendige Infrastruktur an, um COM-Komponenten über ein Netzwerk zu verwenden.

Mit dem Aufkommen der Web-Technologie kam ActiveX, welche auf COM basiert, auf den Markt.

Die COM-Technologie kam unter Beschuss, da unter anderem die Versionierung und Registrierung der Komponenten sehr kompliziert ist.

Nach 9 Jahren Herrschaft war klar, dass COM ersetzt werden muss, und .NET wurde geboren.

von COM zu .NET (2) Vergleicht man COM und .NET kann eher von einer Evolution,

denn einer Revolution gesprochen werden: beide verfolgen die gleichen Ziele, wobei .NET einfach besser ist: Sprachenunabhängigkeit, Komponenteninteroperabilität, Location Transparency, robuste Versionierung.

So werden zum Beispiel .NET Komponenten nicht im Systemregister registriert die Lebensdauer eines Objektes wird durch Garbage Collection

bestimmt, anstatt durch Zählen der Referenzen.

.NET Remoting – Konzept (1) .NET Remoting ermöglicht die Kommunikation zwischen

Objekten aus verschiedenen Applikationsgebieten oder Prozessen und dies unabhängig von Transportprotokollen, Serialisierungsformaten, Lebensdauer und Erstellungsart der Objekte.

Fürs Remoting werden benötigt: eine Implementation eines Remotable Type (Server-Objekt), eine Host-Applikation, ein Klient, ein Transportmechanismus.

.NET Remoting – Konzept (2) By Value By Reference

.NET Remoting – Konzept (3) Auf entfernte Objekte wird über Kanäle (channels) zugegriffen.

Kanäle transportieren die Nachrichten physikalisch von und zu entfernten Objekten. Es existieren zwei verschiedene Kanäle: TcpChannel und HttpChannel.

Eine Möglichkeit .NET Remoting Komponenten zu veröffentlichen, ist über den Internet Information Server (IIS).

Server-aktivierte Objekte können vom Typ Singleton oder SingleCall sein.

.NET Remoting – Konzept (4) Das Benutzen von Objekt-Referenzen ist das Herzstück von

Remoting. Die Remoting Architektur ist sehr einfach. Bei der Konfiguration

des Klienten reicht es ein neues Objekt des gewünschten Typen zu kreieren (z.B. mit new).

.NET Remoting – Das Beispiel

Remoting System

Adder

Remoting System

Client

Proxy

Channel

Web-Services - Konzept Web-Services vereinigen diverse Technologien für

den Zugriff auf Dienste verschiedener Anbieter in verteilten Systemen.

Charakteristiken Können z.B. auch unter Java verwendet werden. Heterogene, verteilte Dienste. Transport von Daten per HTTP, SMTP, Webserver. Beschreibung der transportierten Daten in XML. Unabhängig von Betriebssystem, Programmiersprache,

binärem Übertragungsprotokoll. Die konkrete Implementation ist zustandslos und befindet sich

häufig in einem Web-Service-Container (z.B. IIS). Der Container leitet Aufrufe weiter, aktiviert und deaktiviert die Objekte.

Haben keine Kenntnisse über aufrufenden Klienten. Die Web Services Description Language (WSDL) beschreibt,

was der Web Service anbietet. Unterstützt drei Protokolle: HTTP GET, HTTP POST, SOAP

Ein einfacher Web-Service (1) Da Web-Services zu oberst auf HTTP laufen, muss es auf der

Maschine, wo die Dienste laufen irgend eine Art von Web Server haben, der das HTTP Protokoll unterstützt. Im vorliegenden Fall wird der Internet Information Services (IIS) benutzt, der eine built-in Komponente von Windows2000 ist. Er kann über die Systemsteuerung mit add/remove programs, windows components installiert werden.

Ein einfacher Web-Service (2) Web-Services werden in 3 Schritten erstellt:

Eine neue *.asmx-Datei für den Web Service erstellen. Sie muss die <%webservice … %>-Direktive und die Klasse, die die Implementation bereitstellt enthalten. Die asmx-Datei ist für die Klienten der Eingangspunkt zum Web-Service.

Die Klasse WebService vom System.Web.Services-Namensraum muss erweitert werden. Ermöglicht den Zugriff auf ASP Objekte. Eigener Namensraum definieren.

Alle Methoden, die übers Web veröffentlicht werden sollen, müssen mit dem WebMethod-Attribut versehen werden. Dieses Attribut wird für die Generierung der WSDL verwendet.

Implementation

IIS

Web-Service http://hpnotexy/Example.asmx

wsdl.exe

csc.exe

ExampleProxy.dll

ExampleProxy.cs

Klient

NetClient.exe

/r:ExampleProxy.dll

SOAP SOAP ist ein XML-basiertes Protokoll, mit dem Daten verpackt

und über ein Transportprotokoll (wie HTTP) verschickt werden können. Es ist ein asynchrones einweg Protokoll.

Nachrichtenformate geben an, wie die Daten serialisiert und codiert werden.

Zwei Nachrichtenformate Document: die Daten und Methodenaufrufe werden als XML-

Dokument verschickt. SOAP legt keine Regeln fest, wie der Inhalt aussehen soll. Wird vor allem für grosse Datenmengen eingesetzt.

Rpc: die Struktur der <Body>-Unterelemente wird nach SOAP-Regeln festgelegt.

Für die Serialisierung der Daten können grundsätzlich beliebige Codierungsarten verwendet werden.

Lebenszyklus des Web-Service Web-Service-Objekte sind zustandslos. Sie werden bei einem

Aufruf erzeugt und danach wieder zerstört. Will man die Daten über mehrere Methodenaufrufe hinweg

beibehalten, so müssen sie im Zustand der aktuellen Sitzung oder Applikation gespeichert werden, indem man auf die Properties Session oder Application zugreift.

WSDL Die Beschreibung eines Web-Services muss selten

per Hand erstellt werden, da viele Web-Service-Container diese automatisch generieren.

Für die Integration verschiedener Web-Services ist es aber nützlich die Struktur der WSDL zu kennen.

Die WSDL beschreibt: welche Services welche Methoden anbieten, über welche Ports, Protokolle und Nachrichten die

Methoden aufgerufen werden können, welche Namen und welche Parameter eine Nachricht hat, wie die verwendeten Datentypen einer Nachricht aussehen.

Web Service Discovery Web-Service können privat oder öffentlich sein. Es macht Sinn,

dass einzelne Web-Services nicht für die Öffentlichkeit bestimmt ist. Um die Web-Services bekannt zu machen, stellen die Autoren Discovery Dateien ins Internet. Potentielle Klienten können so herausfinden, wo sich gewünschte Dienste befinden, und wie sie benutzt werden (WSDL).

Die Dienste können auf zwei Arten bekannt gemacht werden: statisch oder dynamisch. In beiden Fällen übermittelt XML den Standort der Dienste.

.NET Remoting vs. Web-Services .NET Remoting ist schneller als Web-Services. Auf ASP.NET basierten Web-Services kann nur über HTTP zugegriffen

werden. Für .NET Remoting kann irgend ein Protokoll verwendet werden.

Web-Services arbeiten in einer zustandslosen Umgebung, wobei jede Anfrage in der Kreation eines neuen Objektes resultiert, das die Anfrage bedient. .NET Remoting unterstützt Zustandsmanagement, Callbacks und kann mehrere Aufrufe desselben Klienten korrelieren.

Web Services kann nur Objekte behandeln, die vollständig in XML ausgedrückt werden können. Bei .NET Remoting können Objekte by value oder by reference übergeben werden können.

Web-Services unterstützen die Interoperabilität über verschiedene Plattformen und sind gut für heterogene Umgebungen. .NET Remoting erfordern, dass die Klienten durch Benützen von .NET erstellt werden, oder einem anderen Framework, welches .NET Remoting unterstützt, das heisst homogene Umgebungen.

Fazit Die beiden Technologien Web-Services und Remoting, die von

der .NET-Infrastruktur für die verteilte Programmierung vorgesehen sind, können im Vergleich mit COM als Revolution bezeichnet werden. Verteilte Komponenten sind nun viel einfacher zu erstellen, und es gibt auch viel mehr Möglichkeiten.

Welche der beiden Technologien vor allem eingesetzt werden soll, ist schwer zu sagen. Beide haben ihre Vor- und Nachteile. Schlussendlich muss der Entwickler abwägen, ob ihm die Web-Services oder die .NET Remoting Komponenten den grösseren Nutzen bringen.

Distributed Programming in .NET Fragen? Bemerkungen?