Cours AGL ENSA 2017-2018 CH7-9

28/12/2018
07 ARCHITECTURES APPLICATIVES
GÉNIE LOGICIEL ET QUALITÉ LOGICIELLE 2018-2019 ENSA KENITRA – UNIVERSITÉ IBN TOUFAIL
ARCHITECTURES APPLICATIVES
Ce qu’il faut savoir
Typologie des
applications et Typologie et
Cartographie Qualification des flux
applicative
Architecture en Architectures
couches d'échange
Contraintes de
Patrons d'architecture
l'architecte
1
28/12/2018
Les différentes vues
Vue métier
Les processus métier et leurs
activités, l’organisation
Vu
Vue fonctionnelle
Les fonctions du SI supportant les
processus métier
Vue applicative
Les blocs applicatifs, les
messages, les données
Vue technique
Les matériels,les logiciels, les
technologies
Rôle de l'architecte
2
28/12/2018
Organisation simplifiée de l’entreprise
Choix à faire !
Développements spécifiques Progiciels
 CRM (Customer Relationship

 Sur serveur web/d'applications : Java Management)
EE, .NET, PHP …  SCP (Supply Chain Management)
 Sur serveur de bases de données :  ERP (Enterprise Resource Planning)
Oracle, Access, SQL Server…
 Bureautique, messagerie
 Sur client : Java, .NET, JavaScript,
Applets…  Applications de travail collaboratif
 Workflows
Pourquoi pas louer des services sur le Cloud ?
3
28/12/2018
Couches applicatives
 3 types de responsabilités = 3 couches principales
 Principe de conception = séparation des responsabilités
Couches applicatives détaillés
 Vue plus fine des responsabilités
4
28/12/2018
Modèle Client-Serveur
 Modèle Client-Serveur = 2 programmes +1 protocole

> Programme « serveur » = offre un service à des clients
> Programme « client » = utilise un service fourni par un serveur
> Protocole = moyen de communication
 Indépendant de la notion de « machine »

> Client et serveur sur la même machine
> Client et serveur sur des machines différentes
Modèle Client-Serveur Où placer les couches applicatives ?
 Distribution des couches entre client et serveur

 Possibilités multiples = typologies multiples (Gartner)
5
28/12/2018
Architecture 1-tiers (mainframe)
 L’application est sur un serveur (éventuellement distant)

 Le client est une application « légère » de visualisation (client « passif »)
Architecture 1-tiers (client autonome)
 L’application est sur le client

 Les données sont sur un serveur (éventuellement distant)
6
28/12/2018
Architecture 2-tiers (client lourd)
 Le cœur de l’application est sur un serveur (éventuellement distant)

 La couche présentation (IHM) de l’application est sur le client
Architecture 3-tiers (client léger)
 Le cœur de l'application est sur un serveur

 Les données sont sur un autre serveur
 Le client est une application « légère » de visualisation (ex : navigateur web)
7
28/12/2018
Architecture n-tiers
 Généralisation des modèles précédents

(remarque : un serveur peut être un client pour un autre serveur !)
 On pourra imaginer une distribution de serveurs par topic: (serveur de web service,
serveur de localisation, serveur LDAP…)
 Distribution des responsabilités en 4 ou + tiers
Exemple avec Java EE pour 4 tiers
 Application de gestion de catalogue de produits

 Architecture 3 ou 4 tiers :
> Client léger
> Serveur de présentation (pouvant être fusionné avec le serveur de traitement dans
le cas de Java EE)
> Serveur d'application
> Serveur de données
8
28/12/2018
Exemple avec Java EE
Composants
 Composant = unité logique de traitement

> Assemblage d’objets interdépendants
> Rend un service (fonction)
> Vue boîte noire
 Propriétés
> Identification : nom unique, référencé dans un annuaire
> Indépendance : utilisable tout seul
> Réutilisation : utilisable dans différents contextes
> Intégration : combinable avec d’autres composants
 Technologies d’implémentation multiples
9
28/12/2018
Composants distribués
 Un Client veut utiliser un composant qui se trouve sur un Serveur (distant)
 Plusieurs solutions permettent d’invoquer des composants distribués

> RMI
> RPC
> CORBA
> WebService: SOAP, REST
Composants distribués: RMI (Remote Method Invocation)
 Le RMI permet d'appeler du code à distance. Plus précisément, nous allons exposer
une partie du code sur le client au travers d'interfaces. L'implémentation proprement
dite se trouvera du côté du serveur et le rôle de RMI sera de faire le nécessaire afin de
lier les interfaces aux implémentations distantes.
10
28/12/2018
Composants distribués: CORBA (Common Object Request Broker Architecture)
 CORBA est une architecture logicielle pour le développement de composants et

d’object request broker (ORB). Ces composants, qui sont assemblés afin de construire
des applications complètes, peuvent être écrits dans des langages de programmation
distincts, être exécutés dans des processus séparés, voire être déployés sur des
machines distinctes.
Composants distribués: SOAP (Simple Object Access Protocol)
 SOAP définit le cadre général pour l’échange de données structurées en XML
 SOAP permet d’échanger des structures de données complexes en XML avec les
Namespaces, et la spécification XML Schéma (WSDL)
11
28/12/2018
Composants distribués: REST (Restfull API)
 Consommer un WebService REST revient à appeler une simple URL en http (Post ou
Get) , le serveur renvoie sa réponse, la plupart du temps en XML
HTTP verb Resource
GET http://
api.openweathermap.org/data/2.5/weather?q=London,uk
URI = Uniform Resource Identifier (bookmarkable, etc.)
Web
Client Server
Resource state representation

(JSON format)
C’EST QUOI REST
 Representational State Transfert

 Un ensembles de principes définis dans la thèse de Roy Fielding dans les années 2000
 Roy Fielding est l’un des 8 fondateurs de la fondation Apache
 REST est
> Ensemble de conventions et de bonnes pratiques à respecter
> Style d’architecture : structurant, efficace, évolutif et indépendant des mises en œuvre
> Une approche pour construire une API
 REST n’est surtout pas
> Un format
> Un protocole
> Un standard
> Une technologie à part entière
OCTO TECHNOLOGY > THERE

GÉNIE LOGICIEL IS A LOGICIELLE
ET QUALITÉ BETTER WAY 2018-2019 ENSA KENITRA – UNIVERSITÉ IBN TOUFAIL
12
28/12/2018
DESIGNER UNE API
 Le design d’une API est-il important ?
> API destinée à l’entreprise et aux partenaires
+ Une API mal « designée » (complexe et non affordante) ne sera pas utilisée
rapidement par les développeurs
+ Le TTFAC (Time To First API Call) désigne le temps nécessaire à un

développeur pour réaliser un 1er appel d’API, après avoir consulté la
documentation sur le « portail developer »
◦ C’est un bon moyen pour mesurer la qualité du design et de la mise en œuvre
d’une API
> Open API
+ Une Open API mal « designée » ne sera pas utilisée par les développeurs

DESIGNER UNE API
 Design d’API a l’état de l’art : deux approches
> Les « puristes » : API RESTful issus de la littérature de référence (Roy Fielding,
Leonard Richardson, Martin Fowler, spécifications HTTP…)
> Les « pragmatiques » : Bonnes pratiques utilisées par les API des « Géants du
Web »
 KISS – « Keep it simple, stupid »

> API vise à « s’ouvrir » sur le WWW, pour toucher un publique large de développeurs
 Affordance – c’est à dire de la capacité de l’API à suggérer son utilisation

> Consulter la documentation le moins possible

13
28/12/2018
REST : PRINCIPE
request
scoping
HTTP verb Resource
elements
GET http://
api.openweathermap.org/data/2.5/weather?q=London,uk
URI = Uniform Resource Identifier (bookmarkable, etc.)
Web
Client Server
Resource state representation

(here in JSON format)

ET QUALITÉ BETTER WAY 2018-2019 ENSA KENITRA––UNIVERSITÉ
ENSAKENITRA UNIVERSITÉIBN
IBNTOUFAIL
TOUFAIL 27
LE MODÈLE DE MATURITÉ DE RICHARDSON
RICHARDSON MATURITY MODEL
 Développé par Léonard Richardson

 Il compte 4 niveaux (0-3), où le niveau 3 représente une vraie API RESTful
 Ces 4 niveaux permettent d’évaluer une API par rapport aux contraintes REST
11

14
28/12/2018
NIVEAU 0 - LE RPC SUR HTTP EN POX
1/2 PLAIN OLD XML
 Le protocole est uniquement utilisé à des fins de transport du message

 Tout circule via un seul et unique point d’entrée
+ Niveau 0 : État basique avec des XML dans tous les sens

ET QUALITÉ BETTER WAY 2018-2019 ENSA KENITRA – UNIVERSITÉ IBN TOUFAIL 12
NIVEAU 0 - LE RPC SUR HTTP EN POX
2/2 PLAIN OLD XML
4
1
2 5

15
28/12/2018
NIVEAU 1 - RESSOURCES
1/2
 Resources sont identifiées avec URI

 Pas de sémantique
+ Niveau 1 : Ajout de la notion de ressources

2/2
1 2

16
28/12/2018
Noms vs verbes
> On utilise des noms concret pour décrire les ressources de l’API.
SOAP/RPC/EJB… RESTful
getClient(1) GET /customers/1

creerClient() POST /customers
majSoldeCompte(1) PATCH /accounts/1
ajoutetProduitDansCommande(1) PUT /orders/1
effacerAdresse(1) DELETE /addresses/1
… …
> API REST == HTTP comme protocole applicatif

> Ne pas façonner un protocole « maison », qui a l’inconvénient de « réinventer la
roue » à chaque fois.

NIVEAU 2 - VERBES ET CODES RETOURS HTTP
1/2
 Multiples resources
 Utilisation sémantiquement correcte des verbes HTTP
 Utilisation correcte des code de réponse
+ Niveau 2 : Ajout de verbes de statut et de codes d’état

17
28/12/2018
2/2
1
3 5

INTERFACE UNIFORME : MANIPULATION DES RESSOURCES À L’AIDE

DES PRINCIPAUX VERBES HTTP
Verbe HTTP Paramètres Description
OPTIONS URI (très peu utilisé)
HEAD URI (très peu utilisé)
GET URI Obtention d’une ressouce
PUT URI, représentation Mise à jour d’une ressource
DELETE URI Suppression d’une ressource
POST URI, représentation Création d’une ressource
Mise à jour “optimisée” d’une ressource de

PATCH* URI
grosse taille (non standardisé)
* : Standard IETF à l’état de « Standard Proposé » depuis 2010, mais non encore adopté dans la spécification HTTP
1.1 par le W3C. Cf. RFC 5789

IBNTOUFAIL
TOUFAIL 36
18
28/12/2018
Codes retour
> Utilisation d’une collection de la structure d’erreur Json suivante
{ "error": "description_courte",
"error_description": "description longue, Human-readable",
"error_uri": "URI vers une description détaillée de l'erreur sur le portail
developper"
}
> Issue de la spécification OAuth2

+ Permet au client qui la consomme de ne pas avoir à gérer deux structures
d’erreurs distinctes
+ Retour systématique d’une collection de cette structure, pour retourner plusieurs
erreurs simultanées (utile dans le cas d’une validation formulaire server-side par
exemple)

 Codes retour
> Utilisation des STATUS CODES HTTP
HTTP Verb HTTP Status code Description
Basic success code. Works for the general case. Especially used on successful
200 OK.
first GET requests, or PUT/PATCH updated content.
Indicates that a resource was created. Typically responding to PUT and POST
201 Created.
request.
Indicates that the request has been accepted for processing. Typically
SUCCESS 202 Accepted. responding to an asynchronous processing call (for a better UX and good
performances).
The request succeeded but there’s really nothing to show. Usually sent after a
204 No Content.
successful DELETE.
206 Partial
The returned resource is incomplete. Typically used with paginated resources.
Content.

19
28/12/2018

HTTP Verb HTTP Status code Description
General error for any request (if it doesn’t fit in any other). A good practice will be to manage two kind of errors: request
behavior errors, and application condition errors.
Request behavior error example:

GET /users?payed=1
< 400 Bad Request
400 Bad request. < {"error": "invalid_request", "error_description": "There is no ‘payed’ property on users."}
Application condition error example:

POST /users
{"name": "John Doe”}
< 400 Bad Request
< {"error": "invalid_user", "error_description": "A user must have an email adress"}
I don’t know you, tell me who you are and I will check your permission.
GET /users/42/orders
401 Unauthorized. < 401 Unauthorized
< {"error": "no_credentials", "error_description": "This resource is under permission, you must be authenticated with the right
rights to have access to it"}
Your credentials rights aren’t sufficient to access this resource.
CLIENT GET /users/42/orders
ERROR 403 Forbidden. < 403 Forbidden
< {"error": "not_allowed", "error_description": "You’re not allowed to perform this request"}
The resource you’re requesting doesn’t exist
GET /users/999999
404 Not Found. < 400 Not Found
< {"error": "not_found", "error_description": "The user with the id ‘999999’ doesn’t exist"}
Either it doesn’t make sense to call such a method on this resource or the authenticated user doesn’t have the right to do it.
POST /users/8000
405 Method not allowed. < 405 Method Not Allowed
< {"error":"method_does_not_make_sense", "error_description":"How would you even post a person?"}
There’s nothing to send that matches the Accept-* headers of the request. For example, you requested a resource in XML and
the resource is only available in JSON. This also works for i18n
GET /users
Accept: text/xml
406 Not Acceptable.
Accept-Language: fr-fr
< 406 Not Acceptable
< Content-Type: application/json
< {"error": "not_acceptable", "available_languages":["us-en", "de", "kr-ko"]}

 Erreurs
> Utilisation des STATUS CODES HTTP
HTTP Status
HTTP Verb Description
code
The request call is right, but a problem is encountered. The client can’t
really do anything about that, so we suggest to return a 500 status code.
SERVER GET /users
500 Internal
ERROR < 500 Internal server error
server Error.
< Content-Type: application/json
< {"error":"server_error", "error_description":"Oops! Something went
wrong... "}

20
28/12/2018
NIVEAU 3 - CONTRÔLE HYPERMEDIA (HATEOAS)
1/2 HYPERMEDIA AS THE ENGINE OF APPLICATION STATE
 Formats hypermedias : HTML, HAL, JSON-LD

 Resources auto-descriptives
 État et comportement accessible via les représentations
 HATEOAS
+ Niveau 3 : Contrôle hypermedia (HATEOAS)

2/2 HYPERTEXT AS THE ENGINE OF APPLICATION STATE
3
1
4
2

21
28/12/2018
 L’API retourne tous les « états » suivants

> « Discoverable »
> Pas besoin de lire la documentation
> Les URI peuvent changer sans impacter le client
> Mimic un utilisateur qui navigue sur un site Web en cliquant sur des liens
 Implémentation de HATEOAS via la notation utilisée par GitHub, compatible avec la

RFC5988
> qui permet de gérer les client qui ne supportent pas plusieurs Header “Link”
GET /clients/007
< 200 Ok
< { "id":"007", "firstname":"James",...}
< Link : <https://api.fakecompany.com/v1/clients>;; rel="self"; method:"GET",
<https://api.fakecompany.com/v1/addresses/42>;; rel="addresses"; method:"GET",
<https://api.fakecompany.com/v1/orders/1234>;; rel="orders"; method:"GET"

 Exemple HATEOAS PAYPAL

> Dans le payload
[
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-
6RV70583SB702805EKEYSZ6Y",
"rel": "self",
"method": "GET"
},
{
"href": "https://www.sandbox.paypal.com/webscr?cmd=_express-checkout&token=EC-
60U79048BN7719609",
"rel": "approval_url",
"method": "REDIRECT"
},
{
"href": "https://api.sandbox.paypal.com/v1/payments/payment/PAY-
6RV70583SB702805EKEYSZ6Y/execute",
"rel": "execute",
"method": "POST"
}
]

22
28/12/2018
 Supports de HATEOAS
> Neuf Formats majeurs 
+ Collection+JSON - http://amundsen.com/media-types/collection/format/
+ UBER - https://rawgit.com/mamund/media-types/master/uber-hypermedia.html
+ ALPS - http://alps.io/
+ HAL - http://stateless.co/hal_specification.html
+ Siren - https://github.com/kevinswiber/siren
+ Hydra - http://www.markus-lanthaler.com/hydra/
+ JSON-LD - http://json-ld.org/
+ json:api - http://jsonapi.org/
+ Mason - https://github.com/JornWildt/Mason
> Difficulté relative d’implémentation coté serveur

> Difficulté élevée d’implémentation coté client
> Le client sera contraint d’implémenter la solution Hypermedia que vous avez
retenue

PRINCIPES ET CONTRAINTES DU STYLE D’ARCHITECTURE REST
 Les principales contraintes de REST
> Style d’architecture Client-Serveur

+ Séparation des considérations : découplage entre l’affichage (IHM Client) et le stockage des données (côté Serveur). Les
deux composants peuvent ainsi évoluer indépendamment.
> Communication sans état … (Statelessness)

+ … entre le client et le serveur : chaque requête d’un client vers un serveur doit contenir toute l’information permettant au
serveur d’exécuter la requête, sans que celui-ci ait a stocker un contexte entre les requête d’un même client. Avantages :
visibilité, fiabilité, scalabilité.
> « Cachabilité »
+ Les données d’une réponse à une requête peuvent être implicitement ou explicitement marquée comme « cachables » ou
pas, notamment à des fins d’optimisation des transferts réseau.
> Interface Uniforme

+ Cette contrainte simplifie l’architecture du système et améliore la visibilité des interactions avec celui-ci.
+ Le désavantage étant que cette contrainte peut amener à dégrader l’efficacité du système au regard des besoins
spécifiques d’une application
> Système en couches

+ Chaque composant de l’architecture ne doit s’appuyer que sur la couche directement sous-jacente, pour améliorer
l’évolutivité et la scalabilité du système
> [Code-à-la-demande] – contrainte optionnelle

+ Capacité à télécharger et exécuter du code à la demande (script, applet…)

IBNTOUFAIL
TOUFAIL 46
23
28/12/2018
BONNES PRATIQUES 1/7
Pluriel vs singulier
> Collection de ressources : /v1/users
> Instance d’une ressource : /v1/users/007
 Une notation « pluriel » pour adresser les collections et les instances

BONNE PRATIQUE 2/7
Casse
> Casse URL
+ spinal-case
POST /v1/specific-orders
> Casse du body

+ snake_case
GET /orders?id_customer=007
POST /orders {"id_customer":"007"}

24
28/12/2018
BONNE PRATIQUE 3/7
Pagination
> doit être gérée sur toutes les ressources de l’API
GET https://api.fakecompany.com/v1/customers?range=60-72
Pagination du 60 au 72ème customers
< 206 Partial Content Réponse partiel sur la collection

< Content-Range: 60-72/46518 Customers 60 à 72, sur 46518
< Accept-Range: customer 50 Pagination par 50 customers maximum
< ...

BONNE PRATIQUE 4/7
Filtres
> Limitation du nombre de ressources récupérées lors d’un appel en spécifiant des
valeurs attendues
GET
https://api.fakecompany.com/v1/offers?status=open,pending&price<1000&days=Saturday,Su
nday
< 200 OK
> Récupération des offers ayant les attributs status égal à « open » ou « pending »,
price inférieur à « 1000 » et days contenant « Saturday » ou « Sunday »

25
28/12/2018
BONNE PRATIQUE 5/7
Tris
> Ordonnancement des résultats de requête d’une collection : sort / dsc
> Exemples : Récupération des customers par ordre décroissant sur les attributs age,
puis marital_status puis par ordre alphabétique sur l’attribut name.
GET
https://api.fakecompany.com/v1/customers?sort=age,marital_status,name&desc=age,marita
l_status
< 200 OK

BONNE PRATIQUE 6/7
Recherche
 Recherche par ressource
GET https://api.fakecompany.com/v1/offers/search?destination=gadeloupe,Ile*
< 200 Ok
< { "count" : 5,
"query" : "destination=Gadeloupe,Ile*",
"suggestions" : ["Guadeloupe", "ile Galápagos"],
"results" : [...] }
 Recherche globale (Google style)
CURL –X GET \
-H "Accept: application/json" \
https://api.fakecompany.com/v1/search?q=running+paid
< [...]

26
28/12/2018
BONNE PRATIQUE 7/7
Cross-Domain
> CORS
+ L’utilisation du Cross-Domain est un prérequis pour toute API, lorsque que le consommateur
se situe sur un autre domaine que celui de l’API, ce qui est principalement vrai sur les SPA
> https://www.fakecompany.com/ javascript SPA

> https://api.fakecompany.com/ API Rest
> JSONP
+ En pratique CORS n’est pas (ou très mal) supporté par les anciens navigateur (IE 7,8,9).
+ Si votre API est à destination d’internet avec des utilisateurs finaux il sera nécessaire
d’implémenter JSONP en fallback de la mise en œuvre CORS
◦ Pas de négociation de contenu via les entête HTTP
◦ Toute les requête sont en GET, la méthode doit être spécifié en query-string
◦ Le body de la requête ne peux pas être utiliser pour acheminer les données, tout doit-être
passé via la query-string
POST /orders /orders.jsonp?method=POST&callback=foo
GET /orders/42 /orders/1234.jsonp?callback=foo
PUT /orders/42 /orders/1234.jsonp?method=PUT&callback=foo

{ "id" : 42, "status": "pending" } &id=42&status=pending

BONNE PRATIQUE 8/7
Versioning
> Dans l’URL, à la racine
+ GET /v1/orders
> L’approche RESTful consisterait à utiliser le Header « Accept-Version »

> En pratique, la version d’une API est fondamentale pour le consommateur de l’API :
+ La version est obligatoire
+ et doit donc apparaître au 1er niveau de l’URL

27
28/12/2018
BONNE PRATIQUE 9/9
SÉCURISER SON API : HTTPS
 La sécurité des échanges REST repose sur celle de HTTP

> et donc en particulier sur la couche SSL/TLS
 SSL (Secure Socket Layer) – qui a posé les bases de TLS (Transfer Layer Security) – apporte,
avec TLS, les propriété suivantes à HTTP :
> Confidentialité
+ Le message est chiffré et ne peut pas être déchiffré par une tierce partie qui accèderait à son contenu
> Intégrité
+ Le contenu du message n’a pas été modifié dans l’intervalle de sa transmission entre les deux parties (émetteur et receveur)
> Authentification
+ Au niveau de la couche de transport – pas au niveau applicatif
 SSL et le protocole TLS sont des standards IETF

> Cf. RFC 2246 (TLS 1) , RFC 5246 (TLS 1.2), RFC 6101 (SSL 3.0)
 La couche SSL/TLS rajoute un overhead lors de la transmission

> et plus particulièrement la phase d’initialisation de la transmission chiffrée (handshake SSL
: échange de clés)
 Tous les appels à l’API (et aux provider d’authentification et d’habilitation) sont réalisés sur
HTTPS

BONNE PRATIQUE 9/9
SÉCURISER SON API : DEUX TYPES DE RESSOURCES
 Les ressources « Publiques »

> Ex : /products, /catalogues, /offers…
> L’enjeu consiste à tracer l’application appelante
> Solutions
+ Utiliser une API_KEY (ou le client_id OAuth2)… OAuth2 n’apporte rien
+ Utiliser le flow client credential de OAuth2… pas réellement utile (l’encodage en
base 64 des credentials de l’application est réversible et donc l’access_token
OAuth2 n’apporte rien et induit des des temps de calcules/réseaux
supplémentaires)
 Les ressources « Privées » qui manipulent les données liées à un utilisateur final
> Ex: /customers, /carts, /payments…
> Les enjeux consistent
+ à tracer l’application appelante
+ à vérifier que l’API manipule bien les données de l’utilisateur connecté
> Solution
+ Utiliser le flow OAuth2 adéquate

28
28/12/2018
BONNE PRATIQUE 9/9
OAUTH – PRINCIPE ET HISTORIQUE
 OAuth (Open Authorization)

> est aujourd’hui le standard de facto définissant un mode de délégation d’accès sécurisé
 OAuth propose
> à la fois un mode d’autorisation d’accès direct entre deux parties,
+ un client et un fournisseur de service (serveur),
> et entre trois partie :
+ client, partenaire (application), fournisseur de service (serveur).
> On parle de :
+ 2-legged OAuth
+ 3-legged Oauth
 OAuth est né au départ chez les Géants du Web

> en particulier Twitter et Google, qui étaient confrontés au problème de déléguer à des applications
développées par des tiers l’autorisation d’accéder aux comptes de leurs utilisateurs – à la
demande expresse de ces derniers – sans révéler aux tiers les secrets de leur utilisateurs
 OAuth 2 (standard IETF)

> A été élaboré par un groupe de travail d’experts spécialiste de la sécurité
> Apporte aujourd’hui une réponse standardisée à ce problème
> Est une solution connue des développeurs d’application
> … mais reste néanmoins complexe dans mise en œuvre côté serveur
BONNE PRATIQUE 9/9
OAUTH 1 VS. OAUTH 2 : LA STANDARDISATION
 OAuth 1, première mouture du protocole, est l’objet d’un mémo publié par l’IETF à titre
d’information – et non pas de standardisation - dans la RFC 5849
> OAuth 1 n’est donc pas un standard Internet IETF (The Internet Engineering Task Force
(IETF®)
 OAuth 1 est rendu obsolète par OAuth 2

> comme précisé dans la spécification de ce dernier (cf. ci-dessous) et dans le statut de la v1
+ RFC 5849 - The OAuth 1.0 Protocol
+ Authors: E. Hammer-Lahav, Ed.
+ Date: April 2010
+ Obsoleted by: RFC6749
 OAuth 2
> Est un standard IETF défini par la RFC 6749, à l’état «Proposed Standard » depuis Oct.
2012, et en attente de standardisation officielle.
> Rend obsolète OAuth v1
+ "This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC
5849. »
29
28/12/2018
BONNE PRATIQUE 9/9
OAUTH 1 VS. OAUTH 2 : LIMITES ET RÉPONSES
 OAuth 1 souffrait de nombreuses limites

> Conçu pour le cas d’une application Web tierce qui se connecte
+ Inadaptée pour les clients de type : Application Javascript SPA, App mobile, Jeux sur console,
Terminaux sans support de navigateur…
◦ Un contournement est possible dans certains cas, mais requiert un polling continu de
l’application tierce vers le serveur pour vérifier l’autorisation temporaire accordée, qui
implique de plus une rupture de l’expérience développeur du fait de la bascule (sans retour
automatique) vers un navigateur
+ Trop de complexité sur l’applicatif client
◦ En imposant le chiffrement et la signature des messages
 OAuth2 apporte des réponses

> en définissant 4 principaux modes possibles (+ des extensions) pour obtenir un jeton
d’autorisation
+ Code d’autorisation (application serveur Java, PHP, …)
+ Autorisation implicite (applications javascript SPA, Applications natives..)
+ Client credential (batch)
+ Resource owner password credential
> En délégant les problématiques de chiffrement et signature à la couche de transport TLS
 Fédération d’identité
> OpenID Connect est l’extension de OAuth2, pour normaliser la partie « authentification ».
BONNE PRATIQUE 9/9
Adoption OAuth 1 vs. OAuth 2 : Géants du Web & entreprises
OAuth 1 OAuth 2
30
28/12/2018
OAUTH2 : EXEMPLE DE L’IMPICIT FLOW
Applications Client-side (JavaScript) & Mobiles (native)

La cinématique suivante permet d’appeler l’API google
https://www.googleapis.com/oauth2/v1/userinfo
Authentification + Autorisation
https://accounts.google.com/o/oauth2/auth?
scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email&
client_id=MY_API_KEY&
redirect_uri=https://www.myapp.fr/oauthcallback&
response_type=token
https://www.myapp.fr/oauthcallback#access_token=ya29.AHES6ZR_PPB0uVI24crULdOi3-
7w8nnAiDsSu6XsedBUYmQ&token_type=Bearer&expires_in=3600
Validation du token
https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.AHES6ZR_PPB0uVI24crULdOi3-
7w8nnAiDsSu6XsedBUYmQ
{
"user_id": "115021724827002762647",
"scope": "https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/userinfo.email",
"expires_in": 3331,
"email": "achantalou@octo.com"
}
Appel de l’API google

curl -H "Authorization: Bearer ya29.AHES6ZR_PPB0uVI24crULdOi3-7w8nnAiDsSu6XsedBUYmQ"
https://www.googleapis.com/oauth2/v1/userinfo
{
"id": "115021724827002762647",
"email": "achantalou@octo.com",
"verified_email": true,
"name": "Antoine Chantalou",
"given_name": "Antoine", "family_name": "Chantalou",
"link": "https://plus.google.com/115021724827002762647",
"picture": "https://lh3.googleusercontent.com/-yAm1YDs-
qoc/AAAAAAAAAAI/AAAAAAAAAIA/InzouodiMoU/photo.jpg",
"gender": "male",
"birthday": "0000-05-10", "locale": "fr", "hd": "octo.com" }
61
OAUTH2 : IMPLÉMENTATION
 Librairies
> De nombreuses librairies implémentant OAuth 2.0 code serveur ou client, existent
pour les principales technologies du marché.
> Ces librairies sont notamment référencées sur le site d’OAuth à l’adresse suivante :
+ http://oauth.net/2/
 Principales implémentations Recommandations

Compte-tenu de la complexité de OAuth 2.0, il est fortement
> Java
recommandé de s’appuyer sur les librairies du marché,
+ Apache Amber (draft 22) bénéficiant d’un support de la communauté, et d’éviter de
réimplémenter l’intégralité de la norme OAuth 2.0.
+ Spring Security for Oauth
OAuth n’étant pas prescriptif sur certains aspects (format du
+ Restlet Framework (draft 30) token, etc.), ces librairies ne dispensent pas de l’écriture
d’une partie non-négligeable de code - mais fournissent un
+ Apache CXF
cadre précieux de développement.
> .NET Il est recommandé de faire réaliser un audit de sécurité pour
+ .NET DotNetOpenAuth valider l’implémentation OAuth 2.0.
> NodeJS
+ NodeJS OAuth 2.0 Provider
31
28/12/2018
SYNTHÈSE DES PRINCIPES SÉCURITAIRES DE L’API
AAA: Authentication, Authorization and Accounting

• OAuth2 : Open Authorization security protocole (AAa)
• Mécanisme Autorisation afin de pouvoir authentifier et habiliter les applications et les utilisateurs
• Couplage avec un ID provider pour gérer l’Authentification : OpenID connect préconisé
• Logs des accès aux ressources : (aaA)
• Etre capable de tracer tous les appels aux ressources (log d'IP, timestamp, ...) avec un identifiant commun (X-
Request-Id) sur le Provider OAuth2 et sur les provider de ressources
• Solution d’API Management
• Monitoring TP & rapports sur les statistiques d’usage (gateway ou plugin)
Echanges sécurisés
• Connexion HTTPS tout du long de la chaine d'appels
• HTTPS systématique lorsque l’access_token et le client_id figurent dans les URL
• Les load balancers portent les certificats HTTPS (coût) : et non les front Nginx/Apache ou les serveurs d’applications
Filtres et quotas
• Etre capable de filtrer les applications autorisées à consommer des ressources, par client_id (API key)
• Mettre en place des règles de quotas "fair use" afin de maitriser la scalabilité du socle et se prémunir des appels tiers qui
sont trop nombreux (bugs, attaque DoS/DDoS,…)
• limiter le nb d’appels par client_id (et IP source si appel serveur)
-> Front Nginx/Apache ou Firewall Applicatif ou API Management
OWASP
• Le Top 10 OWASP des failles sde sécurité doivent être adressée
• cf. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• Pas de mots de passes stockés en base, mais des hash asymétriques des “salted” passwords, via des algorithmes comme MD5
(bien) ouSHA-256/512 (mieux).
ATTAQUES API & SOLUTIONS TECHNIQUES
Attaque Description Solutions
Phishing - Une application tierce (3rd-Party) native, ou javascript tente de  Les informations de l’utilisateur : login, password, PIN, etc. ne doivent
récupérer les informations personnelles de l’utilisateur (login, mot pas être connues par les applications tierces -> utilisation de OAuth2
de passe…)
- Technique utilisée par des fraudeurs pour obtenir des  OAuth2 :
renseignements personnels dans le but de perpétrer une  Les informations de login, password sont présents uniquement sur
usurpation d'identité. les ST
 L’authentification et l’autorisation des applications tierces reste à la
main dans la DSI via paramétrage
 Portail développeur (avec validation)
“Man-in-the-Middle” MITM - L’application redirige l’utilisateur sur un “faux” site, ou les  Ou paramétrage manuel sur le provider OAuth2
ou HDM informations login/password peuvent être récupérées (api_key/client_id + redirect_uri pour les application JS)
• Difficile à remarquer par l’utilisateur en pleine écran, sans  Utilisation systématique de HTTPS
barre d’adresse
DoS / DDoS - Une attaque par déni de service « Denial Of Service attack » est - Front-end
une attaque ayant pour but de rendre indisponible un service,  Firewall applicatif
d'empêcher les utilisateurs légitimes d'un service de l'utiliser. (ou Plate-forme d’API Management)
Unauthorizeaccess - L’application effectue des actions non autorisées  OAuth2

 Gestion d’une autorisation d’accès aux API pour une application
donnée
 Niveaux de permission pour les habilitations :
 Read (GET), Write (POST/PUT/PATCH/DELETE)
 Gestion d’un plan d’url chargé au login par le provider
OAuth2 pour l’accès aux ressources via un pattern d’url
 Le provider OAuth2 retourne les droits d’accès au ressources
providers pour effectuer des contrôles d’habilitation fin coté
applicatif
 Gestion d’une autorisation implicite ou explicite pour les accès aux
données confidentielles d’un utilisateur par une application tierce
32
28/12/2018
SOAP vs REST
An addition with SOAP
Request Documentation (WSDL)
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope <wsdl:definitions targetNamespace="http://axis.test.com"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://axis.test.com"
xmlns:intf="http://axis.test.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
<soapenv:Body> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<ns0:additionner 
xmlns:ns0="http://axis.test.com" <wsdl:message name="additionnerRequest">
<wsdl:part name="valeur1" type="xsd:int"/>
<wsdl:part name="valeur2" type="xsd:int"/>
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encod </wsdl:message>
ing/"> <wsdl:message name="additionnerResponse">
<valeur1 xsi:type="xsd:int">40</valeur1> <wsdl:part name="additionnerReturn" type="xsd:long"/>
</wsdl:message>
<valeur2 xsi:type="xsd:int">2</valeur2> <wsdl:portType name="Calculer">
</ns0:additionner> <wsdl:operation name="additionner" parameterOrder="valeur1
valeur2">
</soapenv:Body> <wsdl:input message="impl:additionnerRequest"
</soapenv:Envelope> name="additionnerRequest"/>
<wsdl:output message="impl:additionnerResponse"
name="additionnerResponse"/>
Response </wsdl:operation>
</wsdl:portType>
<wsdl:binding name="CalculerSoapBinding" type="impl:Calculer">
<soapenv:Envelope <wsdlsoap:binding style="rpc"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="additionner">
xmlns:xsd="http://www.w3.org/2001/XMLSchema" <wsdlsoap:operation soapAction=""/>
<wsdl:input name="additionnerRequest">
<wsdlsoap:body
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
<soapenv:Body> namespace="http://axis.test.com" use="encoded"/>
<ns1:additionnerResponse </wsdl:input>
xmlns:ns1="http://axis.test.com" <wsdl:output name="additionnerResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encod namespace="http://axis.test.com" use="encoded"/>
ing/"> </wsdl:output>
<additionnerReturn href="#id0" /> </wsdl:operation>
</ns1:additionnerResponse> </wsdl:binding>
<wsdl:service name="CalculerService">
<multiRef <wsdl:port binding="impl:CalculerSoapBinding" name="Calculer">
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" <wsdlsoap:address
id="id0" soapenc:root="0" location="http://localhost:8080/TestWS/services/Calculer"/>
</wsdl:port>
</wsdl:service>
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encod </wsdl:definitions>
ing/"
xsi:type="xsd:long">42</multiRef>
</soapenv:Body>
</soapenv:Envelope>
SOAP vs REST
SOAP limitations Not T2M No ATAWAD
1 2
◉ Slow security (VPN) ◉ SPA, native mobile apps
◉ Bad DX need Json REST APIs
◉ Bad TTFAC ◉ A REST Façade is always
required in front of SOAP
servers
Performances
6 issues SIX 3
Interop issues
◉ Between different SOAP

◉ XML is time-consuming
and require a high CPU
usage
reasons ◉
versions (1.0, 1.1, 2.2)
Content-Type and encoding
often break xml parsing
◉ WS-Security implies heavy
processing of XML request to avoid ◉ Different stacks : CXF, AXIS,
etc.
Different technologies : Java,
SOAP
◉
PHP, .NET, Nodejs, etc
Bad maintainability Tech trend

5 4
◉ Updating an existing ◉ Developers don’t want to
service may ask to use SOAP anymore, they
redeploy client that are prefer REST
already deployed
OCTO ACADEMY > LEARN TO CHANGE > CONFIDENTIEL
33
28/12/2018
SOAP VS REST
Web Giants : API means REST
API REST SOAP Comment

SOAP support over HTTP is
deprecated, but it is still available over
☑ ☒
HTTPS. New Amazon S3 features will
Amazon S3 not be supported for SOAP. We
recommend that you use either the
REST API or the AWS SDKs.
Amazon EC2 ☑ -
Facebook
Google
☑
☑
-
-
Web
Twitter
Paypal
☑
☑
-
-
Giant
Instagram ☑ -
Pinterest ☑ -
LinkedIn ☑ -
TripAdvisor ☑ -
Expedia EAN has discontinued support for
☑ ☒
SOAP. See our SOAP to REST
Affiliate migration guide for details on changes
Network required for affected integrations.
OCTO TECHNOLOGY > THERE IS A BETTER WAY
Composants distribués: MicroService
 Les microservices sont de petits services autonomes qui travaillent ensemble
> Simples
> Scalables
> Composables
> Facilement déployables
> Technos hétérogènes
> Facilement testables
> Mappent une organisation
humaine
> Application résiliente
> Des enjeux business
> Des use cases
> Des business rules
> Un référent par domaine
> Une approche par expérience utilisateur
34
28/12/2018
Applications n-tiers: Problématiques
 Applications n-tiers à base de composants = composants distribués avec

responsabilités distribuées
 Problématiques :
> Complexité
> Conception des composants et des applications
> Développement des composants et des applications
> Gestion des aspects transverses : sécurité, disponibilité, communication,
persistance, transactions…
> Interopérabilité des composants
> Administration des composants et des applications
> Sécurisation de bout en bout des applications
Pour mieux gérer les applications n-tiers, l’utilisation des

serveurs d’application et les Frameworks est fortement
recommandé.
Serveurs d’application & frameworks de développement
 Serveur d’Applications (SA) = conteneur et fournisseur de services pour des

composants et des applications
> Gestion du cycle de vie des applications et des composants
> Administration des applications et des composants
> Allocation de ressources
> Processeur, mémoire, réseau, composants logiciels externes…
> Support pour les aspects transverses
> Sécurité, gestion des transaction, accès réseau…
> Support pour l'interopérabilité
 Frameworks de développement
> Cadres pour la conception et le développement de composants (déployés sur SA) et
d'applications à base de composants
35
28/12/2018
Patrons de d’architecture
MVC
MVW
Patrons
MVVM
d’architecture Clean Architecture
logiciel
MVP Onion Architecture
36
28/12/2018
Patrons de d’architecture: MVC (Modèle-Vue-Contrôleur)
 Le patron MVC est le premier à avoir été défni en 1979 par Trygve Reenskaug pour les
applications SmallTalk. Néanmoins, c’est un patron qui est aujourd’hui rarement utilisé
tel que pour les frameworks d’application parce que la séparation des responsabilités
n'est pas complète.
 Dans ce patron la répartition des responsabilités est faite entre trois parties:
> Le modèle contient la logique métier et l’état courant de l’interface durant le cycle
dialogue avec l’utilisateur. Il peut être aussi simple qu’une valeur entière ou aussi
complexe qu’un service nécessitant plusieurs niveaux de traitement avec
persistance des données.
> La vue porte toute la logique de présentation. Son travail consiste à afcher les
données du domaine et à recevoir des interactions de l'utilisateur. La partie vue peut
évidemment être composée de plusieurs « fenêtres » graphiques différentes. La vue
ne gère pas les interactions avec les utilisateurs mais les délègue à un autre
composant : le contrôleur.
> Le contrôleur reçoit les interactions de l’utilisateur de la vue et les traite en modifant
le modèle. Le code à l’intérieur du contrôleur correspond essentiellement à du code
de liaison (glue code) entre la vue et le modèle
Patrons de d’architecture: MVC (Modèle-Vue-Contrôleur)
 Une fois le modèle modifé, il est nécessaire d'afcher les données mises à jour vers
l'utilisateur.
 Le grand intérêt de ce patron est sa capacité d’extension
 Le problème avec MVC est que non

seulement la vue afche les données
mais elle est aussi responsable de
récupérer ces données auprès du
modèle. Cela signife que la vue a
deux raisons de changer : quand les
conditions d'afchage des données
sont modifées et quand la représentation
de ces données est modifée. C’est
particulièrement néfaste. L'interface
utilisateur ne devrait pas dépendre de la
manière dont les données sont organisées dans le modèle du domaine.
37
28/12/2018
Patrons de d’architecture: MVP
 Une manière d'améliorer MVC est de réduire le couplage entre la vue et le modèle. Si
nous établissons une règle selon laquelle toutes les interactions entre la vue et le
modèle doivent passer par le contrôleur, le contrôleur devient le lieu unique pour la
mise en œuvre de la logique de présentation et la vue est déchargée de toute logique.
Le contrôleur devient alors une présentation.
 Le modèle est uniquement centré sur la

logique métier. Il n’a plus rien à voir avec le
dialogue avec l’utilisateur. Le modèle est
totalement indépendant des autres parties.
 La vue ne concerne que la gestion graphique.
 La présentation contient toute la logique de

présentation ainsi que l’état courant du
dialogue. Elle sait comment réagir aux
événements de l'utilisateur en modifiant les
données du domaine si nécessaire puis en
répercutant les effets vers la vue.
Patrons de d’architecture: MVP
 Chaque vue à son propre presenter qui communique avec un ou plusieurs Model
 Le côté négatif est que la présentation contient maintenant beaucoup de code

redondant (boilerplate code) . À chaque fois qu'un retour d'information sur la vue est
nécessaire, c'est la présentation qui prend des mesures.
38
28/12/2018
Patrons de d’architecture: MVVM
 Le patron MVVM est fondamentalement le même que MVP, à l'exception d'une

différence majeure. Le retour d'information n'est plus pris en charge par la présentation
mais par un mécanisme de liaison de données (data binding).
 La présentation devient la vue-modèle, c'est-à-dire un modèle qui permet d'accéder
aux données prêtes à l'afchage dans la vue
 Dans MVP, la présentation pousse ces données vers la vue, dans MVVM la vue tire
ces données de la vue-modèle.
 Le modèle reste le même que pour le patron MVP.

Il ne contient donc que la logique métier.
 La vue ne contient aucune logique. La différence

avec MVP réside dans l’utilisation de liaisons entre
des composants de la vue et des attributs de la
vue-modèle.
 La vue-modèle contient la logique de présentation

et l’état de l‘interface comme la présentation de
MVP.
Patrons de d’architecture: MVW (Model-View-Whatever)
39
28/12/2018
Patrons de d’architecture: Clean architecture
 La clean architecture permet de mieux gérer

l’application en désassociant les cas
d’utilisations métier.
 L’entities : c’est le modèle de données de

l’entreprise.
 Le repository: consiste à définir toutes les

transactions vers les base de données, service,
ou connexion réseaux en général
 Les use case: consiste à définir les règles de

gestion de l’application pour faciliter l’interaction
entre le presenter et le modèle.
 Le presenter joue se charge de mettre à jour

l’interface utilisateur en envoyant des
commandes
Patrons de d’architecture: Onion architecture
 Le principe de l’architecture onion

se base sur les couches.
 Tout le code dépend des couches

plus proches ou du centre
 Les modèles de domaine seront au
centre ou au cœur
 La couche Inner définit les
Interfaces où la couche externe
implémente ces interfaces membres
 Le Comportement est définit autour
du domaine
 Infrastructure, qui contiendrait des
données et l'implémentation du
service devrait être poussé au bord.
 Avec l'infrastructure, les problèmes
d'interface utilisateur sont
également poussés à la limite.
40
28/12/2018
Infrastructures logicielles
 Infrastructure logicielle = logiciel rendant des services aux applications

> Exemples de services : communication, administration, exécution, sécurité…
 Interface entre les applications et l'architecture matérielle

> en dessous des applications
 Exemples :
> Serveur web
> Serveur de bases de données
> Annuaire
> Serveur de fichiers
> Serveur d'applications
> Middleware (solution d'intégration)
Architecture des flux et echanges d'informations
 Flux = données qui passent d’un point A à un point B

> D’une application à une autre,
> D’un module applicatif à un autre
> D'un utilisateur à un autre
> D’une base de données à une autre
> D’une entreprise à une autre
 Exemples de flux
> Transfert de fichier
> Partage de fichier
> Appel de procédure distant
> Requête sur une base de données
41
28/12/2018
Périmètre
Granularité / Fréquence
42
28/12/2018
Granularité / Fréquence
 Souvent pour les flux unitaires au fil de l'eau (« événementiels ») :

> Appels distants entre composants (CORBA, RMI…)
> Transferts de fichiers Partage de base de données
> Electronic Data Interchange (EDI) = norme définissant le(s) protocole(s) + le format
d'échange de données pour le B2B
> Web Services
 Souvent pour les flux de masse cadencés (« batch ») :

> Transferts de fichiers
> Partage de base de données
> Batch = script qui ordonne et cadence un déplacement de données en volume
> Solution « historique » et sans doute encore l'une des plus utilisées
> Extract-Transform-Load (ETL) = progiciel de batch « à grande échelle » permettant
de connecter des entrepôts de données
Architecture des flux
43
28/12/2018
08 OUTILS D’ANALYSE ET
D’IMPLÉMENTATION
OUTILS D’ANALYSE ET D’IMPLÉMENTATION
Débogage Performance
Usine de Qualité de
développement code/couverture
Tests
Sécurité
unitaires/intégrations
44
28/12/2018

Débogage
 Le debug est une inévitable et nécessaire partie de tout cycle de développement.
 Le débogueur permet d'avancer pas à pas dans du code et de l’examiner ou de le

modifier, afin de retrouver et de corriger les bugs.
 Chaque environnement de développement est doté d’un débogueur qui permet

d’analyser le comportant d’un code source.
 Un débogueur, qu'il soit en ligne de commande ou possédant une interface proposera

(entre autres) les fonctionnalités suivantes :
> la possibilité de placer des points d'arrêt ;
> la possibilité de voir les valeurs des variables ;
> la possibilité d'afficher la pile d'appels ;
> la possibilité d'exécuter le programme pas à pas.
Il est très recommandé d’utiliser un débogueur que d’afficher des

messages pour tracer le comportement d’un programme

Tests unitaires/intégrations
 Il y a de nombreux outils de tests unitaires, avec la famille xUnit occupant une place
prépondérante.
 Dans le monde Java, JUnit est le standard de facto, bien que TestNG soit aussi un
framework de test unitaire populaire avec un certain nombre de fonctionnalités
innovantes.
 Pour les applications C#, le framework NUnit propose des fonctionnalités similaires à
celles fournies par JUnit, comme le fait Test::Unit pour Ruby. Pour C/C++, il y
a CppUnit, et les développeurs PHP peuvent utiliser PHPUnit.
 Ces outils peuvent aussi être utilisés pour les tests d'intégration, les tests fonctionnels,
les tests web et ainsi de suite. De nombreux outils de tests web, comme Selenium,
WebDriver, et Watir, génèrent des rapports compatibles xUnit.
 Les outils xMock permettent de mocker des objets pour simuler certains comportement
 Les outils Behaviour-Driven Development et de tests d'acceptation automatisés comme

easyb, Fitnesse, Concordion sont aussi orientés xUnit.
45
28/12/2018

Performance
 Les tests de performance sont très importants dans le cycle de vie et surtout la
validation des logiciels.
 On pourra distinguer deux familles d’outils: outils de tests de charge et outils de tests
de profiling.
> Test de charge: pour simuler des utilisateurs qui utilisent l'application. Dans cette
catégorie :
+ jmeter,
+ Opensta
+ grinder
> Profiling: pour mesurer le temps passé dans les différents appels de méthodes.
Dans cette catégorie :
+ jprobe,
+ jprofiler,
+ Netbeans Profiler,
+ viusalVM
+ Yourkit.

Qualité de code/couverture
 SonarQube est un logiciel open-source permettant d’analyser la qualité du code source d'un
projet de développement dans de multiples langages (JAVA, Javascript, PHP, C# …).
 La qualité est analysée sur les points suivants :

> Duplication de code
> Documentation
> Tests unitaires et couverture de code
> Règles de programmation
> Analyse de la complexité
> Bugs potentiels
 La couverture de code donne une indication sur les parties de votre application qui ont été
exécutées pendant les tests. Alors que ce n'est pas en soit une indication suffisante sur la
qualité du test.
 Il y a de nombreux outils de couverture de code disponibles, et plusieurs sont supportés

dans Jenkins, tous via des plugins dédiés. Les développeurs Java peuvent choisir entre
Cobertura et Emma, deux outils populaires de couverture de code open source, ou Clover,
un puissant outil commercial de couverture de code d'Atlassian. Pour les projets .NET, vous
pouvez utiliser NCover.
 Cobertura est un outil de couverture de code open source pour Java et Groovy qui est
simple d'utilisation et s'intègre parfaitement à la fois dans Maven et Jenkins.
46
28/12/2018

Sécurité
 L’audit de code a pour but de rechercher des vulnérabilités dans le code source d’une
application. Ces vulnérabilités sont de plusieurs types : erreurs de conception et
erreurs de développement.
 Il existe des outils analysant le code source afin d'y détecter des erreurs de
programmation ou même des problèmes de sécurité.
> FindBug
> PMD pour java
> FxCop pour dotNET
> IBM Rational AppScan Source
> HP Fortify
> SonarSource

Usine de développement
 C’est une usine logicielle, contenant des outils pour le développement et permettant
d’automatiser tout ce qui peut l’être et ce dans le processus de construction logiciel.
 Elle joue un rôle important dans l’industrialisation des développements : c’est la clé de
voûte de l’intégration continue. Elle permet aussi de construire les livrables sous forme
de versions de/des applications.
47
28/12/2018
09 VALIDATION DES LOGICIELS
DE L’IMPORTANCE DE LA STRATÉGIE DE TESTS...
• Approche traditionnelle : • Approche agile:

Trouver les bugs Prévenir les bugs
TESTS MANUELS
TESTS IHM
TESTS DE
SERVICES
TESTS
UNITAIRES
48
28/12/2018
QU’EST-CE QU’UN TEST ?
◉ La description d’un comportement technique ou fonctionnel qu’on veut valider
◉ Tester quoi ?
> Un bout d’une application
> Une application isolée
> Les interactions entre applications
> Une fonctionnalité métier fournie par plusieurs applications
> Les fonctions d’un SI (création de VM…)
◉ Sous quelles formes ?

> Ecrit dans le code, la documentation
> Automatisé ou manuel
POURQUOI TESTER ?
◉ Préserver la qualité
> Les tests mettent en évidence les régressions
◉ Améliorer la productivité
> Les tests évitent de reproduire les mêmes erreurs aux mêmes endroits
> Les tests automatisés doivent être fréquemment rejoués, mitigeant la loi
du « Defect Cost Increase »
◉ Réduire les phases de recette et leur faire apporter plus de valeur
> Des tests automatisés filtrent des bugs avant la phase de recette, elle
peut alors se concentrer sur les cas plus compliqués qui n’étaient pas
testés jusque là
◉ Assurer la bonne implémentation des fonctionnalités
> Par la collaboration des équipes fonctionnelles et techniques sur la
définition des tests validant une fonctionnalité
> Les développements s’articulent autour de ces tests
Loi du « Defect Cost Increase » : Plus un bug est détecté tard plus il devient difficile à corriger
49
28/12/2018
QUELQUES TYPES DE TESTS
Foncti
onnel
Tests de recette UAT

automatiques Tests d’usabilité
Tests d’ensemble de Validation de cas
fonctionnalités d’utilisation
Développe
Admin
ur
Tests de performance
Tests unitaires
Tests de disponibilité
Tests d’intégration
Tests de sécurité
Techni
que
OÙ TESTER ?
◉ Dans des environnements spécialisés
◉ L’UDD (Usine de développement) pour les tests automatisés

> Rejeu sur modification de la base de code ou périodique
> D’abord pour les tests unitaires : sur des morceaux isolés de l’application
donc rapides
> Souvent pour les tests d’intégration : sur l’interaction de plusieurs
morceaux de l’application avec des composants externes (avec bouchon
ou non)
◉ Les environnements de non production dans le SI:

> Développement : instable, pour des validations fonctionnelles sur les
dernières implémentations
> Qualification et préproduction : pour les tests de recette avec une
infrastructure au plus proche de l’environnement de production
50
28/12/2018
TESTS ET SERVICES
◉ Pour les architectures de services, il est vital de tester les interactions entre
applications, cela demande de bien s’outiller et d’être rigoureux
◉ Pour les tests bouchonnés chaque application doit fournir des bouchons
couvrant les cas représentatifs
◉ Des environnements de recette mal gérés ralentissent les projets et créent
des frictions
> Il faut monitorer les environnements
> Les applications doivent être opérationnelles : les projets doivent être
responsabilisés
> Leur utilisation doit être régulée
o Cycle de vie des données
o Cycles de vie des applications
◉ Pour des applications avec des cycles de vie différents il faut multiplier les
environnements; l’automatisation est alors primordiale
TEST DES SYSTÈMES EN PRODUCTION
◉ « If we aren’t constantly testing our ability to succeed despite failure, then it

isn’t likely to work when it matters most » - Netflix
Synoptique
• Le monitoring du système d’information alerte du problème et de ses

conséquences
• Les équipes apprennent à faire évoluer le système pour réduire
l’impact de cet échec
Solution : Simian Army
• Chaos Monkey : Termine aléatoirement une machine virtuelle d’un

groupe de réplicas
• Latency Monkey : Ajoute de la latence dans les communications
client-serveur
• Chaos Gorilla : Simule l’arrêt d’une zone Amazon
51
28/12/2018
LES TESTS DE VALIDATION AUTOMATISES CUCMBER/JUNIT
MÉTRIQUES
52

Cours AGL ENSA 2017-2018 CH7-9

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours AGL ENSA 2017-2018 CH7-9

Transféré par

Droits d'auteur :

Formats disponibles

28/12/2018

Développements spécifiques Progiciels

 CRM (Customer Relationship

Pourquoi pas louer des services sur le Cloud ?

 3 types de responsabilités = 3 couches principales

 Principe de conception = séparation des responsabilités

 Vue plus fine des responsabilités

 Modèle Client-Serveur = 2 programmes +1 protocole

 Indépendant de la notion de « machine »

 Distribution des couches entre client et serveur

 L’application est sur un serveur (éventuellement distant)

 L’application est sur le client

 Le cœur de l’application est sur un serveur (éventuellement distant)

 Le cœur de l'application est sur un serveur

 Généralisation des modèles précédents

 Application de gestion de catalogue de produits

 Composant = unité logique de traitement

 Technologies d’implémentation multiples

 Un Client veut utiliser un composant qui se trouve sur un Serveur (distant)

 Plusieurs solutions permettent d’invoquer des composants distribués

 CORBA est une architecture logicielle pour le développement de composants et

 SOAP définit le cadre général pour l’échange de données structurées en XML

URI = Uniform Resource Identifier (bookmarkable, etc.)

Resource state representation

C’EST QUOI REST

 Representational State Transfert

OCTO TECHNOLOGY > THERE

DESIGNER UNE API

 Le design d’une API est-il important ?

> API destinée à l’entreprise et aux partenaires

+ Le TTFAC (Time To First API Call) désigne le temps nécessaire à un

> Open API

OCTO TECHNOLOGY > THERE

DESIGNER UNE API

 Design d’API a l’état de l’art : deux approches

 KISS – « Keep it simple, stupid »

 Affordance – c’est à dire de la capacité de l’API à suggérer son utilisation

OCTO TECHNOLOGY > THERE

URI = Uniform Resource Identifier (bookmarkable, etc.)

Resource state representation

OCTO TECHNOLOGY > THERE

LE MODÈLE DE MATURITÉ DE RICHARDSON

RICHARDSON MATURITY MODEL

 Développé par Léonard Richardson

OCTO TECHNOLOGY > THERE

NIVEAU 0 - LE RPC SUR HTTP EN POX

1/2 PLAIN OLD XML

 Le protocole est uniquement utilisé à des fins de transport du message

OCTO TECHNOLOGY > THERE

NIVEAU 0 - LE RPC SUR HTTP EN POX

2/2 PLAIN OLD XML

OCTO TECHNOLOGY > THERE

 Resources sont identifiées avec URI

+ Niveau 1 : Ajout de la notion de ressources

OCTO TECHNOLOGY > THERE

OCTO TECHNOLOGY > THERE

getClient(1) GET /customers/1

> API REST == HTTP comme protocole applicatif

OCTO TECHNOLOGY > THERE

NIVEAU 2 - VERBES ET CODES RETOURS HTTP

+ Niveau 2 : Ajout de verbes de statut et de codes d’état

OCTO TECHNOLOGY > THERE

NIVEAU 2 - VERBES ET CODES RETOURS HTTP