Web Service est une application Web indépendante de la plate-forme, à faible couplage, autonome et programmable qui peut utiliser la norme open XML (un sous-ensemble du Standard Universal Markup Language). découvrir, coordonner et configurer ces applications pour développer des applications distribuées et interopérables.
La technologie Web Service permet à différentes applications exécutées sur différentes machines d'échanger des données ou de s'intégrer les unes aux autres sans avoir besoin de logiciels ou de matériel tiers spécialisés supplémentaires. Les applications mises en œuvre selon les spécifications des services Web peuvent échanger des données entre elles quel que soit le langage, la plateforme ou le protocole interne qu'elles utilisent. Le service Web est un module autonome et auto-descriptif qui peut être utilisé sur le réseau et peut exécuter des fonctions commerciales spécifiques. Les services Web sont également faciles à déployer car ils sont basés sur certaines normes industrielles conventionnelles et technologies existantes, telles que des sous-ensembles de XML et HTTP sous le langage de balisage universel standard. Les services Web réduisent le coût des interfaces applicatives. Les services Web fournissent un mécanisme commun pour intégrer les processus métier dans une entreprise ou même dans plusieurs organisations.
Pour réaliser la création d'applications distribuées, la plateforme Web Service doit adopter un ensemble de protocoles. Toute plate-forme a sa méthode de représentation des données et son système de types. Pour parvenir à l'interopérabilité, la plate-forme de services Web doit fournir un système de types standard pour communiquer différents systèmes de types sur différentes plates-formes, langages de programmation et modèles de composants. Ces protocoles sont :
XML est un langage de balisage utilisé pour marquer les documents électroniques afin de les rendre structurels, et constitue le format de base pour représenter les données dans la plateforme de services Web. En plus d'être facile à créer et à analyser, le principal avantage du XML est qu'il est à la fois indépendant de la plate-forme et du fournisseur. XML suit les exigences grammaticales de la spécification W3C, sépare la forme et le contenu, a une bonne auto-description, est facile à développer et possède une multitude de bibliothèques de développement tierces, ce qui le rend très approprié pour la transmission d'informations entre des systèmes d'architectures différentes. À mesure que l'application de XML se généralise, XML est devenu de facto la norme d'échange de données en raison de ses avantages dans de nombreux scénarios d'application. XML a été créé par le World Wide Web Consortium (W3C). Le XML SchemaXSD développé par le W3C définit un ensemble de types de données standard et fournit un langage pour étendre cet ensemble de types de données.
La plateforme de services Web utilise XSD comme système de type de données. Lorsque vous utilisez un langage tel que VB. NET ou C# pour construire un service Web, afin de respecter la norme du service Web, tous les types de données que vous utilisez doivent être convertis en types XSD. Si vous souhaitez que le contenu soit fourni entre différentes organisations sur différentes plates-formes et différents logiciels, vous devez également l'envelopper dans quelque chose. Cette chose est un protocole, comme SOAP.
SOAP est le Simple Object Access Protocol. Il s'agit d'un protocole léger utilisé pour échanger des informations codées en XML (un sous-ensemble du Standard Universal Markup Language). les données entre utilisateurs sont une forme d’implémentation courante de service Web. Il comporte trois aspects principaux : l'enveloppe XML définit un cadre pour décrire le contenu de l'information et comment traiter le contenu, des règles pour coder les objets de programme en objets XML et des conventions pour implémenter des appels de procédure à distance (RPC). SOAP peut fonctionner sur n'importe quel autre protocole de transport.
SOAP définit un cadre basé sur le protocole HTTP qui décrit le contenu du message, qui l'a envoyé, qui doit l'accepter et le traiter, et comment les traiter. Il standardise les formats de données en définissant des enveloppes SOAP (Envelops), encapsule les données XML dans des enveloppes pour l'échange d'informations et permet l'interopérabilité entre des systèmes hétérogènes.
Web Service espère réaliser que différents systèmes peuvent s'appeler grâce à un « dialogue logiciel-logiciel », brisant l'incompatibilité entre les applications logicielles, les sites Web et divers appareils, et atteignant l'objectif d'une « intégration transparente basée sur le Web ».
Langage de description de service Web WSDL est un document de description formel fourni de manière lisible par machine et est basé sur XML (un sous-ensemble du langage de balisage universel standard). . , paramètres et valeurs de retour. Parce qu'il est basé sur XML, WSDL est à la fois lisible par machine et par humain.
L'objectif d'UDDI est d'établir des normes pour le commerce électronique ; UDDI est un ensemble de normes de mise en œuvre de centres d'enregistrement d'informations distribués et basés sur le Web pour les services Web, et comprend également un ensemble de normes de mise en œuvre qui permettent entreprises Vous pouvez enregistrer le service Web que vous fournissez afin que d'autres entreprises puissent découvrir les normes de mise en œuvre du protocole d'accès.
Le service Web lui-même implémente la communication entre les applications. Nous pouvons utiliser deux méthodes pour établir la communication entre les applications : les appels de procédure à distance (RPC) et la transmission de messages. Lors de l'utilisation de RPC, le concept d'un client est d'appeler une procédure distante sur le serveur, généralement en instanciant un objet distant et en appelant ses méthodes et propriétés. Le système RPC tente d'obtenir une sorte de transparence positionnelle : le serveur expose l'interface de l'objet distant et le client agit comme si l'interface de ces objets était utilisée localement. Cela masque les informations sous-jacentes et le client n'en a pas besoin. tout. Sachez sur quelle machine se trouve l’objet.
Force 1 : Communication à travers les pare-feu
Si l'application compte des milliers d'utilisateurs et est distribuée dans le monde entier, alors la communication du client avec le serveur sera assurée. être un problème délicat. Parce qu'il existe généralement un pare-feu ou un serveur proxy entre le client et le serveur. Dans ce cas, utiliser DCOM n'est pas si simple et il n'est généralement pas pratique de publier le programme client auprès d'un si grand nombre d'utilisateurs. L'approche traditionnelle consiste à choisir d'utiliser le navigateur comme client, d'écrire de nombreuses pages ASP et d'exposer la couche intermédiaire de l'application à l'utilisateur final. Il en résulte que le développement est difficile et que le programme est difficile à maintenir.
Si le composant intermédiaire est remplacé par WebService, le composant intermédiaire peut être appelé directement depuis l'interface utilisateur, éliminant ainsi l'étape de création d'une page ASP. Pour appeler WebService, vous pouvez utiliser directement un client SOAP tel que MicrosoftSOAP Toolkit ou .NET, ou vous pouvez utiliser un client SOAP auto-développé, puis le connecter à l'application. Non seulement cela raccourcit le cycle de développement, mais cela réduit également la complexité du code et améliore la maintenabilité de l'application. L'application n'a pas besoin d'accéder à la « page de résultats » correspondante à chaque fois qu'elle appelle un composant de niveau intermédiaire.
Les développeurs d'applications d'entreprise savent tous que les entreprises doivent souvent intégrer divers programmes écrits dans différents langages et fonctionnant sur différentes plates-formes, et cette intégration coûtera beaucoup d'efforts de développement. Les applications doivent souvent obtenir des données à partir de programmes exécutés sur le mainframe IBM ou envoyer des données au mainframe ou aux applications UNIX. Différents logiciels doivent souvent être intégrés sur la même plateforme, même s'ils proviennent de fournisseurs de logiciels différents. D'autres applications peuvent utiliser des méthodes standard pour accéder aux fonctionnalités et aux données exposées via le WebService.
Force 2 : Intégration d'applications
Les développeurs d'applications au niveau de l'entreprise savent tous que les entreprises intègrent souvent divers programmes écrits dans différents langages et fonctionnant sur différentes plates-formes, et cette intégration nécessitera beaucoup d'efforts de développement. Les applications doivent souvent obtenir des données à partir de programmes exécutés sur le mainframe IBM ou envoyer des données au mainframe ou aux applications UNIX. Différents logiciels doivent souvent être intégrés sur la même plateforme, même s'ils proviennent de fournisseurs de logiciels différents. D'autres applications peuvent utiliser des méthodes standard pour accéder aux fonctionnalités et aux données exposées via le WebService.
Par exemple, il existe un programme de connexion aux commandes utilisé pour enregistrer les nouvelles commandes des clients, y compris les informations sur le client, l'adresse de livraison, la quantité, le prix et le mode de paiement ; il existe également un programme d'exécution des commandes utilisé pour envoyer les marchandises réelles. Les deux programmes proviennent de fournisseurs de logiciels différents. Lorsqu'une nouvelle commande arrive, le programme de saisie des commandes informera le programme d'exécution des commandes d'envoyer les marchandises. En ajoutant une couche de WebService au-dessus du programme d'exécution de commande, le programme d'exécution de commande peut « exposer » la fonction « AddOrder ». De cette façon, chaque fois qu'une nouvelle commande arrive, le programme de connexion à la commande peut appeler cette fonction pour envoyer la marchandise.
Fonction 3 : Intégration B2B
L'utilisation de WebService pour intégrer des applications peut rendre le traitement commercial interne de l'entreprise plus automatisé. Mais que se passe-t-il lorsque les transactions concernent les fournisseurs et les clients, repoussant ainsi les limites de l’entreprise ? L'intégration des transactions commerciales entre entreprises est souvent appelée intégration B2B.
WebService est la clé d'une intégration B2B réussie. Grâce à WebService, les entreprises peuvent « exposer » leurs applications métier clés à des fournisseurs et clients désignés. Par exemple, en « exposant » le système de commande électronique et le système de facturation électronique, les clients peuvent envoyer des commandes par voie électronique et les fournisseurs peuvent envoyer des factures d'achat de matières premières par voie électronique. Bien sûr, ce n’est pas un concept nouveau, l’EDI (Electronic Document Interchange) existe depuis longtemps. Cependant, la mise en œuvre de WebService est beaucoup plus simple que l'EDI, et WebService fonctionne sur Internet et peut être facilement mis en œuvre n'importe où dans le monde, son coût d'exploitation est donc relativement faible. Cependant, WebService n'est pas une solution complète d'échange de documents ou d'intégration B2B comme l'EDI. Pour réaliser l'intégration, en plus du WebService, de nombreux autres composants sont requis.
Le plus grand avantage de l'utilisation de WebService pour mettre en œuvre l'intégration B2B est que l'interopérabilité peut être facilement réalisée. Tant que la logique métier est « exposée » et devient un service Web, tout partenaire désigné peut appeler cette logique métier, quelle que soit la plate-forme sur laquelle son système s'exécute ou le langage de développement qu'il utilise. Cela réduit considérablement le temps et les coûts consacrés à l'intégration B2B, permettant ainsi à de nombreuses petites et moyennes entreprises qui n'ont pas les moyens de se permettre l'EDI de réaliser l'intégration B2B.
Réutilisation des logiciels et des données
"La réutilisation des logiciels est un sujet important avec de nombreuses formes et différents degrés de mise en œuvre." La forme la plus élémentaire est la réutilisation du module de code source ou au niveau de la classe, et l'autre forme est la réutilisation des composants de formulaire binaire.
Actuellement, les composants logiciels réutilisables comme les contrôles de table ou les contrôles d'interface utilisateur occupent une part importante du marché. La réutilisation de ce type de logiciel est très contraignante car limitée au code et les données ne peuvent pas être réutilisées. La raison en est qu'il est plus facile de publier des composants et même du code source, mais il n'est pas si facile de publier des données, à moins qu'il ne s'agisse de données statiques qui ne changent pas fréquemment.
Tout en réutilisant le code, webService peut également réutiliser le code derrière les données. Grâce à WebService, vous n'avez plus besoin d'acheter et d'installer des composants logiciels auprès d'un tiers comme auparavant, puis d'appeler ces composants depuis l'application, il vous suffit d'appeler directement le WebService distant ; Par exemple, pour confirmer l'adresse saisie par l'utilisateur dans l'application, il vous suffit d'envoyer l'adresse directement au WebService correspondant. Ce WebService vous aidera à vérifier l'adresse postale, la ville, la province, le code postal et d'autres informations pour confirmer la. L'adresse est-elle dans la zone du code postal correspondant ? Le fournisseur de WebService peut facturer le service en fonction de la durée ou du nombre d'utilisations. Il est impossible de mettre en œuvre un tel service via la réutilisation de composants. Dans ce cas, vous devez télécharger et installer une base de données contenant des informations telles que les adresses, les villes, les provinces et les codes postaux, et cette base de données ne peut pas être mise à jour en temps réel.
Une autre situation de réutilisation de logiciels consiste à intégrer les fonctions de plusieurs applications. Par exemple, vous souhaitez créer une application de portail sur le réseau local afin que les utilisateurs puissent consulter les colis FedEx, vérifier les conditions boursières, gérer leurs propres horaires et acheter des billets de cinéma en ligne. Il existe désormais de nombreux fournisseurs d'applications sur le Web, qui ont tous implémenté ces fonctions dans leurs applications. Une fois qu'ils « exposent » ces fonctions via WebService, ils peuvent facilement intégrer toutes ces fonctions dans votre site portail et offrir aux utilisateurs une interface unifiée et conviviale.
À l'avenir, de nombreuses applications utiliseront WebService pour étendre la structure d'application actuelle basée sur les composants en une structure hybride composant/WebService. Vous pouvez utiliser les fonctions fournies par WebService tiers dans l'application, ou vous pouvez ajouter votre propre application. fonctions fournies à d’autres via WebService. Dans les deux cas, le code et les données derrière le code peuvent être réutilisés.
Inconvénient 1 : Applications autonomes
Actuellement, les entreprises et les particuliers utilisent encore de nombreuses applications de bureau. Certains d’entre eux n’ont besoin que de communiquer avec d’autres programmes sur la machine. Dans ce cas, il est préférable d'utiliser l'API locale et d'éviter d'utiliser WebService. COM est idéal pour travailler dans cette situation car il est petit et rapide. Il en va de même pour les logiciels serveur exécutés sur le même serveur. Il est préférable d’utiliser directement COM ou d’autres API locales pour effectuer des appels entre applications. Bien que WebService soit également adapté à ces scénarios, il consommera beaucoup de ressources et n'apportera aucun avantage substantiel.
Faiblesse 2 : Applications isomorphes sur LAN
Dans de nombreuses applications, tous les programmes sont développés avec VB ou VC, tous utilisent COM sous la plateforme Windows et tous s'exécutent sur le même LAN. Par exemple, deux applications serveur doivent communiquer entre elles, ou un programme client Win32 ou WinForm souhaite se connecter à un autre programme serveur sur le réseau local. Dans ces programmes, l'utilisation de DCOM sera bien plus efficace que SOAP/http. De même, si un programme .NET souhaite se connecter à un autre programme .NET sur le réseau local, l'accès à distance .NET doit être utilisé. Fait intéressant, dans l'accès à distance .NET, vous pouvez également spécifier d'utiliser SOAP/http pour effectuer des appels WebService. Cependant, il est préférable de faire des appels RPC directement via TCP, ce qui est beaucoup plus efficace.
En bref, tant qu'il existe d'autres méthodes plus efficaces et réalisables que WebService du point de vue de la structure de l'application, n'utilisez pas WebService.
Réaliser la mobilisation d'interface entre différents projets et transférer les données d'objet via le service Web~
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, classe de configuration de configuration
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, interface
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);
}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;
}
}1. Créez une interface identique
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);
}2.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
