Universeller SMTP-Server - Warum Webdienste?

Übersicht
Die komponentenbasierte Programmierung ist heute beliebter denn je. Kaum eine Anwendung wird heute noch erstellt, die nicht in irgendeiner Form Komponenten verwendet, in der Regel von verschiedenen Anbietern. Mit der zunehmenden Komplexität der Anwendungen ist auch der Bedarf an der Nutzung von Komponenten, die auf entfernten Rechnern verteilt sind, gestiegen.

Ein Beispiel für eine komponentenbasierte Anwendung ist eine End-to-End-E-Commerce-Lösung. Eine E-Commerce-Anwendung, die sich auf einer Webfarm befindet, muss Bestellungen an eine Back-End-Anwendung für die Ressourcenplanung (ERP) übermitteln. In vielen Fällen befindet sich die ERP-Anwendung auf einer anderen Hardware und läuft möglicherweise unter einem anderen Betriebssystem.

Das Microsoft Distributed Component Object Model (DCOM), eine Infrastruktur für verteilte Objekte, die es einer Anwendung ermöglicht, auf einem anderen Server installierte Komponenten des Component Object Model (COM) aufzurufen, wurde auf eine Reihe von Nicht-Windows-Plattformen portiert. Allerdings hat sich DCOM auf diesen Plattformen nie durchgesetzt, so dass es nur selten zur Erleichterung der Kommunikation zwischen Windows- und Nicht-Windows-Computern eingesetzt wird. Anbieter von ERP-Software entwickeln häufig Komponenten für die Windows-Plattform, die über ein proprietäres Protokoll mit dem Back-End-System kommunizieren.

Einige Dienste, die von einer E-Commerce-Anwendung genutzt werden, befinden sich möglicherweise gar nicht im Rechenzentrum. Wenn die E-Commerce-Anwendung beispielsweise Kreditkartenzahlungen für vom Kunden gekaufte Waren akzeptiert, muss sie die Dienste der Händlerbank in Anspruch nehmen, um die Kreditkarteninformationen des Kunden zu verarbeiten. In der Praxis sind DCOM und verwandte Technologien wie CORBA und Java RMI jedoch auf Anwendungen und Komponenten beschränkt, die im Rechenzentrum des Unternehmens installiert sind. Zwei Hauptgründe dafür sind, dass diese Technologien standardmäßig proprietäre Protokolle nutzen und diese Protokolle von Natur aus verbindungsorientiert sind.

Für Clients, die über das Internet mit dem Server kommunizieren, gibt es zahlreiche potenzielle Hindernisse für die Kommunikation mit dem Server. Sicherheitsbewusste Netzwerkadministratoren auf der ganzen Welt haben unternehmenseigene Router und Firewalls eingerichtet, um praktisch jede Art von Kommunikation über das Internet zu unterbinden. Es bedarf oft einer höheren Gewalt, um einen Netzwerkadministrator dazu zu bringen, Ports über das absolute Minimum hinaus zu öffnen.

Wenn Sie das Glück haben, dass ein Netzwerkadministrator die entsprechenden Ports zur Unterstützung Ihres Dienstes freigibt, haben Ihre Kunden wahrscheinlich nicht so viel Glück. Daher sind proprietäre Protokolle, wie sie von DCOM, CORBA und Java RMI verwendet werden, für Internet-Szenarien nicht geeignet.

Das andere Problem bei diesen Technologien ist, wie gesagt, dass sie von Natur aus verbindungsorientiert sind und daher nicht in der Lage sind, Netzunterbrechungen zu bewältigen. Da das Internet nicht unter Ihrer direkten Kontrolle steht, können Sie keine Annahmen über die Qualität oder Zuverlässigkeit der Verbindung machen. Kommt es zu einer Netzunterbrechung, kann der nächste Anruf des Clients an den Server fehlschlagen.

Die verbindungsorientierte Natur dieser Technologien macht es auch schwierig, die für eine hohe Skalierbarkeit erforderlichen lastverteilten Infrastrukturen aufzubauen. Sobald die Verbindung zwischen dem Client und dem Server unterbrochen wird, können Sie die nächste Anfrage nicht einfach an einen anderen Server weiterleiten.

Die Entwickler haben versucht, diese Einschränkungen zu überwinden, indem sie ein Modell namens zustandslos Programmierung, Sie hatten jedoch nur begrenzten Erfolg, weil die Technologien ziemlich schwer sind und es teuer ist, eine Verbindung mit einem entfernten Objekt wiederherzustellen.

Da die Verarbeitung der Kreditkarte eines Kunden von einem entfernten Server im Internet durchgeführt wird, ist DCOM nicht ideal für die Kommunikation zwischen dem E-Commerce-Client und dem Kreditkartenverarbeitungsserver. Wie bei einer ERP-Lösung wird häufig eine Komponente eines Drittanbieters im Rechenzentrum des Kunden installiert (in diesem Fall vom Anbieter der Kreditkartenabwicklungslösung). Diese Komponente dient lediglich als Proxy, der die Kommunikation zwischen der E-Commerce-Software und der Händlerbank über ein proprietäres Protokoll ermöglicht.

Erkennen Sie hier ein Muster? Da die bestehenden Technologien bei der Erleichterung der Kommunikation zwischen Computersystemen an ihre Grenzen stoßen, haben die Software-Anbieter häufig auf den Aufbau einer eigenen Infrastruktur zurückgegriffen. Das bedeutet, dass Ressourcen, die für die Verbesserung der Funktionalität des ERP-Systems oder des Kreditkartenverarbeitungssystems hätten verwendet werden können, stattdessen für die Entwicklung proprietärer Netzwerkprotokolle eingesetzt wurden.

In dem Bestreben, solche Internet-Szenarien besser zu unterstützen, verfolgte Microsoft zunächst die Strategie, seine bestehenden Technologien zu erweitern, einschließlich COM Internet Services (CIS), mit denen Sie eine DCOM-Verbindung zwischen dem Client und der entfernten Komponente über Port 80 herstellen können. Aus verschiedenen Gründen wurde CIS nicht allgemein akzeptiert.

Es wurde deutlich, dass ein neuer Ansatz erforderlich war. Also beschloss Microsoft, das Problem von Grund auf anzugehen. Schauen wir uns einige der Anforderungen an, die die Lösung erfüllen musste, um erfolgreich zu sein.

• Interoperabilität Der Ferndienst muss von Clients auf anderen Plattformen genutzt werden können.
• Internetfreundlichkeit Die Lösung sollte sich für die Unterstützung von Clients eignen, die über das Internet auf den Ferndienst zugreifen.
• Stark typisierte Schnittstellen Es sollte keine Unklarheit über den Typ der an einen Ferndienst gesendeten und von ihm empfangenen Daten bestehen. Darüber hinaus sollten die vom Ferndienst definierten Datentypen den von den meisten prozeduralen Programmiersprachen definierten Datentypen einigermaßen gut entsprechen.
• Fähigkeit, bestehende Internet-Standards zu nutzen Die Implementierung des Ferndienstes sollte so weit wie möglich bestehende Internet-Standards nutzen und vermeiden, Lösungen für bereits gelöste Probleme neu zu erfinden. Eine Lösung, die auf weit verbreiteten Internet-Standards aufbaut, kann die vorhandenen Tools und Produkte, die für diese Technologie entwickelt wurden, nutzen.
• Unterstützung für jede Sprache Die Lösung sollte nicht eng an eine bestimmte Programmiersprache gekoppelt sein. Java RMI zum Beispiel ist eng an die Java-Sprache gekoppelt. Es wäre schwierig, von Visual Basic oder Perl aus Funktionen für ein entferntes Java-Objekt aufzurufen. Ein Client sollte in der Lage sein, einen neuen Webdienst zu implementieren oder einen bestehenden Webdienst zu nutzen, unabhängig von der Programmiersprache, in der der Client geschrieben wurde.
• Unterstützung für jede verteilte Komponenteninfrastruktur Die Lösung sollte nicht eng an eine bestimmte Komponenteninfrastruktur gekoppelt sein. Tatsächlich sollte es nicht erforderlich sein, eine Infrastruktur für verteilte Objekte zu erwerben, zu installieren oder zu warten, nur um einen neuen Remote-Dienst zu erstellen oder einen bestehenden Dienst zu nutzen. Die zugrundeliegenden Protokolle sollten eine Basis-Kommunikation zwischen bestehenden verteilten Objektinfrastrukturen wie DCOM und CORBA ermöglichen.

Angesichts des Titels dieses Buches sollte es nicht überraschen, dass die von Microsoft entwickelte Lösung als Webdienste. Ein Webdienst bietet eine Schnittstelle, über die eine bestimmte Aktivität im Namen des Kunden aufgerufen werden kann. Ein Client kann durch die Verwendung von Internetstandards auf den Webdienst zugreifen.

Bausteine für Webdienste
Die folgende Grafik zeigt die wichtigsten Bausteine, die zur Erleichterung der Fernkommunikation zwischen zwei Anwendungen erforderlich sind.

Lassen Sie uns den Zweck jedes dieser Bausteine besprechen. Da viele Leser mit DCOM vertraut sind, werde ich auch das DCOM-Äquivalent der einzelnen Bausteine erwähnen.

• Entdeckung Die Client-Anwendung, die Zugriff auf die von einem Webdienst bereitgestellten Funktionen benötigt, muss eine Möglichkeit haben, den Standort des Remote-Dienstes zu ermitteln. Dies wird durch einen Prozess erreicht, der allgemein als Entdeckung. Die Suche kann sowohl über ein zentralisiertes Verzeichnis als auch durch Ad-hoc-Methoden erleichtert werden. In DCOM bietet der Service Control Manager (SCM) Suchdienste an.
• Beschreibung Sobald der Endpunkt für einen bestimmten Webdienst festgelegt ist, benötigt der Client ausreichende Informationen, um ordnungsgemäß mit ihm zu interagieren. Die Beschreibung eines Webdienstes umfasst strukturierte Metadaten über die Schnittstelle, die von einer Client-Anwendung genutzt werden soll, sowie eine schriftliche Dokumentation über den Webdienst einschließlich Anwendungsbeispielen. Eine DCOM-Komponente stellt strukturierte Metadaten über ihre Schnittstellen über eine Typbibliothek (typelib) zur Verfügung. Die Metadaten in der Typelib einer Komponente werden in einem proprietären Binärformat gespeichert und sind über eine proprietäre Anwendungsprogrammierschnittstelle (API) zugänglich.
• Format der Nachricht Um Daten austauschen zu können, müssen sich ein Client und ein Server auf eine gemeinsame Methode zur Kodierung und Formatierung der Nachrichten einigen. Ein Standardverfahren zur Kodierung von Daten stellt sicher, dass die vom Client kodierten Daten vom Server richtig interpretiert werden. In DCOM werden die zwischen einem Client und einem Server gesendeten Nachrichten so formatiert, wie es im DCOM Object RPC (ORPC) Protokoll definiert ist.

Ohne eine Standardmethode zur Formatierung der Nachrichten ist die Entwicklung eines Werkzeugsatzes zur Abstraktion des Entwicklers von den zugrunde liegenden Protokollen nahezu unmöglich. Die Schaffung einer Abstraktionsschicht zwischen dem Entwickler und den zugrunde liegenden Protokollen ermöglicht es dem Entwickler, sich mehr auf das eigentliche Geschäftsproblem und weniger auf die zur Implementierung der Lösung erforderliche Infrastruktur zu konzentrieren.

• Kodierung Die zwischen dem Client und dem Server übertragenen Daten müssen im Nachrichtentext kodiert werden. DCOM verwendet ein binäres Kodierungsschema, um die in den zwischen dem Client und dem Server ausgetauschten Parametern enthaltenen Daten zu serialisieren.
• Transport Nach der Formatierung der Nachricht und der Serialisierung der Daten im Nachrichtentext muss die Nachricht über ein Transportprotokoll zwischen dem Client und dem Server übertragen werden. DCOM unterstützt eine Reihe von proprietären Protokollen, die an eine Reihe von Netzwerkprotokollen wie TCP, SPX, NetBEUI und NetBIOS über IPX gebunden sind.

Designentscheidungen für Webdienste

Lassen Sie uns einige der Design-Entscheidungen hinter diesen Bausteinen für Webdienste diskutieren.

Auswahl von Transportprotokollen

Der erste Schritt bestand darin, festzulegen, wie der Client und der Server miteinander kommunizieren sollten. Der Client und der Server können sich im selben LAN befinden, aber der Client könnte auch über das Internet mit dem Server kommunizieren. Daher muss das Transportprotokoll gleichermaßen für LAN-Umgebungen und das Internet geeignet sein.

Wie bereits erwähnt, sind Technologien wie DCOM, CORBA und Java RMI schlecht geeignet, um die Kommunikation zwischen Client und Server über das Internet zu unterstützen. Protokolle wie das Hypertext Transfer Protocol (HTTP) und das Simple Mail Transfer Protocol (SMTP) sind bewährte Internetprotokolle. HTTP definiert ein Anfrage/Antwort-Muster für die Übermittlung einer Anfrage und den Erhalt einer entsprechenden Antwort. SMTP definiert ein routingfähiges Messaging-Protokoll für asynchrone Kommunikation. Untersuchen wir, warum HTTP und SMTP gut für das Internet geeignet sind.

HTTP-basierte Webanwendungen sind von Natur aus zustandslos. Sie sind nicht auf eine kontinuierliche Verbindung zwischen dem Client und dem Server angewiesen. Dies macht HTTP zu einem idealen Protokoll für hochverfügbare Konfigurationen wie Firewalls. Wenn der Server, der die ursprüngliche Anfrage des Clients bearbeitet hat, nicht mehr verfügbar ist, können nachfolgende Anfragen automatisch an einen anderen Server weitergeleitet werden, ohne dass der Client dies merkt oder sich darum kümmert.

Fast alle Unternehmen verfügen über eine Infrastruktur, die SMTP unterstützt. SMTP eignet sich gut für die asynchrone Kommunikation. Wenn der Dienst unterbrochen wird, kümmert sich die E-Mail-Infrastruktur automatisch um Wiederholungsversuche. Anders als bei HTTP können Sie SMTP-Nachrichten an einen lokalen Mail-Server weiterleiten, der dann versucht, die Nachricht in Ihrem Namen zuzustellen.

Der andere große Vorteil von HTTP und SMTP ist ihre weite Verbreitung. Die Mitarbeiter haben sich an E-Mail und Webbrowser gewöhnt, und die Netzwerkadministratoren sind mit der Unterstützung dieser Dienste sehr vertraut. Technologien wie Network Address Translation (NAT) und Proxy-Server ermöglichen den Zugriff auf das Internet über HTTP aus ansonsten isolierten Unternehmens-LANs. Administratoren stellen oft einen SMTP-Server bereit, der sich innerhalb der Firewall befindet. An diesen Server gesendete Nachrichten werden dann über das Internet an ihr endgültiges Ziel weitergeleitet.

Im Falle von Software für die Kreditkartenverarbeitung ist eine sofortige Antwort der Händlerbank erforderlich, um festzustellen, ob der Auftrag an das ERP-System weitergeleitet werden soll. HTTP mit seinem Anfrage/Antwort-Muster ist für diese Aufgabe gut geeignet.

Die meisten ERP-Softwarepakete sind nicht in der Lage, große Mengen von Aufträgen zu verarbeiten, die potenziell von der E-Commerce-Anwendung ausgehen können. Darüber hinaus ist es nicht zwingend erforderlich, dass die Bestellungen in Echtzeit an das ERP-System übermittelt werden. Daher kann SMTP genutzt werden, um Bestellungen in eine Warteschlange zu stellen, so dass sie seriell vom ERP-System verarbeitet werden können.

Wenn das ERP-System verteilte Transaktionen unterstützt, besteht eine weitere Möglichkeit darin, Microsoft Message Queue Server (MSMQ) zu nutzen. Solange sich die E-Commerce-Anwendung und das ERP-System im selben LAN befinden, ist die Konnektivität über Nicht-Internet-Protokolle weniger ein Problem. Der Vorteil von MSMQ gegenüber SMTP besteht darin, dass Nachrichten im Rahmen einer Transaktion in die Warteschlange gestellt und aus ihr entfernt werden können. Wenn der Versuch, eine aus der Warteschlange entfernte Nachricht zu verarbeiten, fehlschlägt, wird die Nachricht automatisch wieder in die Warteschlange gestellt, wenn die Transaktion abbricht.

Auswahl eines Kodierungsschemas

HTTP und SMTP ermöglichen das Senden von Daten zwischen dem Client und dem Server. Beide geben jedoch nicht vor, wie die Daten innerhalb des Nachrichtentextes kodiert werden sollen. Microsoft benötigte eine standardisierte, plattformneutrale Methode zur Kodierung der zwischen Client und Server ausgetauschten Daten.

Da das Ziel darin bestand, Internet-basierte Protokolle zu nutzen, war die Extensible Markup Language (XML) die natürliche Wahl. XML bietet viele Vorteile, darunter plattformübergreifende Unterstützung, ein gemeinsames Typensystem und Unterstützung für Industriestandard-Zeichensätze.

Binäre Kodierungsverfahren, wie sie von DCOM, CORBA und Java RMI verwendet werden, müssen Kompatibilitätsprobleme zwischen verschiedenen Hardwareplattformen berücksichtigen. Beispielsweise haben verschiedene Hardwareplattformen eine unterschiedliche interne Binärdarstellung von Multi-Byte-Zahlen. Intel-Plattformen ordnen die Bytes einer Multi-Byte-Zahl nach der Little-Endian-Konvention an; viele RISC-Prozessoren ordnen die Bytes einer Multi-Byte-Zahl nach der Big-Endian-Konvention an.

XML vermeidet binäre Kodierungsprobleme, da es ein textbasiertes Kodierungsschema verwendet, das Standardzeichensätze nutzt. Außerdem können einige Transportprotokolle, wie z. B. SMTP, nur textbasierte Nachrichten enthalten.

Binäre Kodierungsmethoden, wie sie von DCOM und CORBA verwendet werden, sind umständlich und erfordern eine unterstützende Infrastruktur, die den Entwickler von den Details abstrahiert. XML ist viel leichter und einfacher zu handhaben, da es mit Standard-Text-Parsing-Techniken erstellt und konsumiert werden kann.

Darüber hinaus gibt es eine Vielzahl von XML-Parsern, die die Erstellung und Verwendung von XML-Dokumenten auf praktisch jeder modernen Plattform weiter vereinfachen. XML ist leichtgewichtig und verfügt über eine hervorragende Toolunterstützung, so dass die XML-Kodierung eine unglaubliche Reichweite hat, da praktisch jeder Client auf jeder Plattform mit Ihrem Webdienst kommunizieren kann.

Auswahl einer Formatierungskonvention

Oft ist es notwendig, zusätzliche Metadaten in den Nachrichtentext aufzunehmen. So können Sie z. B. Informationen über die Art der Dienste einfügen, die ein Webdienst bereitstellen muss, um Ihre Anfrage zu erfüllen, wie z. B. die Eintragung in eine Transaktion oder Routing-Informationen. XML bietet keinen Mechanismus zur Unterscheidung zwischen dem Nachrichtentext und den zugehörigen Daten.

Transportprotokolle wie HTTP bieten einen erweiterbaren Mechanismus für Kopfdaten, aber einige mit der Nachricht verbundene Daten sind möglicherweise nicht spezifisch für das Transportprotokoll. So könnte der Client beispielsweise eine Nachricht senden, die an mehrere Ziele weitergeleitet werden muss, möglicherweise über verschiedene Transportprotokolle. Wären die Routing-Informationen in einem HTTP-Header enthalten, müssten sie übersetzt werden, bevor sie über ein anderes Transportprotokoll, wie z. B. SMTP, an den nächsten Vermittler gesendet werden. Da die Routing-Informationen spezifisch für die Nachricht und nicht für das Transportprotokoll sind, sollten sie Teil der Nachricht sein.

Das Simple Object Access Protocol (SOAP) bietet ein protokollunabhängiges Mittel, um Header-Informationen mit dem Hauptteil der Nachricht zu verknüpfen. Jede SOAP-Nachricht muss einen Umschlag definieren. Der Umschlag hat einen Körper, der die Nutzlast der Nachricht enthält, und einen Kopf, der mit der Nachricht verbundene Metadaten enthalten kann.

SOAP macht keine Vorgaben, wie der Nachrichtentext formatiert werden kann. Dies ist ein potenzielles Problem, denn ohne eine einheitliche Methode zur Kodierung der Daten ist es schwierig, ein Toolset zu entwickeln, das von den zugrunde liegenden Protokollen abstrahiert. Es kann sein, dass Sie eine Menge Zeit damit verbringen müssen, sich mit der Schnittstelle des Webdienstes vertraut zu machen, anstatt das eigentliche Geschäftsproblem zu lösen.

Benötigt wurde eine Standardmethode zur Formatierung einer RPC-Nachricht (Remote Procedure Call) und zur Kodierung ihrer Parameterliste. Genau dies ist in Abschnitt 7 der SOAP-Spezifikation vorgesehen. Er beschreibt eine Standard-Namenskonvention und einen Kodierungsstil für prozedurorientierte Nachrichten.

Da SOAP ein Standardformat für die Serialisierung von Daten in eine XML-Nachricht bietet, können Plattformen wie ASP.NET und Remoting die Details für Sie abstrahieren.

Auswahl der Beschreibungsmechanismen

SOAP bietet eine Standardmethode zur Formatierung von Nachrichten, die zwischen dem Webdienst und dem Client ausgetauscht werden. Der Client benötigt jedoch zusätzliche Informationen, um die Anfrage richtig zu serialisieren und die Antwort zu interpretieren. Mit XML-Schema lassen sich Schemata erstellen, die zur Beschreibung des Inhalts einer Nachricht verwendet werden können.

XML-Schema bietet einen Kernsatz integrierter Datentypen, die zur Beschreibung des Inhalts einer Nachricht verwendet werden können. Sie können auch Ihre eigenen Datentypen erstellen. So kann z. B. die Händlerbank einen komplexen Datentyp erstellen, um den Inhalt und die Struktur des Textkörpers einer Nachricht zu beschreiben, die zur Übermittlung einer Kreditkartenzahlungsanfrage verwendet wird.

Ein Schema enthält eine Reihe von Datentyp- und Elementdefinitionen. Ein Webdienst verwendet das Schema nicht nur, um die Art der Daten mitzuteilen, die in einer Nachricht enthalten sein sollen, sondern auch, um eingehende und ausgehende Nachrichten zu validieren.

Ein Schema allein bietet jedoch nicht genügend Informationen, um einen Webdienst effektiv zu beschreiben. Das Schema beschreibt nicht die Nachrichtenmuster zwischen dem Client und dem Server. So muss ein Client beispielsweise wissen, ob er eine Antwort erwarten kann, wenn ein Auftrag an das ERP-System gesendet wird. Ein Client muss auch wissen, über welches Transportprotokoll der Webdienst Anfragen erwartet. Schließlich muss der Client die Adresse kennen, unter der der Webdienst erreichbar ist.

Diese Informationen werden durch ein WSDL-Dokument (Web Services Description Language) bereitgestellt. WSDL ist ein XML-Dokument, das einen bestimmten Webdienst vollständig beschreibt. Tools wie ASP.NET WSDL.exe und Remoting SOAPSUDS.exe können WSDL konsumieren und automatisch Proxys für den Entwickler erstellen.

Wie bei jeder Komponente, die zur Erstellung von Software verwendet wird, sollte auch ein Webdienst von einer schriftlichen Dokumentation für Entwickler begleitet werden, die gegen den Webdienst programmieren. Die Dokumentation sollte beschreiben, was der Webdienst tut, die Schnittstellen, die er bereitstellt, und einige Beispiele für seine Verwendung. Eine gute Dokumentation ist vor allem dann wichtig, wenn der Webdienst Kunden über das Internet zur Verfügung gestellt wird.

Auswahl der Entdeckungsmechanismen

Wenn Sie einen Webdienst entwickelt und dokumentiert haben, wie können potenzielle Kunden ihn dann finden? Wenn der Webdienst für ein Mitglied Ihres Entwicklungsteams bestimmt ist, können Sie recht informell vorgehen, indem Sie z. B. die URL des WSDL-Dokuments an Ihren Kollegen ein paar Kabinen weitergeben. Wenn sich die potenziellen Kunden jedoch im Internet befinden, ist eine effektive Werbung für Ihren Webdienst eine ganz andere Sache.

Was wir brauchen, ist eine gemeinsame Methode zur Bekanntmachung von Webdiensten. Universal Description, Discovery, and Integration (UDDI) bietet genau einen solchen Mechanismus. UDDI ist ein dem Industriestandard entsprechender zentraler Verzeichnisdienst, der zur Bekanntmachung und zum Auffinden von Webdiensten verwendet werden kann. UDDI ermöglicht die Suche nach Webdiensten anhand einer Vielzahl von Suchkriterien, darunter Firmenname, Kategorie und Art des Webdienstes.

Webdienste können auch über DISCO beworben werden, ein von Microsoft definiertes proprietäres XML-Dokumentenformat, das es Websites ermöglicht, die von ihnen bereitgestellten Dienste zu bewerben. DISCO definiert ein einfaches Protokoll zur Erleichterung eines Hyperlink-Stils zum Auffinden von Ressourcen. Der Hauptnutzer von DISCO ist Microsoft Visual Studio.NET. Ein Entwickler kann einen bestimmten Webserver ansteuern und durch die verschiedenen vom Server angebotenen Webdienste navigieren.

Was fehlt in den Webdiensten?

Vielleicht ist Ihnen aufgefallen, dass einige wichtige Elemente einer verteilten Komponenteninfrastruktur nicht durch Webdienste definiert sind. Zwei der auffälligsten Lücken sind eine klar definierte API für die Erstellung und Nutzung von Webdiensten und eine Reihe von Komponentendiensten, wie z. B. die Unterstützung verteilter Transaktionen. Lassen Sie uns jedes dieser fehlenden Elemente diskutieren.

• Webdienst-spezifische API Die meisten Infrastrukturen für verteilte Komponenten definieren eine API, um Aufgaben wie die Initialisierung der Laufzeit, die Erstellung einer Instanz einer Komponente und die Wiedergabe der zur Beschreibung der Komponente verwendeten Metadaten durchzuführen. Da die meisten höheren Programmiersprachen ein gewisses Maß an Interoperabilität mit C bieten, wird die API in der Regel als ein flacher Satz von C-Methodensignaturen dargestellt. RMI geht so weit, dass es seine API eng mit einer einzigen Hochsprache, Java, koppelt.

Um sicherzustellen, dass Webdienste programmiersprachenunabhängig sind, hat Microsoft es den einzelnen Softwareanbietern überlassen, die Unterstützung für Webdienste an eine bestimmte Plattform zu binden. Zwei Webdienst-Implementierungen für die .NET-Plattform, ASP.NET und Remoting, werden später in diesem Buch besprochen.

• Komponentendienste Die Plattform für Webdienste bietet viele der Dienste, die üblicherweise in Infrastrukturen für verteilte Komponenten zu finden sind, nicht an, wie z. B. die Verwaltung der Lebensdauer von Remote-Objekten, das Pooling von Objekten und die Unterstützung für verteilte Transaktionen. Die Implementierung dieser Dienste wird der Infrastruktur für verteilte Komponenten überlassen.

Einige Dienste, wie die Unterstützung verteilter Transaktionen, können später eingeführt werden, wenn die Technologie ausgereift ist. Andere, wie Object Pooling und möglicherweise Object Lifetime Management, können als ein Implementierungsdetail der Plattform betrachtet werden. Beispielsweise definiert Remoting Erweiterungen, um die Verwaltung der Objektlebensdauer zu unterstützen, und Microsoft Component Services bietet Unterstützung für Objektpooling.

Zusammenfassung

Die komponentenbasierte Programmierung hat sich als ein Segen für die Produktivität von Entwicklern erwiesen, aber einige Dienste können nicht durch eine Komponente gekapselt werden, die sich im Rechenzentrum des Kunden befindet. Ältere Technologien wie DCOM, CORBA und Java RMI sind schlecht geeignet, um Clients den Zugriff auf Dienste über das Internet zu ermöglichen, so dass Microsoft es für notwendig hielt, ganz von vorne anzufangen und einen Industriestandard für den Zugriff auf Remote-Dienste zu entwickeln.

Webdienste ist ein Oberbegriff, der eine Sammlung von Industriestandardprotokollen und -diensten beschreibt, die zur Erleichterung einer grundlegenden Interoperabilität zwischen Anwendungen verwendet werden. Die Unterstützung, die Webdienste in der Industrie erfahren haben, ist beispiellos. Nie zuvor haben sich so viele führende Technologieunternehmen für einen Standard eingesetzt, der die Interoperabilität zwischen Anwendungen unabhängig von der Plattform, auf der sie ausgeführt werden, erleichtert.

Einer der Faktoren, die zum Erfolg von Webdiensten beitragen, ist, dass sie auf bestehenden Internetstandards wie XML und HTTP aufbauen. Daher kann jedes System, das in der Lage ist, Text zu parsen und über ein standardisiertes Internet-Transportprotokoll zu kommunizieren, mit einem Webdienst kommunizieren. Die Unternehmen können auch die Investitionen nutzen, die sie bereits in diese Technologien getätigt haben.