156
Laboratoire d'InfoRmatique en Image et Systèmes d'information LIRIS UMR 5205 CNRS/INSA de Lyon/Université Claude Bernard Lyon 1/Université Lumière Lyon 2/Ecole Centrale de Lyon http://liris.cnrs.fr/ De l’Internet au Web des objets Lionel Médini Michael Mrissa Domaine des Hautannes 03/09/2013 École d’été WIoT - 02/09/2013

De l’Internet au Web des objets - perso.liris.cnrs.fr · IoT Internet of Things L’internet des choses Le réseau interconnectant les objets de tous les jours Sous entendu : objet

Embed Size (px)

Citation preview

Laboratoire d'InfoRmatique en Image et Systèmes d'information LIRIS UMR 5205 CNRS/INSA de Lyon/Université Claude Bernard Lyon 1/Université Lumière Lyon 2/Ecole Centrale de Lyon

http://liris.cnrs.fr/

De l’Internet au Web des objets

Lionel Médini

Michael Mrissa

Domaine des Hautannes – 03/09/2013

École d’été WIoT - 02/09/2013

Plan de la présentation

Introduction et historique

Internet, IoT, TCP/IP, les systèmes distribués, le Web

Les technologies du Web

Technologies de base (URI, HTML, HTTP)

Programmation côté serveur (servlets)

Programmation côté client (JavaScript, AJAX)

Aperçu des bibliothèques / frameworks disponibles (jQuery)

WebSockets

Services Web

Web sémantique

Services Web sémantiques

Conclusion

Le WoT

2

Rappel : Internet

Un réseau de réseaux interconnectés (d’où le nom)

Un ensemble de matériels, logiciels et protocoles (notamment IP)

Un ensemble de services Application qui utilise un protocole et un numéro de port

e-mail, transfert de fichiers, connexion à distance, WWW…

Une somme « d’inventions » qui s’accumulent Mécanismes réseau de base (TCP/IP)

Nommage et adressage des ressources (DNS, URL)

Outils et protocoles spécialisés

Langages d’échange d’informations standardisés (HTML, XML…)

Introduction et historique 3

IoT Internet of Things

L’internet des choses

Le réseau interconnectant les objets de tous les jours

Sous entendu : objet avec une pile TCP/IP ?

Pas forcément, si interactions limitées

(Sean Dodson, 2003) "IoT" can be expressed as the building of a

global infrastructure for RFid tags. You could think of it as a wireless

layer on top of the internet where millions of things from razor blades

to euro banknotes to car tyres are constantly being tracked and

accounted for. A network … is for computers to identify "any object

anywhere in the world instantly". "Put a tag - a microchip with an

antenna - on a can of Coke or a car axle, and suddenly a computer

can 'see' it. Put tags on every can of Coke and every car axle, and

suddenly the world changes.

Introduction et historique 4

IoT Internet of Things

Notion de large échelle

Les définitions parlent d’intégrer « tous les objets »

Richesse : création d’interactions spontanées à partir de

combinaisons d’objets non prévues

Dangers : contrôle sur le vivant et l’humain (tags RFID)

Point de vue technologique

cf présentation JP Jamont hier

Limitation au niveau IP ? => IPv6

Introduction et historique 5

Feuille de route technologique

Introduction et historique 6

Genèse du Web : la notion d’hypertexte

Principe S’abstraire de l’aspect linéaire du document textuel

Mécanisme intellectuel permettant le cheminement d’une information à une autre navigation, butinage, transclusion

Historique 1945 : invention de la notion d’hypertexte

Vannevar Bush, As We may think, Atlantic Monthly, 1945

1965 : invention du terme d’hypertexte

Ted Nelson, projet Xanadu

Années 1960 : premier système hypertexte fonctionnel

NLS (oNLine System), Douglas Englebart

1987-2004 : diffusion du logiciel HyperCard

Programme et environnement graphique de programmation, créé par Bill Atkinson pour Mac OS, livré avec les Mac

1987 : première conférence HyperText

Sponsorisée par l’ACM

Introduction et historique 7

World Wide Web

Principe original : accéder à des documents textuels

situés sur des machines accessibles par Internet

reliés entre eux par un mécanisme de lien « hypertexte »

Actuellement : servir des ressources

De différentes natures : texte, image, son, vidéo, contenu

applicatif…

Hypermédia

Interactives

Permettant à l’utilisateur d’accéder à un service donné :

rechercher de l’information, acheter un objet, accéder à ses

mails, consulter ses comptes en banque…

Nombreuses évolutions techniques

Introduction et historique 8

Usages du Web (2008)

Consultation simple (Web 1.0) Navigation

Recherche d’informations

Divertissement TV, radio, musique, vidéo en ligne

Information

Jeux

Communication Asynchrone (Webmail)

Synchrone (Web chat, Webconférence)

Web 2.0 Travail collaboratif : partage / édition de documents sur des intranets

Autres sites participatif (blogs…)

Réseaux sociaux

Consommation de services Sites marchands, enchères

Autres services en ligne : banque, administration…

Sources : Journal du Net (http://www.journaldunet.com), Ipsos (http://www.ipsos.fr), Carrefour Numérique (http://carrefour-numerique.cite-sciences.fr)

Introduction et historique 9

Aspects techniques du Web

Les 3 mécanismes de base du Web URL

Le Web permet d’accéder à un ensemble de ressources

Le mécanisme de localisation peut faire appel au protocole DNS

HTML

Langage de description de « pages Web »

Texte, images et autres objets

Liens hypermédias entre les pages

Programmation déclarative

HTTP

Protocole de niveau applicatif

Paradigme client-serveur

Protocole sans état (pas de « mémoire » des transactions précédentes)

Introduction et historique 10

URI, URL et URN

URI : Uniform Resource Identifier But : identifier de façon unique une ressource sur le

web En disant où elle se trouve

Donner son URL (Uniform Resource Locator)

Format : protocole ":" chemin "/" nom de fichier "/" requête

http://www.w3.org/2001/XMLSchema

Permet d’accéder réellement à la ressource (tant qu’elle existe)

Enregistrement des DNS auprès de l’entité concernée

URI 11

URI, URL et URN

URI : Uniform Resource Identifier But : identifier de façon unique une ressource sur le

web En disant comment elle s’appelle

Donner son URN (Uniform Resource Name)

Format : "URN:" NID (namespace identifier) ":" NSS (namespace specific string)

URN:ISBN:0-395-36341-1

Choix plus « libre », et correspondant mieux à la définition d’un espace de noms

Enregistrement des NID à l’IANA (Internet Assigned Numbers Authority)

URI 12

URI, URL et URN

URI : Uniform Resource Identifier

But : identifier de façon unique une ressource sur le web

Syntaxe générique

« scheme » ":" autorité ":" chemin ":" requête ":" fragment

Avec le temps, on s’est mis à penser que « urn » peut aussi être un

URI scheme

On n’utilise plus que la notion d’URI pour désigner les

ressources

URI 13

URI, URL et URN

On parle maintenant aussi d’IRI

Internationalized Resource Identifier

Une IRI est une URI acceptant des caractères Unicode

Exemple :

Remarque : nécessite un protocole similaire à DNS, mais gérant les

noms de domaine Unicode : Internationalized Domain Name (IDN)

Référence : http://www.w3.org/International/articles/idn-and-iri/

URI 14

Introduction aux langages à balises

Quelques langages dédiés au Web

SGML

XML HT

ML

SO

AP

/RP

C

Math

ML

SV

G

SM

IL

P3P

PIC

S

RD

F

OW

L

RD

F-S

chém

a

XS

L

XH

TM

L

Applications

(DTD) SGML

Applications

XML

Surcouches

RDF

SGMLSGML

XML XML HT

ML

HT

ML

SO

AP

/RP

CS

OA

P/R

PC

Math

ML

Math

ML

SV

GS

VG

SM

ILS

MIL

P3P

P3P

PIC

SP

ICS

RD

FR

DF

OW

LO

WL

RD

F-S

chém

aR

DF

-Schém

a

XS

LX

SL

XH

TM

LX

HT

ML

Applications

(DTD) SGML

Applications

XML

Surcouches

RDF

HTML

DTD SGML : ensemble (dé)fini d’éléments SGML

Destiné à visualiser des hyperdocuments sur écran

Interprété côté client par les navigateurs

V. 1.0 : 1992 -> V. 4.01 (dernière…) : oct. 1997

Souvent associé à d’autres langages

CSS : langage de feuilles de style

Langages de scripts : JavaScript, JScript, VBscript…

Inclusion d’objets définis dans d’autres langages : applets

Java, contrôles ActiveX…

Remarque : le langage D(H)TML n’existe pas

HTML 16

XHTML

DTD XML : ensemble (dé)fini de balises XML

But initial : réécrire HTML, mais en plus propre

V. 1.0 : janv. 2000, révisée en 2002

Trois recommandations

XHTML frameset

XHTML transitionnel

XHTML strict

Séparation du fond et de la forme

Pris en charge par tous les navigateurs récents

Pris en charge par les outils de traitement XML

HTML 17

HTML

HTML 5 : http://www.w3.org/TR/html5/

Historique

A l’origine (fin 2003) : initiative d’Opera pour harmoniser Xforms et

HTML dans son navigateur

Par extension : un langage qui prendra en charge les différentes

fonctionnalités des « Web applications »

Proposition de création d’un GdT du W3C rejetée (début 2004)

Finalement, création du Web Hypertext Application Technology

WG (WHATWG) en 2006 sous la pression d’Apple, Mozilla et Opera

Principes de développement

Don't Reinvent The Wheel

Pave The Cowpaths (!) : (X)HTML, CSS, DOM, EcmaScript…

HTML 18

HTML

HTML 5 : http://www.w3.org/TR/html5/

Détails des spécifications

Un langage de représentation abstrait

Description de documents et d’« applications Web »

API d’interaction avec les représentations mémoire de ces

ressources (DOM)

Deux syntaxes concrètes

HTML5 : pour les contenus de type HTML, destinés à être traités

par un navigateur

XHTML5 : pour les contenus de type XML, destinés à être parsés

puis traités par une application particulière

Dernière version : Candidate Recommendation du 6 août 2013

Date initiale de sortie de la spec. : avant octobre 2010…

HTML 19

Le protocole HTTP

Rappels

HTTP : Hyper Text Transfer Protocol

Dédié au Web (origine : CERN, 1990)

RFC 2616 (HTTP 1.1)

Fonctionne en mode client / serveur

Port standard : 80

Protocole sans état Gestion légère des transactions

aucune information conservée entre 2 connexions

permet au serveur HTTP de servir plus de clients

Nécessite un mécanisme de gestion des sessions

cookie, Id dans l’URL, champ caché de formulaire...

HTTP 20

Différentes versions de HTTP

HTTP 0.9 : version d’origine Une seule méthode : GET

Pas d'en-têtes

Une requête = une connexion TCP

HTTP 1.0 : améliorations (1) introduction d’en-têtes (échange de "méta" info)

utilisation de caches

méthodes d'authentification...

HTTP 1.1 : améliorations (2) mode connexions persistantes par défaut

plusieurs transactions HTTP (ressources) pour une connexion TCP

la connexion est maintenue tant que le serveur ou le client ne décident pas de la fermer (connection: close)

introduction des serveurs virtuels

la directive Host dans la requête est nécessaire

HTTP 21

Format des requêtes

Commande HTTP

Méthode : GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS,

CONNECT

URL à partir de la racine du serveur

Version HTTP

En-têtes (ensemble de lignes)

Nom de l’en-tête

Deux-points

Valeur de l’en-tête

Une ligne vide

Contenu (éventuel)

Passage de paramètres à traiter par le serveur

HTTP 22

La méthode GET

Méthode standard de requête d'un document

récupérer un fichier, une image...

activer un programme en lui transmettant des données

Le corps (contenu) de la requête est toujours vide

Ajout de paramètres après le nom de la ressource Transmission des données dans l'URL après un ?

Les champs sont séparés par un &

Remarques Toutes les données sont transmises en clair et visibles

dans l’URL

L'URL a une taille limitée (4Ko)

GET /cgi-bin/[email protected]&pass=toto&s=login HTTP/1.1

HTTP 23

La méthode POST

Transmission des données dans le corps de la

requête

Les données sont également transmises en clair

POST /cgi-bin/prog.cgi HTTP/1.1

User-Agent: Mozilla/5.0 (compatible;MSIE 6.0;Windows NT 5.1)

Host: localhost

Accept: */*

Content-type: application/x-www-form-urlencoded

Content-length: 36

[email protected]&pass=toto&s=login

HTTP 24

Format des réponses

Type de la réponse

Version HTTP

Code de la réponse

Description du code

En-têtes (ensemble de lignes)

Nom de l’en-tête

Deux-points

Valeur de l’en-tête

Une ligne vide

Contenu éventuel

Ressource encodée en fonction du type MIME spécifié

HTTP 25

Codes de réponses

Les codes de réponse Indiquent le résultat de la requête : succès ou échec

En cas d'échec, le contenu de la réponse en décrit la raison fichier non présent, problème de droit

Classes de codes 100-199 : information

200-299 : succès

300-399 : redirection

400-499 : échec dû au client

500-599 : échec dû au serveur

Plus d’infos http://www.codeshttp.com/

HTTP/1.1 200 OK

HTTP/1.1 304 Not Modified

HTTP/1.1 403 Forbidden

HTTP/1.1 404 Not Found

HTTP/1.1 500 Internal Server error

HTTP 26

Une transaction typique (1)

Requête du client : client serveur

1. demande du document test.html

GET /~lmedini/MIF13/test.html HTTP/1.1

2. envoi des informations d'en-tête : informer le serveur

- configuration

- documents acceptés

User-Agent: Mozilla/5.0 (compatible;MSIE 6.0;Windows NT 5.1)

Host: www710.univ-lyon1.fr

Accept: image/gif, image/jpeg

3. envoi d'une ligne vide (fin de l'en-tête)

4. envoi du contenu (vide dans cet exemple)

HTTP 27

Une transaction typique (2)

Réponse du serveur : serveur client 5. code indiquant l'état de la requête

HTTP/1.1 200 OK

6. envoi des informations d'en-tête : informer le client

- configuration du serveur

- document demandé Date: Tue, 30 Sep 2008 06:11:28 GMT

Server: Apache/1.3.34 (Debian) PHP/5.2.1

Last-Modified: Tue, 30 Sep 2008 06:11:14 GMT

ETag: "600593b3-61-48e1c302"

Accept-Ranges: bytes

Content-Length: 97

Content-Type: text/html; charset=iso-8859-1

3. envoi d'une ligne vide (fin de l'en-tête)

4. envoi du contenu si la requête a réussi HTTP 28

Encodage des ressources

Position du problème

Un serveur Web peut servir différents types de ressources :

texte, pages Web, images, documents, fichiers

exécutables…

Chaque type de ressource est codé de façon différente

Un client doit connaître le type de ressource pour pouvoir

la traiter :

visualisation dans un navigateur, utilisation d’un plugin,

application externe

Solution (HTTP et Internet en général)

MIME : Multi-purpose Internet Mail Extensions

Prise en charge de MIME dans HTTP : depuis V1.0

HTTP 29

Encodage des ressources

Types MIME : composition

Type général : text, image, audio, video, application...

Sous-type : dépend du type général

Exemples : image/gif, image/jpeg, application/pdf,

application/rtf, text/plain, text/html

En perpétuelle évolution

Types MIME : utilisation

Le serveur positionne le header Content-type

Content-Type: text/html; charset=UTF-8

Le client associe chaque type MIME à un type de prise en

charge

HTTP 30

Encodage des caractères

L’encodage des caractères utilisés dans une ressource

est considéré comme une sous-partie de l’encodage des

ressources

lié au type MIME de la ressource

lié à la langue de la ressource

est indiqué dans les headers HTTP de la réponse Content-Language: en, fr

Content-Type: text/html; charset=ISO-8859-1

HTTP 31

Encodage des paramètres

Format : URL-encoded Permet de coder les données dans l'URL (méthode GET)

Encodage fait par le client

Syntaxe des URL (RFC 2396) début des paramètres : ?

séparation entre le nom du champ et sa valeur : =

séparateur de champ : &

espaces dans la valeur d’un champ : +

caractères réservés : ; / ? : @ & = + $ ,

caractères non-alphanumériques remplacés par %xx (xx = code ASCII du caractère en hexadécimal)

Exemple nom_champ1=valeur1&nom_champ2=valeur2&...

Cas des champs à valeurs multiples (listes de sélection) nom_liste=valeur1&nom_liste=valeur2&...

HTTP 32

Application Web

Application dont l’interface est visible dans un navigateur

Nécessairement des programmes côté serveur

Parfois une partie côté client

Dépendent de l’infrastructure web choisie

Exemple

Programmation côté serveur

Client Serveur

Données

Requêtes

HTTP

Réponses

HTTP

HT

TP

Interface Métier

HT

TP

HTML

Programmation côté serveur 33

Exemples de technologies Php

Langage interprété

Type de programmation : scripts / fonctions / objets

Moteur : interpréteur existant sur la quasi-totalité des serveurs

Java Bytecode

Type de programmation : classes (servlets), scripts (JSP)…

Moteur : container de servlets Jakarta (+ Apache = Tomcat)

Microsoft™ .Net Framework Ensemble de technologies de développement

Type de programmation : dépend du langage VB, C#, J#, ASP…

Moteur : framework sur serveur IIS

Python Langage interprété

Type de programmation : scripts python, scriptlets, DTML…

Moteur : serveur d’applications Zope, Plone

Applications Web

Programmation côté serveur 34

Programmation côté serveur en Java

Réception de la requête du client

Encapsulation de la requête client dans un objet Java HTTPServletRequest

Traitement de la requête et génération de la réponse sous forme d’un objet Java HTTPServletResponse

Désencapsulation de la réponse

Envoi de la réponse au client

Serveur Web

Moteur de servlets

Composants Java (servlets, JSP, classes, interfaces, JavaBeans…)

Moteur de servlets

Serveur Web

Principes de la programmation côté serveur en Java

Programmation côté serveur 35

Programmation côté serveur en Java

Principes de la programmation côté serveur en Java

Machine serveur

Données Serv

eu

r HT

TP

Java VM

Container Web

Interface Métier

Connecteur

Servlet

Servlet

Servlet

Servlet

Classe

Classe

Classe

Classe

JSP JSP

JSP

Programmation côté serveur 36

Programmation côté serveur en Java

Quelques outils disponibles Tomcat

Projet d’Apache issu de Jakarta

Référence en matière de moteurs de servlets

Contenu

Serveur web : Apache

Connecteur : mod_jk (Jakarta) + AJP13

Moteur de servlets : Catalina

Compilateur de JSP : Jasper

Jetty

Serveur + conteneur de servlets : « léger », issu d’Eclipse

JServ

À la fois un connecteur et un moteur de servlets pour Apache

Programmation côté serveur 37

Servlets

Définition (officielle) http://java.sun.com/products/servlet/whitepaper.html

Servlets are protocol- and platform-independent server side

components, written in Java, which dynamically extend Java

enabled servers.

They provide a general framework for services built using the

request-response paradigm.

Their initial use is to provide secure web-based access to

data which is presented using HTML web pages, interactively

viewing or modifying that data using dynamic web page

generation techniques.

Since servlets run inside servers, they do not need a

graphical user interface.

Programmation côté serveur 38

Servlets

Définition (courte)

Implémentation Java d’un mécanisme de requête/réponse

Initialement : indépendant d’un protocole

Avec encapsulation des données dans des objets

Générique

Requête

Réponse

Contexte applicatif

Spécifique HTTP

Méthode

Type MIME de la réponse

Headers

Session

Cookies

Programmation côté serveur 39

Servlets

Concrètement

Objet (classe) Java

Composant d’application

Derrière un serveur (Web, mais pas seulement)

Mappée à une URL sur le serveur

Dans un « Container »

Pas d’accès direct au serveur

Accès protégé aux autres objets métier de l’application

Gestion avancée par le container

Programmation côté serveur 40

Servlets

L’API Servlet Packages Java

javax.servlet

Servlet : interface

GenericServlet : classe abstraite

javax.servlet.http

HttpServlet : classe d’implémentation

Méthodes

Gestion du cycle de vie

Service

« interface »

Servlet

GenericServlet

HttpServlet

Programmation côté serveur 41

Servlets

Méthodes de gestion du cycle de vie

Sont appelées par le conteneur

après l’instanciation (pour rendre une servlet opérationnelle) ou

en fin de service (avant le garbage collecting)

Permettent des traitements spécifiques à l’application

Chargement / déchargement de données de configuration

Activation de services annexes (logs, persistence…)

Programmation côté serveur 42

Servlets

Méthodes de gestion du cycle de vie javax.servlet.GenericServlet

public void init(ServletConfig config) throws

ServletException

Il faut appeler super.init(config) en surchargeant cette méthode

public void init( ) throws ServletException

Inutile d’appeler super.init() ; il vaut mieux surcharger celle-ci

public void destroy( )

Programmation côté serveur 43

Servlets

Méthodes de service

Permettent de rendre le service

traitement de la requête

génération de la réponse

Implémentation différente avec/sans protocole HTTP

GenericServlet : une seule méthode

HttpServlet : une méthode (de classe) par méthode (HTTP)

Utilisation

GenericServlet

surchager la méthode de service (abstraite)

HttpServlet

surchager au moins une méthode de service

Programmation côté serveur 44

Servlets

Méthodes de service javax.servlet.GenericServlet

public abstract void service(ServletRequest req,

ServletResponse res) throws ServletException,

IOException

javax.servlet.http.HttpServlet

protected void doGet(HttpServletRequest req,

HttpServletResponse resp) throws ServletException,

IOException

protected void doPost(HttpServletRequest req,

HttpServletResponse resp) throws ServletException,

IOException

… doDelete, doHead, doOptions, doPut, doTrace

Programmation côté serveur 45

Servlets

ServletRequest

getParameter

HttpServletRequest

getCookies

getHeader

getMethod

getSession

ServletResponse

getWriter

HttpServletResponse

addCookie

addHeader

sendError

sendRedirect

Accès aux données encapsulées

Via les objets requête et réponse passés en paramètres des méthodes de service

Programmation côté serveur 46

Servlets

Exemple de code (HTTP) import javax.servlet.*;

import javax.servlet.http.*;

public class NewServlet extends HttpServlet {

public void init(ServletConfig config) throws ServletException {

super.init(config); … }

public void destroy() { … }

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html");

PrintWriter out = response.getWriter();

out.println("<html><head><title>Hello page</title></head>");

out.println("<body><h1>Hello "+ request.getParameter("name") + </h1></body></html>");

}

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { … }

}

Programmation côté serveur 47

Servlets

Conclusion sur les servlets

Avantages

Composants simples…

Classes Java

…pratiques…

Codage minimum : cycle de vie, traitement de la requête

Tous les autres aspects sont pris en charge par le conteneur

…et sûrs

Isolation du serveur par le conteneur

« rigueur » de l’orienté-objet

Inconvénients

Beaucoup de out.println( )

Difficile de comprendre le code HTML généré

Programmation côté serveur 48

Packaging et déploiement

Déploiement d’une application Web Java Consiste à permettre à un conteneur Web d’exécuter

l’application

Dépôt dans un répertoire ad hoc du serveur

Exemple : répertoire « webapps » de Tomcat

Lecture des fichiers war au (re)démarrage du serveur

Analyse du fichier war et des paramètres de configuration du descripteur de déploiement

Création du répertoire correspondant dans webapps

Mapping des URL de l’application vers le répertoire créé

Autres méthodes de déploiement

http://tomcat.apache.org/tomcat-4.0-doc/appdev/deployment.html

Packaging d’une application Web Java Un fichier .war (Web ARchive)

Programmation côté serveur 49

Programmation côté client

Objectif : concevoir des applications Web « riches »

Web-based

Paradigme client-serveur, HTTP

Programmation côté serveur et côté client

Expérience utilisateur proche des applications natives

Interface utilisateur fluide, ergonomique, dynamique

Traitement de l’interface côté client (JavaScript, CSS , DOM)

Échanges client-serveur asynchrones (AJAX)

Logique métier complexe

Outils « évolués » de modélisation, conception, développement

IDE, POO, UML, design patterns, méthodes agiles, XP…

Où placer la logique métier ? La couche données ?

Programmation côté client 50

Rappels JavaScript / ECMAScript

Caractéristiques Interprété

Fonctionnel

Orienté prototype

« object-based » plutôt qu’« object-oriented »

Typage dynamique : types associés aux instances et non aux classes

Événementiel

Mécanismes de « callback »

Pattern observer : eventListener

Fonctionnalités Reflection

E4X : ECMAScript for XML (ECMA-357)

JSON

Programmation côté client 51

Rappels JavaScript / ECMAScript

Programmation orientée prototype POO sans classe : on ne manipule que des objets

Objets représentés sous forme de dictionnaires (tableaux associatifs)

Propriétés

Pas de distinction entre les propriétés (attributs/méthodes) d'un objet

On peut remplacer le contenu des propriétés et en ajouter d'autres

Réutilisation des comportements (héritage)

se fait en clonant les objets existants, qui servent de prototypes

Sources

http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_prototype

http://en.wikipedia.org/wiki/Prototype-based_programming

Programmation côté client 52

Rappels JavaScript / ECMAScript

Fonctions de rappel (callback) Définition

Fonction qui est passée en paramètre à une autre fonction afin que cette dernière puisse en faire usage

Exemple : soient une fonction A et une fonction B

Lors de l’appel de A, on lui passe en paramètre la fonction B : A(B)

Lorsque A s’exécutera, elle pourra exécuter la fonction B

Intérêt : faire exécuter du code

Sans savoir ce qu’il va faire (défini par un autre programmeur)

En suivant une interface de programmation qui définit

Le nombre et le type des paramètres en entrée

Le type de la valeur en sortie

Source : http://www.epershand.net/developpement/algorithmie/explication-utilite-fonctions-callback

Programmation côté client 53

Rappels JavaScript / ECMAScript

Fonctions de rappel (callback)

La fonction qui reçoit une callback en paramètre doit respecter

son interface

fonctionNormale(fonctionCallBack) {… fonctionCallback(argument); …}

2 syntaxes pour le passage d’une fonction callback en

argument d’une autre fonction

Sans paramètre : directement le nom de la fonction

fonctionNormale(fonctionCallback);

Avec paramètre : encapsulation dans une fonction anonyme

fonctionNormale(function() { fonctionCallback(arg1); });

Programmation côté client 54

Rappels JavaScript / ECMAScript

Programmation événementielle Deux processus en parallèle

Principale : déroulement des traitements et association des événements à des fonctions de callback

Callbacks : récupèrent et traitent les événements

Deux syntaxes

DOM 0 : attributs HTML / propriétés JavaScript spécifiques onclick, onload… (http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.3)

DOM 2 : ajout d’eventListeners en JavaScript monElement.addEventListener("click", maFonctionCallback, false);

Remarques :

Le troisième paramètre indique le type de propagation dans l’arbre DOM

Internet Explorer utilise la méthode attachEvent() au lieu de addEventListener()

Source : http://www.alsacreations.com/article/lire/578-La-gestion-des-evenements-en-JavaScript.html

Programmation côté client 55

Rappels JavaScript / ECMAScript

Programmation événementielle L’objet Event

Dénote un changement d’état de l’environnement Peut être provoqué par l’utilisateur ou par l’application

Peut être intercepté à l’aide de code JavaScript

Possède un flux d’événement : propagation dans l’arbre DOM Capture : du nœud Document au nœud visé par l’événement

Cible : sur le nœud visé

Bouillonnement (bubling) : remontée jusqu’au nœud document

Principales propriétés type : type de l’événement ("click", "load", "mouseover"…)

target : élément cible (élément a pour un lien cliqué)

stopPropagation : arrête le flux d’un événement

preventDefault : empêche le comportement par défaut (navigation quand un lien est cliqué)

Source : http://www.alsacreations.com/article/lire/578-La-gestion-des-evenements-en-JavaScript.html

Programmation côté client 56

Outils de programmation avec XML

Définitions

Qu’est-ce qu’un parser ?

« Un module logiciel […] utilisé pour lire les documents XML

et pour accéder à leur contenu et à leur structure. »

Qu’est-ce qu’une application ?

« On suppose qu'un processeur XML effectue son travail

pour le compte d'un autre module, appelé l'application. »

http://babel.alis.com/web_ml/xml/REC-xml.fr.html#dt-xml-proc

Programmation côté client 57

Outils de programmation avec XML

Communications entre parsers et applications

Rappel : Application Programming Interface

Outils

Protocole de communication

Schéma des échanges de données

Document

Échange

de

données Parser API Application

<?xml version

<!DOCTYPE Doc

<Document>

<Element>

Contenu

</Element>

</Document>

Données

Requêtes

Réponses

Erreurs

Programmation côté client 58

L’API DOM (Document Object Model)

Généralités

Modèle objet de document

Motivations

Rendre les applications W3 dynamiques

Accéder aux documents HTML et XML depuis un langage de

programmation

Utilisations courantes

Intégré aux navigateurs

Utilisé en programmation comme API XML

Origine : DOM working group (W3C)

Début : 1997 ; fin : …

But : standardiser les tentatives existantes

Programmation côté client 59

L’API DOM (Document Object Model)

Fonctionnalités

Programmation côté client 60

L’API DOM (Document Object Model)

Interfaces

DOM Core :

DOM XML :

DOM Implementation NodeList Node NamedNodeM ap

DocumentFragment Document Element AttrCharacterData

Text Comment

Node

DocumentTyp e Entity Entity Reference ProcessingInstructionNotation

Text

CDATASection

Programmation côté client 61

L’API DOM (Document Object Model)

Hiérarchisation des interfaces d’un document XML

Programmation côté client 62

L’API DOM (Document Object Model)

Déplacement

dans une

arborescence

DOM

(interfaces du

module Core)

parentNode

previousSibling

Node

childNodes

firstChild

item(0)

lastChild

nextSibling

item(0)

item(Node.childNodes.length - 1)

Programmation côté client 63

L’API DOM (Document Object Model)

Conclusion sur le DOM

Utilisation du DOM XML en JavaScript

Utilisation directe des propriétés

DOM XML relativement standardisé sur les navigateurs

récents

Exemple : document.getElementById()

En revanche, DOM HTML plus dépendant du navigateur

Exemple : monElement.innerHTML += …;

n’interprétait pas le nouveau code HTML sous IE 6 et 7

Références sur le DOM

http://www.w3.org/DOM/

http://www.w3schools.com/dom/

Programmation côté client 64

Asynchronous Javascript And XML

Composants d’une application Web « classique » Côté serveur

Contrôleur général de l’application (index.jsp)

Ressources statiques

Modèle de document, bibliothèques de scripts, feuilles de style

Traitements dynamiques des données (couche métier)

Composition dynamique de l’interface (couche vue)

Côté client

Gestion des événements utilisateur

Composition dynamique de l’interface (couche vue)

HT

TP, (X

)HT

ML

Programmation côté client 65

Asynchronous Javascript And XML

Composants d’une application Web AJAX Côté serveur

Contrôleur général de l’application (index.php)

Ressources statiques

Modèle de document, bibliothèques de scripts, feuilles de style

Traitements dynamiques des données (couche métier)

Côté client

Contrôleurs délégués relatifs à un type de vue

Gestion des événements utilisateur

Traitement des données reçues (couche métier)

Composition dynamique de l’interface (couche vue)

HT

TP, X

ML, J

SO

N

Programmation côté client 66

AJAX

Généralités sur AJAX

Applications web avec interface utilisateur

Déporter un maximum de code sur le client

Réduction des ressources consommées côté serveur

Réduction de la bande passante réseau

Applications Web AJAX les plus connues

Google (Mail, Map, Earth…)

Suggestions automatiques

Traitement de texte

Exemple

http://www.standards-schmandards.com/exhibits/ajax/

Programmation côté client 67

AJAX

Fonctionnement

Requête asynchrone au serveur dans une fonction JavaScript

(déclenchée par un événement quelconque)

Transfert asynchrone de données en XML

Traitement dynamique côté client

Affichage (inclusion au document HTML, transformation XSLT…)

Logique applicative (fonctions JavaScript dédiées)

Spécificité de la technologie AJAX

Requête asynchrone sur un document XML via un

Objet XMLHttpRequest (Mozilla)

Contrôle ActiveX XMLHTTP (IE)

Programmation côté client 68

AJAX

Fonctionnement

Étapes d’une communication AJAX côté client

Envoi de la requête

Créer un objet requête

Spécifier les éléments de la requête

URL, méthode , headers HTTP, paramètres

Lui associer un gestionnaire d’événement

L’envoyer

Réception de la réponse

À chaque changement d’état de la requête, tester si l’état est

« ready »

Traiter les données reçues

Ajout à l’interface, transformation XSL…

Programmation côté client 69

AJAX

Fonctionnement

Étapes d’une communication AJAX côté serveur

Que doit faire un serveur Web à la réception d’une requête

asynchrone AJAX ?

Programmation côté client 70

AJAX

Implémentation de la logique applicative

Standardisation de la communication avec les langages de

programmation côté serveur : JSON

Spécification liée à ECMAScript – RFC 4627

Implémentée par tous les navigateurs

Permet de sérialiser des types de données (alternative à XML)

Définit des types de données de façon simple

Indépendant du langage de programmation utilisé

Permet les échanges de données entre serveur et client

Syntaxe : des inclusions

d’objets sous forme d’une liste de membres

{ nommembre1 : valmembre1, nommembre2: valmembre2, … }

de tableaux sous forme d’une liste de valeurs

[ valeur1, valeur2, valeur3, …]

Programmation côté client 71

AJAX

Implémentation de la logique applicative Standardisation de la

communication avec les langages de programmation côté serveur : JSON

Exemple de fichier au format JSON :

{ "menu": "Fichier", "commandes": [ { "title": "Nouveau", "action":"CreateDoc" }, { "title": "Ouvrir", "action": "OpenDoc" }, { "title": "Fermer", "action": "CloseDoc" } ] }

<?xml version="1.0" ?> <root> <menu>Fichier</menu> <commands> <item> <title>Nouveau</value> <action>CreateDoc</action> </item> <item> <title>Ouvrir</value> <action>OpenDoc</action> </item> <item> <title>Fermer</value> <action>CloseDoc</action> </item> </commands> </root>²

Programmation côté client

Equivalence en XML :

Source : http://www.xul.fr/ajax-format-json.html

72

AJAX

Implémentation de la logique applicative

Standardisation de la communication avec les langages de

programmation côté serveur : JSON

Utilisation côté client :

Utilisation côté serveur : librairies ad hoc

req.open("GET", "fichier.json", true); // requête … var doc = eval('(' + req.responseText + ')'); // récupération … var nomMenu = document.getElementById('jsmenu'); // recherche nomMenu.value = doc.menu.value; // assignation … doc.commands[0].title // lire la valeur "title" dans le tableau doc.commands[0].action // lire la valeur "action" dans le tableau

Programmation côté client 73

AJAX - sécurité

Risques

Déporter de la logique applicative sur le client présente des

risques

Falsification du client

L’envoi d’une requête asynchrone XHR à un autre serveur que

celui ayant délivré le script est impossible (en principe)

Same Origin Policy

Programmation côté client 74

AJAX - sécurité Types d’attaques Usurpation de session/d’identité :

on ne peut jamais être sûr que le client est celui qu’il prétend être

la partie applicative tournant sur le client est-elle réellement celle envoyée par le serveur ?

Double validation (mots de passe)

Cross-site scripting (XSS) http://cwe.mitre.org/top25/index.html#CWE-79 https://www.owasp.org/index.php/XSS

violation de la same-origin policy

exécution de scripts malicieux dans le contexte d’un site « trusté »

exemple: injection de scripts dans les commentaires des forums

Revenir au HTML de base pour les données sensibles

Vérifier le contenu saisi par les utilisateurs

Cross-site request forgery (CSRF) http://cwe.mitre.org/top25/index.html#CWE-352 https://www.owasp.org/index.php/CSRF

utiliser l’authentification d’un utilisateur pour réaliser des actions à son insu

souvent permise par l’authentification par cookies

Utiliser des champs hidden ou l’en-tête HTTP Referer

Programmation côté client 75

AJAX - conception

Quelques règles pour développer une application Web riche Outils de développement

Utilisez les ressources à votre disposition

Choisissez une bibliothèque aussi standard que possible

Vérifiez la compatibilité avec les navigateurs visés

Compatibilité avec les navigateurs

Testez la fonctionnalité à utiliser, pas le navigateur…

Utilisez des façades aussi souvent que possible

Restez calmes : http://webilus.com/tableau/repartition-du-temps-passe-pour-un-webdesign-moderne

Programmation côté client 76

JavaScript avancé

Fonctionnalités en lien avec la spécification HTML5

Philosophie Rapprocher les fonctionnements des navigateurs de ceux des OS

Exemples de fonctionnalités Sélecteurs CSS : accès standardisé aux contenus de la page

Workers : threads

WebSockets : streaming, server push, connexion avec d’autres clients (P2P)

WebStorage : émulation BD pour stockage des données de session (sessionStorage) ou d’une application (localStorage)

GeoLocation

Device APIs…

Implémentations variables selon les moteurs/navigateurs

Utilisation simplifiée par de nombreuses bibliothèques

plus de détails : http://blog.xebia.fr/2010/03/18/html5-les-api-javascript/ ; http://html5demos.com/

Programmation côté client 77

Bibliothèques / frameworks JS

APIs d’applications Web externes

Principe : interfacer son application avec une plus connue

Nombreux exemples dans le Web 2.0 :

Google (Calendar, Mail, Wave…), FaceBook, YouTube, Ebay…

Un moyen rapide d’améliorer vos applications

Permet d’attirer des utilisateurs

Frameworks AJAX

Programmation dans un autre langage

Génération du code JavaScript

Mécanismes de communication standard entre client et serveur

Références

http://www.ajaxpatterns.org/

Liste de près de 10000 API disponibles

http://www.programmableweb.com/apis/directory

Bibliothèques et frameworks 78

Bibliothèques Web

Bibliothèques CSS Exemples de feuilles de style CSS open source :

http://www.oswd.org/

Bibliothèques AJAX Bibliothèques « directes »

Bibliothèques de fonctions JavaScript pour faciliter le codage

Peu structurées, ne sont utilisables que pour de petites applications

Éventuellement, des outils côté serveur facilitant la génération de pages liées à ces bibliothèques

Nécessitent d’avoir une vue claire de l’application

Exemples

Génériques : jQuery, SAJAX, DHTMLX, Fleejix.js, JsHTTPRequest, My Library

Java : JSP Tags Library

PHP : XAJAX, PhpLiveX

.Net : DotNetRemoting Rich Web Client SDK for ASP.NET , ASP.Net AJAX

Bibliothèques et frameworks 79

Bibliothèques Web directes

jQuery Présentation

Bibliothèque de fonctions d’aide à la génération d’applications Web

Navigation dans un document et sélection d’éléments (X)HTML

Gestion d’événements

AJAX

Animations…

Utilisation très répandue

Existence de plugins développés par la communauté

Remarque : 2 versions

Compressée (production) / Lisible (développement)

Site Web

http://jquery.com/

Documentation

http://docs.jquery.com/

Bibliothèques et frameworks 80

jQuery

L’objet jQuery Équivalent : $

Fonction membre de l’objet window

Plusieurs utilisations

jQuery(selector [, context])

Renvoie tous les éléments DOM Correspondant au sélecteur selector

À partir de l’élément DOM donné en context

jQuery(html [, ownerDocument])

Renvoie objet jQuery correspondant à un ou plusieurs élément(s) DOM

Rajouté(s) au document ownerDocument

Correspondant à la chaîne de caractères html

jQuery(callback)

Appelle une fonction de callback quand le DOM est chargé

Équivalent : jQuery(document).ready()

Bibliothèques et frameworks 81

jQuery

Sélecteurs

Tous les sélecteurs CSS (versions 1 à 3)

Des attributs et fonctions spécifiques

:checked, :empty, :even, :header…

:eq(), :lt(), :not(), :nth-child()…

Des notations particulières

Sélecteurs multiples : ("selector1", "selector2 ", "selector3 ")

Next adjacent selector : ("previous + next ")

Next sibling selector : ("previous ~ sibling ")

Référence : http://api.jquery.com/category/selectors/

Bibliothèques et frameworks 82

jQuery

Objets jQuery

Toutes les méthodes jQuery retournent un ou plusieurs

(tableau) objets jQuery

Chaque objet jQuery possède l’ensemble des méthodes

définies par l’API jQuery

On peut donc chaîner les méthodes entre elles :

$(‘h1#titre').html($('title').html()).before('Voici le titre :').click(mafonction);

Le chaînage s’appliquera pour chacun des objets retournés

par chaque fonction de la chaîne

Exemples : http://www.siteduzero.com/tutoriel-3-160891-jquery-ecrivez-moins-

pour-faire-plus.html?all=1

Bibliothèques et frameworks 83

jQuery

Gestion des événements

Fourniture de fonctions pour l’ajout d’EventHandlers

d’événements standards…

click(), dblclick(), load()

…Ou définis par la bibliothèque

ready()

Permet d’attacher une callback à un événement quelconque

bind(), unbind()

Référence : http://api.jquery.com/category/events/

Remarque : l’objet Event est lui aussi surchargé par un objet

jQuery spécifique

http://api.jquery.com/category/events/event-object/

Bibliothèques et frameworks 84

jQuery

Requêtes asynchrones

AJAX

$.ajax({

url: "test.html",

context: document.body,

success: function(){

$(this).addClass("done");

}

});

JSON

Générale

Bibliothèques et frameworks 85

jQuery

Requêtes asynchrones

AJAX

JSON

jQuery.getJSON( url [, data] [, success(data, textStatus, jqXHR)] )

Équivalent à :

$.ajax({

url: "test.html",

datatype: 'json',

context: document.body,

success: success

});

Générale

Bibliothèques et frameworks 86

jQuery

Requêtes asynchrones

AJAX

JSON

Générale

jQuery.get( url [, data] [, success(data, textStatus, jqXHR)] [, dataType] )

Équivalent à :

$.ajax({

url: "test.html",

datatype: datatype,

context: document.body,

success: success

});

Référence : http://api.jquery.com/category/ajax/

Bibliothèques et frameworks 87

jQuery UI

Extension de jQuery

Bibliothèque d’éléments d’interface (thèmes, widgets,

primitives d’interaction)

Permet de rajouter facilement des interactions complexes

Permet de rendre une application Web plus dynamique

Exemple

Drag’n drop : http://jqueryui.com/demos/draggable/

Utilisation

1. Identifier les éléments dont on a besoin

2. Construire et télécharger sa bibliothèque personnalisée

3. L’utiliser dans son application

Site Web

http://jqueryui.com/

Bibliothèques et frameworks 88

WebSockets

Position du problème

HTTP : protocole client-serveur

Le serveur ne peut que répondre à une requête d'un client

Manquent des technologies de

Push serveur

Requêtes répétées du client

Gaspillage de bande passante

Ne pas fermer la connexion persistante (COMET)

Réponses "Chunked", Pushlet, Long polling, Flash XML sockets...

Communication bidirectionnelle (P2P) entre clients

WebSockets 89

La spécification WebSocket

But : permettre la communication bidirectionnelle

entre un client et un serveur

Contenu de la spec

Un protocole de communication : RFC6455

Au-dessus de TCP

Headers en "HTTP-like"

"Compatible avec HTTP" : un même port peut être utilisé

pour les deux protocoles

Une API en WebIDL : WebSocket API

Modèle d'implémentation pour les serveurs et les

navigateurs

Description des échanges entre les deux parties

WebSockets 90

Techniquement

Handshake en HTTP (1.1)

Ouverture d'un WebSocket à l'initiative du client

Clé : chaîne de caractères aléatoire

Options : sous-protocole, version...

WebSockets 91

GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

Techniquement

Handshake en HTTP (1.1)

Acceptation du serveur

Statut : changement de protocole

Clé : SHA de la concaténation de la chaîne envoyée + un

Globally Unique Identifier (RFC 4122)

Options : choix d'un sous-protocole...

WebSockets 92

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat

La spécification WebSocket

Utilisation

Échange de données bidirectionnel en TCP

Chaque côté peut envoyer des données quand bon lui

semble

Pas de réponse à un envoi de données

Les ensembles de données envoyées simultanément sont

appelées "messages"

côté client :

Emission : méthode send() de l'interface Message

Réception : Abonnement à un événement onMessage

côté serveur (nécessite la prise en charge des

WebSocket) :

Réception : même principe

Emission : idem...

WebSockets 93

Utilisation côté client

Source : http://java.dzone.com/articles/creating-websocket-chat

WebSockets 94

var ws; $(document).ready( function() { ws = new WebSocket("ws://localhost:8080/../WebSocketChat"); ws.onopen = function(event) { } ws.onmessage = function(event) { var $textarea = $('#messages'); $textarea.val($textarea.val() + event.data + "\n"); } ws.onclose = function(event) { } }); function sendMessage() { var message = $('#username').val() + ":" + $('#message').val(); ws.send(message); $('#message').val(''); }

Outils

Côté client

Protocole et API JS intégrés aux navigateurs récents

Bibliothèques : plugin jQuery, jWebSocket

Côté serveur

Nécessite un serveur qui prenne en charge le protocole et

l'API

Exemples en Java :

jWebSocket (serveur standalone ou bundle pour Tomcat)

Jetty

GlassFish

Autres langages :

Socket.IO (node.js)

EventMachine (Ruby)

Twisted WebSocket Server (Python)

WebSockets 95

Références

Le protocole RFC6455

L'API WebSocket

Candidate Recommendation (septembre 2012)

Editor's Draft

Documentation

Une page Wikipedia générale sur le push serveur

Une page Wikipedia générale sur les technologies Comet

La page Wikipedia sur les WebSockets

Tutoriel

Un exemple de chat en WebSocket avec Jetty et GlassFish

WebSockets 96

Vue d’ensemble

Contexte et rappel historique

Des SI distribués aux services

Les services Web

Définition

Retour sur XML

Architectures orientées services (SOA)

Présentation générale

Services ”classiques”

Protocoles et langages (SOAP, WSDL, UDDI)

Services RESTful

L'approche REST et les services

Services Web 97

98

Contexte et rappel historique

SI répartis sur le réseau (Internet)

Technologies client/serveur (parfois P2P)

Accès à des données distribuées

Différents moyens d'accès

Mobile (Wap - WML)

Web (HTTP – HTML)

Autres (minitel, news, etc...)

Plusieurs sources de données

Plusieurs mises en formes

Services Web

99

Contexte et rappel historique

Notion de service dans les SI distribués

Fournisseur de fonctionnalité

Combinaison entre services

Interne: Enterprise Application Integration (EAI)

Externe: portails d'entreprises

Problématiques ”réactualisées”

Interopérabilité (échange de données)

disponibilité, fiabilité, sécurité, QoS, etc.

Services Web

100

Contexte et rappel historique

Tentatives précédentes

CORBA => très (trop?) complexe

COM, DCOM => dépendant de la plateforme (M$)

RMI => dépendant du langage (Java)

Problèmes généraux

Clients lourds, implémentations complexes

Dépendances nombreuses

Avantages généraux

Efficacité de fonctionnement après installation

Services Web

101

Contexte et rappel historique

De quoi a-t-on besoin?

Modèle de communication clair

Simplicité de mise en œuvre ET d'exploitation

Indépendance plateforme ET langage

Adoption rapide par les responsables des SI (!)

La solution? Le Web, i.e. HTTP et XML

Plus quelques langages et protocoles (1ère gen)...

...ou pas (2de gen) !

Services Web

102

Contexte et rappel historique

Le Web comme support

HTTP est universel (et simple?) + SSL possible

Peut être adopté même intra muros

Passe les firewalls (port 80)

Client standardisé? (cf browser wars)

Moins performant qu'un RMI ou CORBA

Débit, qualité des communications...

XML comme langage

HTTP transporte (entre autres) de l'hypertexte...

Informations structurées en mode texte => XML

Services Web

103

Les Services Web

Objectif des services Web

Simplifier la complexité inhérente aux SI

Exploiter au mieux les avantages du Web

Définition du W3C:

●A Web Service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered by XML artefacts and support direct interactions with other software applications using XML-based messages via Internet-based protocols.

Services Web

104

Les Services Web

Interactions client/serveur

Au dessus de TCP/IP

Utilisent HTTP (même si tout est permis)

Passage du Web client au Web machine

L'information n'est plus destinée à être affichée

Échanges et traitements automatisés

Passage des techno ”adhoc” au Web

CORBA, RMI, DCOM, => HTTP & XML

Services Web

105

Retour sur XML

HTML

Sémantique stricte et définie une fois pour toutes

Mise en forme de documents Web

Problèmes

Pas extensible

Ne décrit pas (ou peu) la sémantique du contenu

Mélange mise en forme et contenu (jusqu'à CSS)

Par rapport à HTML, XML apporte

Définition libre des balises => schéma

Support de structures complexes

Séparation contenu/mise en page

Services Web

106

Retour sur XML

Grands principes de XML

Lisible par l'homme et la machine

Full-text (non binaire, donc portable)

Structure non ambigüe

balisage strict parsable + schéma associé

Séparation entre document et relations inter-doc

Notion d'espace de nommage

Séparation structure des données et mise en forme

XML => structure, association avec CSS/XSLT

Services Web

107

XML Schéma

Support de nombreux types de données

Possibilité de définir ses propres types de données

Ajout de contraintes sur les données

Notion d'héritage

Support des espaces de nommage

Indicateurs d'occurences des éléments

Conception modulaire des schémas

Défini sur: http://www.w3.org/XML/Schema

Retour sur XML

Services Web

108

Architectures orientées services

Utilisation des services Web

XML (description), XML (messages)

Web (HTTP) pour le transport

Découverte à l'aide d'annuaires (ou registres)

Invocation d'une fonction à distance

Notion de faible couplage

Indépendance des plateformes sous-jacentes

Indépendance des langages sous-jacents

Services Web

109

Architectures orientées services

Nouveau modèle de développement

Service-oriented architectures (SOA)

Rationalisation des SI par domaines

Décomposition abstraite des fonctionnalités

Combinaison de services => composition

Fonctionnalités avancées

Cross-domain apps...

Interactions dans les SOA

3 acteurs: le fournisseur, le registre, le client

Actions: publication, découverte, exécution

Services Web

110

Architectures orientées services

Le client cherche dans l'annuaire un WS correspondant à ses besoins en termes de

Fonctionnalité

Qualité de service (QoS): fiabilité, rapidité, etc...

Sélection parmi plusieurs WS fournissant la même fonctionnalité

Plusieurs cas d'utilisation

Entre applications distribuées

Entre une application et un client Web

Services Web

111

Architectures orientées services

Source W3C Services Web

112

Architectures orientées services

Quoi de nouveau ?

Services Web

113

Architectures orientées services

Alors qu'apportent les services Web?

Les technologies utilisées

SOAP (Simple Object Access Protocol)

Remplace IIOP (CORBA) et RMI-IIOP (RMI)

WSDL (Web Service Description Language)

Remplace IDL (CORBA) et interface Java (RMI)

UDDI (Universal Description, Discovery and Integration)

Remplace CosNaming (CORBA) et JNDI (RMI)

L'indépendance des langages et plateformes

Interopérabilité, flexibilité, la notion de composant

La rationalisation des SI

Le soutien des grands acteurs du Web... Services Web

114

Architectures orientées services

Source W3C Services Web

115

Architectures orientées services

Le protocole SOAP

Assure les appels de procédure

Au dessus d'un protocole de transport (svt

HTTP)

Simple enveloppe autour des données à

transmettre via HTTP

Services Web

116

Architectures orientées services

SOAP Côté client

Ouverture d'une connexion HTTP

Requête SOAP: document XML décrivant

la méthode à invoquer sur la machine distante

les paramètres de la méthode

SOAP Côté Serveur

Récupère la requête

Exécution de la méthode avec les paramètres

Renvoie une réponse SOAP (document XML) au client

Services Web

117

Architectures orientées services

Le langage WSDL

Souvent généré par les outils de développement

Décrit l'interface du service au format XML

les méthodes, les paramètres et valeurs retournées, les protocoles de transport possibles, et la localisation du service

De manière abstraite et concrète

Indépendance des 2 parties

On reste indépendant des plateformes et langages d'implémentation des services

=> Faible couplage

Services Web

118

Architectures orientées services

Services Web

119

Transparence complète côté serveur

BD Oracle ?

Autre service Web ?

C, C++, Java ?

UNIX, Windows ?

=> boîte noire => faible couplage

Et de même côté client

Que voit-on du serveur?

On ne voit que les ports ouverts

Nécessite un serveur de type Apache Tomcat

Le protocole SOAP

Services Web

120

Avantages de SOAP

Séparation des traitements de données

Pas besoin de ”stub” et ”skeleton” comme

avec CORBA et RMI

Passage de firewall dans HTTP

Inconvénients

Verbeux (bande passante)

Pas si ”simple”

Le protocole SOAP

Services Web

121

Histoire jusqu'a SOAP

80's: DCOM et CORBA

Couplage fort, très orienté objet

99': XML-RPC

Messages XML, envoi de formulaire (HTTP/POST), pas extensible, types de données limités

SOAP

Standardisé par le W3C

Protocol-independent

Extensible, et basé sur XML

Le protocole SOAP

Services Web

122

2 styles de communication

RPC: Appels de procédures distants

Paramètres proches des types des langages de programmation

Degré élevé d’automatisation

DOC: Echanges de messages conformes à des schémas arbitraires (Ex: Demande d’achat).

Plus de flexibilité au niveau des datatypes

La fonction manque dans le message SOAP

Encouragé par .Net

Voir: http://www.eherenow.com/soapfight.htm

Le protocole SOAP

Services Web

123

2 types de communication

Synchrone (par dessus HTTP)

Appels bloquants, pb de timeout...

Asynchrones (SMTP, JMS...)

Appels non bloquants

garantie de service (messages recus une et une

seule fois)

Le protocole SOAP

Services Web

124

WSDL cache le détail de l’implémentation du service, permet une utilisation indépendante

de la plate-forme et du langage utilisé

Regroupe les informations nécessaires pour interagir avec le service :

les méthodes, les paramètres et valeurs retournées, le protocole de transport utilisé, la localisation du service

Les documents WSDL sont générés par les outils de développement et favorisent une intégration rapide du service

Le langage WSDL

Services Web

125

Un document WSDL contient 6 parties

Les quatre premières parties décrivent des informations abstraites indépendantes d’un contexte de mise en œuvre. On y trouve :

les types de données envoyées et reçues

les opérations utilisables

le protocole qui sera utilisé,

Les deux dernières parties décrivent des informations liées à un usage contextel du service. On y trouve :

Le point d'accès du service, les protocoles utilisés et le lien entre les 2

Le langage WSDL

Services Web

126

L'annuaire UDDI

UDDI (Universal Description, Discovery and Integration), standard né sous l’initiation de Microsoft, IBM, Sun, Oracle, Compaq, HP, Intel, SAP, etc.

Standard pour faciliter la collaboration entre partenaires dans le cadre d’échanges commerciaux

Le cœur de UDDI est un annuaire qui contient des informations techniques et administratives sur les entreprises et les services qu’elles publient

Services Web

127

L’annuaire UDDI permet de :

Publier, découvrir des informations sur une entreprise et ses services

L’inscription sur UDDI permet à une entreprise de se présenter ainsi que ses services

L’adoption de UDDI facilite le développement des échanges de type « B2B »

L’enregistrement des services dans un annuaire s’effectue après d’un opérateur (Microsoft ou IBM actuellement) à travers son site mais on peut créer ses propres registres UDDI (UDDI4J, jUDDI)

L'annuaire UDDI

Services Web

128

Implémentations

Architecture .NET

Services Web

129

Architecture J2EE

Implémentations

Services Web

130

Conclusion

Bilan

Beaucoup de technologies

Poussées par les grosses firmes

Trop de standards tuent la standardisation

Trop de variantes sur les implémentations

Encore des problèmes entre J2EE et .NET

Questions ouvertes...pour la suite

Et les services RESTful?

Quid de la sémantique?

Services Web

REpresentational State Transfer

Contexte historique

REST : Une alternative à SOAP

Proposée dans la thèse de Fielding en 2000

En 2006, Google change son API pour REST

De nombreux fournisseurs de services suivent

Aujourd’hui

Sur programmableweb.com

6279 APIs REST

2052 APIs SOAP

Pourquoi ce changement ?

Services Web 131

SOAP : inconvénients

Problèmes d’implémentation

Diverses implémentations incomplètes ou bancales

Sérialisations des types XML complexes incompatibles

Profusion d’extensions

La fameuse pile WS-* (policy, security, trust)

Connue pour sa mauvaise lisibilité

Avantage initial de SOAP

=> indépendance du protocole de transport sous-jacent

Constat à l’utilisation => HTTP standard de facto

=> redondance, utilisation contre nature du HTTP

Services Web 132

REST: définition et objectifs

Définition

Style architectural : ensemble de contraintes pour qu’un

système vérifie un certain nombre de propriétés

L’idée étant de conserver les « bonnes » propriétés du

Web et d’en éviter les erreurs

Objectifs

Passage à l’échelle (performance, disponibilité)

=> fonctionnement décentralisé

Interface la plus générique possible

faible couplage (une notion venus des services)

=> verbes HTTP

Mise en valeur de HTTP par son utilisation

Services Web 133

REST: définition et objectifs

Contraintes techniques à respecter

Connexions sans état (stateless)

L’état n’est plus sauvegardé sur le serveurs

=> allègement du serveur, passage à l’échelle favorisé

Communications Client/Serveur

Problématique pour les notifications au client

Interface uniforme

WSDL ??

Principle of partial understanding (Michael Hausenblas)

Cf thèse Roy Fielding…

Services Web 134

REST : principes généraux

Ressource

Une ressource est une entité abstraite.

→ Ce n'est pas un fichier.

Une ressource est identifiée par un URI (Uniform

Resource Identifier).

→ Un URI/URL n'identifie pas un fichier !

Représentation

Une ressource a une ou plusieurs représentation(s).

→ négociation de contenu

Ces représentations peuvent varier dans le temps.

Les ressources sont toujours manipulées via leurs

représentations.

Services Web 135

Les Services RESTful

Adaptation des services « classiques » Censés respecter les contraintes REST

Lesquelles ne sont souvent pas toutes respectées

Navigation via les liens hypertextes L’état d’un échange long est transmis avec la connexion

Nombreuses implémentations (repose sur HTTP)

JAX-RS, PHP, .net, Python…

Conclusion Nombreux avantages par rapport à SOAP

Bonne adoption par la communauté

Futur prometteur

Ne résout pas les problèmes « classiques »

Interopérabilité, sémantique…

Services Web 136

Le Web sémantique

Tout est ici :

http://liris.cnrs.fr/~pchampin/2012/semweb/rdf.html

Le Web sémantique 137

138

Services Web sémantiques

D'un côté le Web sémantique

Plusieurs langages (RDF(S) – OWL)

Ajout d'une sémantique (machine-)explicite

Annotation sur le Web (GRDDL, µformats, RDFa)

De l'autre côté les services Web

Notion de SOA: passage au Web orienté service

Les technologies (SOAP/WSDL/UDDI)

Basé sur XML/HTTP

Combiner les deux ?

Services Web sémantiques

140

Services Web sémantiques

Limitations des services Web

Tout est manuel (!)

Souvent l'appel aux services est figé dans le code

La sémantique est là, mais pas pour les machines

Objectifs de la sémantique ajoutée:

Automatiser et rendre dynamiques les tâches liées

aux services Web

Découverte, sélection, composition, négociation,

invocation, monitoring, reprise sur erreur, etc...

Services Web sémantiques

141

Services Web sémantiques

Annotation des descriptions de services

Ajout de sémantique interprétable par les machines

Références à des ontologies (OWL)

2 approches

Bottom-up: Extension de WSDL (SAWSDL, hREST...)

Top-down: intégration de WSDL (OWL-S, WSMO...)

avantages/inconvénients...

W3C porteur des projets

Services Web sémantiques

142

Services Web sémantiques

OWL for Services (OWL-S)

Description formelle des services

Capacité, interface, etc...

Intègre le langage WSDL

Objectifs

Raisonnement automatique sur les descriptions

Composition automatique

OWL-S est exprimé via OWL

Il définit comment décrire un service par un ensemble de structures

Services Web sémantiques

143

OWL-S

Source: http://www.w3.org/Submission/OWL-S/

Services Web sémantiques

144

OWL-S

Service profile

Répond à: ”Que fait le service?”

Description de haut niveau, utile pour les registres

Permet de sélectionner les services selon les fonctionnalités sont définies dans les ontologies

Un service peut posséder plusieurs profiles

Utilisation

Sélection: identifier la fonctionnalité via ses attributs

Planning: I/O, précondi., effets, notion de process

Services Web sémantiques

145

OWL-S

Source: http://www.w3.org/Submission/OWL-S/

Services Web sémantiques

146

OWL-S

Source: http://www.w3.org/Submission/OWL-S/

Services Web sémantiques

147

OWL-S

Service model

Répond à: ”Comment fonctionne le service?”

Décrit les interactions du service

Construit autour du ”process” + IOPE

Atomique ou composé. Si composé:

opérateurs de contrôle et de flux de données

Utilisation

Invocation, planning/composition, interopération, monitoring

Services Web sémantiques

148

OWL-S

Services Web sémantiques

149

OWL-S

Source: http://www.w3.org/Submission/OWL-S/

Services Web sémantiques

150

OWL-S

Service Grounding

Répond à: ”Comment accéder au service?”

Spécifique à l'implémentation

Formats des messages, protocoles de transport, encodage des données

Utilisation de la description OWL-S

Le profile est pour la découverte

On peut invoquer un service avec son ”Model” et son ”Grounding”, construits autour de WSDL

Services Web sémantiques

151

OWL-S

Source: http://www.w3.org/Submission/OWL-S/

Services Web sémantiques

Annotations de services

De nombreuses contributions

WSDL-S => SA-WSDL, SA-REST

RDFa, hRESTS (µ-format), microWSMO

Sémantique des services explicite

Facilite les interactions

La découverte, les échanges de données

Ne résout pas certains problèmes

Sémantique des données peu détaillée

Intégration dans le Web sémantique

Services Web sémantiques

Les linked services

Linked services

Des données liées décrivant des services

Les entrées sorties et fonctionnalités des services

décrits en RDF(S)

Un linked service reçoit et produit du RDF

Ne pas confondre avec un data service

Avantages

Meilleure intégration dans le Web sémantique

Inconvénient

Apprentissage pour l’utilisation de RDF

Services Web sémantiques

WoT : Web of Things

Le « Web des choses »

Souvent appelé le Web des objets

Comment le définir ?

Une surcouche de l’IoT

Repose sur les technologies Web pour les interactions

TCP => HTTP et IP => URI

Fournit une sous-couche applicative générique

Facilite le développement

Intégration « naturelle » avec les services

Plutôt REST que SOAP

Un objet = une ou plusieurs ressources

Accessible par des URIs, propose des services

Conclusion 154

Domaines de recherche

Le WoT intéresse de nombreux domaines

Embarqué : intégrer de l’informatique dans des

dispositifs souvent limités en ressources

Web : tirer partie des nouvelles spécifications du W3C

(device APIs, WebSockets, Web workers…)

Services : rationaliser les SI et faciliter les échanges des

données/fonctionnalités distantes

Web sémantique : description explicite et interconnexion

des connaissances accessibles par les machines

SMA : interactions entre des nombreux objets pouvant

être vus comme un système multi-agents

Cloud computing : les objets sont des ressources de

calcul, et/ou ont des besoins en ressources

Conclusion 155

Les problèmes ouverts

Quels sont les challenges aujourd’hui ?

Intégration !!

Les objets, le Web, la sémantique, les services…

De notre point de vue

L’automatisation de l’accès aux objets et de l’échange

entre objets à travers des interfaces de services

possédant une sémantique explicite…

est LE challenge de demain !

Communauté grandissante autour du sujet

Workshop Web of things

mot clé web of things dans les conférences « services »

Écoles d’été !

Lieu de la présentation - 17/11/2003 156