WebService-bezogene Konzepte

1. Vorwort

Jeder hat mehr oder weniger von WebService (Webdienst) gehört. Viele Computerzeitschriften, Bücher und Websites haben die WebService-Technologie erwähnt und beworben Komponenten. Aber wir müssen zugeben, dass WebService wirklich eine aufstrebende und vielversprechende Technologie ist. Was genau ist WebService? Wann sollte es verwendet werden?

Die aktuelle Anwendungsentwicklung zeigt nach und nach zwei völlig unterschiedliche Tendenzen: Die eine sind browserbasierte Thin-Client-Anwendungen und die andere sind browserbasierte Rich-Client-Anwendungen (RIA). Natürlich ist die letztere Technologie relativ modischer ( (z. B. die mittlerweile beliebte Html5-Technologie), hier sprechen wir hauptsächlich über Ersteres.

Browserbasierte Thin-Client-Anwendungen nicht, weil Thin-Clients eine bessere Benutzeroberfläche bieten, sondern weil sie die hohen Kosten für die Veröffentlichung von Desktop-Anwendungen vermeiden. Das Veröffentlichen von Desktopanwendungen ist teuer, teilweise aufgrund von Installations- und Konfigurationsproblemen der Anwendung und teilweise aufgrund von Kommunikationsproblemen zwischen Client und Server. Herkömmliche Windows-Rich-Client-Anwendungen verwenden DCOM, um mit dem Server zu kommunizieren und Remoteobjekte aufzurufen. DCOM so zu konfigurieren, dass es in einem großen Netzwerk ordnungsgemäß funktioniert, wird eine äußerst anspruchsvolle Aufgabe sein und für viele IT-Ingenieure auch ein Albtraum sein. Tatsächlich würden viele IT-Ingenieure lieber die durch den Browser verursachten Funktionseinschränkungen in Kauf nehmen, als einen DCOM im LAN auszuführen. In Bezug auf das Kommunikationsproblem zwischen Client und Server besteht eine perfekte Lösung darin, das HTTP-Protokoll für die Kommunikation zu verwenden. Dies liegt daran, dass jeder Computer, auf dem ein Webbrowser ausgeführt wird, das HTTP-Protokoll verwendet. Gleichzeitig sind viele aktuelle Firewalls auch so konfiguriert, dass sie nur HTTP-Verbindungen zulassen. Ein weiteres Problem, mit dem viele kommerzielle Programme konfrontiert sind, ist die Interoperabilität mit anderen Programmen. Wenn alle Anwendungen in der Sprache COM oder .NET geschrieben wären und alle auf der Windows-Plattform laufen würden, wäre die Welt friedlich. Tatsächlich werden die meisten Geschäftsdaten jedoch immer noch in Form von nicht relationalen Dateien (VSAM) auf Mainframes gespeichert und von in COBOL-Sprache geschriebenen Mainframe-Programmen abgerufen. Darüber hinaus werden viele kommerzielle Programme weiterhin in C++, Java, Visual Basic und verschiedenen anderen Sprachen geschrieben. Heutzutage müssen alle bis auf die einfachsten Programme Anwendungen integrieren und Daten mit ihnen austauschen, die auf anderen heterogenen Plattformen ausgeführt werden. Solche Aufgaben werden normalerweise durch spezielle Methoden wie Dateiübertragung und -analyse, Nachrichtenwarteschlangen und APIs erledigt, die nur für bestimmte Situationen geeignet sind, wie beispielsweise Advanced Program to Program Communication (APPC) von IBM. Bisher gab es keinen Anwendungskommunikationsstandard, der unabhängig von Plattform, Komponentenmodell und Programmiersprache war. Nur über Web Service können Client und Server frei über HTTP kommunizieren, unabhängig von der Plattform und Programmiersprache der beiden Programme.

2. Was ist WebService?

Kurz gesagt: WebService ist eine Remote-Calling-Technologie für alle Programmiersprachen und Betriebssystemplattformen.

Die sogenannte Cross-Programming-Sprache und Cross-Operating-Plattform bedeutet, dass das Serverprogramm in Java geschrieben ist und das Client-Programm in anderen Programmiersprachen geschrieben werden kann und umgekehrt! Betriebssystemübergreifende Plattform bedeutet, dass das Serverprogramm und das Clientprogramm auf unterschiedlichen Betriebssystemen laufen können.

Der sogenannte Remote-Aufruf ist eine Methode, mit der ein Programm auf einem Computer A ein Objekt auf einem anderen Computer B aufrufen kann. Zum Beispiel das von UnionPay für das Einkaufszentrum bereitgestellte POS-Kartendurchziehsystem und das POS Automatenüberweisung im Einkaufszentrum Der Code zum Aufrufen der Überweisungsmethode läuft tatsächlich auf dem Bankserver. Ein weiteres Beispiel: Amazon, das Wettervorhersagesystem, Taobao, Xiaonei.com, Baidu usw. stellen ihre Systemdienste in Form von Webservice-Diensten zur Verfügung, sodass Websites und Programme Dritter diese Dienstfunktionen aufrufen und so ihren Marktanteil vergrößern können Die Effizienz ihrer eigenen Systeme ist in einem größeren Konzept die sogenannte SOA-Anwendung.

Tatsächlich kann WebService aus mehreren Blickwinkeln verstanden werden. Oberflächlich betrachtet ist WebService eine Anwendung, die eine API für die Außenwelt bereitstellt, die über das Web aufgerufen werden kann Aufrufen des Webs mithilfe von Programmiermethoden. Wir nennen die Anwendung, die diesen WebService aufruft, den Client, und die Anwendung, die diesen WebService bereitstellt, nennen wir den Server. Aus einer tieferen Perspektive ist WebService eine neue Plattform zum Erstellen interoperabler verteilter Anwendungen. Es handelt sich um eine Plattform und eine Reihe von Standards. Es definiert, wie Anwendungen im Web Interoperabilität erreichen können. Sie können Webdienste in jeder gewünschten Sprache und auf jeder gewünschten Plattform schreiben, solange wir diese Dienste über den Webdienststandard abfragen und darauf zugreifen können.

Die WebService-Plattform erfordert eine Reihe von Protokollen, um die Erstellung verteilter Anwendungen zu erreichen. Jede Plattform verfügt über eine eigene Datendarstellungsmethode und ein eigenes Typsystem. Um Interoperabilität zu erreichen, muss die WebService-Plattform ein Standardtypsystem für die Kommunikation verschiedener Typsysteme in verschiedenen Plattformen, Programmiersprachen und Komponentenmodellen bereitstellen. Die Webdienstplattform muss einen Standard zur Beschreibung des Webdiensts bereitstellen, damit Kunden genügend Informationen erhalten, um den Webdienst aufzurufen. Schließlich müssen wir eine Möglichkeit haben, Remote-Aufrufe an diesen Webdienst durchzuführen. Bei dieser Methode handelt es sich tatsächlich um ein Remote Procedure Call Protocol (RPC). Um Interoperabilität zu erreichen, muss dieses RPC-Protokoll außerdem plattform- und programmiersprachenunabhängig sein.

3. WebService-Plattformtechnologie

XML+XSD, SOAP und WSDL sind die drei Haupttechnologien, aus denen die WebService-Plattform besteht.

3.1, XML + Was ist das Rückgabeergebnis des Objekts). XML ist das Format zur Darstellung von Daten in der WebService-Plattform. Der Hauptvorteil von XML besteht nicht nur darin, dass es einfach zu erstellen und zu analysieren ist, sondern auch darin, dass es sowohl plattform- als auch herstellerunabhängig ist. Bedeutungslosigkeit ist wichtiger als technische Überlegenheit: Softwareanbieter werden sich nicht für eine Technologie entscheiden, die von einem Konkurrenten erfunden wurde.

XML löst das Problem der Datendarstellung, definiert jedoch keinen Satz Standarddatentypen, geschweige denn, wie dieser Satz Datentypen erweitert werden kann. Was genau stellen beispielsweise ganze Zahlen dar? 16-Bit, 32-Bit, 64-Bit? Diese Details sind wichtig, um Interoperabilität zu erreichen. XML Schema (XSD) ist eine Reihe von Standards, die speziell dieses Problem lösen. Es definiert einen Standardsatz von Datentypen und stellt eine Sprache zur Erweiterung dieses Satzes von Datentypen bereit. Die WebService-Plattform verwendet XSD als Datentypsystem. Wenn Sie eine bestimmte Sprache (z. B. VB.NET oder C#) verwenden, um einen Webdienst zu erstellen, müssen alle von Ihnen verwendeten Datentypen in XSD-Typen konvertiert werden, um dem WebService-Standard zu entsprechen. Das von Ihnen verwendete Tool hat diese Konvertierung möglicherweise automatisch für Sie durchgeführt, Sie werden den Konvertierungsprozess jedoch höchstwahrscheinlich an Ihre Bedürfnisse anpassen.

3.2, SOAP

Wenn WebService Anforderungen über das HTTP-Protokoll sendet und Ergebnisse empfängt, werden der Anforderungsinhalt und der gesendete Ergebnisinhalt im XML-Format gekapselt und einige spezifische HTTP-Nachrichtenheader werden zu Describe hinzugefügt Das Inhaltsformat der HTTP-Nachricht ist das SOAP-Protokoll. SOAP bietet Standard-RPC-Methoden zum Aufrufen von Webdiensten.

SOAP-Protokoll = HTTP-Protokoll + XML-Datenformat

Das SOAP-Protokoll definiert das Format der SOAP-Nachricht. Das SOAP-Protokoll basiert ebenfalls auf XML und XSD . XML ist eine SOAP-Datenkodierungsmethode. Um eine Analogie zu ziehen: HTTP ist eine gewöhnliche Autobahn, XML ist der grüne Isolationsgürtel in der Mitte und Leitplanken auf beiden Seiten, und SOAP ist eine Autobahn, die durch das Hinzufügen von Isolationsgürteln und Leitplanken von einer gewöhnlichen Autobahn umgewandelt wurde.

3.3, WSDL

Genau wie wenn wir in ein Geschäft gehen, um etwas zu kaufen, müssen wir zuerst wissen, was im Geschäft verfügbar ist, und dann einen Kauf tätigen Werbeplakate aufhängen. Dasselbe gilt für WebService-Dienste. Um einen WebService-Dienst aufzurufen, muss der WebService-Client zunächst wissen, wo sich die Adresse des Dienstes befindet und welche Methoden im Dienst aufgerufen werden können. Daher muss der WebService-Server zunächst seine Homepage über eine WSDL beschreiben Welche Dienste können extern aufgerufen werden, was ist der Dienst (was sind die Methoden im Dienst, welche Parameter werden von der Methode akzeptiert, was ist der Rückgabewert), welche URL-Adresse wird zur Darstellung der Netzwerkadresse des Dienstes verwendet , und wie heißt der Dienst?

WSDL (Web Services Description Language) ist eine solche XML-basierte Sprache, die zur Beschreibung von Webdiensten und deren Funktionen, Parametern und Rückgabewerten verwendet wird. Es handelt sich um ein Standardformat, das sowohl der WebService-Client als auch der Server verstehen können. Da WSDL auf XML basiert, ist es sowohl maschinenlesbar als auch menschenlesbar, was einen großen Vorteil darstellt. Einige der neuesten Entwicklungstools können nicht nur WSDL-Dokumente basierend auf Ihrem Webdienst generieren, sondern auch WSDL-Dokumente importieren, um Proxy-Klassencode zu generieren, der den entsprechenden WebService aufruft.

Die WSDL-Datei wird auf dem Webserver gespeichert und kann über eine URL-Adresse aufgerufen werden. Bevor der Client einen WebService-Dienst aufruft, muss er die Adresse der WSDL-Datei des Dienstes kennen. Der WebService-Dienstanbieter kann seine WSDL-Dateiadresse auf zwei Arten offenlegen: 1. Registrieren Sie sich beim UDDI-Server, damit sie gefunden werden kann. 2. Teilen Sie sie dem Client-Anrufer direkt mit.

4. WebService-Entwicklung

Die WebService-Entwicklung kann in zwei Aspekte unterteilt werden: serverseitige Entwicklung und clientseitige Entwicklung

Serverseitige Entwicklung

Das Unternehmen stellt die Geschäftsmethoden des internen Systems als WebService-Dienste bereit, damit entfernte Kooperationseinheiten und Einzelpersonen sie aufrufen können. (Mit Hilfe einiger WebService-Frameworks können Sie Ihre Geschäftsobjekte problemlos in WebService-Diensten veröffentlichen. Zu den typischen WebService-Frameworks in Java gehören: axis, xfire, cxf usw. Java ee-Server unterstützen normalerweise auch die Veröffentlichung von WebService-Diensten wie JBoss.)

4.2. Client-Entwicklung

Aufruf von WebService-Diensten, die von anderen veröffentlicht wurden. Die meisten Leute beschäftigen sich mit der Entwicklung in diesem Bereich, zum Beispiel mit dem Aufruf von Wettervorhersage-WebService-Diensten. (Verwenden Sie die Tools des Herstellers wie WSDL2Java, um statisch aufgerufenen Proxy-Klassencode zu generieren; verwenden Sie die vom Hersteller bereitgestellte Client-Programmier-API-Klasse; verwenden Sie das frühe Standard-Jax-RPC-Entwicklungskit von SUN; verwenden Sie das neueste Standard-Jax-WS-Entwicklungskit von SUN. Natürlich SUN wurde von ORACLE erworben)

Das Funktionsprinzip des WebService-Aufrufs

Für den Client übergeben wir die URL-Adresse der WSDL-Datei an diese verschiedenen WebService-Client-APIs die zugrunde liegenden Proxy-Klassen Wenn ich diese Proxys aufrufe, kann ich auf den Webservice-Dienst zugreifen. Die Proxy-Klasse wandelt den Methodenaufruf des Clients in Anforderungsdaten im SOAP-Format um, sendet sie über das HTTP-Protokoll aus und gibt die empfangenen SOAP-Daten in einen Rückgabewert zurück. Für den Server ist das Wesentliche verschiedener WebService-Frameworks ein großes Servlet. Wenn der Remote-Aufruf-Client ihm Anforderungsdaten im SOAP-Format über das HTTP-Protokoll sendet, analysiert er die Daten und weiß, welche Java-Klasse welche Methode aufrufen soll Erstellen Sie dieses Objekt, rufen Sie seine Methode auf, packen Sie dann das von der Methode zurückgegebene Ergebnis in Daten im SOAP-Format und senden Sie es über eine HTTP-Antwortnachricht an den Client zurück.

5. Anwendbare Anlässe

1. Firewall-übergreifende Kommunikation

Wenn die Anwendung Tausende von Benutzern hat und auf der ganzen Welt verteilt ist, ist die Beziehung zwischen dem Client und dem Server Die Kommunikation zwischen ihnen wird ein heikles Thema sein. Denn zwischen Client und Server befindet sich in der Regel eine Firewall oder ein Proxyserver. In diesem Fall ist die Verwendung von DCOM nicht so einfach und es ist normalerweise nicht bequem, das Clientprogramm für eine so große Anzahl von Benutzern zu veröffentlichen. Der traditionelle Ansatz besteht darin, den Browser als Client zu verwenden, viele ASP-Seiten zu schreiben und die mittlere Ebene der Anwendung dem Endbenutzer zugänglich zu machen. Dies hat zur Folge, dass die Entwicklung schwierig ist und das Programm nur schwer aufrechtzuerhalten ist. Wenn die Middle-Tier-Komponente durch WebService ersetzt wird, kann die Middle-Tier-Komponente direkt über die Benutzeroberfläche aufgerufen werden. Nach der Erfahrung der meisten Menschen kann die Verwendung der WebService-Struktur in einer Anwendung mit viel Interaktion zwischen der Benutzeroberfläche und der mittleren Schicht 20 % der Entwicklungszeit einsparen, die für die Programmierung der Benutzeroberfläche aufgewendet wird.

2. Anwendungsintegration

Anwendungsentwickler auf Unternehmensebene wissen, dass Unternehmen häufig verschiedene Programme integrieren, die in verschiedenen Sprachen geschrieben sind und auf verschiedenen Plattformen ausgeführt werden Entwicklungsaufwand. Anwendungen müssen häufig Daten von Programmen abrufen, die auf dem IBM-Mainframe ausgeführt werden, oder Daten an Mainframe- oder UNIX-Anwendungen senden. Selbst auf derselben Plattform muss häufig verschiedene Software verschiedener Softwareanbieter integriert werden. Durch WebService können Anwendungen mit unterschiedlichen Strukturen einfach integriert werden.

3. B2B-Integration

Durch die Verwendung von WebService zur Integration von Anwendungen kann die unternehmensinterne Geschäftsabwicklung stärker automatisiert werden. Aber was passiert, wenn Transaktionen sich über Lieferanten und Kunden erstrecken und die Grenzen des Unternehmens überschreiten? Die unternehmensübergreifende Integration von Geschäftstransaktionen wird oft als B2B-Integration bezeichnet. WebService ist der Schlüssel zur erfolgreichen B2B-Integration. Über WebService können Unternehmen wichtige Geschäftsanwendungen bestimmten Lieferanten und Kunden „zugänglich machen“. Durch die „Offenlegung“ des elektronischen Bestellsystems und des elektronischen Rechnungssystems können Kunden beispielsweise Bestellungen elektronisch senden und Lieferanten können Rohstoffeinkaufsrechnungen elektronisch senden. Natürlich ist das kein neues Konzept, EDI (Electronic Document Interchange) gibt es schon seit langem. Die Implementierung von WebService ist jedoch viel einfacher als bei EDI. WebService läuft im Internet und kann überall auf der Welt problemlos implementiert werden, sodass die Betriebskosten relativ niedrig sind. Allerdings ist WebService keine Komplettlösung für den Dokumentenaustausch oder die B2B-Integration wie EDI. WebService ist nur ein wichtiger Teil der B2B-Integration, und viele andere Teile sind erforderlich, um die Integration zu erreichen.

Der größte Vorteil der Verwendung von WebService zur Implementierung der B2B-Integration besteht darin, dass Interoperabilität problemlos erreicht werden kann. Solange die Geschäftslogik „offengelegt“ ist und zu einem WebService wird, kann jeder designierte Partner diese Geschäftslogik aufrufen, unabhängig davon, auf welcher Plattform sein System läuft oder welche Entwicklungssprache er verwendet. Dies reduziert den Zeit- und Kostenaufwand für die B2B-Integration erheblich und ermöglicht vielen kleinen und mittleren Unternehmen, die sich EDI nicht leisten können, die B2B-Integration.

4. Wiederverwendung von Software und Daten

Die Wiederverwendung von Software ist ein großes Thema, es gibt viele Formen der Wiederverwendung und der Grad der Wiederverwendung variiert. Die einfachste Form ist die Wiederverwendung von Quellcodemodulen oder Klassenebene, und eine Form ist die Wiederverwendung von binären Formularkomponenten. WebService-Anwendungen können Standardmethoden verwenden, um Funktionen und Daten für die Verwendung durch andere Anwendungen „offenzulegen“, um eine Wiederverwendung auf Geschäftsebene zu erreichen.

6. Nicht anwendbare Fälle

1. Eigenständige Anwendungen

Derzeit nutzen Unternehmen und Privatpersonen immer noch viele Desktop-Anwendungen. Einige von ihnen müssen lediglich mit anderen Programmen auf der Maschine kommunizieren. In diesem Fall ist es am besten, WebService nicht zu verwenden, sondern einfach die lokale API zu verwenden. COM ist für die Arbeit in dieser Situation ideal, da es klein und schnell ist. Das Gleiche gilt für Serversoftware, die auf demselben Server läuft. Es ist am besten, COM oder andere lokale APIs direkt zu verwenden, um Aufrufe zwischen Anwendungen durchzuführen. Natürlich kann in diesen Situationen auch WebService eingesetzt werden, aber das verbraucht nicht nur zu viel, sondern bringt auch keine Vorteile.

2. Isomorphe Anwendungen im LAN

In vielen Anwendungen werden alle Programme mit VB oder VC entwickelt, alle nutzen COM unter der Windows-Plattform und laufen alle im selben LAN. Beispielsweise gibt es zwei Serveranwendungen, die miteinander kommunizieren müssen, oder es gibt ein Win32- oder WinForm-Clientprogramm, das eine Verbindung zu einem anderen Serverprogramm im LAN herstellen möchte. In diesen Programmen ist die Verwendung von DCOM wesentlich effizienter als SOAP/HTTP. Wenn ein .NET-Programm eine Verbindung zu einem anderen .NET-Programm im LAN herstellen möchte, sollte ebenfalls .NET-Remoting verwendet werden. Interessanterweise können Sie in .NETremoting auch angeben, dass SOAP/HTTP zum Durchführen von WebService-Aufrufen verwendet werden soll. Es ist jedoch besser, RPC-Aufrufe direkt über TCP durchzuführen, was wesentlich effizienter ist.

Weitere Artikel zu WebService-Konzepten finden Sie auf der chinesischen PHP-Website!