Les services Web sont des normes définies pour l'échange de données sur le Web. Cela ne veut pas dire que les services Web seront exposés à Internet, mais simplement qu'il existe un ensemble convenu de « normes Web » prises en charge par de nombreux produits. Au moment de décider quelle norme adopter, la chose la plus importante à prendre en compte est souvent l’avis du personnel technique.
Ils peuvent vous recommander, dans l'ordre, une norme la plus simple à mettre en œuvre, bénéficiant du support technique le plus étendu pour le produit et la plus susceptible de bien fonctionner dans votre environnement. Afin de réussir la mise en œuvre d'une SOA qui résistera à l'épreuve du temps et continuera à évoluer à l'avenir, ces trois facteurs sont extrêmement importants.
WS-I
La Web Services Interoperability Organization (WS-I) est spécialisée dans le développement de meilleures pratiques pour les normes Web afin de garantir l'interopérabilité entre différents systèmes d'exploitation, plates-formes ou langages de programmation. WS-I est chargé de définir les documents de bonnes pratiques tels que les spécifications techniques de sécurité des services Web et de traitement des services Web. Cette documentation aide les développeurs et les entreprises à se conformer aux pratiques que d'autres utilisent pour garantir l'opérabilité des utilisateurs.
WS-I publie également des spécifications techniques, des suites de tests et des exemples sur la manière de déployer ces protocoles. En fait, WS-I est un organe directeur formé par de nombreuses organisations telles que Microsoft et IBM, et sa mission est de promouvoir des services Web interopérables.
Accord d'utilisation
Les services Web s'appuient sur des protocoles pour garantir que la communication est significative. Le contenu des données envoyées entre les services doit être convenu au préalable pour garantir que les deux parties savent quel contenu est reçu. SOAP est un exemple de protocole le plus largement utilisé lors de l'échange de données. SOAP utilise le langage de programmation XML, permettant aux deux parties de décoder ce qui est envoyé et de formater les informations échangées.
illustrer
Nous aborderons bientôt une partie de l'architecture et ferons également référence à certains protocoles de services Web. Il est important de ne pas confondre ces deux choses. Alors présentons-le brièvement ci-dessous.
Les architectures logicielles telles que REST et RPC ne sont pas des protocoles. Ce sont des méthodes qui précisent comment l’accord doit être mis en œuvre.
WSDL (Web Services Description Language) est un langage utilisé pour décrire un service Web spécifique de manière formatée afin que les applications puissent analyser le service. WSDL lui-même ne fournit aucune fonctionnalité sous la forme d'interactions de services Web.
Les protocoles eux-mêmes, tels que SOAP, XML-RPC ou DCOM, définissent exactement comment les messages sont transmis et comment un programme comprend les données qu'il reçoit.
Il existe deux principaux types d'architectures dans SOA : la famille de protocoles RPC et l'approche Representational State Transfer (REST).
RPC
La méthode d'appel de procédure à distance (RPC) permet aux programmeurs d'appeler les ressources d'un système distant, tout comme "appeler" les ressources locales lors de la programmation sur un système. L'inconvénient des services de type RPC est que les utilisateurs ont tendance à les utiliser comme s'ils connaissaient le langage de programmation de la plate-forme spécifique. Il est même facile d'appeler une procédure distante si elle est identique à la procédure locale.
Cette logique viole le concept de « couplage lâche ». Le concept de couplage lâche signifie en réalité que le processus distant ne doit dépendre d’aucun système d’exploitation ou langage de programmation spécifique.
SOAP est le protocole successeur de XML-RPC et n'est qu'un appel de procédure distante qui contient ses informations au format XML. SOAP utilise le protocole HTTP pour envoyer des données, ce qui est simple et agréable, mais il présente certains inconvénients. Malgré cela, la plupart des services Web utilisent encore aujourd’hui le protocole HTTP pour la communication puisqu’ils sont construits à l’aide du protocole SOAP.
REPOS
L'approche Representational State Transfer (REST) est fondamentalement différente des appels de procédure à distance car elle fonctionne à un niveau différent. Un appel REST ressemble à n'importe quelle autre requête Web via le protocole HTTP, tandis qu'un appel RPC ressemble à un appel de fonction standard. L'objectif de REST est de fonctionner avec des ressources stables plutôt qu'avec des messages individuels, ce qui aboutit à une manière d'interagir plus standard et plus largement comprise, un peu comme le protocole HTTP lui-même. REST gère le transfert de morceaux de données simples, tandis que RPC transfère des processus complexes.
Faut-il utiliser REST ou RPC ?
La question de savoir s’il faut utiliser REST est certainement une bonne question. Cela semble être la voie de l’avenir. Cependant, votre SOA doit être intégrée à chaque logiciel que vous utilisez actuellement. L'adoption de REST a été lente, principalement en raison de la prise en charge des services Web. Bien qu'un système REST puisse utiliser WSDL pour décrire un message SOAP via HTTP, il n'existe pas suffisamment de support pour l'utiliser réellement. Par exemple, Apache ne prend même pas en charge les méthodes requises pour utiliser REST sans installer le module plug-in.
Il existe d'autres standards qui ne font pas partie de la famille des services Web. Mais comme on peut s’y attendre, ces normes ne bénéficient pas d’un large soutien. Jini, WCF et CORBA en sont quelques exemples. Lorsqu'un fournisseur vous propose un produit qui ne prend en charge qu'une des technologies ci-dessus, vous souhaitez vous enfuir, pas vous en aller. Les services Web sont désormais largement pris en charge. L'utilisation des services Web ne fera que croître. La SOA elle-même est considérée comme nouvelle, instable et risquée. Cependant, ces risques peuvent être largement atténués lorsque vous choisissez une norme de services Web appropriée bénéficiant d'un large support technique.
Enfin, s'en tenir au SOAP à l'ancienne plutôt qu'à un certain type de système de type RPC constitue actuellement un mécanisme viable pour créer une SOA à l'aide de services Web. Si vous procédez ainsi, vous réduisez considérablement vos risques de dépendance envers un fournisseur.