Workshop e-Business® - emse.fr · – SOA: An Integration Blueprint. Schmutz et al, Packtpub 2010....
Transcript of Workshop e-Business® - emse.fr · – SOA: An Integration Blueprint. Schmutz et al, Packtpub 2010....
Workshop e-Business 23-27 février 2015
Philippe Lalevée 1
Workshop e-Business® ISMIN 3A – P2015
Philippe Lalevée [email protected]
23-27 février 2015 Workshop e-Business P2015 1
Votre semaine
• Durée : 30 heures (10 x 3h) dont ~6 heures de cours
• Cours : rappels sur les technologies Web, XML, modèles de programmation, architectures réparties, applications d’entreprise et : – « Web Services »
– « Service Oriented Architecture » (SOA)
– « Cloud Computing »
• Projet: sujet remis lundi ou mardi après-midi
• Évaluation : démonstrations commentées vendredi après-midi
23-27 février 2015 2 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 2
Organisation générale • Mise en œuvre des technologies
– Lundi AM: Cours de présentation générale – Lundi PM
• Mise en œuvre des « machines » • Deux TP de mise en jambe : Servlet/JSP et Node.js
• Mise en œuvre d’un ERP – Mardi AM: Technologies des Web Services (REST, SOA, Cloud) – Mardi PM
• Deux TP de consolidation : Web Services
• Projet du Mercredi à Vendredi AM : 30 heures de travail
• Démonstrations : Vendredi PM – 13h15-15h30 : passage des 4 groupes – 15h30-16h : évaluation de la semaine
23-27 février 2015 3 Workshop e-Business P2015
Bibliographie • Web Services
– Architectures n-tiers et déploiement d’applications Web. Caromel et al, INRIA, 2004. – Construire des Services Web XML avec .NET. Short, Microsoft Press, 2002. – Services Web avec J2EE et .NET. Maesano, Bernard, Le Galles, Eyrolles, 2003 – Les Web Services. Kadima et Montfort, Dunod, 2003 – Web Service Contract Design and Versioning for SOA. Erl et al, Prentice Hall 2008. – Developing Web Services with Apache CXF and Axis2. Tong, Tiptec 2010. – RESTful Web Services Cookbook. Allamaraju, O’Reilly 2010
• SOA – SOA: le guide de l’architecte. Fournier-Morel et al, Dunod, 2006. – SOA Governance. Biske, Packtpub 2008. – SOA Design Patterns. Erl, Prentice Hall 2008. – Implementing SOA Using JEE. Kumar et al, Addison Wesley 2009 – 100 SOA Questions. Holley et Arsanjani, Prentice Hall 2010. – SOA: An Integration Blueprint. Schmutz et al, Packtpub 2010.
• Cloud – Cloud Application Architectures. Reese, O’Reilly 2009. – Cloud Computing and SOA Convergence in Your Enterprise. Linthicum, Addison Wesley
2009. – Implementing and Developing Cloud Computing Applications. Sarna, Auerbach 2010. – Host Your Web Site in the Cloud. Barr, Sitepoint 2010. – The Cloud at Your Service. Rosenberg et Mateos, Manning 2010. – Developing Applications for the Cloud. Betts et al, Microsoft Press 2010. – Microsoft SQL Azure: Enterprise Application Development. Krishnaswamy, Packtpub 2010. – Cloud Computing: Principles and Paradigms. Buyya et al, Wiley 2010. – Code in the Cloud. Chu-Carroll, Pragmatic bookshelf 2011
4 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 3
RAPPELS ET INTRODUCTION GÉNÉRALE
Première partie
5 23-27 février 2015 Workshop e-Business P2015
Qu’est-ce que le E-Business® ?
Source IBM
23-27 février 2015 Workshop e-Business P2015 6
Workshop e-Business 23-27 février 2015
Philippe Lalevée 4
RÉSEAUX ET PROTOCOLES Rappels et introduction générale
7 23-27 février 2015 Workshop e-Business P2015
Les protocoles de l’Internet
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Internet Layer
Application Layer
Telnet FTP SMTP DNS RIP SNMP HTTP
IP
Host-to-Host Transport
Layer TCP UDP
Token Ring
Ethernet ATM Frame Relay
Network Interface
Layer
OSI Model Layers
TCP/IP Protocol
Architecture Layers
TCP/IP Protocol Suite
ARP ICM
P IGM
P
Web
23-27 février 2015 Workshop e-Business P2015 8
Workshop e-Business 23-27 février 2015
Philippe Lalevée 5
Internet et le World Wide Web • Internet/internet, intranet/extranet • Basé sur Internet (protocole HTTP/TCP) • Conséquences sur les applications
– Ressources accessibles 24/24 – Notions générales de services (clients et serveurs) – Pas (ou peu) d’installation « côté client »
• Les informations sont reliées les unes aux autres – Information hypertexte de type « chaîne de caractères » – Propose une façon générique d’accéder et de partager de l’information
hétérogène – Contenus variés : médias (articles techniques, blogs, musique), achats, données
brutes applicatives, etc. – Accès variés : synchrone/asynchrone, fiable/non fiable, qualité de service/bande
passante
• Est devenu une plate-forme de développement – Applications accessibles depuis n’importe où – Vision fournisseur : applications pour les clients décentralisés – Vision client : bibliothèque virtuelle de composants
23-27 février 2015 Workshop e-Business P2015 9
Principes de conception • Interopérabilité : les langages et protocoles du Web sont
compatibles entre eux et indépendants des matériels et des logiciels
• Évolutivité : le Web est du coup capable de s’adapter à de nouvelles technologies (interfaces simples) – Modularité des ressources et des usages
– Extensibilité pour s’adapter à la demande
• Décentralisation : facilite l’extensibilité et la robustesse – Pas de « centre » global (pas de contrôle de flux)
– Tout nœud diffuse et reçoit (symétrie) (conséquence: révolution « technico-sociale »)
– Repose sur une architecture client/serveur
23-27 février 2015 Workshop e-Business P2015 10
Workshop e-Business 23-27 février 2015
Philippe Lalevée 6
Les standards du Web • Internet Engineering Task Force (IETF)
– http://www.ietf.org/
– Fondé en 1986
– Standards basés sur des RFC (Request For Comments) disponibles sur http://www.ietf.org/rfc.html
– Par exemple, HTTP : RFC2616
• World Wide Web Consortium (W3C) – http://www.w3.org
– Fondé en 1994 par Tim Berners-Lee
– Publie des rapports techniques et des recommandations
• OASIS – http://www.oasis-open.org
– Standards e-business (ebXML, OpenDoc, UDDI…)
23-27 février 2015 11 Workshop e-Business P2015
Architecture du Web
Serveur Web (Apache/IIS)
Navigateur (Firefox/IE)
Clients
Serveur
Requête : HTTP request http://www.emse.fr
Réponse : HTTP Response <html>…</html>
Réseau Internet (TCP/IP)
12 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 7
URI, URL et URN • Uniform Resource Identifier (URI = URL ou URN)
– Est une courte chaîne de caractères identifiant une ressource Web physique ou abstraite, et dont la syntaxe respecte une norme d'Internet mise en place pour le « World Wide Web » (voir RFC 3986)
• Uniform Resource Locator (URL) – Est un URI qui fournit les moyens d'agir sur une ressource ou d'obtenir
une représentation de la ressource en décrivant son mode d'accès primaire ou "emplacement" réseau (instructions explicites pour désigner la méthode d’accès à la ressource sur Internet)
– Ex : http://www.emse.fr, ftp://ftp.lip6.fr/public, mailto:[email protected]
• Uniform Resource Name (URN) – Est un URI qui identifie une ressource par son nom dans un espace de
noms – Exemple : urn:isbn:0-395-36341-1 est un URI qui, avec un ISBN
(International Standard Book Number) autorise quelqu'un à faire référence à un livre, mais ne suggère où et comment en obtenir une copie réelle
23-27 février 2015 Workshop e-Business P2015 13
Accès aux ressources • Les ressources sont repérées par des URL
(Uniform Resource Locator) protocol://id:pw@server:port/resource?param
• Exemple http://toto:[email protected]:80/req?p=M2
• Syntaxe
– Protocole: http – Identification pour accéder à la ressource : toto:passwd – Nom du serveur : www.emse.fr – Numéro du port (application) : 80 – Web page: req (index.html souvent par défaut) – Paramètres avec la méthode GET : p=M2
23-27 février 2015 Workshop e-Business P2015 14
Workshop e-Business 23-27 février 2015
Philippe Lalevée 8
HTTP Request : GET
GET /req?prenom=Philippe&nom=Lalevee HTTP/1.1
Host: www.emse.fr
Connection: close
User-Agent: Web-sniffer/1.0.27 (+http://web-sniffer.net/)
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7
Cache-Control: no-cache
Accept-Language: de,en;q=0.7,en-us;q=0.3
Referer: http://web-sniffer.net/
Méthode Ressource Version HTTP Lignes d’entête
Données – associées à la ressource pour GET
Ligne blanche (2 LF successifs)
23-27 février 2015 15 Workshop e-Business P2015
HTTP Request : POST
POST /req HTTP/1.0
Host: www.emse.fr
Connection: close
Referer: http://web-sniffer.net/
Content-type: application/x-www-form-urlencoded
Content-length: 0
Connection: Keep-Alive
If-Modified-Since: Sunday, 17-Apr-96 04:32:58 GMT
prenom=Philippe&nom=Lalevee
...
Méthode Ressource Version HTTP Lignes d’entête
Données POST Ligne blanche de séparation
16 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 9
Les méthodes HTTP • GET
– Saisie URL ou clic – Paramètres placés dans l’URL (max ~240 octets)
• POST – Formulaires ou fichiers – Paramètres placés après l’entête (taille non limitée par le
protocole)
• Autres – HEAD : obtention de l’entête seule – PUT : dépôt d’une ressource – DELETE : suppression d’une ressource – OPTIONS : interrogation du serveur – TRACE : pour le débogage
23-27 février 2015 Workshop e-Business P2015 17
HTTP Response
HTTP/1.1 200 OK
Date: Mon, 17 Feb 2014 07:30:00 GMT
Server: Apache/2.0.52 (Red Hat)
X-Powered-By: PHP/4.3.9
Content-Length: 1599
Connection: close
Content-Type: text/html
<!DOCTYPE html PUBLIC "-//W3C…" "http://www...">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Site Web de l’EMSE</title>
</head>
...
Version HTTP Status code
Raison Lignes d’entête
Données
18 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 10
Le protocole HTTP
• HTTP est un protocole « sans état » – Exemples de la vie courante ?
– Idempotence
• Le fait d’être « sans état » a de grandes conséquences sur la conception des applications et leur extensibilité – Connaissez-vous les propriétés ACID ?
• Maintien de la connexion (keep-alive) pour plus d’efficacité – En HTTP 1.1, mode par défaut
(Connection: close pour enlever) 19 23-27 février 2015 Workshop e-Business P2015
ARCHITECTURES TECHNIQUES Rappels et introduction générale
20 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 11
Architecture centralisée Applications monolithiques
Service
Service
ENTREPRISE
BD
BD
BD
Ordinateurs centraux
Term
inau
x
Co
ncen
trateurs
Ordinateur Réseau
21 23-27 février 2015 Workshop e-Business P2015
Programmation « mainframe »
• Architecture centralisée – Ordinateur central (IBM 3090)
– Bases de données centrales
– Réseaux de terminaux clients
• Méthodes « systémiques » – Séparation traitement/données : MERISE
– Langages impératifs : ex. Cobol
• Systèmes propriétaires
Avantages / inconvénients ?
22 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 12
Architecture client/serveur Partage des données
Service
ENTREPRISE
Service
BD
BD
Appli
Appli
AppliServeur
Stations de travail
Internet
Stations de travail
Pare-feu
Service
Intranet
Stations de travail
23 23-27 février 2015 Workshop e-Business P2015
Programmation « répartie » • Architecture décentralisée
– Chaque nœud est un ordinateur indépendant – Bases de données accessibles à tout nœud – Réseau local (LAN) ou distant (WAN) d’interconnexion
• Algorithmique répartie (distribuée) – Les applications sont multi-machines – Les modules applicatifs de chaque machine coopèrent par échange de
messages – Nouvelles problématiques sécuritaires et transactionnelles
• Premiers systèmes libres (Unix) – RPC, RMI, CORBA, DCOM – SQL, HTTP – Java EE, .NET
Avantages / inconvénients ?
24 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 13
RPC : Remote Procedure Call
• Mécanisme dissymétrique
– Le client émet une requête avec un message
– Le serveur lit et exécute la requête
– Le client obtient la réponse par un message
25 23-27 février 2015 Workshop e-Business P2015
Appel de procédure
Appel local
Client Serveur
Encapsulation des paramètres SEND
Récupération des paramètres
RECV
Transmission des paramètres
Communication synchrone Mode bloquant Contrôle des erreurs
fonction
fonction
appelant appelant
Encapsulation des résultats
Récupération des résultats
23-27 février 2015 26 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 14
Java EE RMI
Enterprise Java Bean
Réseau
Java RMI Middleware
Enterprise Java Bean
Stub (talon)
Application 1 Application 2
23-27 février 2015 27 Workshop e-Business P2015
OMG CORBA
ORB core (Object Request Broker)
Client Serveur
ORB ORB
Proxy (souche)
POA
Serviteur (squelette)
BUS MIDDLEWARE
23-27 février 2015 28 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 15
Architecture des applications Modèle MVC
• MVC : Model-View-Controller – Étudié en 1979 par Xerox (pour smalltalk)
– Utilisé dans les applications GUI (AWT, Swing)
– Event-driven Programming
• Model – réalise effectivement les traitements applicatifs sur les données ( Business Process)
• View – obtient les données du « modèle » et les « présente » à l’utilisateur ( Human-Machine I{nteraction|nterface})
• Controller – reçoit et traduit les entrées en requêtes vers le « modèle » ou la « vue » ( Business Logic)
29 23-27 février 2015 Workshop e-Business P2015
Architecture MVC
• Séparation des flux par des interfaces
Affichage View Model
Côté Application
Controller
Vitrine
Arrière-boutique
30 23-27 février 2015 Workshop e-Business P2015
Orienteur
Workshop e-Business 23-27 février 2015
Philippe Lalevée 16
Architecture n-tier
• Découpage des applications en « étages » (tier)
tier client tier du milieu
(Middleware)
tier ressource
(S.I.)
Côté serveur
23-27 février 2015 31 Workshop e-Business P2015
Rôle du tier client
• Ici le client peut être de « toute » nature – Utilisateur final humain
– Autres applications
– Systèmes de stockage
• IHM : interface graphique (GUI) ou console (CLI) – Partie vue du modèle MVC
– Présentation des données
• Adaptation au « terminal » – Transformations « à la volée »
– Prise en compte des caractéristiques de sortie (reporting)
32 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 17
Rôle du middle-tier (middleware)
• Gestion des composants – fournit tous les services et outils pour gérer les composants du
système et l’implémentation de la «logique métier (business) »
• Transaction Management – Une transaction comprend plusieurs opérations, dont toutes ou
aucune doivent être effectuées pour protéger l’intégrité des données
– Assure les propriétés ACID des transactions (atomicité, consistance, isolation et durabilité)
• Passage à l'échelle (scaling) – Capacité du système d'accroître ses ressources matérielles pour
supporter un nombre accru de requêtes utilisateur avec un temps de réponse constant
33 23-27 février 2015 Workshop e-Business P2015
Rôle du middle-tier (middleware)
• Répartition de charge – Capacité d’envoyer une requête a différents serveurs en fonction de
leur disponibilité
– Gestion aux différents étages, à partir du réseau
• Tolérance aux fautes, haute disponibilité – Règle des ‘9’ : 3 8h45 et 5 5 mn
– Redondance aux différents étages
• Sécurité – Identification, authentification, autorisation
• Console de management – Gestion centrale de tout le système
23-27 février 2015 34 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 18
Le tier ressource (S.I.)
• Système de Gestion de Base de Données (database) – JDO, SQL/J, JDBC, ADO.NET
• Systèmes existants (legacy systems)
• ERP (Enterprise Resource Planning)
• EAI (Enterprise Application Integration)
• Intégration avec : – Connecteurs (JCA) : développement
– Protocoles propriétaires : dépendances
23-27 février 2015 35 Workshop e-Business P2015
Serveur d’applications • Environnement complet de développement, de test et
d’exécution coté serveur
• Il comprend toujours un serveur de composants
• Serveur avec états
• Supporte la «logique métier» (Business Logic) décrite à l’aide d’objets, de règles et de composants
• Exemples – Microsoft Server 2012 – Visual Studio
– Serveurs Java EE : IBM WebSphere, Redhat JBoss, ObjectWeb JONAS, Oracle WebLogic / Glassfish
– Serveurs CORBA : Micro Focus VisiBroker / ORBacus
36 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 19
Intégration S.I. aux applications Web
Service
ENTREPRISE
BD
BD
Appli
Web
Appli
Web
Appli
Web
Serveur
Web
Ordinateurs centraux
Stations de travail
InternetHTML
Stations de travail
Pare-feu
Service
?
37 23-27 février 2015 Workshop e-Business P2015
Conséquences de l’utilisation d’Internet sur le S.I. • Passage d’un réseau propriétaire à un réseau public
– Nécessité de bâtir des Intranet d’entreprise – Politique de sécurité interne et non déléguée – Prise en compte de cette sécurité dans les applications
• Sécurité – Filtrage réseau : limites – Cryptage : partage de clés (PKI) – Culture d’entreprise : services supports
• Plate-forme de développement – Basée sur des standards et non des technologies – Indépendante du type d’application – Prépondérance des interfaces – Accessibilité étendue : progrès ?
23-27 février 2015 38 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 20
Architecture client/serveur
• Exécution de code en architecture client/serveur
Client léger (navigateur)
Serveur WEB
Applications
Côté serveur Côté client
Client lourd • Applet • ORB • Serveur
23-27 février 2015 39 Workshop e-Business P2015
Programmation Web côté client Qu’est-ce que du code « côté client » ?
• Du logiciel qui est téléchargé d’un serveur Web vers un navigateur et qui s’exécute sur la machine du « client »
• Pourquoi du code « côté client » ? – Meilleure extensibilité : moins de travail pour le serveur
– Meilleure performance pour gérer l’interface
– Créer des interfaces utilisateur non basées sur HTML (animations, validation des informations)
• Technologies
– DHTML, Javascript
– Composants
40 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 21
DHTML et JavaScript • Encapsuler un script dans une page HTML
• Généralement écrit en JavaScript (ECMAScript, JScript) pour des raisons de portabilité – Internet Explorer supporte aussi VBScript et d’autres langages de script
– Mozilla est extensible par plug-in
• Chaque élément HTML devient un objet qui peut être associé à des événements (i.e. onClick)
• Les scripts fournissent du code qui sont exécutés lors de la production d’événements de la part du navigateur
41 23-27 février 2015 Workshop e-Business P2015
Les applets
• Basées sur du bytecode Java
• Portabilité garantie par les JVM :
– « Write once, run anywhere »
• Sûr : le code s’exécute dans un « bac à sable » (sandbox) dont les accès sont contrôlés
• Compatibilité et performance permettent un usage intensif et une large diffusion
– À noter : le succès de Java est plutôt venu des applications côté serveur
42 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 22
Programmation Web côté serveur (1)
Qu’est-ce que du code « côté serveur » ?
• Du logiciel qui s’exécute sur le serveur Web et non sur la machine du client
• Il reçoit ses données en entrée à partir de :
– Les paramètres des URL
– Les données des formulaires HTML
– Les entêtes HTTP, y compris les cookies
• Il peut accéder à des bases de données côté serveur, des serveurs de mail, des machines de gestion, etc.
• Il construit dynamiquement une réponse adaptée à chaque requête client
43 23-27 février 2015 Workshop e-Business P2015
Programmation Web côté serveur (2)
• Accessibilité – Tout client peut atteindre Internet de n’importe quel navigateur,
n’importe quelle machine, n’importe quand, n’importe où…
• Gestion – Ne nécessite pas la distribution du code des applications
– Facilité de changer le code
• Sécurité – Le code source n’est pas accessible
– Une fois le client authentifié, ses actions peuvent être autorisées ou interdites
• Extensibilité – Extension facile avec l’architecture « 3-tier »
23-27 février 2015 44 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 23
Technologies côté serveur • Codes
– Common Gateway Interface (CGI en C) – Internet Server API (ISAPI) – Netscape Server API (NSAPI)
• Scripts – (PERL, RUBY, PYTHON…) – Active Server Pages (ASP) – Personal Home Page (PHP) – Coldfusion de Macromedia (CFM)…
• Codes et scripts mêlés – Java Server Pages (JSP) – ASP.NET
23-27 février 2015 Workshop e-Business P2015 45
Réponse
Compilation à la volée : JEE
Réponse Classe de la page Instanciation,
traitement, affichage
Classe générée
Génère Analyse moteur JAVAC
Fichier JSP
1ère Requête
Com- posants
Bro
wse
r W
eb
Tomcat 2ème Requête
Instancie
23-27 février 2015 46 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 24
Réponse
Compilation à la volée : .NET
Réponse Classe de la page Instanciation,
traitement, affichage
Classe générée
Génère Analyse moteur
ASPX
Fichier ASPX
1ère Requête
Classe Code
Behind
Bro
wse
r W
eb
IIS 2ème Requête
Instancie
23-27 février 2015 47 Workshop e-Business P2015
Web et MVC • Traitement de la présentation (View) sur le client et le serveur
(étage « front office ») et du contrôle de processus (Controller) et de la partie métier (Model) sur le serveur (étage « back office »)
• Adaptation de la présentation au « client » – Données : HTML, WML, XML, PDF…
– Terminal : PC, Tablette, PDA, SP, GSM
– Réseau
• Gestion « passive » ou « active » des changements d’état – Passive : « Adapter pattern » (interruption ou callback)
– Active : « Observer pattern » (scrutation)
23-27 février 2015 48 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 25
Architecture n-tier : application au Web
Le tier client
Le tier du milieu
Le tier ressource
(EIS)
Le côté serveur
Clients web
Web services
Le tier web
Web Services
Contenu statique
Web Container Web
Serveur
CGI scripts
Scripts (Fast CGI)
Autres extensions
HTML, XML / HTTP, HTTPS
SOAP / HTTPS
SOAP / HTTPS
SQL, propriétaire
XML, RMI / HTTP, IIOP,
JRMP, JMS
Front Office Back Office
49 23-27 février 2015 Workshop e-Business P2015
Enchaînements n-tier
Le tier client
Client Web
tier web
Web Services
SOAP / HTTPS SOAP /
HTTPS
tier web
Web Services
SOAP / HTTPS
SOAP / HTTPS
tier web
SOAP / HTTPS
tier web
SOAP / HTTPS
50 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 26
Bilan des architectures
• La solution doit intégrer les architectures existantes
– Mainframe : institutions
– Réseaux locaux d’applications
– Client-serveur WEB
• Nouvelles solutions
– Réseaux de serveurs applicatifs (enchainements n-tier)
– Architectures orientées composants
– Politiques d’intégration et de sécurité
• Évolutions EAI, SOA et Cloud computing
51 23-27 février 2015 Workshop e-Business P2015
Technologies Applicatives Web
Bilan des technologies
23-27 février 2015 52
• HTML (ou XHTML) : langage à balises hypertexte
• CSS (Cascading Style Sheet) : présentation des documents
• Javascript : code côté client
• XML (eXtended Markup Language) : description des données
• RSS (ou ATOM) : syndication des flux
• HTTP : protocole de transport des messages
• URI : identifiants universels • XML-RPC (Remote Procedure Call) : invocation synchrone
• REST (Representational State Transfer) : accès aux ressources
• WS-* (Web Services) : invocation de services • AJAX (Asynchronous Javascript and XML) : requêtes JSON sur HTTP
en mode asynchrone en Javascript
Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 27
PUB ! Rappels et introduction générale
53 23-27 février 2015 Workshop e-Business P2015
Pub! Architecture .NET • .NET est une stratégie de produits Microsoft
• Remplacement de Microsoft DNA
23-27 février 2015 Workshop e-Business P2015 54
Workshop e-Business 23-27 février 2015
Philippe Lalevée 28
Pub! Architecture JEE
• Le serveur JEE fournit des conteneurs qui permettent de simplifier les composants et d’offrir tous les services nécessaires
55
• JEE est un standard industriel – contrairement à .NET c’est une
spécification
– Actuellement, version 1.4
• Une application JEE assemble des composants – Web : servlets et JSP
– business : EJB
– écrits en Java, compilés en bytecode
– applications clientes, applets
– assemblés dans l’application
– déployés dans un serveur
23-27 février 2015 Workshop e-Business P2015
Pub! Modèles de développement
Source : http://www.sdmagazine.com/documents/s=733/sdm0103a/0103a.htm
Un langage Plusieurs plate-formes
Plusieurs langages Une plate-forme
23-27 février 2015 56 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 29
Tableau comparatif JEE/.NET
Microsoft.
NETJ2EE différences essentielles
LangageC#, Multi-
LangageJava
C# a certains des JavaBeans et ajoute les metadata tags. L'intégration dans la
syntaxe est différente. J2EE est plate-forme indépendant mais langage spécifique,
.NET est langage indépendant mais plate-forme spécifique.
Services BCLJava core
APISimilaire services
Présentation ASP.NETServlet
JSP
ASP.NET utilise tout les langages supportes dans .NET et est compile en code natif
par le CLR. JSPs utilisent Java code (snippets, ou JavaBean références), compile en
bytecodes.
Interprète CLR JVMCLR permet a du code de plusieurs langages d'utiliser un ensemble de composants
partages.
GUI
composants
Win
Forms
Web
Forms
SwingComposants Web similaire ne sont pas disponible en Java. WinForms et WebForms
sont complètement intègre a VisualStudio .net
DB accès ADO.NET
JDBC,
JDO,
SQL/J
ADO.NET est construit a partir d'une architecture XML
WebServices oui oui.NET web services supposent un model de message base sur SOAP tandis que
J2EE laisse le choix au developpeur.
Implicit
middlewareoui oui
Technologie Produit Standard J2EE est une specification, .NET est une strategie de produits
23-27 février 2015 57 Workshop e-Business P2015
XML Rappels et introduction générale
58 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 30
Représentation des données • Brute (« raw »)
– Flux d’octets (bits) – Efficace mais sensible à son usage
• Textuelle – Adoption d’un jeu de caractères – Conversions implicites (endianness, formats)
• Relationnelle – Inspirée des MLD (Merise) – Utilisation dans les bases de données relationnelles
• Arborescente – Inspirée des « enregistrements » COBOL – Représentation unique (non ambigüe)
59 23-27 février 2015 Workshop e-Business P2015
Présentation rapide de XML • Sous-ensemble de SGML
– Alors que HTML est une implémentation de SGML
• Métalangage avec balises (Markup) – Fichier texte
• Conçu pour une représentation structurée de l’information – Sous forme hiérarchique (arborescente)
• Fournit un « contexte » aux données (signifiantes) – Informations auto-descriptives
• Séparation de la présentation (HTML) des données (XML) – Pas de sémantique associée
• Standard ouvert du W3C
23-27 février 2015 60 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 31
• Spécification de données « utilisable partout »
• Intérêt applicatif : Validation XML et Définition – Respect de la grammaire XML – Respect de la définition de la structure
Application A
Utilisation de XML
Application C
Application B
XML BD XML
61 23-27 février 2015 Workshop e-Business P2015
Description
• DTD : Document Type Definition
– Définition simple (et rapide)
– Obsolète aujourd’hui
• Schéma
– Définition XML de la structure
– Typage fort des données
– Réutilisation possible
23-27 février 2015 62 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 32
Manipulation
• Traitement séquentiel et événementiel
– De type « SaX »
– Les éléments sont lus « ligne à ligne »
– Chaque ligne déclenche un événement activable
• Traitement de l’arbre
– De type « DOM »
– Le fichier (instance) est lu complètement en mémoire sous la forme d’un arbre
– Cet arbre est vu comme une arborescence objet
63 23-27 février 2015 Workshop e-Business P2015
Transformations
• Traitement de sortie
– Application de feuilles de styles : XSLT
– Sérialisation des données
• XSL : eXtensible Stylesheet Language
– XSL Transformations : XML Langage
– XSL-FO (formatting objects) mise en page
• Transformations
– PS, PDF, HTML, WML, ASCII… et XML
64 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 33
XML et RPC/RMI
• RPC/RMI dans lequel :
– Le protocole de communication est HTTP
– L’encodage des données est XML
• SOAP (Simple Object Access Protocol)
– Version proposée par Microsoft
– Reprise par les éditeurs de logiciels
65 23-27 février 2015 Workshop e-Business P2015
URBANISATION ET INTÉGRATION Rappels et introduction générale
66 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 34
Scénarios n-tier
• L’architecture n-tier permet plusieurs modèles d’exécution des applications
– Applications Web (classiques)
– Applications B2C
– Applications Intranet
– Applications B2B
– Applications multi-tier
• Inspirés de Java EE, mais valables aussi en .NET
67 23-27 février 2015 Workshop e-Business P2015
Applications Web
• Requêtes HTTP par des URL
– Servlet : descripteur de déploiement
– JSP : extension du fichier
23-27 février 2015 68 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 35
Applications B2C
• Le conteneur Web interagit avec le S.I. de l’entreprise par des API ad hoc
– JavaMail, JDBC, JMS, JXTA…
69 23-27 février 2015 Workshop e-Business P2015
Applications intranet
• Le client accède directement aux ressources applicatives de l’entreprise
• Intérêts : client « riche », sécurité simplifiée
70 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 36
Applications B2B
• Les conteneurs accèdent à leurs homologues – Protocoles standards : CORBA, RMI, DCOM
– Technologies Web Services (architecture SOA)
71 23-27 février 2015 Workshop e-Business P2015
Applications multi-tier
• Applications complètement intégrées
– Multiplateformes, multi-machines (cluster)
– Indépendance des parties (tier)
23-27 février 2015 72 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 37
Urbanisation
Construction « historique »
73 23-27 février 2015 Workshop e-Business P2015
Conséquences sur le S.I.
• Gestion des données : ruptures – Applications : mises à jour non répercutées
– Identifiants : plusieurs accès à une même information
– Chaîne informatique : échanges de données non « industrialisés » (sensibilité variable)
– Temporelle : délais de mise à jour longs
– Géographique : les données sont situées en des endroits différents
• Constats – Duplication, saisies multiples
– Incohérences et erreurs
74 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 38
Urbanisation • Urbaniser, c'est diriger la transformation continue du système
d’information pour le simplifier durablement
Démarche d’urbanisation Cartographie des
systèmes existants
Détermination des systèmes cibles
23-27 février 2015 75 Workshop e-Business P2015
Principe d’urbanisation n°1
Modularité et encapsulation
• Partitionnement du S.I. en sous-ensembles fortement cohérents – Données et traitements conceptuellement
proches
• et faiblement couplés – Évolution de l’un n’a pas d’impact sur les autres
• Services Fonctionnels – Référentiels de données, accessibles par des
interfaces publiques
– Traitements sous le contrôle de « pilotes »
76 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 39
Principe d’urbanisation n°2
Sécurité du S.I. • Infrastructure de confiance
– Authentification réciproque des acteurs
– Autorisation des échanges
• Les flux de contrôle sont toujours à l’initiative du destinataire – Mode Pull
– Chaque Service Fonctionnel garde le contrôle de ses données
• Fonctionnement autonome des Services Fonctionnels
77 23-27 février 2015 Workshop e-Business P2015
Principe d’urbanisation n°3
Localisation unique des informations
• Gestion en un point unique du S.I. – Localisation unique et uniforme (URI) – Distinction information/donnée
• Copie(s) possible(s) – Archivage – Gestion des délais (mémoire « cache ») – Redondance, clustering… – Non accessible aux traitements « métier »
• Intégrité des informations – Propriétés ACID – Modèle de données disjoints
78 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 40
Principe d’urbanisation n°4
Localisation unique du pilotage
• Pilotage des activités du S.I. – Modélisation sous forme d’activités « métier »
– Toute activité métier est pilotée de bout en bout sans délégation par un unique Service Fonctionnel pilote
– Ce pilote enchaine les demandes de services aux référentiels
• Localisation unique et uniforme (URI) – Modèle homogène
– Ressource : information ou traitement
79 23-27 février 2015 Workshop e-Business P2015
Principe d’urbanisation n°5
Urbanisation des échanges
• Architecture de communication point à point
– Chaque application métier « connaît » ses destinataires
– Elle assure le contrôle, la transformation, le suivi, la gestion des erreurs
dépendances inter-application
• Découpage applicatif « urbain »
– Définition des zones (quartier/îlots/blocs)
– Définition des échanges entre zones
– Dictionnaire de données métier
80 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 41
Principe d’urbanisation n°6
Sémantique des Protocoles • Asynchronisme des pilotes
– Pas de contrainte point à point de synchronisation
– Modélisation doit permettre l’activation simultanée « conversationnel/non conversationnel »
– Pas de connaissance « a priori »
Gestion par messages
Journalisation / invalidation des informations
• Services « sans état »
– État des référentiels toujours cohérents
– Facilite la gestion des transactions (à deux phases)
81 23-27 février 2015 Workshop e-Business P2015
Intégration des Applications d’Entreprise
Intégration niveau de l’Entreprise
82 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 42
Intégration des Applications d’Entreprise
Intégration Entreprise
• A2A : Application-to-Application – Intégration des applications et des systèmes
• B2B : Business-to-Business – Intégration des processus et des applications des
partenaires/clients/fournisseurs
• B2C : Business-to-Consumer – Intégration directe des clients finaux en processus
« corporate »
• B2E : Business-to-Employee – Intégration des fonctions de management de
l’organisation de l’entreprise (RH, KM)
83 23-27 février 2015 Workshop e-Business P2015
Intégration des Applications d’Entreprise
Types d’intégration
• Portails – Intégration d’applications (portlets) au niveau utilisateur
• Données partagées – Architecture d’intégration au niveau de l’accès aux données
• Fonctions partagées – Architecture d’intégration au niveau des fonctions ou méthodes
Enterprise Application Integration o Partage de données et de processus métiers entre des
applications connectées
Service Oriented Architecture o Partage / échanges de services fonctionnels faiblement couplés
23-27 février 2015 84 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 43
Intégration des Applications d’Entreprise
Principes EAI • Partage des informations et des traitements entre
« applications » – Échanges d’informations métier – Enchaînement des processus métier
• Optimisation du S.I. – Maintenance / erreurs et fautes – Évolutivité des solutions technologiques
• La décentralisation (départementalisation) a entrainé – Développement sur systèmes hétéroclites – SGDB hétérogènes – Réseaux non interopérables
85 23-27 février 2015 Workshop e-Business P2015
Solutions actuelles • Middleware
– Définition d’interfaces applicatives – Bus logiciel
• S.I. centré sur un ERP – Intégration « propriétaire » – Ces ERP sont des « silos »
• Applications WEB – Développement « en dehors » du S.I. – Notions intranet et Extranet
• Infrastructure « Orientée Message » – Désynchroniser les traitements – Adaptation des données
• Orchestration des processus – BPM et Workflow – Gestion des événements / séquences d’action
23-27 février 2015 86 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 44
Communications entre applications
ERP ERP
Cli/Srv DataWH
SCM CRM
Legacy
EAI
SCM
DataWH
Legacy
Cli/Srv
CRM
23-27 février 2015 87 Workshop e-Business P2015
Intégration et XML
• Choix de XML – Universalité de la solution
– Flexibilité des technologies
• Niveau des données – Définition de formats de documents
– Validation des messages
– Transformations de format
• Niveau architecture technique – Découplage des communications
– Applications hétérogènes
88 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 45
XML et les S.I.
BUS XML
XML
XML
XML
XML
XML
Applications métiers
ERP
Services Distribués
Annuaire
Bases de Données
23-27 février 2015 89 Workshop e-Business P2015
Niveaux d’intégration • Plate-forme
– Connectivité matérielle, système et logicielle
• Données – Passerelles bases de données et outils d’extraction
(datawarehouse)
• Composants – Serveurs d’applications, passerelles ERP, Tier du milieu
• Applications – Adaptateurs dédiés ou Hub & Spoke
• Processus – BPM (Business Process Management) : moteur de
workflow, modélisation processus métiers
Mid
dle
war
e
90 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 46
EAI : niveau application
• Intégration au niveau système mais aussi « sémantique »
• Différents aspects – Nature des échanges : les messages sont des éléments du business
(bon de commande…)
– Traitements particuliers liés aux échanges : « suivi », « stockage », « datawarehouse »…
– Modèles de données mécanismes de conversion
– Intégration analyse business, sous forme d’enchaînement de tâches enchaînement de programmes
• Architectures classique : point à point et pipeline
• Proposition d’architecture centralisée : le « hub and spoke »
91 23-27 février 2015 Workshop e-Business P2015
Architecture « hub and spoke »
• Le Hub – Gestion centralisée des files d’attente – Communications 1/1 (question/réponse) ou 1/n
(publier/souscrire) – Le workflow
• Destination en fonction de l’entête des messages • Des valeurs contenues dans le message • Séquences de traitement e-business (liste des
étapes)
– Traitement des données • Conversion métier • Différent du codage
• Le Spoke – Partie protocole réseau – Adaptateur (JCA)
• Les messages (JMS, MSMQ) – En XML – Entête d’identification – Propriétés
ApplicationA
Adaptateur
Spoke Spoke
WorkFlow
LDAP
Hub
File File
Traitement
de données
File
ApplicationB
Adaptateur
92 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 47
EAI : niveau processus
Application 1
Application 2
Application 3 Annuaire Services
Services
Workflow Métier Backoffice
Bases Données
Autres Systèmes
23-27 février 2015 93 Workshop e-Business P2015
WEB SERVICES TECHNOLOGIES ET ARCHITECTURES
Deuxième partie
94 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 48
PRINCIPES Web Services: Technologies et Architecture
95 23-27 février 2015 Workshop e-Business P2015
Exemple type
Agence de voyage • Un produit « voyage » est la combinaison de plusieurs
produits – Billets de transport
– Chambres d’hôtel
– Voitures de location
– …
• Son élaboration est le résultat de services et d’informations obtenus auprès de plusieurs fournisseurs – Compagnies aériennes
– Chaînes hôtelières
– Loueurs de véhicules
– …
• Quelles sont les solutions ?
23-27 février 2015 Workshop e-Business P2015 96
Workshop e-Business 23-27 février 2015
Philippe Lalevée 49
Les besoins des entreprises
Agence de voyage
Compagnies aériennes
Loueurs de véhicules
• Les compagnies, les fournisseurs, les partenaires et les clients doivent être capables de travailler ensemble
– Plus vite que jamais auparavant
– À travers Internet
– Ou risquer la « mort par isolement »
• leurs systèmes d’information se recouvrent
• Certains de leurs processus métier sont donc communs
• Assurer l’interopérabilité ? – Évolutivité ?
– Transparence ?
– Sécurité ?
23-27 février 2015 Workshop e-Business P2015 97
Serveurs d’applications
• Architecture 3-tier des applications
– Moyen puissant pour construire des applications Web extensibles et adaptables
• Mais de telles applications sont des silos
– L’intégration est une conséquence « après coup »
– Elles peuvent être intégrées derrière le pare-feu de l’entreprise (firewall)
• Même cela peut être un problème
– Elles ne fournissent pas de moyen pour s’intégrer à travers les pare-feux (i.e. à travers Internet)
23-27 février 2015 Workshop e-Business P2015 98
Workshop e-Business 23-27 février 2015
Philippe Lalevée 50
Les Web Services ! • Un Web Service expose ses fonctionnalités au client
– Par une description (contrat) XML – Automatisation des processus métiers
• Basé sur des standards Web – TCP/IP, HTTP, XML, SOAP, WSDL, UDDI, WS-* (d’autres à venir) – Par une URL programmable à travers Internet ou l’intranet (REST…) – Par des fonctions appelables sur Internet
• Implémentés dans n’importe quel langage sur n’importe quelle plate-forme – Ils agissent comme des « boîtes noires » – Garantie d’interopérabilité – « Composants logiciels réutilisables »
• Les Web Services reprennent les avantages du calcul réparti et des portails et n’en possèdent pas les inconvénients – En fournissant un mécanisme pour invoquer des « méthodes » à
distance – En utilisant des standards du Web (comme HTTP, SMTP, XML…) – En proposant un « bus XML » garant de l’interopérabilité – En intégrant les applicatifs sans les remettre en cause
23-27 février 2015 Workshop e-Business P2015 99
SCHÉMAS XML Web Services: Technologies et Architecture
100 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 51
Les acteurs
• Le client
– Celui qui utilise, invoque le Web Service
• Le fournisseur (prestataire)
– Serveur d’application (par exemple, J2EE)
– Les services sont des composants (par exemple, des servlet/EJB) enveloppés dans une couche service
• L’annuaire
– Publication du service dans un dépôt (registre)
23-27 février 2015 Workshop e-Business P2015 101
Tâches associées • Interroger un annuaire
– Pour connaître la nature, le rôle et le contenu des services
• Négocier avec les fournisseurs – Nature exacte du service fourni
– Qualité, coût…
• Interagir avec le service – Modalités d’interaction
– Introduire le service dans la chaîne de traitement
• Composer des services
• Publier des services
23-27 février 2015 Workshop e-Business P2015 102
Workshop e-Business 23-27 février 2015
Philippe Lalevée 52
Relations entre les acteurs
Demandeur de Services Web Fournisseur de
Services Web
Annuaire UDDI
Client API SOAP
Document WSDL
Impl Publi
2. Recherche le service
3. Recherche le WSDL
1. Publie le service
4. Invoque le service
Tous les messages sont des requêtes SOAP
23-27 février 2015 Workshop e-Business P2015 103
Scénario complet • Étape 1. Définition et description du service
– Contrat de service en WSDL
• Étape 2. Publication du service – Annuaire UDDI
• Étape 3. Recherche du service – Interrogation d’un annuaire UDDI
• Étape 4. Enregistrement du service – Contact avec le fournisseur et respect du contrat
• Étape 5. Mise en œuvre du service – Invocation selon le contrat
• Étape 6. Composition – Applications orientées service
23-27 février 2015 Workshop e-Business P2015 104
Workshop e-Business 23-27 février 2015
Philippe Lalevée 53
Les protocoles et schémas • Internet (le Web)
– HTTP, XML et DNS
• SOAP (Simple Object Access Protocol) – IIOP pour CORBA
– RMI pour les EJB
• WSDL (Web Service Description Language) – IDL pour CORBA
– Interfaces Java pour les EJB
• UDDI (Universal Description, Discovery and Integration) et DISCO – CosNaming pour CORBA
– JNDI pour les EJB
23-27 février 2015 Workshop e-Business P2015 105
Un exemple
Source : http://www.dotnetguru.org/articles/webservices/WebServices.htm
23-27 février 2015 Workshop e-Business P2015 106
Workshop e-Business 23-27 février 2015
Philippe Lalevée 54
CONCEPTION Web Services: Technologies et Architecture
107 23-27 février 2015 Workshop e-Business P2015
Conception d’un Web Service • Un composant logiciel fabrique la concaténation à
partir de deux chaines de caractères – Les clients peuvent utiliser différents langages sur
différentes plateformes – Les échanges se font par Internet, en traversant des
firewalls
• Principe : fournir un Web Service (SimpleService) à partir d’un serveur (www.emse.fr)
• L’URL http://www.emse.fr/SimpleService est appelée Web Service Endpoint
• Pour l’instant, une seule opération concat est proposée
23-27 février 2015 Workshop e-Business P2015 108
Workshop e-Business 23-27 février 2015
Philippe Lalevée 55
Structure du Web Service (1)
Internet
Serveur Web : http://www.emse.fr
Web Service : /SimpleService
Opération :
Opération :
Nom : concat
Nom : …
Ils constituent ensemble le EndPoint du Web Service
Comment garantir que concat soit globalement unique ?
Utiliser un namespace ! • concat est un « local name » • Le nom complet est appelé un
QName (Qualified Name)
Namespace : http://www.emse.fr/ns
23-27 février 2015 Workshop e-Business P2015 109
Style RPC du Web Service
• Style RPC (Remote Procedure Call)
– Forme : Type Opération (Type par1, Type
par2…)
– Les paramètres sont transmis « un par un »
Opération :
Local Name : concat Namespace : http://www.emse.fr/ns Paramètres : s1 : string s2 : string Retour : string
Que signifie string ?
Ce ne peut pas être un type d’un langage, donc utiliser un schéma XML !
(w3.org/XMLSchema)
(w3.org/XMLSchema)
(w3.org/XMLSchema)
23-27 février 2015 Workshop e-Business P2015 110
Workshop e-Business 23-27 février 2015
Philippe Lalevée 56
Organisation des messages • Les RPC peuvent être proposés, sous forme de messages
– L’appel est appelé « input message » – La valeur de retour est appelée « output message » – Les paramètres sont appelées « parts »
Local Name: concat
Namespace: http://www.emse.fr/ns
Input Message:
Part 1:
Name: s1
Type : string (w3.org/XMLSchema)
Part 2:
Name: s2
Type : string (w3.org/XMLSchema)
Output Message:
Part 1:
Name: retour
Type : string (w3.org/XMLSchema)
23-27 février 2015 Workshop e-Business P2015 111
Appel du Web Service
Local Name: concat
Namespace: http://www.emse.fr/ns
Input Message:
Part 1:
Name: s1
Type : string (w3.org/XMLSchema)
Part 2:
Name: s2
Type : string (w3.org/XMLSchema)
Output Message:
Part 1:
Name: retour
Type : string (w3.org/XMLSchema)
<miage:concat xmlns:miage="http://www.emse.fr/ns"
xmlns:xsd="... XMLSchema" ...>
<s1 xsi:type="xsd:string">Bonne</s1>
<s2 xsi:type="xsd:string">journée</s2>
</miage:concat>
23-27 février 2015 Workshop e-Business P2015 112
Workshop e-Business 23-27 février 2015
Philippe Lalevée 57
Retour du Web Service
Local Name: concat
Namespace: http://www.emse.fr/ns
Input Message:
Part 1:
Name: s1
Type : string (w3.org/XMLSchema)
Part 2:
Name: s2
Type : string (w3.org/XMLSchema)
Output Message:
Part 1:
Name: retour
Type : string (w3.org/XMLSchema)
<miage:concat xmlns:miage="http://www.miage.org/ns"
xmlns:xsd="... XMLSchema" ...>
<retour xsi:type="xsd:string">Bonne journée</retour>
</miage:concat>
23-27 février 2015 Workshop e-Business P2015 113
Style DOCUMENT du Web Service • Les données envoyées et reçues peuvent être validées
– Forme : Document Opération (Document) – Les schémas des documents doivent être fournis dans l’interface du WS
Local Name: concat
Namespace: http://www.emse.fr/ns
Input Message:
Part 1:
Name: concatRequest
Element: concatRequest
Output Message:
…
<xsd:schema targetNameSpace="http://www.emse.fr/ns" ...">
<xsd:element name="concatRequest">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="s1" type="xsd:string"/>
<xsd:element name="s2" type="xsd:string"/>
</...>
</xsd:schema>
23-27 février 2015 Workshop e-Business P2015 114
Workshop e-Business 23-27 février 2015
Philippe Lalevée 58
Port Type: quelles opérations ?
• Seul le document est envoyé dans la requête : comment transmettre l’opération ?
• Les Web Services ne contiennent pas la liste des opérations – Les opérations sont groupées dans des « Port Type » – Un Port Type peut être vu comme une classe Java et les
opérations qu’il contient comme des méthodes statiques
• Plusieurs Port Type peuvent être associés à un Web Service
<miage:concatRequest xmlns:miage="http://www.emse.fr/ns">
<s1>Bonne</s1>
<s2>journée</s2>
</miage:concatRequest>
23-27 février 2015 Workshop e-Business P2015 115
Les WS avec des Port Type
Internet
Serveur Web : http://www.emse.fr
Web Service : /SimpleService
Opération :
Nom : concat NS: http://www.emse.fr/ns
Schéma:
Port Type:
Name: stringUtil NS: http://www.emse.fr/ns
Opération :
Nom : concat NS: http://www.emse.fr/ns
Port Type:
Name: dateUtil NS: http://www.emse.fr/ns
…
… … …
…
23-27 février 2015 Workshop e-Business P2015 116
Workshop e-Business 23-27 février 2015
Philippe Lalevée 59
binding : comment préciser le format ?
• Le format des messages spécifie comment ils sont échangés : – Texte (chaîne de caractères) éventuellement MIME
– XML : XML-RPC ou SOAP
– Le format textuel ne permet pas la validation
– Le standard W3C SOAP fournit une interface HTTP/XML robuste • Support étendu des types de données
• Mais complexité de mise en œuvre (et efficacité ?)
• Et aussi comment ils sont transportés – GET ou POST
– SMTP
– GET et POST utilisent le protocole HTTP pour invoquer les Web Services en mode synchrone
– SMTP utilise le mail en mode asynchrone
• Les combinaisons sont appelées des « binding »
23-27 février 2015 Workshop e-Business P2015 117
Les WS avec des Binding Web Service : /SimpleService
Schéma:
Port Type:
Name: stringUtil NS: http://www.emse.fr/ns
Binding:
Nom : Liaison1 Port Type: stringUtil Format: SOAP Transport: HTTP
…
…
…
Nom : Liaison2 Port Type: stringUtil Format: TEXT Transport: SMTP
Binding:
POST /M2/TP2/WS.do HTTP/1.1
User-Agent: Mozilla/1.22 ...
<miage:concatRequest ...>
<s1>Bonne</s1>
<s2>journée</s2>
</miage:concatRequest>
FROM: [email protected]
concat(s1="Bonne",s2="journée")
23-27 février 2015 Workshop e-Business P2015 118
Workshop e-Business 23-27 février 2015
Philippe Lalevée 60
Port: sur plusieurs machines
• Un même Web Service peut être proposé sur plusieurs machines « Port » – C’est un « Binding » que l’on place sur un « Port »
– Par exemple, dans l’exemple précédent, on peut placer Liaison1sur les machines miage1, miage2 et miage3, et Liaison2 sur la machine miage3
– Il y a dans ce cas QUATRE « Port »
• Un composant logiciel devra être présent pour mettre en œuvre le « Port Type » – Les ports peuvent être de langage différent
– Sur une même machine (par exemple miage3), plusieurs formats et transports peuvent cohabiter
23-27 février 2015 Workshop e-Business P2015 119
Retour sur les URI, URN et URL • Les Web Services doivent définir un espace de nommage
unique (en général, il est commun) en utilisant une URI, « Uniform Resource Identifier » – Soit une URL, « Uniform Resource Locator » – Soit un URN, « Uniform Resource Name »
• Choix d’une URL – Le domaine est géré par vous – Cohérence possible avec l’accès – Mais risque de confusion
• Choix d’un URN – Indépendance avec l’accès et la localisation – Syntaxe : urn:name_identifier:name_specific
– Désignation standardisée par le IANA, mais utilisation possible du nom de domaine comme name_identifier
– Par exemple, pour notre Web Service : urn:miage.org:ns
23-27 février 2015 Workshop e-Business P2015 120
Workshop e-Business 23-27 février 2015
Philippe Lalevée 61
WSDL Web Services: Technologies et Architecture
121 23-27 février 2015 Workshop e-Business P2015
WSDL : présentation • Les concepts que nous venons de voir constituent les éléments de
schéma WSDL • Un fichier WSDL regroupe les informations nécessaires pour
interagir avec le Web Service – Les types (schéma), types de port (classes), opérations (méthodes) – Les parties (paramètres), liaisons (protocole de transport) et ports
(localisation du service)
• La publication et la recherche de services au sein de l’annuaire UDDI se font avec WSDL – Le fichier retourné est celui contenant l’implémentation du service – Le fichier contenant l’interface de mise en œuvre est fourni par le premier
• Schéma XML : deux fichiers distincts – Définitions des interfaces des services
• Sémantique abstraite pour les Web Services
– Définitions de l’implémentation du service • Nom concret du nœud et adresse réseau où le Web Service peut être invoqué
– Délimitation claire entre les messages abstraits et concrets
23-27 février 2015 Workshop e-Business P2015 122
Workshop e-Business 23-27 février 2015
Philippe Lalevée 62
Exemple : gestion de compte • Pour illustrer les différentes parties, voici une
interface Java pour une gestion de compte – Le passage de Java vers WSDL se fait en général avec
des outils fournis (wsdl2java) ou bien intégrés au serveur d’application
import java.util.*; public interface CompteInterface { public void depotDe (int montant); public boolean retraitDe (int montant); public int valeurSolde (); public Vector listeMouvements(); }
23-27 février 2015 Workshop e-Business P2015 123
Partie 1. Les types
• La methode listeMouvements retourne un Vector description de ce type
<wsdl:types>
<schema targetNamespace="http://xml.apache.org/xml-soap"
xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<complexType name="Vector">
<sequence>
<element maxoccurs="unbounded" minoccurs="0"
name="item" type="xsd:anyType" />
</sequence>
</complexType>
</schema>
</wsdl:types>
Pour cet exemple, les autres types sont prédéfinis
23-27 février 2015 Workshop e-Business P2015 124
Workshop e-Business 23-27 février 2015
Philippe Lalevée 63
Partie 2. Les messages
• Les méthodes disposeront de deux messages : un pour l’appel, un pour la réponse
<wsdl:message name="listeMouvementsRequest" />
<wsdl:message name="listeMouvementsResponse">
<wsdl:part name="listeMouvementsReturn"
type="apachesoap:Vector" />
</wsdl:message>
<wsdl:message name="depotDeRequest">
<wsdl:part name="in0" type="xsd:int" />
</wsdl:message>
<wsdl:message name="depotDeResponse">
<wsdl:part name="depotDeReturn" type="xsd:boolean" />
</wsdl:message>
...
23-27 février 2015 Workshop e-Business P2015 125
Partie 3. Les types de port
• Un type de port est composé des opérations abstraites applicables au service, ie les signatures de méthodes Java (dans l’interface)
• Les opérations sont composées d’une séquence de messages (un pour l’appel, un pour le retour) à un mode d’invocation particulier du service
<wsdl:operation name="listeMouvements">
<wsdl:input message="impl:listeMouvementsRequest"
name="listeMouvementsRequest" />
<wsdl:output message="impl:listeMouvementsResponse"
name="listeMouvementsResponse" />
</wsdl:operation>
23-27 février 2015 Workshop e-Business P2015 126
Workshop e-Business 23-27 février 2015
Philippe Lalevée 64
Partie 3. Les types de port
• Dans l’exemple, il y aura un seul type de port, composé des 4 opérations
<wsdl:portType name="Compte">
<wsdl:operation name="listeMouvements">
<wsdl:input message="impl:listeMouvementsRequest"
name="listeMouvementsRequest" />
<wsdl:output message="impl:listeMouvementsResponse"
name="listeMouvementsResponse" />
</wsdl:operation>
<wsdl:operation name="depotDe" parameterOrder="in0">
<wsdl:input message="impl:depotDeRequest"
name="depotDeRequest" />
<wsdl:output message="impl:depotDeResponse"
name="depotDeResponse" />
</wsdl:operation>
...
</wsdl:portType>
23-27 février 2015 Workshop e-Business P2015 127
Partie 4. Les liaisons • Les liaisons décrivent la façon dont un type de port (l’abstraction
du service) est mis en œuvre – pour un protocole particulier (HTTP par exemple)
– Pour un mode d’invocation particulier (RPC par exemple)
• Cette description est faite pour un ensemble d’opérations abstraites
• Pour un type de port, on peut avoir plusieurs liaisons – Différenciation des modes d’invocation ou de transport des différentes
opérations
23-27 février 2015 Workshop e-Business P2015 128
Workshop e-Business 23-27 février 2015
Philippe Lalevée 65
Partie 4. Les liaisons <wsdl:binding name="CompteSvcBinding" type="impl:compte">
<wsdlsoap:binding style="soap"
transport="http://schemas.xmlsoap.org/soap/http/" />
<wsdl:operation name="depotDe">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="depotDeRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/CompteSvc"
use="encoded" />
</wsdl:input>
<wsdl:output name="depotDeResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/CompteSvc"
use="encoded" />
</wsdl:output>
</wsdl:operation>
...
</wsdl:binding>
23-27 février 2015 Workshop e-Business P2015 129
Partie 5. Les ports • Un port spécifie une adresse URL de l’implémentation d’un
service par un fournisseur
• Le port est associé à une « liaison » définissant ainsi un simple point de terminaison
<wsdl:port binding="impl:CompteSvcBinding" name="CompteSvc">
<wsdlsoap:address
location="http://localhost:8080/axis/services/CompteSvc" />
</wsdl:port>
23-27 février 2015 Workshop e-Business P2015 130
Workshop e-Business 23-27 février 2015
Philippe Lalevée 66
Partie 6. Le service
• Un service est décrit comme un ensemble de points finaux du réseau : « port »
<wsdl:service name="CompteSvc">
<wsdl:port binding="impl:CompteSvcBinding" name="CompteSvc">
<wsdlsoap:address
location="http://localhost:8080/axis/services/CompteSvc" />
</wsdl:port>
</wsdl:service>
23-27 février 2015 Workshop e-Business P2015 131
SOAP Web Services: Technologies et Architecture
132 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 67
SOAP : les principes
• Principe fondateur : « ne pas inventer de nouvelles technologies »
• Bâti à partir de standards Internet clé – SOAP ≈ HTTP + XML
– Soumis au W3C
• Les spécifications SOAP définissent : – Le format des messages SOAP
– Comment envoyer des messages
– Comment recevoir des messages
– L’encodage des données
23-27 février 2015 Workshop e-Business P2015 133
Structure des messages
SOAP Message
SOAP Envelope
SOAP Header
SOAP Body
Message Name & Data
Headers
Headers
Nom et données encodées en XML du message SOAP
<Body> contient le nom du message SOAP
Entête particulière
<Header> contient les entêtes
<Envelope> contient les données
Entêtes de liaison du protocole
Le message complet SOAP
23-27 février 2015 Workshop e-Business P2015 134
Workshop e-Business 23-27 février 2015
Philippe Lalevée 68
Exemple complet d’une requête
<?xml version="1.0" encoding="UTF-8" ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" > <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="urn:monServiceSOAP"> <symbol>DIS</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
23-27 février 2015 Workshop e-Business P2015 135
Exemple complet d’une réponse
<?xml version=“1.0” encoding=“UTF-8” ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= http:”//schemas.xmlsoap.org/soap/encoding/” xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema" > <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=“urn:monServiceSOAP"> <return xsi:type=“xsd:float”>34.5</return> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
23-27 février 2015 Workshop e-Business P2015 136
Workshop e-Business 23-27 février 2015
Philippe Lalevée 69
Exemple : réponse avec une structure de données
<soap:Envelope ...>
<soap:Body>
<GetStockDataResult xmlns=“http://tempuri.org/”>
<result>
<Description>Plastic Novelties Ltd</Description>
<Prix>129</Prix>
<Action>PLAS</Action>
</result>
</GetStockDataRseult>
</soap:Body>
</soap:Envelope>
23-27 février 2015 Workshop e-Business P2015 137
Exemple d’erreur
<?xml version=“1.0” encoding=“UTF-8” ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:MustUnderstand</faultcode> <faultstring SOAP Must Understand Error </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
23-27 février 2015 Workshop e-Business P2015 138
Workshop e-Business 23-27 février 2015
Philippe Lalevée 70
La sécurité des échanges
• Bâtie sur la sécurité offerte par HTTP
– HTTPS
– certificats X.509
• Les développeurs choisissent quelle méthode exposer explicitement
• Les applications (source) ne sont pas concernées
• Compatible avec les pare-feux
• Compatible avec les types de données
23-27 février 2015 Workshop e-Business P2015 139
SOAP et Tomcat : schéma simplifié
Client Serveur
HTTP Tomcat
SOAP Dispatcher
Implémentation
Requête SOAP
Réponse SOAP
Fournisseur de service
Réseau Internet
23-27 février 2015 Workshop e-Business P2015 140
Workshop e-Business 23-27 février 2015
Philippe Lalevée 71
SOAP: Interopérabilité Java et Excel
Tomcat
Servlet SOAP VB
Macro
HTTP DLL
SOAP DLL
Tableau Excel
Parser XML
SOAP jar
JDBC jar
Data Base
Service
Serveur Client
23-27 février 2015 Workshop e-Business P2015 141
Interactions WSDL et SOAP
23-27 février 2015 Workshop e-Business P2015 142
Workshop e-Business 23-27 février 2015
Philippe Lalevée 72
Liaison entre services
23-27 février 2015 Workshop e-Business P2015 143
Mécanismes mis en jeu
23-27 février 2015 Workshop e-Business P2015 144
Workshop e-Business 23-27 février 2015
Philippe Lalevée 73
Insertion de services techniques
23-27 février 2015 Workshop e-Business P2015 145
SOA AVEC REST ET WS-* Web Services: Technologies et Architecture
146 23-27 février 2015 Workshop e-Business P2015
Workshop e-Business 23-27 février 2015
Philippe Lalevée 74
Retour sur les architectures
• Architecture logicielle – Description de sa structure : composants logiciels,
connecteurs (propriétés externes) et les relations entre eux (communication)
• Style – Modèles de structure, vocabulaire de composants,
contraintes de relation Caractérisation
• Trois grands styles – Architectures orientées objet – Architectures orientées ressources – Architectures orientées services
23-27 février 2015 Workshop e-Business P2015 147
Architecture orientée Objet
• Composant = objet – Identificateur
– État
• Connecteur = interface – Comportement
– Liste d’opérations (méthodes)
• Relations = appel « bloquant/synchrone » – RPC, RMI, DCOM
– Modèle client/serveur
CORBA / JEE RMI / .NET
23-27 février 2015 Workshop e-Business P2015 148
Workshop e-Business 23-27 février 2015
Philippe Lalevée 75
Architecture orientée Ressource
• Composant = URI – « tout ce qui a une identité »
– État
• Connecteur = « copie » de la ressource – Extraction par requête (HTTP get, SQL select)
– Gestion comparable à une mémoire cache
• Relations = WWW – Standards Internet
– Modèle client/serveur
WEB 2.0 / REST 23-27 février 2015 Workshop e-Business P2015 149
Architecture REST • REST = REpresentational State Transfer
– Inventé par Fielding en 1994 – À la base du WWW : accès aux ressources – Accès ressource = représentation de cette ressource par un
serveur – Clic sur un lien = transition d’état (accès) – Application Web = réseau de ressources permettant des
transitions d’état
• Exemples – http://www.lemonde.fr/europe/article/2011/05/26/article – http://www.amazon.fr/Grendha-Trends-Plat-Sandales-
femme/dp/B004AP93FE...
• Standards W3C – URI / URL / URN – HTTP / HTTPS – XHTML / XML / MIME
23-27 février 2015 Workshop e-Business P2015 150
Workshop e-Business 23-27 février 2015
Philippe Lalevée 76
Les 10 principes REST
1. Identifier les ressources 2. Choisir celles dont la durée de vie est supérieure à une
transaction/session 3. Les nommer avec une URI (logique) pour favoriser le
couplage lâche 4. Utiliser des noms car ressource = état 5. Donner des URI stables (permanentes) 6. Nommer les ressources « métier » 7. Utilisation de GET pour la lecture (mémoire cache,
sécurité) et POST pour la mise à jour 8. Services sans état (à la charge du client) 9. Services asynchrones 10. Représentation des données en XML
23-27 février 2015 Workshop e-Business P2015 151
Architecture orientée Service
• Composant = fonction logicielle autonome – Sans état – Couplage faible – Interopérabilité (agnostique)
• Connecteur = URI du prestataire – Schémas XML – Description par un « contrat »
• Relations = WWW – Standards Internet – Modèle consommateur/prestataire
WS-* (SOAP-WSDL-UDDI) / REST
23-27 février 2015 Workshop e-Business P2015 152
Workshop e-Business 23-27 février 2015
Philippe Lalevée 77
Les 6 principes WS-* • Message
– Enveloppe (entête / corps) – Requester / Provider : agents Web Service – Transport « abstrait »
• Action – Exécutée par un agent (message, notification…)
• Service – Ressource (URI) dont la description est accessible – Description = interface des services – Interface = messages reçus/envoyés par les actions
• Orchestration – Enchainement des actions, sous couvert d’une politique – réalisation processus métier
• Chorégraphie – Interactions de plusieurs Web Services dans leur intégration
• Politique de gestion – Sémantique de communication – Contrôle de flot (états successifs des services) – Sécurité et qualité des services, « console de management »
23-27 février 2015 Workshop e-Business P2015 153
Pour aller plus loin …
Le p
ort
ail
pro
gram
mab
lew
eb
.co
m
23-27 février 2015 Workshop e-Business P2015 154
Workshop e-Business 23-27 février 2015
Philippe Lalevée 78
developer.ebay.com
4,5 Mo !!
23-27 février 2015 Workshop e-Business P2015 155
Architecture SOA • Principe SOA (Service Oriented Architecture)
– toute application est un ensemble de processus coopérant en se fournissant mutuellement des services
• Englobe les architectures client/serveur (maître/esclave) et pair à pair (peer-to-peer)… – Architecture client/serveur « rendue » symétrique
– Architecture pair à pair applicative
• Application orientée services – rôle de prestataire et de client dans les relations de service
• Les « Web Services » permettent de bâtir des applications SOA, mais ce n’est pas le seul moyen
23-27 février 2015 Workshop e-Business P2015 156
Workshop e-Business 23-27 février 2015
Philippe Lalevée 79
Intégration de la chaîne de valeur
Source IBM
23-27 février 2015 Workshop e-Business P2015 157
Évolution des technologies
23-27 février 2015 Workshop e-Business P2015 158
Workshop e-Business 23-27 février 2015
Philippe Lalevée 80
Architecture technique (simple)
23-27 février 2015 Workshop e-Business P2015 159
Les fonctions SOA
23-27 février 2015 Workshop e-Business P2015 160
Workshop e-Business 23-27 février 2015
Philippe Lalevée 81
Architecture complète
23-27 février 2015 Workshop e-Business P2015 161
Infrastructure généralisée
23-27 février 2015 Workshop e-Business P2015 162
Workshop e-Business 23-27 février 2015
Philippe Lalevée 82
Enterprise Service Bus
23-27 février 2015 Workshop e-Business P2015 163
ESB et SOA
23-27 février 2015 Workshop e-Business P2015 164
Workshop e-Business 23-27 février 2015
Philippe Lalevée 83
SOAP/WSDL ≠ ESB !
23-27 février 2015 Workshop e-Business P2015 165
Vision IBM: on demand
Source IBM
23-27 février 2015 Workshop e-Business P2015 166
Workshop e-Business 23-27 février 2015
Philippe Lalevée 84
CLOUD COMPUTING Web Services: Technologies et Architecture
167 23-27 février 2015 Workshop e-Business P2015
Cloud computing
Pourquoi « cloud computing» ?
23-27 février 2015 Workshop e-Business P2015 168
Workshop e-Business 23-27 février 2015
Philippe Lalevée 85
Premiers éléments
23-27 février 2015 Workshop e-Business P2015 169
L’architecture complète
23-27 février 2015 Workshop e-Business P2015 170
Workshop e-Business 23-27 février 2015
Philippe Lalevée 86
Storage-as-a-Service
• Espace disque à la demande
• Accès à un espace de stockage distant « vu » localement
• Service de « base »
dropbox, box.net, ubuntu one, Amazon S3
23-27 février 2015 Workshop e-Business P2015 171
Database-as-a-Service • SGBD distant « partagé » vu localement • Différents modèles
– Relationnel – Objet – XML – Document
• Externalisation administration
• Apache CouchDB, Amazon SimpleDB
23-27 février 2015 Workshop e-Business P2015 172
Workshop e-Business 23-27 février 2015
Philippe Lalevée 87
Information-as-a-Service
• Capacité de traiter tout type de donnée, stockée à distance
• Définition d’interfaces publiques
• Données métier – Cours de la bourse
– Agences d’information
– Service météorologique
– Validation d’adresse
Facebook, twitter, linkedin
23-27 février 2015 Workshop e-Business P2015 173
Process-as-a-Service • Réalisation de processus métier à partir de
ressources distantes pouvant interconnecter des services et des données
23-27 février 2015 Workshop e-Business P2015 174
Workshop e-Business 23-27 février 2015
Philippe Lalevée 88
Application-as-a-Service
• Ou Software-as-a-Service
• Application Web fournie à travers un navigateur
• Granularité variable
Google Docs, Salesforce SFA, Zimbra, Yahoo, Bloomberg, Zoho
23-27 février 2015 Workshop e-Business P2015 175
Platform-as-a-Service
• Plate-forme complète de développement d’applications
• Basée sur un modèle « temps partagé »
• Conception, développement, déploiement, intégration, stockage, opérations…
Google app engine, Microsoft Azure, IBM Cloud, Sun Zembly…
23-27 février 2015 Workshop e-Business P2015 176
Workshop e-Business 23-27 février 2015
Philippe Lalevée 89
Integration-as-a-Service
• Fourniture de capacités d’intégration aux applications : interfaces, contrôle de flux, orchestration…
• Technologie EAI fournie sous forme de services
– Transformation
– Routage
– Interfaces
– journalisation
23-27 février 2015 Workshop e-Business P2015 177
Security-as-a-Service
• Services de sécurité fournis à travers Internet
• Gestion centralisée d’identification
23-27 février 2015 Workshop e-Business P2015 178
Workshop e-Business 23-27 février 2015
Philippe Lalevée 90
Gouvernance-as-a-Service
• Gestion des services du « cloud »
• Topologie, utilisation des ressources, virtualisation, temps de service
• Définitions de politiques d’accès aux données et aux services
23-27 février 2015 Workshop e-Business P2015 179
Testing-as-a-Service
• Test de systèmes/applications utilisant des services hébergés
• Systèmes locaux ou distants
• Applications Web
• Systèmes d’information d’entreprise
23-27 février 2015 Workshop e-Business P2015 180
Workshop e-Business 23-27 février 2015
Philippe Lalevée 91
Infrastructure-as-a-Service
• Service de type « data center »
• Fourniture de ressources de calcul
– Serveurs physiques
– Systèmes d’exploitation
• Accès à l’ensemble des ressources de machines
• Regroupe SaaS, DaaS, PaaS…
Amazon EC2
23-27 février 2015 Workshop e-Business P2015 181
SOA et Cloud Computing
• Le cloud intègre les technologies – Virtualisation des ressources – Interfaces standards « service »
23-27 février 2015 Workshop e-Business P2015 182
Workshop e-Business 23-27 février 2015
Philippe Lalevée 92
Exemple : dropbox • Dropbox for developers
– Accueil : https://www.dropbox.com/developers – Inscription applications (App) :
https://www.dropbox.com/developers/apps
• Création application – Create an App (name, description, App folder | full) génération [key, secret]
• Téléchargez un SDK : Java, Python, etc. : – Après, décompression archive, aller dans exemples et tester – Vérifier la prise en compte de l’accès (autorisation)
• Documentation – Pour le tutorial, regardez les exemples – Consulter la documentation REST :
https://www.dropbox.com/developers/reference/api
23-27 février 2015 Workshop e-Business P2015 183
Extraits de code Java (adaptés) // La première fois
AppKeyPair appKeys = new AppKeyPair (APP_KEY, APP_SECRET);
WebAuthSession was = new WebAuthSession (appKeys, Session.AccessType.APP_FOLDER);
WebAuthSession.WebAuthInfo info = was.getAuthInfo ();
System.out.println ("Go to: " + info.url + " and allow access");
// Exception si autorisation non donnée (dans les 5 minutes)
String uid = was.retrieveWebAccessToken (info.requestTokenPair);
AccessTokenPair accessToken = was.getAccessTokenPair ();
// Accès aux ressources
FileOutputStream flot = new FileOutputStream (localpath);
WebAuthSession session = new WebAuthSession (appKeys, Session.AccessType.DROPBOX, accessToken);
DropboxAPI<?> client = new DropboxAPI<WebAuthSession> (session);
DropboxAPI.DropboxFileInfo fi = client.getFile (path, null, flot, null);
23-27 février 2015 Workshop e-Business P2015 184