Web Service ist eine plattformunabhängige, niedrig gekoppelte, eigenständige, programmierbare webbasierte Anwendung, die den offenen XML-Standard (eine Teilmenge der Standard Universal Markup Language) verwenden kann. Entdecken, koordinieren und konfigurieren Sie diese Anwendungen, um verteilte, interoperable Anwendungen zu entwickeln.
Web-Service-Technologie ermöglicht es verschiedenen Anwendungen, die auf unterschiedlichen Maschinen laufen, Daten auszutauschen oder miteinander zu integrieren, ohne dass zusätzliche, spezialisierte Software oder Hardware von Drittanbietern erforderlich ist. Nach Web-Service-Spezifikationen implementierte Anwendungen können Daten untereinander austauschen, unabhängig von der verwendeten Sprache, Plattform oder dem internen Protokoll. Web Service ist ein eigenständiges, selbstbeschreibendes Modul, das im Netzwerk verwendet werden kann und bestimmte Geschäftsfunktionen ausführen kann. Webdienste lassen sich auch einfach bereitstellen, da sie auf einigen herkömmlichen Industriestandards und vorhandenen Technologien wie XML und HTTP basieren, einer Teilmenge der standardmäßigen universellen Auszeichnungssprache. Web Services reduzieren die Kosten für Anwendungsschnittstellen. Webdienste bieten einen gemeinsamen Mechanismus zur Integration von Geschäftsprozessen in einem Unternehmen oder sogar zwischen mehreren Organisationen.
Um die Erstellung verteilter Anwendungen zu realisieren, muss die Webservice-Plattform eine Reihe von Protokollen übernehmen. Jede Plattform verfügt über eine eigene Datendarstellungsmethode und ein eigenes Typsystem. Um Interoperabilität zu erreichen, muss die Web-Service-Plattform ein Standardtypsystem für die Kommunikation verschiedener Typsysteme in verschiedenen Plattformen, Programmiersprachen und Komponentenmodellen bereitstellen. Diese Protokolle sind:
XML ist eine Auszeichnungssprache, die zum Markieren elektronischer Dokumente verwendet wird, um sie strukturell zu gestalten, und das Grundformat für die Darstellung von Daten in der Web-Service-Plattform. Neben der einfachen Erstellung und Analyse besteht der Hauptvorteil von XML darin, dass es sowohl plattform- als auch herstellerunabhängig ist. XML folgt den grammatikalischen Anforderungen der W3C-Spezifikation, trennt Form und Inhalt, verfügt über eine gute Selbstbeschreibung, ist leicht zu erweitern und verfügt über eine umfangreiche Entwicklungsbibliothek von Drittanbietern, wodurch es sich sehr gut für die Informationsübertragung zwischen Systemen unterschiedlicher Architektur eignet. Mit der zunehmenden Verbreitung von XML hat sich XML aufgrund seiner Vorteile in vielen Anwendungsszenarien zum De-facto-Standard für den Datenaustausch entwickelt. XML wurde vom World Wide Web Consortium (W3C) erstellt. Das vom W3C entwickelte XML SchemaXSD definiert eine Reihe von Standarddatentypen und stellt eine Sprache zur Erweiterung dieser Datentypen bereit.
Die Web-Service-Plattform verwendet XSD als Datentypsystem. Wenn Sie eine Sprache wie VB. NET oder C# verwenden, um einen Webdienst zu erstellen, müssen alle von Ihnen verwendeten Datentypen in XSD-Typen konvertiert werden, um dem Webdienststandard zu entsprechen. Wenn Sie möchten, dass es zwischen verschiedenen Organisationen auf unterschiedlichen Plattformen und unterschiedlicher Software bereitgestellt wird, müssen Sie es auch in etwas verpacken. Dieses Ding ist ein Protokoll, wie SOAP.
SOAP ist ein einfaches Protokoll zum Austausch von XML-codierten Informationen (eine Teilmenge der Standard Universal Markup Language). zwischen Benutzern ist eine gängige Implementierungsform von Webdiensten. Es besteht aus drei Hauptaspekten: Der XML-Umschlag definiert einen Rahmen zur Beschreibung des Informationsinhalts und zur Verarbeitung des Inhalts, Regeln für die Kodierung von Programmobjekten in XML-Objekte und Konventionen für die Ausführung von Remote Procedure Calls (RPC). SOAP kann über jedes andere Transportprotokoll ausgeführt werden.
SOAP definiert ein auf dem HTTP-Protokoll basierendes Framework, das beschreibt, was in der Nachricht enthalten ist, wer sie gesendet hat, wer sie annehmen und verarbeiten soll und wie sie verarbeitet werden soll. Es standardisiert Datenformate durch die Definition von SOAP-Umschlägen (Envelops), kapselt XML-Daten in Umschlägen für den Informationsaustausch und ermöglicht die Interoperabilität zwischen heterogenen Systemen.
Web Service hofft zu erkennen, dass verschiedene Systeme sich durch „Software-Software-Dialog“ gegenseitig anrufen können, um die Inkompatibilität zwischen Softwareanwendungen, Websites und verschiedenen Geräten zu beseitigen und das Ziel einer „nahtlosen Integration basierend auf dem Web“ zu erreichen.
Web Service Description Language WSDL ist ein formales Beschreibungsdokument, das auf maschinenlesbare Weise bereitgestellt wird und auf XML (einer Teilmenge der Standard Universal Markup Language) basiert. Es wird zur Beschreibung von Webdiensten und ihren Funktionen verwendet . , Parameter und Rückgabewerte. Da WSDL auf XML basiert, ist es sowohl maschinenlesbar als auch menschenlesbar.
Der Zweck von UDDI besteht darin, Standards für den E-Commerce zu etablieren; Unternehmen können den von Ihnen bereitgestellten Webdienst registrieren, damit andere Unternehmen die Implementierungsstandards des Zugriffsprotokolls entdecken können.
Der Webdienst selbst implementiert tatsächlich die Kommunikation zwischen Anwendungen. Wir können die Kommunikation zwischen Anwendungen auf zwei Arten erreichen: Remote Procedure Calls (RPC) und Message Passing. Bei der Verwendung von RPC besteht das Konzept eines Clients darin, eine Remote-Prozedur auf dem Server aufzurufen, normalerweise durch Instanziieren eines Remote-Objekts und Aufrufen seiner Methoden und Eigenschaften. Das RPC-System versucht, eine Art Positionstransparenz zu erreichen: Der Server legt die Schnittstelle des Remote-Objekts offen und der Client verhält sich so, als ob die Schnittstelle dieser Objekte lokal verwendet würde. Dadurch werden die zugrunde liegenden Informationen ausgeblendet und der Client benötigt sie nicht alle. Wissen Sie, auf welcher Maschine sich das Objekt befindet.
3. Anwendungsszenarien und Nachteile von Webservices ein heikles Problem 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 Schicht 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, wodurch der Schritt der Erstellung einer ASP-Seite entfällt. Um WebService aufzurufen, können Sie direkt einen SOAP-Client wie MicrosoftSOAP Toolkit oder .NET verwenden oder einen selbst entwickelten SOAP-Client verwenden und diesen dann mit der Anwendung verbinden. Dies verkürzt nicht nur den Entwicklungszyklus, sondern reduziert auch die Codekomplexität und verbessert die Wartbarkeit der Anwendung. Die Anwendung muss nicht bei jedem Aufruf einer Middle-Tier-Komponente zur entsprechenden „Ergebnisseite“ navigieren. Entwickler von Unternehmensanwendungen wissen alle, dass Unternehmen oft verschiedene Programme integrieren müssen, die in verschiedenen Sprachen geschrieben sind und auf verschiedenen Plattformen laufen, und dass diese Integration viel Entwicklungsaufwand kosten wird. Anwendungen müssen häufig Daten von Programmen abrufen, die auf dem IBM-Mainframe ausgeführt werden, oder Daten an den Mainframe oder UNIX-Anwendungen senden. Oftmals müssen verschiedene Softwareprogramme auf derselben Plattform integriert werden, auch wenn diese von unterschiedlichen Softwareanbietern stammen. Andere Anwendungen können Standardmethoden verwenden, um auf die über den WebService bereitgestellten Funktionen und Daten zuzugreifen.Stärke 2: Anwendungsintegration
Funktion 3: B2B-IntegrationDurch 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.
Wiederverwendung von Software und Daten„Die Wiederverwendung von Software ist ein bedeutendes Thema mit vielen Formen und unterschiedlichem Umsetzungsgrad.“ Die einfachste Form ist die Wiederverwendung von Quellcodemodulen oder Klassenebene, die andere Form ist die Wiederverwendung von binären Formularkomponenten.
Während der Wiederverwendung von Code kann webService auch den Code hinter den Daten wiederverwenden. Mit WebService müssen Sie nicht mehr wie bisher Softwarekomponenten von einem Drittanbieter kaufen und installieren und diese Komponenten dann aus der Anwendung aufrufen, sondern nur noch den Remote-WebService aufrufen. Um beispielsweise die vom Benutzer in der Anwendung eingegebene Adresse zu bestätigen, müssen Sie die Adresse nur direkt an den entsprechenden WebService senden. Dieser WebService hilft Ihnen, die Straße, die Stadt, die Provinz, die Postleitzahl und andere Informationen zur Bestätigung zu überprüfen Adresse. Liegt sie im entsprechenden Postleitzahlgebiet? Der Anbieter von WebService kann den Dienst auf Basis der Zeit oder der Anzahl der Nutzungen abrechnen. Es ist unmöglich, einen solchen Dienst durch Wiederverwendung von Komponenten zu implementieren. In diesem Fall müssen Sie eine Datenbank herunterladen und installieren, die Informationen wie Straßenadressen, Städte, Provinzen und Postleitzahlen enthält. Diese Datenbank kann nicht in Echtzeit aktualisiert werden.
Eine weitere Situation der Software-Wiederverwendung besteht darin, die Funktionen mehrerer Anwendungen zu integrieren. Sie möchten beispielsweise eine Portalanwendung im LAN erstellen, damit Benutzer FedEx-Pakete überprüfen, die Börsenbedingungen überprüfen, ihre eigenen Zeitpläne verwalten und Kinokarten online kaufen können. Mittlerweile gibt es viele Anwendungsanbieter im Web, die alle diese Funktionen in ihren Anwendungen implementiert haben. Sobald sie diese Funktionen über WebService „offengelegt“ haben, können sie alle diese Funktionen problemlos in Ihre Portal-Site integrieren und den Benutzern eine einheitliche und benutzerfreundliche Oberfläche bieten.
Zukünftig werden viele Anwendungen WebService verwenden, um die aktuelle komponentenbasierte Anwendungsstruktur zu einer Komponenten/WebService-Hybridstruktur zu erweitern. Sie können die von Drittanbietern bereitgestellten WebService-Funktionen in der Anwendung verwenden oder Ihre eigene Anwendung hinzufügen Funktionen, die anderen über WebService bereitgestellt werden. In beiden Fällen können der Code und die Daten hinter dem Code wiederverwendet werden.
Nachteil 1: Eigenständige Anwendung
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 besser, die lokale API zu verwenden und die Verwendung von WebService zu vermeiden. 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. Am besten verwenden Sie COM oder andere lokale APIs direkt, um Aufrufe zwischen Anwendungen durchzuführen. Obwohl WebService auch für diese Szenarien geeignet ist, verbraucht es viele Ressourcen und bringt keine wesentlichen Vorteile.
Schwäche 2: Isomorphe Anwendungen im LAN
In vielen Anwendungen werden alle Programme mit VB oder VC entwickelt, alle verwenden COM unter der Windows-Plattform und alle laufen 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 beim .NET-Remoting 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.
Kurz gesagt: Solange es andere Methoden gibt, die aus Sicht der Anwendungsstruktur effektiver und praktikabler sind als WebService, sollten Sie WebService nicht verwenden.
Realisieren Sie die Schnittstellenmobilisierung zwischen verschiedenen Projekten und übertragen Sie Objektdaten über Webservice~
1, pom
<!--webservice-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web-services</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>3.1.12</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>3.1.12</version>
</dependency>2, Konfigurationskonfigurationsklasse
package com.guor.config;
import com.guor.service;
import com.guor.service.implImpl;
import org.apache.cxf.Bus;
import org.apache.cxf.bus.spring.SpringBus;
import org.apache.cxf.jaxws.EndpointImpl;
import org.apache.cxf.transport.servlet.CXFServlet;
import org.springframework.boot.web.servlet.ServletRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.xml.ws.Endpoint;
@Configuration
public class CxfConfig {
@Bean
public ServletRegistrationBean createServletRegistrationBean() {
return new ServletRegistrationBean(new CXFServlet(), "/WebService/*");
}
@Bean(name = Bus.DEFAULT_BUS_ID)
public SpringBus springBus() {
return new SpringBus();
}
@Bean
public WebService myService() {
return new WebServiceImpl();
}
@Bean
public Endpoint endpoint() {
EndpointImpl endpoint = new EndpointImpl(springBus(), myService());
endpoint.publish("/api");
return endpoint;
}
}3, Schnittstelle
package com.guor.service;
import com.guor.entity.dto.User;
import javax.jws;
@WebService(name = "WebService", // 暴露服务名称
targetNamespace = "http://service.guor.com"// 命名空间,一般是接口的包名倒序
)
public interface WebService {
User sendInfo(User user);
}1. Erstellen Sie eine identische Schnittstelle
package com.guor.service.impl;
import com.guor.entity.dto.User;
import com.guor.service;
import org.springframework.stereotype.Service;
import javax.jws;
@WebService(serviceName = "WebService", // 与接口中指定的服务name一致
targetNamespace = "http://service.guor.com", // 与接口中的命名空间一致,一般是接口的包名倒
endpointInterface = "com.guor.service"// 接口地址
)
@Service
public class WebServiceImpl implements WebService {
@Override
public User sendInfo(User user) {
return user;
}
}package com.guor.service;
import com.guor.entity.dto.User;
import javax.jws;
@WebService(name = "WebService", // 暴露服务名称
targetNamespace = "http://service.guor.com"// 命名空间,一般是接口的包名倒序
)
public interface WebService {
User sendInfo(User user);
}Das obige ist der detaillierte Inhalt vonWie Webservice Schnittstellenaufrufe und Objektübertragungen zwischen Springboot-Projekten implementiert. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
