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


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


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


Philippe Lalevée 3

RAPPELS ET INTRODUCTION GÉNÉRALE

Première partie


Qu’est-ce que le E-Business® ?

Source IBM



Philippe Lalevée 4

RÉSEAUX ET PROTOCOLES Rappels et introduction générale


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



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


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



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…)


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)



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


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



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)


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



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


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



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




Architecture centralisée Applications monolithiques

Service

Service

ENTREPRISE

BD

BD

BD

Ordinateurs centraux

Term

inau

x

Co

ncen

trateurs

Ordinateur Réseau


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 ?




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


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 ?




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


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




Java EE RMI

Enterprise Java Bean

Réseau

Java RMI Middleware

Enterprise Java Bean

Stub (talon)

Application 1 Application 2


OMG CORBA

ORB core (Object Request Broker)

Client Serveur

ORB ORB

Proxy (souche)

POA

Serviteur (squelette)

BUS MIDDLEWARE




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)


Architecture MVC

• Séparation des flux par des interfaces

Affichage View Model

Côté Application

Controller

Vitrine

Arrière-boutique


Orienteur



Architecture n-tier

• Découpage des applications en « étages » (tier)

tier client tier du milieu

(Middleware)

tier ressource

(S.I.)

Côté serveur


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)




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


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




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


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




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

?


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 ?




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


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




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


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




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


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 »




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


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




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


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)




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


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




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


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



PUB ! Rappels et introduction générale


Pub! Architecture .NET • .NET est une stratégie de produits Microsoft

• Remplacement de Microsoft DNA




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




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


XML Rappels et introduction générale




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)


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




• 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


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




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


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




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


URBANISATION ET INTÉGRATION Rappels et introduction générale




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


Applications Web

• Requêtes HTTP par des URL

– Servlet : descripteur de déploiement

– JSP : extension du fichier




Applications B2C

• Le conteneur Web interagit avec le S.I. de l’entreprise par des API ad hoc

– JavaMail, JDBC, JMS, JXTA…


Applications intranet

• Le client accède directement aux ressources applicatives de l’entreprise

• Intérêts : client « riche », sécurité simplifiée




Applications B2B

• Les conteneurs accèdent à leurs homologues – Protocoles standards : CORBA, RMI, DCOM

– Technologies Web Services (architecture SOA)


Applications multi-tier

• Applications complètement intégrées

– Multiplateformes, multi-machines (cluster)

– Indépendance des parties (tier)




Urbanisation

Construction « historique »


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




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


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 »





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



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





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



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





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)


Intégration des Applications d’Entreprise

Intégration niveau de l’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)



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





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


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




Communications entre applications

ERP ERP

Cli/Srv DataWH

SCM CRM

Legacy

EAI

SCM

DataWH

Legacy

Cli/Srv

CRM


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




XML et les S.I.

BUS XML

XML

XML

XML

XML

XML

Applications métiers

ERP

Services Distribués

Annuaire

Bases de Données


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




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 »


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




EAI : niveau processus

Application 1

Application 2

Application 3 Annuaire Services

Services

Workflow Métier Backoffice

Bases Données

Autres Systèmes


WEB SERVICES TECHNOLOGIES ET ARCHITECTURES

Deuxième partie




PRINCIPES Web Services: Technologies et Architecture


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 ?




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é ?


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)




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


SCHÉMAS XML Web Services: Technologies et Architecture




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)


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




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


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




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


Un exemple

Source : http://www.dotnetguru.org/articles/webservices/WebServices.htm




CONCEPTION Web Services: Technologies et Architecture


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




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


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)




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


Output Message:

Part 1:

Name: retour



Appel du Web Service

Local Name: concat


Input Message:

Part 1:

Name: s1


Part 2:

Name: s2


Output Message:

Part 1:

Name: retour


<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>




Retour du Web Service

Local Name: concat


Input Message:

Part 1:

Name: s1


Part 2:

Name: s2


Output Message:

Part 1:

Name: retour


<miage:concat xmlns:miage="http://www.miage.org/ns"

xmlns:xsd="... XMLSchema" ...>

<retour xsi:type="xsd:string">Bonne journée</retour>

</miage:concat>


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


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>




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>


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

…

… … …

…




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 »


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]

TO: [email protected]

concat(s1="Bonne",s2="journée")




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


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




WSDL Web Services: Technologies et Architecture


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




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(); }


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




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>

...


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>




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>


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




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>


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>




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>


SOAP Web Services: Technologies et Architecture




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


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




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>


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>




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>


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>




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


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




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


Interactions WSDL et SOAP




Liaison entre services


Mécanismes mis en jeu




Insertion de services techniques


SOA AVEC REST ET WS-* Web Services: Technologies et Architecture




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


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




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




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


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




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 »


Pour aller plus loin …

Le p

ort

ail

pro

gram

mab

lew

eb

.co

m




developer.ebay.com

4,5 Mo !!


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




Intégration de la chaîne de valeur

Source IBM


Évolution des technologies




Architecture technique (simple)


Les fonctions SOA




Architecture complète


Infrastructure généralisée




Enterprise Service Bus


ESB et SOA




SOAP/WSDL ≠ ESB !


Vision IBM: on demand

Source IBM




CLOUD COMPUTING Web Services: Technologies et Architecture


Cloud computing

Pourquoi « cloud computing» ?




Premiers éléments


L’architecture complète




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


Database-as-a-Service • SGBD distant « partagé » vu localement • Différents modèles

– Relationnel – Objet – XML – Document

• Externalisation administration

• Apache CouchDB, Amazon SimpleDB




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


Process-as-a-Service • Réalisation de processus métier à partir de

ressources distantes pouvant interconnecter des services et des données




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


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…




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


Security-as-a-Service

• Services de sécurité fournis à travers Internet

• Gestion centralisée d’identification




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


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




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


SOA et Cloud Computing

• Le cloud intègre les technologies – Virtualisation des ressources – Interfaces standards « service »




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


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);


https://www.dropbox.com/developers

https://www.dropbox.com/developers/apps

https://www.dropbox.com/developers/reference/api



FIN Workshop e-Business


workshop e-business® - emse.fr · – soa: an integration blueprint. schmutz et al, packtpub 2010....

Documents