\u00dcbersicht<\/b>
\nDie 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\u00e4t der Anwendungen ist auch der Bedarf an der Nutzung von Komponenten, die auf entfernten Rechnern verteilt sind, gestiegen.<\/p>\n
<\/p>\n
Ein Beispiel f\u00fcr eine komponentenbasierte Anwendung ist eine End-to-End-E-Commerce-L\u00f6sung. Eine E-Commerce-Anwendung, die sich auf einer Webfarm befindet, muss Bestellungen an eine Back-End-Anwendung f\u00fcr die Ressourcenplanung (ERP) \u00fcbermitteln. In vielen F\u00e4llen befindet sich die ERP-Anwendung auf einer anderen Hardware und l\u00e4uft m\u00f6glicherweise unter einem anderen Betriebssystem.<\/p>\n
Das Microsoft Distributed Component Object Model (DCOM), eine Infrastruktur f\u00fcr verteilte Objekte, die es einer Anwendung erm\u00f6glicht, 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\u00e4ufig Komponenten f\u00fcr die Windows-Plattform, die \u00fcber ein propriet\u00e4res Protokoll mit dem Back-End-System kommunizieren.<\/p>\n
Einige Dienste, die von einer E-Commerce-Anwendung genutzt werden, befinden sich m\u00f6glicherweise gar nicht im Rechenzentrum. Wenn die E-Commerce-Anwendung beispielsweise Kreditkartenzahlungen f\u00fcr vom Kunden gekaufte Waren akzeptiert, muss sie die Dienste der H\u00e4ndlerbank 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\u00e4nkt, die im Rechenzentrum des Unternehmens installiert sind. Zwei Hauptgr\u00fcnde daf\u00fcr sind, dass diese Technologien standardm\u00e4\u00dfig propriet\u00e4re Protokolle nutzen und diese Protokolle von Natur aus verbindungsorientiert sind.<\/p>\n
F\u00fcr Clients, die \u00fcber das Internet mit dem Server kommunizieren, gibt es zahlreiche potenzielle Hindernisse f\u00fcr die Kommunikation mit dem Server. Sicherheitsbewusste Netzwerkadministratoren auf der ganzen Welt haben unternehmenseigene Router und Firewalls eingerichtet, um praktisch jede Art von Kommunikation \u00fcber das Internet zu unterbinden. Es bedarf oft einer h\u00f6heren Gewalt, um einen Netzwerkadministrator dazu zu bringen, Ports \u00fcber das absolute Minimum hinaus zu \u00f6ffnen.<\/p>\n
Wenn Sie das Gl\u00fcck haben, dass ein Netzwerkadministrator die entsprechenden Ports zur Unterst\u00fctzung Ihres Dienstes freigibt, haben Ihre Kunden wahrscheinlich nicht so viel Gl\u00fcck. Daher sind propriet\u00e4re Protokolle, wie sie von DCOM, CORBA und Java RMI verwendet werden, f\u00fcr Internet-Szenarien nicht geeignet.<\/p>\n
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\u00e4ltigen. Da das Internet nicht unter Ihrer direkten Kontrolle steht, k\u00f6nnen Sie keine Annahmen \u00fcber die Qualit\u00e4t oder Zuverl\u00e4ssigkeit der Verbindung machen. Kommt es zu einer Netzunterbrechung, kann der n\u00e4chste Anruf des Clients an den Server fehlschlagen.<\/p>\n
Die verbindungsorientierte Natur dieser Technologien macht es auch schwierig, die f\u00fcr eine hohe Skalierbarkeit erforderlichen lastverteilten Infrastrukturen aufzubauen. Sobald die Verbindung zwischen dem Client und dem Server unterbrochen wird, k\u00f6nnen Sie die n\u00e4chste Anfrage nicht einfach an einen anderen Server weiterleiten.<\/p>\n
Die Entwickler haben versucht, diese Einschr\u00e4nkungen zu \u00fcberwinden, indem sie ein Modell namens zustandslos <\/i>Programmierung<\/i>, Sie hatten jedoch nur begrenzten Erfolg, weil die Technologien ziemlich schwer sind und es teuer ist, eine Verbindung mit einem entfernten Objekt wiederherzustellen.<\/p>\n
Da die Verarbeitung der Kreditkarte eines Kunden von einem entfernten Server im Internet durchgef\u00fchrt wird, ist DCOM nicht ideal f\u00fcr die Kommunikation zwischen dem E-Commerce-Client und dem Kreditkartenverarbeitungsserver. Wie bei einer ERP-L\u00f6sung wird h\u00e4ufig eine Komponente eines Drittanbieters im Rechenzentrum des Kunden installiert (in diesem Fall vom Anbieter der Kreditkartenabwicklungsl\u00f6sung). Diese Komponente dient lediglich als Proxy, der die Kommunikation zwischen der E-Commerce-Software und der H\u00e4ndlerbank \u00fcber ein propriet\u00e4res Protokoll erm\u00f6glicht.<\/p>\n
Erkennen Sie hier ein Muster? Da die bestehenden Technologien bei der Erleichterung der Kommunikation zwischen Computersystemen an ihre Grenzen sto\u00dfen, haben die Software-Anbieter h\u00e4ufig auf den Aufbau einer eigenen Infrastruktur zur\u00fcckgegriffen. Das bedeutet, dass Ressourcen, die f\u00fcr die Verbesserung der Funktionalit\u00e4t des ERP-Systems oder des Kreditkartenverarbeitungssystems h\u00e4tten verwendet werden k\u00f6nnen, stattdessen f\u00fcr die Entwicklung propriet\u00e4rer Netzwerkprotokolle eingesetzt wurden.<\/p>\n
In dem Bestreben, solche Internet-Szenarien besser zu unterst\u00fctzen, verfolgte Microsoft zun\u00e4chst die Strategie, seine bestehenden Technologien zu erweitern, einschlie\u00dflich COM Internet Services (CIS), mit denen Sie eine DCOM-Verbindung zwischen dem Client und der entfernten Komponente \u00fcber Port 80 herstellen k\u00f6nnen. Aus verschiedenen Gr\u00fcnden wurde CIS nicht allgemein akzeptiert.<\/p>\n
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\u00f6sung erf\u00fcllen musste, um erfolgreich zu sein.<\/p>\n
Angesichts des Titels dieses Buches sollte es nicht \u00fcberraschen, dass die von Microsoft entwickelte L\u00f6sung als Webdienste<\/i>. Ein Webdienst bietet eine Schnittstelle, \u00fcber die eine bestimmte Aktivit\u00e4t im Namen des Kunden aufgerufen werden kann. Ein Client kann durch die Verwendung von Internetstandards auf den Webdienst zugreifen.<\/p>\n
Bausteine f\u00fcr Webdienste<\/b>
\nDie folgende Grafik zeigt die wichtigsten Bausteine, die zur Erleichterung der Fernkommunikation zwischen zwei Anwendungen erforderlich sind.<\/p>\n
Lassen Sie uns den Zweck jedes dieser Bausteine besprechen. Da viele Leser mit DCOM vertraut sind, werde ich auch das DCOM-\u00c4quivalent der einzelnen Bausteine erw\u00e4hnen.<\/p>\n
Ohne eine Standardmethode zur Formatierung der Nachrichten ist die Entwicklung eines Werkzeugsatzes zur Abstraktion des Entwicklers von den zugrunde liegenden Protokollen nahezu unm\u00f6glich. Die Schaffung einer Abstraktionsschicht zwischen dem Entwickler und den zugrunde liegenden Protokollen erm\u00f6glicht es dem Entwickler, sich mehr auf das eigentliche Gesch\u00e4ftsproblem und weniger auf die zur Implementierung der L\u00f6sung erforderliche Infrastruktur zu konzentrieren.<\/p>\n
Designentscheidungen f\u00fcr Webdienste<\/b><\/p>\n
Lassen Sie uns einige der Design-Entscheidungen hinter diesen Bausteinen f\u00fcr Webdienste diskutieren.<\/p>\n
Auswahl von Transportprotokollen<\/b><\/p>\n
Der erste Schritt bestand darin, festzulegen, wie der Client und der Server miteinander kommunizieren sollten. Der Client und der Server k\u00f6nnen sich im selben LAN befinden, aber der Client k\u00f6nnte auch \u00fcber das Internet mit dem Server kommunizieren. Daher muss das Transportprotokoll gleicherma\u00dfen f\u00fcr LAN-Umgebungen und das Internet geeignet sein.<\/p>\n
Wie bereits erw\u00e4hnt, sind Technologien wie DCOM, CORBA und Java RMI schlecht geeignet, um die Kommunikation zwischen Client und Server \u00fcber das Internet zu unterst\u00fctzen. Protokolle wie das Hypertext Transfer Protocol (HTTP) und das Simple Mail Transfer Protocol (SMTP) sind bew\u00e4hrte Internetprotokolle. HTTP definiert ein Anfrage\/Antwort-Muster f\u00fcr die \u00dcbermittlung einer Anfrage und den Erhalt einer entsprechenden Antwort. SMTP definiert ein routingf\u00e4higes Messaging-Protokoll f\u00fcr asynchrone Kommunikation. Untersuchen wir, warum HTTP und SMTP gut f\u00fcr das Internet geeignet sind.<\/p>\n
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\u00fcr hochverf\u00fcgbare Konfigurationen wie Firewalls. Wenn der Server, der die urspr\u00fcngliche Anfrage des Clients bearbeitet hat, nicht mehr verf\u00fcgbar ist, k\u00f6nnen nachfolgende Anfragen automatisch an einen anderen Server weitergeleitet werden, ohne dass der Client dies merkt oder sich darum k\u00fcmmert.<\/p>\n
Fast alle Unternehmen verf\u00fcgen \u00fcber eine Infrastruktur, die SMTP unterst\u00fctzt. SMTP eignet sich gut f\u00fcr die asynchrone Kommunikation. Wenn der Dienst unterbrochen wird, k\u00fcmmert sich die E-Mail-Infrastruktur automatisch um Wiederholungsversuche. Anders als bei HTTP k\u00f6nnen Sie SMTP-Nachrichten an einen lokalen Mail-Server weiterleiten, der dann versucht, die Nachricht in Ihrem Namen zuzustellen.<\/p>\n
Der andere gro\u00dfe Vorteil von HTTP und SMTP ist ihre weite Verbreitung. Die Mitarbeiter haben sich an E-Mail und Webbrowser gew\u00f6hnt, und die Netzwerkadministratoren sind mit der Unterst\u00fctzung dieser Dienste sehr vertraut. Technologien wie Network Address Translation (NAT) und Proxy-Server erm\u00f6glichen den Zugriff auf das Internet \u00fcber 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 \u00fcber das Internet an ihr endg\u00fcltiges Ziel weitergeleitet.<\/p>\n
Im Falle von Software f\u00fcr die Kreditkartenverarbeitung ist eine sofortige Antwort der H\u00e4ndlerbank erforderlich, um festzustellen, ob der Auftrag an das ERP-System weitergeleitet werden soll. HTTP mit seinem Anfrage\/Antwort-Muster ist f\u00fcr diese Aufgabe gut geeignet.<\/p>\n
Die meisten ERP-Softwarepakete sind nicht in der Lage, gro\u00dfe Mengen von Auftr\u00e4gen zu verarbeiten, die potenziell von der E-Commerce-Anwendung ausgehen k\u00f6nnen. Dar\u00fcber hinaus ist es nicht zwingend erforderlich, dass die Bestellungen in Echtzeit an das ERP-System \u00fcbermittelt werden. Daher kann SMTP genutzt werden, um Bestellungen in eine Warteschlange zu stellen, so dass sie seriell vom ERP-System verarbeitet werden k\u00f6nnen.<\/p>\n
Wenn das ERP-System verteilte Transaktionen unterst\u00fctzt, besteht eine weitere M\u00f6glichkeit 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\u00e4t \u00fcber Nicht-Internet-Protokolle weniger ein Problem. Der Vorteil von MSMQ gegen\u00fcber SMTP besteht darin, dass Nachrichten im Rahmen einer Transaktion in die Warteschlange gestellt und aus ihr entfernt werden k\u00f6nnen. Wenn der Versuch, eine aus der Warteschlange entfernte Nachricht zu verarbeiten, fehlschl\u00e4gt, wird die Nachricht automatisch wieder in die Warteschlange gestellt, wenn die Transaktion abbricht.<\/p>\n
Auswahl eines Kodierungsschemas<\/b><\/p>\n
HTTP und SMTP erm\u00f6glichen 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\u00f6tigte eine standardisierte, plattformneutrale Methode zur Kodierung der zwischen Client und Server ausgetauschten Daten.<\/p>\n
Da das Ziel darin bestand, Internet-basierte Protokolle zu nutzen, war die Extensible Markup Language (XML) die nat\u00fcrliche Wahl. XML bietet viele Vorteile, darunter plattform\u00fcbergreifende Unterst\u00fctzung, ein gemeinsames Typensystem und Unterst\u00fctzung f\u00fcr Industriestandard-Zeichens\u00e4tze.<\/p>\n
Bin\u00e4re Kodierungsverfahren, wie sie von DCOM, CORBA und Java RMI verwendet werden, m\u00fcssen Kompatibilit\u00e4tsprobleme zwischen verschiedenen Hardwareplattformen ber\u00fccksichtigen. Beispielsweise haben verschiedene Hardwareplattformen eine unterschiedliche interne Bin\u00e4rdarstellung 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.<\/p>\n
XML vermeidet bin\u00e4re Kodierungsprobleme, da es ein textbasiertes Kodierungsschema verwendet, das Standardzeichens\u00e4tze nutzt. Au\u00dferdem k\u00f6nnen einige Transportprotokolle, wie z. B. SMTP, nur textbasierte Nachrichten enthalten.<\/p>\n
Bin\u00e4re Kodierungsmethoden, wie sie von DCOM und CORBA verwendet werden, sind umst\u00e4ndlich und erfordern eine unterst\u00fctzende 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.<\/p>\n
Dar\u00fcber 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\u00fcgt \u00fcber eine hervorragende Toolunterst\u00fctzung, so dass die XML-Kodierung eine unglaubliche Reichweite hat, da praktisch jeder Client auf jeder Plattform mit Ihrem Webdienst kommunizieren kann.<\/p>\n
Auswahl einer Formatierungskonvention<\/b><\/p>\n
Oft ist es notwendig, zus\u00e4tzliche Metadaten in den Nachrichtentext aufzunehmen. So k\u00f6nnen Sie z. B. Informationen \u00fcber die Art der Dienste einf\u00fcgen, die ein Webdienst bereitstellen muss, um Ihre Anfrage zu erf\u00fcllen, wie z. B. die Eintragung in eine Transaktion oder Routing-Informationen. XML bietet keinen Mechanismus zur Unterscheidung zwischen dem Nachrichtentext und den zugeh\u00f6rigen Daten.<\/p>\n
Transportprotokolle wie HTTP bieten einen erweiterbaren Mechanismus f\u00fcr Kopfdaten, aber einige mit der Nachricht verbundene Daten sind m\u00f6glicherweise nicht spezifisch f\u00fcr das Transportprotokoll. So k\u00f6nnte der Client beispielsweise eine Nachricht senden, die an mehrere Ziele weitergeleitet werden muss, m\u00f6glicherweise \u00fcber verschiedene Transportprotokolle. W\u00e4ren die Routing-Informationen in einem HTTP-Header enthalten, m\u00fcssten sie \u00fcbersetzt werden, bevor sie \u00fcber ein anderes Transportprotokoll, wie z. B. SMTP, an den n\u00e4chsten Vermittler gesendet werden. Da die Routing-Informationen spezifisch f\u00fcr die Nachricht und nicht f\u00fcr das Transportprotokoll sind, sollten sie Teil der Nachricht sein.<\/p>\n
Das Simple Object Access Protocol (SOAP) bietet ein protokollunabh\u00e4ngiges Mittel, um Header-Informationen mit dem Hauptteil der Nachricht zu verkn\u00fcpfen. Jede SOAP-Nachricht muss einen Umschlag definieren. Der Umschlag hat einen K\u00f6rper, der die Nutzlast der Nachricht enth\u00e4lt, und einen Kopf, der mit der Nachricht verbundene Metadaten enthalten kann.<\/p>\n
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\u00fcssen, sich mit der Schnittstelle des Webdienstes vertraut zu machen, anstatt das eigentliche Gesch\u00e4ftsproblem zu l\u00f6sen.<\/p>\n
Ben\u00f6tigt 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\u00fcr prozedurorientierte Nachrichten.<\/p>\n
Da SOAP ein Standardformat f\u00fcr die Serialisierung von Daten in eine XML-Nachricht bietet, k\u00f6nnen Plattformen wie ASP.NET und Remoting die Details f\u00fcr Sie abstrahieren.<\/p>\n
Auswahl der Beschreibungsmechanismen<\/b><\/p>\n
SOAP bietet eine Standardmethode zur Formatierung von Nachrichten, die zwischen dem Webdienst und dem Client ausgetauscht werden. Der Client ben\u00f6tigt jedoch zus\u00e4tzliche 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\u00f6nnen.<\/p>\n
XML-Schema bietet einen Kernsatz integrierter Datentypen, die zur Beschreibung des Inhalts einer Nachricht verwendet werden k\u00f6nnen. Sie k\u00f6nnen auch Ihre eigenen Datentypen erstellen. So kann z. B. die H\u00e4ndlerbank einen komplexen Datentyp erstellen, um den Inhalt und die Struktur des Textk\u00f6rpers einer Nachricht zu beschreiben, die zur \u00dcbermittlung einer Kreditkartenzahlungsanfrage verwendet wird.<\/p>\n
Ein Schema enth\u00e4lt 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.<\/p>\n
Ein Schema allein bietet jedoch nicht gen\u00fcgend 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, \u00fcber welches Transportprotokoll der Webdienst Anfragen erwartet. Schlie\u00dflich muss der Client die Adresse kennen, unter der der Webdienst erreichbar ist.<\/p>\n
Diese Informationen werden durch ein WSDL-Dokument (Web Services Description Language) bereitgestellt. WSDL ist ein XML-Dokument, das einen bestimmten Webdienst vollst\u00e4ndig beschreibt. Tools wie ASP.NET WSDL.exe und Remoting SOAPSUDS.exe k\u00f6nnen WSDL konsumieren und automatisch Proxys f\u00fcr den Entwickler erstellen.<\/p>\n
Wie bei jeder Komponente, die zur Erstellung von Software verwendet wird, sollte auch ein Webdienst von einer schriftlichen Dokumentation f\u00fcr 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\u00fcr seine Verwendung. Eine gute Dokumentation ist vor allem dann wichtig, wenn der Webdienst Kunden \u00fcber das Internet zur Verf\u00fcgung gestellt wird.<\/p>\n
Auswahl der Entdeckungsmechanismen<\/b><\/p>\n
Wenn Sie einen Webdienst entwickelt und dokumentiert haben, wie k\u00f6nnen potenzielle Kunden ihn dann finden? Wenn der Webdienst f\u00fcr ein Mitglied Ihres Entwicklungsteams bestimmt ist, k\u00f6nnen 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\u00fcr Ihren Webdienst eine ganz andere Sache.<\/p>\n
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\u00f6glicht die Suche nach Webdiensten anhand einer Vielzahl von Suchkriterien, darunter Firmenname, Kategorie und Art des Webdienstes.<\/p>\n
Webdienste k\u00f6nnen auch \u00fcber DISCO beworben werden, ein von Microsoft definiertes propriet\u00e4res XML-Dokumentenformat, das es Websites erm\u00f6glicht, 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.<\/p>\n
Was fehlt in den Webdiensten?<\/b><\/p>\n
Vielleicht ist Ihnen aufgefallen, dass einige wichtige Elemente einer verteilten Komponenteninfrastruktur nicht durch Webdienste definiert sind. Zwei der auff\u00e4lligsten L\u00fccken sind eine klar definierte API f\u00fcr die Erstellung und Nutzung von Webdiensten und eine Reihe von Komponentendiensten, wie z. B. die Unterst\u00fctzung verteilter Transaktionen. Lassen Sie uns jedes dieser fehlenden Elemente diskutieren.<\/p>\n
Um sicherzustellen, dass Webdienste programmiersprachenunabh\u00e4ngig sind, hat Microsoft es den einzelnen Softwareanbietern \u00fcberlassen, die Unterst\u00fctzung f\u00fcr Webdienste an eine bestimmte Plattform zu binden. Zwei Webdienst-Implementierungen f\u00fcr die .NET-Plattform, ASP.NET und Remoting, werden sp\u00e4ter in diesem Buch besprochen.<\/p>\n
Einige Dienste, wie die Unterst\u00fctzung verteilter Transaktionen, k\u00f6nnen sp\u00e4ter eingef\u00fchrt werden, wenn die Technologie ausgereift ist. Andere, wie Object Pooling und m\u00f6glicherweise Object Lifetime Management, k\u00f6nnen als ein Implementierungsdetail der Plattform betrachtet werden. Beispielsweise definiert Remoting Erweiterungen, um die Verwaltung der Objektlebensdauer zu unterst\u00fctzen, und Microsoft Component Services bietet Unterst\u00fctzung f\u00fcr Objektpooling.<\/p>\n
Zusammenfassung<\/b><\/p>\n
Die komponentenbasierte Programmierung hat sich als ein Segen f\u00fcr die Produktivit\u00e4t von Entwicklern erwiesen, aber einige Dienste k\u00f6nnen nicht durch eine Komponente gekapselt werden, die sich im Rechenzentrum des Kunden befindet. \u00c4ltere Technologien wie DCOM, CORBA und Java RMI sind schlecht geeignet, um Clients den Zugriff auf Dienste \u00fcber das Internet zu erm\u00f6glichen, so dass Microsoft es f\u00fcr notwendig hielt, ganz von vorne anzufangen und einen Industriestandard f\u00fcr den Zugriff auf Remote-Dienste zu entwickeln.<\/p>\n
Webdienste<\/i> ist ein Oberbegriff, der eine Sammlung von Industriestandardprotokollen und -diensten beschreibt, die zur Erleichterung einer grundlegenden Interoperabilit\u00e4t zwischen Anwendungen verwendet werden. Die Unterst\u00fctzung, die Webdienste in der Industrie erfahren haben, ist beispiellos. Nie zuvor haben sich so viele f\u00fchrende Technologieunternehmen f\u00fcr einen Standard eingesetzt, der die Interoperabilit\u00e4t zwischen Anwendungen unabh\u00e4ngig von der Plattform, auf der sie ausgef\u00fchrt werden, erleichtert.<\/p>\n
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 \u00fcber ein standardisiertes Internet-Transportprotokoll zu kommunizieren, mit einem Webdienst kommunizieren. Die Unternehmen k\u00f6nnen auch die Investitionen nutzen, die sie bereits in diese Technologien get\u00e4tigt haben.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/de\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}