Bonnes Pratiques Web & Cloud

Objectifs pédagogiques :

• Concevoir une application web avec une approche par composants

• Créer un web service SOAP

• Isoler et déployer une application dans des conteneurs grâce à Docker

• Sélectionner les langages de programmation adaptés pour le développement de l’application

• Interagir avec des composants externes

Pré-requis :

• Vous devez avoir les bases de Maven.

•  

  Partie 1 - Maîtrisez les principes fondamentaux de la SOA

   

  1. 1. Découvrez pourquoi mettre en place une SOA

  2. 2. Assimilez les 8 commandements de la SOA

  3. 3. Créez une SOA à partir d’un cas réel

  • Quiz : Les principes de la SOA
•  

  Partie 2 - Implémentez une SOA grâce à JAX-WS et SOAP/WSDL

   

  1. 1. Mettez en place l'environnement de développement

  2. 2. Créez un web service Bottom-up

  3. 3. Créez un client et un web service Top-down

  • Quiz : Création de services répondant aux principes de la SOA
•  

  Partie 3 - Testez votre service grâce à SoapUI

   

  1. 1. Réalisez des tests fonctionnels

  2. 2. Simulez un service avec les mocks

  3. 3. Gérez les erreurs

  • Quiz : Tests de services et gestion des erreurs

SOAP is a protocol used to exchange messages between SOAP applications on a network, usually an intranet or the Internet. A SOAP application is simply any piece of software that generates or processes SOAP messages. For example, any Java application or J2EE component that uses JAX-RPC (covered in Part IV) would be considered a SOAP application, because JAX-RPC is used to generate and process SOAP messages. The application sending a SOAP message is called the sender, and the application receiving it is called the receiver. As a J2EE Web services developer you will be creating SOAP applications using JAX-RPC-enabled applications and components, which will act as receivers or senders or both.

A SOAP message travels along the message path from a sender to a receiver (see Figure 4-5). All SOAP messages start with the initial sender, which creates the SOAP message, and end with the ultimate receiver. The term client is sometimes associated with the initial sender of a request message, and the term Web service with the ultimate receiver of a request message.

Limites de JSON

Même si JSON est un format de données relativement concis et flexible, facile à utiliser dans de nombreux langages de programmation, il a néanmoins quelques inconvénients. On peut lister cinq limitations principales

1- Absence de schéma. Cela signifie d’une part que le développeur dispose d'une flexibilité totale pour représenter les données comme il le souhaite. Mais d'autre part, cela signifie qu’il peut très facilement créer sans le vouloir des données déformées.

2- Un type de nombre unique : le format à virgule flottante double précision IEEE-754. Cela signifie simplement qu’il n’est pas possible de tirer parti de la diversité et des nuances des types de nombres disponibles dans de nombreux langages de programmation.

3-Pas de type de date. Cette omission signifie que les développeurs doivent avoir recours à des représentations de dates sous forme de chaînes de caractères, ce qui entraîne des écarts de formatage, ou ils doivent représenter les dates en millisecondes à partir de la date d’origine (1er janvier 1970)

4- Pas de commentaires. Il est donc impossible d'annoter les champs en ligne, ce qui nécessite une documentation supplémentaire et augmente les risques de malentendus.

5- Verbosité. Même si JSON est moins verbeux que XML, ce n'est pas le format d'échange de données le plus concis. Pour les services à grand volume ou spéciaux, mieux vaut utiliser des formats de données plus efficaces.

L’objectif de cette leçon est d’apprendre à inspecter et à invoquer un service web via l’outil SoapUI. La leçon insiste sur la découverte des standards WSDL et SOAP et sur l’outillage proposé par SoapUI pour réaliser des tests fonctionnels (simulation, test de performance, validation de messages SOAP...).

Cette leçon est inspirée des articles publiés par Meera SUBBARAO sur le site de DZone (https://architects.dzone.com/users/meera).

Buts pédagogiques : lecture d'un WSDL, lecture et écriture de messages SOAP, invoquer une opération d'un service web sans programmation, création de tests fonctionnels, simulation de services web à partir de sa description.

Ce dépôt est utilisé dans le cadre d'un cours sur les architectures orientées services que je dispense à l'ISAE-ENSMA et à l'Université de Poitiers en français. Tous les supports de cours et tutoriaux sont disponibles sur ma page Developpez.com : https://mbaron.developpez.com.