La Gouvernance des Services Informatiques

Gouvernance des Services I.T.« ITIL SMP / CMMi SVC, Architecture SOA et WebServices »

« Centre de Service IT, Architecture de Services et flux applicatifs »« Centre de Service IT, Architecture de Services et flux applicatifs »

Publication : avril 2009Catégorie : conférence

Auteur : Jimmy SIMEONVersion éditoriale : 3.0 du 170409

Niveau :

Public : managertechnique métier

avancédébutant expert

MASTER INFORMATIQUE

SOAWebService

Service technique Service d’architecture Service d’entreprise

Gouvernance des Services I.T. Jimmy SIMEON, mars 2009

AGENDA

�Gouvernance des services du Système d’Information

�Centre de Service IT (Technologie de l’Information)

�Architecture Orientée Service

�WebService


Gouvernance des services du Système d’Information

�Système d’information (S.I.) �Système d’information & Services de l’Entreprise�Expérience Utilisateur (QoE), Qualité de Service (QoS)�Référentiel IT : CMMi, CMMi SVC

� Objectifs des domaines de processus de CMMI SVC

�Référentiel IT : ITIL� Évolution de ITIL v2 vers ITIL v3 (ou ITIL SMP)� Objectifs de ITIL Service Management Practice� Activités de ITIL v3� 10 processus ITIL� Cycle de vie d’un Service ITL SMP


Gouvernance des Services


Entreprise Orienté Service

�Enterprise Architecture (EA),

�Services Oriented Enterprise (SOE),

�Service-Oriented Architecture (SOA)

�Service Oriented Computing (SOC)


Système d’information (S.I.)

�Un Système d’information représente l’ensemble des

�éléments matériels et immatériels participant à la gestion,

�au stockage, au traitement, au transport et à la diffusion de l’information au sein d’une organisation.


Système d’information & Services de l’Entreprise

Cartographie & urbanisation du S.I. Architecture d’Entreprise

4 niveaux du système d’information

Application 3-tiers Une Architecture Orientée Service1. Services d’accès à la présentation 2. Services d’accès à la logique métier3. Services d’accès au données

Utilisateur

1

2

3

4


Démarche orientée « Service Informatique »

�implique la définition d’un catalogue de services.

�Cartographie des services : � Inventaire des ressources IT (matériel ou applications) qui sont nécessaires pour exécuter le service.


Expérience Utilisateur (QoE), Qualité de Service (QoS)

Clients

Application WebRéseau

QoE

QoSBSLM / IT SLM

SLA / SLM

IT(Technologies de l’information)

Services Métier & IT :� Gestion des contrats de services,� Des niveaux de services.

Qualité de l’Expérience Utilisateur

Qualité de Service IT


Référentiel IT : CMMi

�CMMi : Capability Maturity Model Integration�CMM évolue vers SW-CMM (Software) puis CMMi en 2001�Modèle de bonnes pratiques de management

�Développement (CMMI-DEV), � Service (CMMi-SVC),

� Achat (CMMi-ACQ)

Aligné sur des niveaux de maturités de l’entreprise.Aligné sur des niveaux de maturités de l’entreprise.


Référentiel IT : CMMi SVC

Optimisé

Maîtrisé

Définit

Reproductible

Initial« Task-force » fréquente

(Software Engineering Institute)

�CMMi SVC : activités pour gérer, établir, et délivrer des Services.


Objectifs des domaines de processus de CMMI SVC

� SSD (Service System Developement) :

� Analyser, concevoir, développer, intégrer et tester les services systèmes au regard des engagements de Service.

� SCON (Service Continuity) :

� Préparer le dispositif permettant d'assurer la continuitéde service basée sur les engagements de Service.

� OSM (Organizational Service Management) :

� Etablir des services standards qui assure que la satisfaction client sera au rendez-vous.


Référentiel IT : ITIL


Évolution de ITIL v2 vers ITIL v3 (ou ITIL SMP)

� ITIL est devenu en quelques années une référence autour des bonnes pratiques dédiées à l'industrie IT (Information & Technology).

� ITIL version 3 sert principalement deux objectifs :

� Adapter le référentiel ITIL version 2 à l'évolution du Business et des technologies. En assurant notamment la transition de l'IT "orientée DSI" vers l'IT "orientée fournisseurs" (SSII, Externalisation).

� Passer d'une version "orientée processus" à une version plus aboutie "orientée service". Un processus étant une composante d'un service.

� A ce titre ITIL (Information & Technology Infrastructure Library) devient ITIL SMP ou Service Management Practice.


Objectifs de ITIL Service Management Practice

� Prouver que l'informatique apporte de la valeur à l'entreprise.

� Identifier les besoins métiers de l'entreprise et adapter l'informatique à ces besoins et non l'inverse.

� Ne pas perdre de vue l'apport en valeur ajoutée que peut avoir l'informatique.

� Mettre l'accent sur la Qualité de service IT.

� Améliorer la perception des services IT par les clients/utilisateurs

� Garantir la pérennité et le développement de l'entreprise en garantissant une informatique adaptée à sa stratégiede l’entreprise.


Activités de ITIL v3

« ITIL version 3 décrit le service comme une organisation composée

de ressources humaines et IT (matériels et logiciels), dont l'objectif

est l'apport de valeur pour l'entreprise et le bénéficiaire du Service. »


10 processus ITIL


Processus de gestion d’infrastructures informatiques (1/2)

� Configuration Management :

� Matériel, réseaux, câblages) et leurs interactions au sein du système d’information.

� Help-Desk :

� Processus de Gestion des Appels et de résolution des problèmes clients.

� Problem Management :

� Processus de résolution des causes des incidents techniques

� Cost Management :

� Processus de gestion des coûts des services informatiques et desclients.

� Security Management :

� Processus de définition et de mise en œuvre des la politique de sécurité informatique et entreprise.


Processus de gestion d’infrastructures informatiques (2/2)

� Change Management :

� Processus de gestion des changements de composants d’infrastructure informatique de l’entreprise

� Software Control and Distribution Management :

� Processus de gestion du cycle de vie de logiciels, de sa production à son installation

� Service Level Management :

� Processus de gestion des contrats de services entre la directioninformatique et ses clients

� Capacity Management :

� Processus de gestion des objectifs de performances négociés dans le contrats de service

� Availability Management :

� Processus de gestion des objectifs de disponibilité négociés dans le contrats de service.


Champ d’application de ITIL dans l’Entreprise


Cycle de vie d’un Service ITL SMP

� Là ou ITIL version 2 s'assurait de délivrer et opérer un service, � ITIL version 3 s'intéresse au service de bout en bout. De la genèse

du service à sa fin de vie (on parle du cycle de vie d’un Service).

� Des groupements d'activités ont été identifiés :

� Service Strategy (Stratégie de Services) : Aligner la stratégie IT sur la stratégie de l'entreprise en s'assurant que l'apport de valeur permettra à l'entreprise d'atteindre ses objectifs.

� Service Design (Conception de Services) : Concevoir les Services à partir des exigences collectées par le Service Strategy.

� Service Transition (Transition de Services) : Assurer la Qualité de la transition d'un nouveau Service entre les études et les opérations.

� Service Operation (Exploitation de Services) : Opérer les Services de manière efficace et efficiente.

� Continual Service Improvement (Amélioration Continue des Services) : Créer les conditions d'une amélioration continue des Services.


Centre de Service IT

�Gestion des Niveaux & contrats de Service

�BSM : Gestion des Services Métiers

�Centre de Service IT des PME et TPE

�Logiciels de mesure opérationnelle associés à ITIL : � « Request Tracker » (PERL, Open Source)

� GLPI Gestion Libre de Parc Informatiques (PHP) GNU/GPL

� Greffon OCS-NG (PERL, C, MySQL), Open Source

� NAGIOS (CGI, APACHE), licence GPL


Gestion des Niveaux & contrats de Service

�SLM (Service Level Management) :� gestion des contrats des engagements de service (SLA = Service Level Agreement)

� basés sur des métriques, des indicateurs de performance, purement techniques (IT SLM).

�IT SLM : surveillance des infrastructures techniques,� surveillance des disponibilités et des débits,

� respect des engagements de service (délai de reprise sous incidents, …).

�BSLM (Business Service Level Management) :� inclut dans la mesure IT SLM des métriques métiers

� Ex : un montant maximum de commandes en attente de validation.


BSM : Gestion des Services Métiers

� BSM (Business Service Management) répond à 3 besoins :� superviser les processus métier et leurs dépendances par rapport aux

ressources IT,

� connaître en temps réel l'impact (financier, production, ...) dudysfonctionnement d'un processus surveillé sur les métiers de l'entreprise,

� aider à la décision d'allocation de ressources en fonction de la criticité des processus métier.

� outils (de type Business Intelligence) d’analyse des 4 niveaux du SI


Centre de Service des PME et TPE

�Point de contact unique, puis il enregistre, traite, escalade, suit et communique sur le statut des incidents, demandes de services, plaintes.

�Centre de Service :� téléphones pour collecter les appels.

� un outil de gestion de « ticket » vous permettra de mettre en œuvre le suivi, traitement des demandes et de donner accès à vos clients à la saisie de leurs demandes.


Logiciel : « Request Tracker » « ticket » au support (PERL, Open Source)


Logiciel : GLPI Gestion Libre de Parc Informatiques(PHP) GNU/GPL version 2

�Inventaires manuel (logique et physique) des biens informatiques.


Logiciel : Greffon OCS-NG (PERL, C, MySQL), Open Source

�Solution d'inventaire automatisé du parc informatique et de télédistribution


NAGIOS(CGI, APACHE), licence GPL

� Gestionnaires des services technique de infrastructure� application permettant la surveillance système et réseau.

� Elle surveille les hôtes et services spécifiés, alertant lorsque les systèmes vont mal et quand ils vont mieux.

� Nagios se décompose en trois parties :

1. Le moteur de l'application qui vient ordonnancer les tâches de supervision.

2. L'interface web, qui permet d'avoir une vue d'ensemble du système d'information et des possibles anomalies.

3. Les plugins, une centaine de mini programmes que l'on peut compléter en fonction des besoins de chacun pour superviser chaque service ou ressource disponible sur l'ensemble des ordinateurs ou éléments réseaux du SI.


Architecture Orientée Service

� Architecture Orienté Service � Orientaton Service

� Gestion des processus Métier et SOA

� Architecture de Service de Composants

� Orienté objet et Services Orientés Architecture

� Maturité de SOA en Entreprise

� Bus de Service d’Entreprise

� SOA : ESB, BAM, BPM, BPEL

� SOA appliqué à l’informatique d’Entreprise� Apports d’une démarche orientée services

� Définition d’une démarche orientée services

� Domaines d’application d’une architecture en services

� Facteurs clés de succès d’une démarche orientée services


Service Orienté Architecture

Bus


Orientation Service


Gestion des processus Métier et SOA

� Selon une étude Gartner, la gestion des processus métier (BPM) et les architectures orientées services (SOA) figurent – encore aujourd'hui – au premier rang des priorités des DSI, dans le monde.

� Pourquoi ? Le BPM,

� parce que les entreprises, motivées par l'amélioration de leurs performances, souhaitent mieux maîtriser et mieux appréhender leurs processus métier ;

� Pourquoi ? le SOA,

� pour résoudre les problématiques de réutilisabilité, d'interopérabilité et d'élimination des données dupliquées dans les différentes infrastructures informatiques de l'entreprise.


Architecture de Service de Composants(Service Component Architecture)

� SCA : modèle de programmation pour la construction d’applications àbase de composants suivant le paradigme SOA.

� SCA insiste sur une séparation forte entre l’implémentation des services et leur assemblage.

© Xebia


Bus de Service d’Entreprise

�Les ESB (Enterprise Service Bus)

� offrent un moyen de réaliser la connexion et à la médiation de

l’ensemble des communications et interactions entre les

services et applications du SI.

� L’ESB expose un service de niveau N qu’il construit par composition ou agrégation de plusieurs services de niveau N-1 (voire N). On parle d’orchestration des Services.


Orienté objet et Services Orientés Architecture


Maturité de SOA en Entreprise

© XIBM


SOMA : Service Oriented Modeling & Architecture

�Méthode de mise en œuvre de SOA dans une entreprise.


SOA : ESB, BAM, BPM et BPEL

�Business Activity Monitoring (BAM)

�Business Process Management (BPM)

�Business Process Execution Language (BPEL)


Apports d’une démarche orientée services (1/2)

�Agilité métier� Alignement du SI avec les besoins du métier

� Construction rapide de nouvelles fonctionnalités en combinant et/ou en réutilisant un catalogue de servicesdisponibles pour la MOA et la MOE

�Flexibilité du SI : � Chaque application avec ses flux explicités peut évoluer à son

rythme tant qu’elle assure la compatibilité des messageséchangés et des services rendus vis-à-vis des autres applications


Apports d’une démarche orientée services (2/2)

�Evolutivité du SI� La structuration des applications en services (Règles

métier, accès aux données, etc…) permet d’assurer une meilleure maintenabilité des applications, à moindre coût

�Ouverture vers l’extérieur� Les échanges avec le monde extérieur en mode message

se généralisent. La production ou la prise en compte de ces messages se fait en général avec des services.


Définition d’une démarche orientée services (2/2)

�C’est la possibilité d’offrir rapidement de nouveaux services en combinant ou en réutilisant de manière contrôlée et administrée des services.

�C’est la possibilité d’un couplage lâche entre les processus opérationnels et les fonctions des applications qui peuvent évoluer chacun à des rythmes différents.


Domaines d’application d’une architecture orientée services

� Découplage entre :� Les applications du Front Office et celles du Back Office� Le SI Producteur et le SI Distributeur

� Offre de services multi-canaux tout en assurant la cohérence des fonctions associées (Agence, Centre de Relation Client, Web, Plateforme de services vocaux)

� Services d’accès aux référentiels et nomenclatures du SI� Ouverture du SI vers l’extérieur (Fournisseurs, Partenaires, Accès

aux marchés financiers, Clients)

� Mutualisation de services techniques pour les applications. Par exemple :� Accès aux données d’une base� Envoi d’un e-mail,� Archivage d’un document, etc…


Facteurs clés de succès d’ une démarche orientée services

�Organisation et un fonctionnement en mode matriciel� Mettre en place des équipes projet MOA et MOE ayant un démarche

de conception synchronisée

� Mettre en place une organisation transverse pérenne pour :� Gérer l’évolution des services

� Assurer la publication et la communication du catalogue des services disponibles

� Faciliter leur réutilisation

�Une approche pragmatique � Combiner une approche Top Down (urbanisme, processus) avec une approche Bottom Up (définition des services et des messages) en réconciliant une démarche d’urbanisme du SI avec une structuration « technique » qui soit opérationnelle et performante.


Facteurs clés de succès d’ une démarche orientée services

�Une vision globale du SI� Construire une cartographie fonctionnelle et technique du SI

� Eviter le raisonnement en mode silo par application

�Un découplage fonctionnel entre les services� Mettre en place des outils d’échange qui permettent de découpler fonctionnellement les échanges entre les

services afin de faciliter les évolutions


Apports de la SOA dans l’évolution du SI Urbanisé

�1- Refonte globale ou ré-urbanisation du SI�2- Mise en place d’une architecture Producteur

Distributeur

�3- Conception et réalisation d’une nouvelle application�4- Evolution importante d’une application existante pour

répondre à de nouveaux besoins

�5- Ouverture du SI aux clients, fournisseurs et partenaires

�6- Mise en place d’un référentiel ou de nomenclatures�7- Mise en place de fonctions mutualisées


Refonte globale du SI avec SOA (1/2)

�Permettre un alignement du SI avec les objectifs métier :� Meilleure modularité globale du SI

� Meilleure réactivité du SI face à des changements de processus ou d’organisation

� Capacité à intégrer rapidement de nouveaux produits et services

�Offrir plus de "fraîcheur " globale dans les informations

du SI, en évitant certains traitements batchs et des

reflets multiples de données.


Refonte globale du SI avec SOA (2/2)

�Structurer et faciliter les échanges entre :� Les applications de type Front Office plutôt orientées par

catégorie de clients et/ou canal de communication

� Les applications de type Back Office plutôt organisées par type de produit/service

� Le SI de l’entreprise et les SI des clients, fournisseurs et partenaires

�Faciliter l’accès aux référentiels et aux nomenclatures par les différentes applications

�Faciliter l’accès aux fonctions mutualisées


Définition d’une démarche orientée services (1/2)

�C’est un mode de structuration globale du SI pour :� Obtenir un découpage modulaire du SI pour que chaque application ou

module puisse évoluer d’une façon la plus indépendante possible des autres

� Expliciter les échanges entre les modules sous la formes de messages qui sont produits ou intégrés par des services dont chaque application ou module est responsable

� Documenter les messages échangés entre les services sous la forme de contrats

�C’est aussi un mode de structuration des fonctions et des traitements à l’intérieur d’une application ou module pour :� Séparer les traitements liés aux règles de gestion métier des traitements de type présentation

� Regrouper dans des services ces règles de gestion et les traitements associés de telle manière à assurer une cohérence de leur implémentation, quelque soit le canal de présentation utilisé. Ces services constituent en général le tiers « métier » d ’une architecture n-tiers.


Architecture Producteur/Distributeur avec SOA (1/2)

� Réduire le décalage dans la fraîcheur des informationsnotamment sur la situation et le détail des comptes et contrats entre le Producteur et le Distributeur vis-à-vis du client final

� Accélérer la transmission d’une demande client issue du multi-canal ou du Front Office vers le Producteur et pouvoir suivre plus facilement l’avancement global de cette demande (Processus de demande client de bout en bout)


Architecture Producteur/Distributeur avec SOA (2/2)

� Permettre au Distributeur d’accéder en temps réel à des outils spécialisés du Producteur : outil d’analyse de risque client, outil de simulation sur des produits, référentiels spécialisés du Producteur comme des données de type market-data par exemple, etc.

� Permettre au Producteur d’offrir une interface de service commune aux différents distributeurs : � Cohérence des règles de gestion appliquées vis-à-vis des

Distributeurs� Réelle économie d’échelle quand le nombre de Distributeurs

augmente,� Meilleure évolutivité des applications du Producteur� Meilleure réactivité pour l’intégration d’un nouveau Distributeur


Mise en œuvre de nouvelles applications avec SOA

� Rendre la nouvelle application plus modulaire et autonome en explicitant les flux de messages de type synchrone ou asynchroneéchangées avec les autres applications

� Disposer de plus de flexibilité pour la prise en compte des évolutions ultérieures :� Séparer les règles de gestion métier des fonctions de présentation, en particulier dans un contexte multi-canal pour améliorer l’évolutivité de l’application

� Pouvoir proposer de nouvelles fonctionnalités en recombinant des services existants

� Rendre les fonctionnalités de l’application moins dépendantes des processus et de l’organisation opérationnelle à un moment donné


Évolution fonctionnelle importante avec un approche SOA

� Expliciter et simplifier les échanges avec les autres applications : éviter les croisements point à point avec une redondance des fonctionnalités : un service = une fonction, un point d’entrée et un point de sortie

� Masquer la complexité fonctionnelle ou technique interne de l’application, notamment pour les applications d’un certain âge,mettant en œuvre un modèle de données qui n’est pas 100% cohérent avec celui des autres applications

� Éviter d’avoir à importer ou à exporter en masse des données avec les autres applications via des batchs complexes : � Améliorer la disponibilité de l’application

� Augmenter la fraîcheur des informations mises à disposition

� Faciliter une refonte ultérieure de l’application après avoir explicité les flux échangées avec les autres applications


Clients, fournisseurs et partenaires accèdent au SI via SOA

� Offrir une réaction, c’est à dire une mise en oeuvre des règles de gestion homogène et cohérente quelque soit le canal d’échange en cas d’échanges multi-canaux avec l’extérieur

� Pouvoir structurer les échanges en explicitant :� Les messages échangés� Le service rendu et le message de retour suite à la réception d’un

message en entrée� Le contrat de qualité de services associé (disponibilité, temps de

réponse, débit de traitement, etc…) vis-à-vis de l’extérieur

� Faciliter les échanges dans un environnement hétérogène en s’inscrivant dans des formats et des protocoles standardsd’échanges reconnus :� au niveau mondial : Webservices par exemple� et au sein d’une profession : messages SWIFT par exemple


Référentiel ou nomenclatures & SOA

�Offrir un accès direct aux référentiels et aux nomenclatures :� Réactivité lorsqu’une mise à jour du référentiel par une

application du SI est nécessaire

� Fraîcheur de l’information pour les accès en consultation

�Éviter ainsi, dans beaucoup de cas, d’avoir à mettre en place des reflets qui peuvent être complexes à synchroniser fonctionnellement et techniquement

�Faciliter l’évolution interne de ces référentiels et nomenclatures tant que les interfaces publiques d’accès ne sont pas modifiées


SOA dans la mise en place de fonctions mutualisées

�Pouvoir offrir et publier les fonctions mutualisées vis-à-vis des applications clientes :� Expliciter les messages échangées,� Expliciter les fonctions et services rendus, � Expliciter le contrat de services associé (disponibilité, temps de

réponse, débit de traitement, etc…)

�Permettre de masquer les technologies utilisées et la complexité interne éventuelle de ces fonctions mutualisées

�Faciliter l’évolution interne de ces fonctions mutualisées tant que leur interface publique n’est pas modifiée


WebService

� Service technique en informatique� Message SOAP = interopérabilité inter-applicative� Normes & Standards

� WebServices, organisation WS-I et standards WS-*� Cartographie des standards de WebServices

� Technologie des WebServices

� Protocole HTTP, message SOAP, contrat WSDL� Réutilisation de Services (PHP / JAVA)� Description des services (WSDL = contrat)

� Services technique du Framework de WebService� Architecture des Framework de WebServices

� Développement d’un WebService� Sécurité des WebServices

� Attaques XML des WebServices� Comment sécurité HTTP et le flux XML WebService� WS-Security : sécurisation des Web Services

� Architecture 3-tiers des WebServices


Message SOAP = interopérabilité inter-applicative

Enveloppe

En-tête

Corps du message

XML

Balises XML


Service technique en informatique

�Un service technique : c’est un numéro de port et protocole de communication.

HTTP, port 80

WebService XML


SOA et les WebServices

�1 - Service fournit le WSDL

�2 - Le Client veut un service et reçoit son WSDL

�3 - Le Client peut communiquer avec le service


WebServices, organisation WS-I et standards WS-*

Les Web Services offre un protocole de

communication et un descriptif de services

standard pour l’interaction entre des

applicatifs distants et hétérogènes, y

compris dans des contextes multi entreprises.


La jungle des spécific

ations W

ebServices


Interopérabilité des WebServices

�Interopérabilité est assurée avec le respect du standard « WS Basic profile 1.0 » :

� Enveloppe SOAP 1.1

� Description du WebService WSDL 1.1 Limitation au style d’écriture «DOCUMENT/LITERAL WRAPPED»

� Sécurité WS Security 1.0

� Transport HTTPS 1.1


Protocole HTTP, message SOAP, contrat WSDL


Publier un WebService

� Publier sur la couche présentation

� sur la couche présentation (webservice de typeServlet) pour les partenaires (internes et externes).

� Publier sur la couche Service :

� sur la couche service pour une communication entre les applications internes Assurance (webservice de type EJB SLSB).

Application 3-tiers Une Architecture Orientée Service1. Services d’accès à la présentation 2. Services d’accès à la logique métier3. Services d’accès au données

Utilisateur

1

2

3

4

Couche Service


Réutilisation de Services (PHP / JAVA)

� Interopérabilité PHP / Java possible avec « WS Basic Profil v1.1 »

�« WS Basic Profil v1.1 » :� Enveloppe SOAP SOAP 1.1 � Description du WebService WSDL 1.1 Limitation au style d’écriture

«DOCUMENT/LITERAL WRAPPED» � Sécurité WS Security 1.0 � Transport HTTPS 1.1

Logique de traitement DonnéesPrésentationInterface Homme Machine


Description des services (WSDL = contrat)

HTTP/SOAP (XML)


Services technique du Framework de WebService

� Le Framawork Web Service intègre un framework de Mapping Object/XML pour sérialiser et désérialiser les messages SOAP. JAXB réalise le mapping Object/XML.


Architecture des Framework de WebServices

Container

ApplicatifClient

ApplicatifServeur

Servlet Container

Appel WebService

SOAP / HTTP(S)

Réponse

SOAP / HTTP(S)

Fournisseur WebServiceContexte JAVA

Runtime

InitWSDLOutil de Génération SOAP -

WSDLOutil de Génération

SOAP

Class Java

Framework WebServiceDéveloppement

Légende :

ServiceLocator

Client WebServiceContexte Multi-Technologie

MappingO/XML

STUBSocketHTTP

HandlerCINRJ

ServletHTTPFacade

FrameworkWebService SKELETON


Développement d’un WebService (1/2)

�Partie Initialisation

�1. Identification des services métiers ou techniques à exposer côté Serveur.

�2. Génération du SKELETON et du WSDL à partir des services côtéFournisseur

�3. Génération à partir du WSDL du STUB côté Client


Développement d’un WebService (2/2)

� Partie Runtime

� 1. L’applicatif client utilise le STUB pour appeler le service distant. Ce STUB est chargé de transformer l’appel de méthode en message SOAP (Sérialisation) et de reconstruire le résultat reçu (Désérialisation)

� 2. Le Framework WebService se charge de la gestion des Erreurs (SoapFault), de fournir au SKELETON des services de Sérialisation et de Désérialisation Object/XML, de communiquer avec le Handler de Sécurité CINRJ si la sécurité WS-Security est activée.

� 3. Le SKELETON se charge de reconstruire les paramètres, de trouver l’objet appelé et d’invoquer la méthode de service.


Attaques XML des WebServices


Architecture 3-tiers des WebServices


Comment sécurité HTTP et le flux XML WebService

HTTPS

WS-Security


WS-Security : sécurisation des Web Services

�Activation de HTTPS (le certificat X509 ne se propage pas en standards, contrairement à XMLS) : point-à-point.

� l’activation de WSS (WebService Security) qui sécurise le flux XML SOAP : � login/pwd en clair, ou pwd en mode digest,

� ou certificat (token avec un certificat Groupe X509),

� ou signature XML, ou chiffrement d’une partie

� ou de la totalité du message XML métier (XMLS).

� le reverse proxy protège contre les attaques applicatives (RFC, DoS, injection de code, etc.).


Vos Questions

�http://www.antilloo.com

�[email protected]

La Gouvernance des Services Informatiques

Technology

Transcript of La Gouvernance des Services Informatiques