Web Services - Kurzanleitung

Verschiedene Bücher und verschiedene Organisationen bieten unterschiedliche Definitionen für Webdienste. Einige von ihnen sind hier aufgelistet.

Ein Webdienst ist eine Software, die sich über das Internet zur Verfügung stellt und ein standardisiertes XML-Nachrichtensystem verwendet. XML wird verwendet, um die gesamte Kommunikation mit einem Webdienst zu codieren. Ein Client ruft beispielsweise einen Webdienst auf, indem er eine XML-Nachricht sendet, und wartet dann auf eine entsprechende XML-Antwort. Da die gesamte Kommunikation in XML erfolgt, sind Webdienste nicht an ein Betriebssystem oder eine Programmiersprache gebunden. Java kann mit Perl kommunizieren. Windows-Anwendungen können mit Unix-Anwendungen kommunizieren.
Webdienste sind eigenständige, modulare, verteilte, dynamische Anwendungen, die über das Netzwerk beschrieben, veröffentlicht, lokalisiert oder aufgerufen werden können, um Produkte, Prozesse und Lieferketten zu erstellen. Diese Anwendungen können lokal, verteilt oder webbasiert sein. Webdienste basieren auf offenen Standards wie TCP / IP, HTTP, Java, HTML und XML.
Webdienste sind XML-basierte Informationsaustauschsysteme, die das Internet für die direkte Interaktion von Anwendung zu Anwendung verwenden. Diese Systeme können Programme, Objekte, Nachrichten oder Dokumente enthalten.
Ein Webdienst ist eine Sammlung offener Protokolle und Standards, die für den Datenaustausch zwischen Anwendungen oder Systemen verwendet werden. Softwareanwendungen, die in verschiedenen Programmiersprachen geschrieben sind und auf verschiedenen Plattformen ausgeführt werden, können mithilfe von Webdiensten Daten über Computernetzwerke wie das Internet austauschen, ähnlich wie bei der Kommunikation zwischen Prozessen auf einem einzelnen Computer. Diese Interoperabilität (z. B. zwischen Java und Python oder Windows- und Linux-Anwendungen) ist auf die Verwendung offener Standards zurückzuführen.

Zusammenfassend ist ein vollständiger Webdienst daher jeder Dienst, der -

Ist über das Internet oder private (Intranet-) Netzwerke verfügbar
Verwendet ein standardisiertes XML-Messagingsystem
Ist nicht an ein Betriebssystem oder eine Programmiersprache gebunden
Beschreibt sich selbst über eine gemeinsame XML-Grammatik
Ist über einen einfachen Suchmechanismus erkennbar

Komponenten von Webdiensten

Die grundlegende Webdienstplattform ist XML + HTTP. Alle Standard-Webdienste arbeiten mit den folgenden Komponenten:

SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)

Alle diese Komponenten wurden im Kapitel Web Services-Architektur erläutert .

Wie funktioniert ein Webdienst?

Ein Webdienst ermöglicht die Kommunikation zwischen verschiedenen Anwendungen mithilfe offener Standards wie HTML, XML, WSDL und SOAP. Ein Webdienst nimmt die Hilfe von -

XML zum Kennzeichnen der Daten
SOAP, um eine Nachricht zu übertragen
WSDL zur Beschreibung der Verfügbarkeit von Diensten.

Sie können unter Solaris einen Java-basierten Webdienst erstellen, auf den Sie mit Ihrem Visual Basic-Programm zugreifen können, das unter Windows ausgeführt wird.

Sie können C # auch verwenden, um neue Webdienste unter Windows zu erstellen, die von Ihrer Webanwendung aufgerufen werden können, die auf JavaServer Pages (JSP) basiert und unter Linux ausgeführt wird.

Beispiel

Stellen Sie sich ein einfaches Kontoverwaltungs- und Auftragsabwicklungssystem vor. Das Buchhaltungspersonal verwendet eine mit Visual Basic oder JSP erstellte Clientanwendung, um neue Konten zu erstellen und neue Kundenaufträge einzugeben.

Die Verarbeitungslogik für dieses System ist in Java geschrieben und befindet sich auf einem Solaris-Computer, der auch mit einer Datenbank interagiert, um Informationen zu speichern.

Die Schritte zum Ausführen dieser Operation sind wie folgt:

Das Client-Programm bündelt die Kontoregistrierungsinformationen in einer SOAP-Nachricht.
Diese SOAP-Nachricht wird als Hauptteil einer HTTP-POST-Anforderung an den Webdienst gesendet.
Der Webdienst entpackt die SOAP-Anforderung und konvertiert sie in einen Befehl, den die Anwendung verstehen kann.
Die Anwendung verarbeitet die Informationen nach Bedarf und antwortet mit einer neuen eindeutigen Kontonummer für diesen Kunden.
Als Nächstes packt der Webdienst die Antwort in eine andere SOAP-Nachricht, die er als Antwort auf seine HTTP-Anforderung an das Client-Programm zurücksendet.
Das Client-Programm entpackt die SOAP-Nachricht, um die Ergebnisse des Kontoregistrierungsprozesses zu erhalten.

Hier sind die Vorteile der Verwendung von Webdiensten:

Offenlegen der vorhandenen Funktion im Netzwerk

Ein Webdienst ist eine Einheit aus verwaltetem Code, die über HTTP remote aufgerufen werden kann. Das heißt, es kann über HTTP-Anforderungen aktiviert werden. Mit Webdiensten können Sie die Funktionalität Ihres vorhandenen Codes über das Netzwerk verfügbar machen. Sobald es im Netzwerk verfügbar ist, können andere Anwendungen die Funktionalität Ihres Programms nutzen.

Interoperabilität

Mit Webdiensten können verschiedene Anwendungen miteinander kommunizieren und Daten und Dienste untereinander austauschen. Andere Anwendungen können auch die Webdienste verwenden. Beispielsweise kann eine VB- oder .NET-Anwendung mit Java-Webdiensten kommunizieren und umgekehrt. Webdienste werden verwendet, um die Anwendungsplattform und -technologie unabhängig zu machen.

Standardisiertes Protokoll

Webdienste verwenden für die Kommunikation ein standardisiertes Industriestandardprotokoll. Alle vier Schichten (Service Transport-, XML Messaging-, Service Description- und Service Discovery-Schichten) verwenden genau definierte Protokolle im Webdienst-Protokollstapel. Diese Standardisierung des Protokollstapels bietet dem Unternehmen viele Vorteile, wie z. B. eine breite Auswahl, Reduzierung der Kosten aufgrund des Wettbewerbs und Steigerung der Qualität.

Kostengünstige Kommunikation

Webdienste verwenden SOAP über das HTTP-Protokoll, sodass Sie Ihr vorhandenes kostengünstiges Internet für die Implementierung von Webdiensten verwenden können. Diese Lösung ist im Vergleich zu proprietären Lösungen wie EDI / B2B viel kostengünstiger. Neben SOAP über HTTP können Webdienste auch auf anderen zuverlässigen Transportmechanismen wie FTP implementiert werden.

Webdienste weisen die folgenden besonderen Verhaltensmerkmale auf:

XML-basiert

Webdienste verwenden XML auf der Ebene der Datendarstellung und des Datentransports. Durch die Verwendung von XML werden Netzwerk-, Betriebssystem- oder Plattformbindungen vermieden. Auf Webdiensten basierende Anwendungen sind auf ihrer Kernebene in hohem Maße interoperabel.

Locker verbunden

Ein Verbraucher eines Webdienstes ist nicht direkt an diesen Webdienst gebunden. Die Webdienstschnittstelle kann sich im Laufe der Zeit ändern, ohne die Fähigkeit des Kunden zur Interaktion mit dem Dienst zu beeinträchtigen. Ein eng gekoppeltes System impliziert, dass die Client- und Serverlogik eng miteinander verbunden sind, was bedeutet, dass bei einer Änderung einer Schnittstelle die andere aktualisiert werden muss. Durch die Verwendung einer lose gekoppelten Architektur werden Softwaresysteme in der Regel leichter verwaltet und können einfacher zwischen verschiedenen Systemen integriert werden.

Grobkörnig

Objektorientierte Technologien wie Java stellen ihre Dienste durch individuelle Methoden zur Verfügung. Eine einzelne Methode ist zu fein, um auf Unternehmensebene nützliche Funktionen bereitzustellen. Um ein Java-Programm von Grund auf neu zu erstellen, müssen mehrere feinkörnige Methoden erstellt werden, die dann zu einem grobkörnigen Dienst zusammengesetzt werden, der entweder von einem Client oder einem anderen Dienst verwendet wird.

Unternehmen und die von ihnen bereitgestellten Schnittstellen sollten grobkörnig sein. Die Webdiensttechnologie bietet eine natürliche Möglichkeit, grobkörnige Dienste zu definieren, die auf die richtige Menge an Geschäftslogik zugreifen.

Fähigkeit, synchron oder asynchron zu sein

Synchronizität bezieht sich auf die Bindung des Clients an die Ausführung des Dienstes. Bei synchronen Aufrufen blockiert der Client und wartet, bis der Dienst seinen Vorgang abgeschlossen hat, bevor er fortfährt. Durch asynchrone Operationen kann ein Client einen Dienst aufrufen und dann andere Funktionen ausführen.

Asynchrone Clients rufen ihr Ergebnis zu einem späteren Zeitpunkt ab, während synchrone Clients ihr Ergebnis nach Abschluss des Dienstes erhalten. Die asynchrone Fähigkeit ist ein Schlüsselfaktor für die Ermöglichung lose gekoppelter Systeme.

Unterstützt Remote Procedure Calls (RPCs)

Mithilfe von Webdiensten können Clients Prozeduren, Funktionen und Methoden für Remoteobjekte mithilfe eines XML-basierten Protokolls aufrufen. Remote-Prozeduren legen Eingabe- und Ausgabeparameter offen, die ein Webdienst unterstützen muss.

Die Entwicklung von Komponenten durch Enterprise JavaBeans (EJBs) und .NET Components ist in den letzten Jahren zunehmend Teil von Architekturen und Unternehmensbereitstellungen geworden. Beide Technologien sind über eine Vielzahl von RPC-Mechanismen verteilt und zugänglich.

Ein Webdienst unterstützt RPC, indem er eigene Dienste bereitstellt, die denen einer herkömmlichen Komponente entsprechen, oder indem eingehende Aufrufe in einen Aufruf einer EJB- oder einer .NET-Komponente übersetzt werden.

Unterstützt den Dokumentenaustausch

Einer der Hauptvorteile von XML ist die generische Darstellung nicht nur von Daten, sondern auch von komplexen Dokumenten. Diese Dokumente können so einfach sein wie die Darstellung einer aktuellen Adresse, oder sie können so komplex sein wie die Darstellung eines gesamten Buches oder einer Angebotsanfrage (RFQ). Webdienste unterstützen den transparenten Austausch von Dokumenten, um die Geschäftsintegration zu erleichtern.

Es gibt zwei Möglichkeiten, die Webdienstarchitektur anzuzeigen:

Die erste besteht darin, die einzelnen Rollen der einzelnen Webdienstakteure zu untersuchen.
Die zweite besteht darin, den aufkommenden Webdienstprotokollstapel zu untersuchen.

Webdienstrollen

Innerhalb der Webdienstarchitektur gibt es drei Hauptrollen:

Dienstleister

Dies ist der Anbieter des Webdienstes. Der Dienstanbieter implementiert den Dienst und stellt ihn im Internet zur Verfügung.

Serviceanforderer

Dies ist jeder Verbraucher des Webdienstes. Der Anforderer verwendet einen vorhandenen Webdienst, indem er eine Netzwerkverbindung öffnet und eine XML-Anforderung sendet.

Serviceregistrierung

Dies ist ein logisch zentralisiertes Verzeichnis von Diensten. Die Registrierung bietet einen zentralen Ort, an dem Entwickler neue Dienste veröffentlichen oder vorhandene finden können. Es dient daher als zentrale Clearingstelle für Unternehmen und deren Dienstleistungen.

Web Service Protocol Stack

Eine zweite Option zum Anzeigen der Webdienstarchitektur besteht darin, den aufkommenden Webdienstprotokollstapel zu untersuchen. Der Stapel befindet sich noch in der Entwicklung, hat jedoch derzeit vier Hauptschichten.

Servicetransport

Diese Schicht ist für den Transport von Nachrichten zwischen Anwendungen verantwortlich. Derzeit umfasst diese Schicht das HTTP (Hyper Text Transport Protocol), das SMTP (Simple Mail Transfer Protocol), das FTP (File Transfer Protocol) und neuere Protokolle wie BEEP (Blocks Extensible Exchange Protocol).

XML-Messaging

Diese Schicht ist für die Codierung von Nachrichten in einem gemeinsamen XML-Format verantwortlich, sodass Nachrichten an beiden Enden verstanden werden können. Derzeit enthält diese Schicht XML-RPC und SOAP.

Leistungsbeschreibung

Diese Schicht ist für die Beschreibung der öffentlichen Schnittstelle zu einem bestimmten Webdienst verantwortlich. Derzeit wird die Dienstbeschreibung über die WSDL (Web Service Description Language) verarbeitet.

Serviceerkennung

Diese Schicht ist für die Zentralisierung von Diensten in einer gemeinsamen Registrierung und die Bereitstellung einfacher Veröffentlichungs- / Suchfunktionen verantwortlich. Derzeit erfolgt die Serviceerkennung über die universelle Beschreibung, Erkennung und Integration (UDDI).

Während sich Webdienste weiterentwickeln, können zusätzliche Schichten hinzugefügt werden und jeder Schicht können zusätzliche Technologien hinzugefügt werden.

Im nächsten Kapitel werden die Komponenten von Webdiensten erläutert.

Einige Worte zum Servicetransport

Das Ende des Webdienstprotokollstapels ist der Diensttransport. Diese Schicht ist für den tatsächlichen Transport von XML-Nachrichten zwischen zwei Computern verantwortlich.

Hyper Text Transfer Protocol (HTTP)

Derzeit ist HTTP die beliebteste Option für den Servicetransport. HTTP ist einfach, stabil und weit verbreitet. Darüber hinaus erlauben die meisten Firewalls HTTP-Verkehr. Dadurch können sich XMLRPC- oder SOAP-Nachrichten als HTTP-Nachrichten tarnen. Dies ist gut, wenn Sie Remoteanwendungen integrieren möchten, wirft jedoch eine Reihe von Sicherheitsbedenken auf. Es gibt eine Reihe von Sicherheitsbedenken.

Blockiert das BEEP (Extensible Exchange Protocol)

Dies ist eine vielversprechende Alternative zu HTTP. BEEP ist ein neues Framework der Internet Engineering Task Force (IETF) zum Erstellen neuer Protokolle. BEEP ist direkt auf TCP geschichtet und enthält eine Reihe integrierter Funktionen, darunter ein anfängliches Handshake-Protokoll, Authentifizierung, Sicherheit und Fehlerbehandlung. Mit BEEP können neue Protokolle für eine Vielzahl von Anwendungen erstellt werden, darunter Instant Messaging, Dateiübertragung, Content-Syndication und Netzwerkverwaltung.

SOAP ist nicht an ein bestimmtes Transportprotokoll gebunden. Tatsächlich können Sie SOAP über HTTP, SMTP oder FTP verwenden. Eine vielversprechende Idee ist daher die Verwendung von SOAP over BEEP.

In den letzten Jahren haben sich drei Primärtechnologien als weltweite Standards herauskristallisiert, die den Kern der heutigen Webdiensttechnologie bilden. Diese Technologien werden unten diskutiert.

XML-RPC

Dies ist das einfachste XML-basierte Protokoll für den Informationsaustausch zwischen Computern.

XML-RPC ist ein einfaches Protokoll, das XML-Nachrichten zum Ausführen von RPCs verwendet.
Anforderungen werden in XML codiert und über HTTP POST gesendet.
XML-Antworten sind in den Hauptteil der HTTP-Antwort eingebettet.
XML-RPC ist plattformunabhängig.
XML-RPC ermöglicht die Kommunikation verschiedener Anwendungen.
Ein Java-Client kann XML-RPC mit einem Perl-Server sprechen.
XML-RPC ist der einfachste Weg, um mit Webdiensten zu beginnen.

Weitere Informationen zu XML-RPC finden Sie in unserem XML-RPC-Lernprogramm .

SEIFE

SOAP ist ein XML-basiertes Protokoll zum Informationsaustausch zwischen Computern.

SOAP ist ein Kommunikationsprotokoll.
SOAP dient zur Kommunikation zwischen Anwendungen.
SOAP ist ein Format zum Senden von Nachrichten.
SOAP dient zur Kommunikation über das Internet.
SOAP ist plattformunabhängig.
SOAP ist sprachunabhängig.
SOAP ist einfach und erweiterbar.
Mit SOAP können Sie Firewalls umgehen.
SOAP wird als W3C-Standard entwickelt.

Um mehr über SOAP zu erfahren, besuchen Sie unser SOAP-Tutorial .

WSDL

WSDL ist eine XML-basierte Sprache zur Beschreibung von Webdiensten und deren Zugriff.

WSDL steht für Web Services Description Language.
WSDL wurde gemeinsam von Microsoft und IBM entwickelt.
WSDL ist ein XML-basiertes Protokoll für den Informationsaustausch in dezentralen und verteilten Umgebungen.
WSDL ist das Standardformat zur Beschreibung eines Webdienstes.
Die WSDL-Definition beschreibt, wie auf einen Webdienst zugegriffen wird und welche Vorgänge ausgeführt werden.
WSDL ist eine Sprache zur Beschreibung der Schnittstelle zu XML-basierten Diensten.
WSDL ist ein wesentlicher Bestandteil von UDDI, einem XML-basierten weltweiten Unternehmensregister.
WSDL ist die Sprache, die UDDI verwendet.
WSDL wird als "wiz-langweilig" ausgesprochen und als "WSD-L" geschrieben.

Um mehr über WSDL zu erfahren, besuchen Sie unser WSDL-Tutorial .

UDDI

UDDI ist ein XML-basierter Standard zum Beschreiben, Veröffentlichen und Suchen von Webdiensten.

UDDI steht für Universal Description, Discovery und Integration.
UDDI ist eine Spezifikation für eine verteilte Registrierung von Webdiensten.
UDDI ist ein plattformunabhängiges, offenes Framework.
UDDI kann über SOAP, CORBA und Java RMI Protocol kommunizieren.
UDDI verwendet WSDL, um Schnittstellen zu Webdiensten zu beschreiben.
UDDI wird mit SOAP und WSDL als einer der drei Grundstandards für Webdienste angesehen.
UDDI ist eine offene Brancheninitiative, die es Unternehmen ermöglicht, sich gegenseitig zu entdecken und zu definieren, wie sie über das Internet interagieren.

Um mehr über UDDI zu erfahren, besuchen Sie unser UDDI-Tutorial .

Basierend auf der Webdienstarchitektur erstellen wir im Rahmen der Implementierung von Webdiensten die folgenden zwei Komponenten:

Dienstleister oder Herausgeber

Dies ist der Anbieter des Webdienstes. Der Dienstanbieter implementiert den Dienst und stellt ihn im Internet oder Intranet zur Verfügung.

Wir werden einen einfachen Webdienst mit .NET SDK schreiben und veröffentlichen.

Serviceanforderer oder Verbraucher

Dies ist jeder Verbraucher des Webdienstes. Der Anforderer verwendet einen vorhandenen Webdienst, indem er eine Netzwerkverbindung öffnet und eine XML-Anforderung sendet.

Wir werden auch zwei Webdienst-Anforderer schreiben: einen webbasierten Consumer (ASP.NET-Anwendung) und einen anderen Windows-anwendungsbasierten Consumer.

Im Folgenden finden Sie unser erstes Beispiel für einen Webdienst, der als Dienstanbieter arbeitet und zwei Methoden (add und SayHello) als Webdienste für Anwendungen bereitstellt. Dies ist eine Standardvorlage für einen Webdienst. .NET-Webdienste verwenden die Erweiterung .asmx. Beachten Sie, dass eine als Webdienst bereitgestellte Methode das WebMethod-Attribut hat. Speichern Sie diese Datei als FirstService.asmx im virtuellen IIS-Verzeichnis (wie in der Konfiguration von IIS erläutert; z. B. c: \ MyWebSerces).

FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>

using System;
using System.Web.Services;
using System.Xml.Serialization;

[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
   [WebMethod]
   public int Add(int a, int b) {
      return a + b;
   }

   [WebMethod]
   public String SayHello() {
      return "Hello World";
   }
}

Um einen Webdienst zu testen, muss er veröffentlicht werden. Ein Webdienst kann entweder im Intranet oder im Internet veröffentlicht werden. Wir werden diesen Webdienst auf IIS veröffentlichen, der auf einem lokalen Computer ausgeführt wird. Beginnen wir mit der Konfiguration des IIS.

Öffnen Sie Start → Einstellungen → Systemsteuerung → Verwaltung → Internet Services Manager.
Erweitern Sie die Standardwebsite und klicken Sie mit der rechten Maustaste darauf. Wählen Sie Neu & # rarr; Virtuelles Verzeichnis. Der Assistent zum Erstellen virtueller Verzeichnisse wird geöffnet. Weiter klicken.
Der Bildschirm "Virtual Directory Alias" wird geöffnet. Geben Sie den Namen des virtuellen Verzeichnisses ein. Zum Beispiel MyWebServices. Weiter klicken.
Der Bildschirm "Website-Inhaltsverzeichnis" wird geöffnet.
Geben Sie den Verzeichnispfadnamen für das virtuelle Verzeichnis ein. Zum Beispiel c: \ MyWebServices. Weiter klicken.
Der Bildschirm "Zugriffsberechtigung" wird geöffnet. Ändern Sie die Einstellungen gemäß Ihren Anforderungen. Lassen Sie uns die Standardeinstellungen für diese Übung beibehalten.
Klicken Sie auf die Schaltfläche Weiter. Damit ist die IIS-Konfiguration abgeschlossen.
Klicken Sie auf Fertig stellen, um die Konfiguration abzuschließen.

Kopieren Sie eine HTML-Datei (z. B. x.html) in das oben erstellte virtuelle Verzeichnis (C: \ MyWebServices), um zu testen, ob der IIS ordnungsgemäß konfiguriert wurde. Öffnen Sie nun den Internet Explorer und geben Sie einhttp://localhost/MyWebServices/x.html. Es sollte die Datei x.html öffnen.

Note- Wenn dies nicht funktioniert, versuchen Sie, den lokalen Host durch die IP-Adresse Ihres Computers zu ersetzen. Wenn es immer noch nicht funktioniert, überprüfen Sie, ob IIS ausgeführt wird. Möglicherweise müssen Sie den IIS und das virtuelle Verzeichnis neu konfigurieren.

Um diesen Webdienst zu testen, kopieren Sie FirstService.asmx in das oben erstellte virtuelle IIS-Verzeichnis (C: \ MyWebServices). Öffnen Sie den Webdienst in Internet Explorer (http: //localhost/MyWebServices/FirstService.asmx). Es sollte Ihre Webservice-Seite öffnen. Die Seite sollte Links zu zwei Methoden enthalten, die von unserer Anwendung als Webdienste verfügbar gemacht werden. Herzliche Glückwünsche! Sie haben Ihren ersten Webdienst geschrieben!

Testen des Webdienstes

Wie wir gerade gesehen haben, ist das Schreiben von Webdiensten in .NET Framework einfach. Das Schreiben von Webdienstkonsumenten ist auch im .NET Framework einfach. es ist jedoch etwas komplizierter. Wie bereits erwähnt, werden wir zwei Arten von Dienstkonsumenten schreiben, einen webbasierten und einen anderen anwendungsbasierten Windows-Konsumenten. Lassen Sie uns unseren ersten Web-Service-Konsumenten schreiben.

Webbasierter Service-Verbraucher

Schreiben Sie einen webbasierten Verbraucher wie unten angegeben. Nennen Sie es WebApp.aspx. Beachten Sie, dass es sich um eine ASP.NET-Anwendung handelt. Speichern Sie dies im virtuellen Verzeichnis des Webdienstes (c: \ MyWebServices \ WebApp.axpx).

Diese Anwendung verfügt über zwei Textfelder, mit denen vom Benutzer Zahlen hinzugefügt werden, die hinzugefügt werden sollen. Es hat eine Schaltfläche, Ausführen, die beim Klicken die Webdienste Add und SayHello abruft.

WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
   void runSrvice_Click(Object sender, EventArgs e) {
      FirstService mySvc = new FirstService();
      Label1.Text = mySvc.SayHello();
      Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text),  Int32.Parse(txtNum2.Text)).ToString();
   }
</script>

<html>
   <head> </head>
   
   <body>
      <form runat = "server">
         <p>
            <em>First Number to Add </em>:
            <asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4<  /asp:TextBox>
         </p>
			
         <p>
            <em>Second Number To Add </em>:
            <asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
         </p>
			
         <p>
            <strong><u>Web Service Result -</u></strong>
         </p>
			
         <p>
            <em>Hello world Service</em> :
            <asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
         </p>

         <p>
            <em>Add Service</em> :
            & <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
         </p>
			
         <p align = "left">
            <asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
         </p>
      </form>
   </body>
</html>

Nachdem der Consumer erstellt wurde, müssen wir einen Proxy für den zu konsumierenden Webdienst erstellen. Diese Arbeit wird von Visual Studio .NET für uns automatisch ausgeführt, wenn auf einen hinzugefügten Webdienst verwiesen wird. Hier sind die Schritte zu befolgen -

Erstellen Sie einen Proxy für den zu verwendenden Webdienst. Der Proxy wird mit dem im Lieferumfang des .NET SDK enthaltenen WSDL-Dienstprogramm erstellt. Dieses Dienstprogramm extrahiert Informationen aus dem Webdienst und erstellt einen Proxy. Der Proxy ist nur für einen bestimmten Webdienst gültig. Wenn Sie andere Webdienste verwenden müssen, müssen Sie auch einen Proxy für diesen Dienst erstellen. Visual Studio .NET erstellt automatisch einen Proxy für Sie, wenn die Webdienstreferenz hinzugefügt wird. Erstellen Sie einen Proxy für den Webdienst mit dem im Lieferumfang des .NET SDK enthaltenen WSDL-Dienstprogramm. Die Datei FirstSevice.cs wird im aktuellen Verzeichnis erstellt. Wir müssen es kompilieren, um FirstService.dll (Proxy) für den Webdienst zu erstellen.

c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs

Legen Sie den kompilierten Proxy im bin-Verzeichnis des virtuellen Verzeichnisses des Webdienstes ab (c: \ MyWebServices \ bin). Internet Information Services (IIS) sucht in diesem Verzeichnis nach dem Proxy.
Erstellen Sie den Service-Consumer auf die gleiche Weise, wie wir es bereits getan haben. Beachten Sie, dass ein Objekt des Webdienst-Proxys im Consumer instanziiert wird. Dieser Proxy kümmert sich um die Interaktion mit dem Dienst.
Geben Sie die URL des Verbrauchers in IE ein, um ihn zu testen (z. B. http: //localhost/MyWebServices/WebApp.aspx).

Windows Application-Based Web Service Consumer

Das Schreiben eines Windows-anwendungsbasierten Webdienstkonsumenten entspricht dem Schreiben einer anderen Windows-Anwendung. Sie müssen nur den Proxy erstellen (was wir bereits getan haben) und auf diesen Proxy verweisen, wenn Sie die Anwendung kompilieren. Im Folgenden finden Sie unsere Windows-Anwendung, die den Webdienst verwendet. Diese Anwendung erstellt ein Webdienstobjekt (natürlich einen Proxy) und ruft die Methoden SayHello und Add auf.

WinApp.cs

using System;
using System.IO;

namespace SvcConsumer {
   class SvcEater {
      public static void Main(String[] args) {
         FirstService mySvc = new FirstService();
         Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
         Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
      }
   }
}

Kompilieren Sie es mit c:\>csc /r:FirstService.dll WinApp.cs. Es wird WinApp.exe erstellt. Führen Sie es aus, um die Anwendung und den Webdienst zu testen.

Nun stellt sich die Frage: Wie können Sie sicher sein, dass diese Anwendung tatsächlich den Webdienst aufruft?

Es ist einfach zu testen. Stoppen Sie Ihren Webserver, damit der Webdienst nicht kontaktiert werden kann. Führen Sie nun die WinApp-Anwendung aus. Es wird eine Laufzeitausnahme ausgelöst. Starten Sie nun den Webserver erneut. Es sollte funktionieren.

Sicherheit ist für Webdienste von entscheidender Bedeutung. Weder XML-RPC- noch SOAP-Spezifikationen stellen jedoch explizite Sicherheits- oder Authentifizierungsanforderungen.

Es gibt drei spezifische Sicherheitsprobleme bei Webdiensten:

Confidentiality
Authentication
Netzwerksicherheit

Vertraulichkeit

Können wir sicherstellen, dass die Kommunikation vertraulich bleibt, wenn ein Client eine XML-Anfrage an einen Server sendet?

Antwort liegt hier -

XML-RPC und SOAP werden hauptsächlich über HTTP ausgeführt.
HTTP unterstützt Secure Sockets Layer (SSL).
Die Kommunikation kann über SSL verschlüsselt werden.
SSL ist eine bewährte Technologie und weit verbreitet.

Ein einzelner Webdienst kann aus einer Kette von Anwendungen bestehen. Beispielsweise kann ein großer Dienst die Dienste von drei anderen Anwendungen zusammenführen. In diesem Fall ist SSL nicht ausreichend. Die Nachrichten müssen an jedem Knoten entlang des Dienstpfads verschlüsselt werden, und jeder Knoten stellt ein potenziell schwaches Glied in der Kette dar. Derzeit gibt es keine vereinbarte Lösung für dieses Problem, aber eine vielversprechende Lösung ist der W3C XML Encryption Standard. Dieser Standard bietet ein Framework zum Ver- und Entschlüsseln ganzer XML-Dokumente oder nur Teile eines XML-Dokuments. Sie können es unter www.w3.org/Encryption überprüfen

Authentifizierung

Wie identifizieren wir den Benutzer, wenn ein Client eine Verbindung zu einem Webdienst herstellt? Ist der Benutzer berechtigt, den Dienst zu nutzen?

Die folgenden Optionen können in Betracht gezogen werden, es besteht jedoch kein klarer Konsens über ein starkes Authentifizierungsschema.

HTTP bietet eine integrierte Unterstützung für die Basic- und Digest-Authentifizierung. Daher können Dienste auf die gleiche Weise geschützt werden, wie HTML-Dokumente derzeit geschützt sind.
SOAP Digital Signature (SOAP-DSIG) nutzt die Kryptografie mit öffentlichen Schlüsseln, um SOAP-Nachrichten digital zu signieren. Es ermöglicht dem Client oder Server, die Identität der anderen Partei zu überprüfen. Überprüfen Sie es unter www.w3.org/TR/SOAP-dsig .
Die Organisation zur Weiterentwicklung strukturierter Informationsstandards (OASIS) arbeitet an der Security Assertion Markup Language (SAML).

Netzwerksicherheit

Derzeit gibt es keine einfache Antwort auf dieses Problem, und es wurde viel diskutiert. Wenn Sie wirklich SOAP- oder XML-RPC-Nachrichten herausfiltern möchten, besteht eine Möglichkeit darin, alle HTTP-POST-Anforderungen herauszufiltern, deren Inhaltstyp auf text / xml festgelegt ist.

Eine andere Alternative besteht darin, das SOAPAction-HTTP-Headerattribut zu filtern. Firewall-Anbieter entwickeln derzeit auch Tools, die explizit zum Filtern des Webdienstverkehrs entwickelt wurden.

In diesem Kapitel erhalten Sie einen Überblick über die neuesten Standards für Webdienste.

Transporte

BEEP, das Blocks Extensible Exchange Protocol (früher als BXXP bezeichnet), ist ein Framework zum Erstellen von Anwendungsprotokollen. Es wurde von der IETF standardisiert und macht für Internetprotokolle das, was XML für Daten getan hat.

Blockiert das BEEP (Extensible Exchange Protocol)

Messaging

Diese Messaging-Standards und -Spezifikationen sollen einen Rahmen für den Informationsaustausch in einer dezentralen, verteilten Umgebung bieten.

SOAP 1.1 (Hinweis)
SOAP 1.2 (Spezifikation)
Web Services Attachments Profile 1.0
Optimierungsmechanismus für die SOAP-Nachrichtenübertragung

Beschreibung und Entdeckung

Webdienste sind nur dann sinnvoll, wenn potenzielle Benutzer Informationen finden, die ausreichen, um ihre Ausführung zu ermöglichen. Der Schwerpunkt dieser Spezifikationen und Standards liegt auf der Definition einer Reihe von Diensten, die die Beschreibung und Ermittlung von Unternehmen, Organisationen und anderen Webdienstanbietern unterstützen. die von ihnen zur Verfügung gestellten Webdienste; und die technischen Schnittstellen, die für den Zugriff auf diese Dienste verwendet werden können.

UDDI 3.0
WSDL 1.1 (Hinweis)
WSDL 1.2 (Arbeitsentwurf)
WSDL 2.0 (Arbeitsgruppe)

Sicherheit

Mithilfe dieser Sicherheitsspezifikationen können Anwendungen eine sichere Kommunikation durchführen, die für das allgemeine Webdienst-Framework ausgelegt ist.

Web Services Security 1.0
Security Assertion Markup Language (SAML)

Management

Die Verwaltbarkeit von Webdiensten ist definiert als eine Reihe von Funktionen zum Ermitteln der Existenz, Verfügbarkeit, des Zustands, der Leistung, der Nutzung sowie der Steuerung und Konfiguration eines Webdienstes innerhalb der Webdienstarchitektur. Da Webdienste allgegenwärtig und für den Geschäftsbetrieb von entscheidender Bedeutung sind, ist die Verwaltung und Implementierung dieser Dienste für den Erfolg des Geschäftsbetriebs von entscheidender Bedeutung.

Verteilte Verwaltung von Webdiensten

In diesem Tutorial haben Sie gelernt, wie Sie Webdienste verwenden. Ein Webdienst enthält jedoch auch Komponenten wie WSDL, UDDI und SOAP, die dazu beitragen, ihn aktiv zu machen. Der nächste Schritt ist das Erlernen von WSDL, UDDI und SOAP.

WSDL

WSDL ist eine XML-basierte Sprache zur Beschreibung von Webdiensten und deren Zugriff.

WSDL beschreibt einen Webdienst zusammen mit dem Nachrichtenformat und den Protokolldetails für den Webdienst.

Um mehr über WSDL zu erfahren, besuchen Sie unser WSDL-Tutorial .

UDDI

UDDI ist ein XML-basierter Standard zum Beschreiben, Veröffentlichen und Suchen von Webdiensten.

Um mehr über UDDI zu erfahren, besuchen Sie unser UDDI-Tutorial .

SEIFE

SOAP ist ein einfaches XML-basiertes Protokoll, mit dem Anwendungen Informationen über HTTP austauschen können.

Um mehr über SOAP zu erfahren, besuchen Sie unser SOAP-Tutorial .