Architecture et SOA

1
Architecture et SOA

• La place de larchitecture et de SOA dans les
  projets informatiques

Sami Jaber DotNetGuru.orgwebmaster_at_dotnetguru.or
g
Version 1.0 9/10/2003 DNG/002
2
Le Symposium Architecte DNG
L'agenda
S1
Service Oriented Architecture
S2
Architecture n-tiers et Design Patterns
S3
Les Web Services en entreprise
S4
Le Mapping Objet/Relationnel
Lagenda du Symposium DNG
3
Logistique/Remerciements

• Matin Architecture SOA / Les concepts de demain
• Après-midi WebServices/Mapping O/R
• Logistique
• Pause dun quart dheure entre chaque session
• Repas du midi offert sur place
• Goodies en fin de journée (Polo à leffigie DNG)
• Questions/Débats en fin de chaque session
• Un grand merci à notre Sponsors !

4
DotNetGuru.org

• Site Web à destination des développeurs et
  architectes
• Plus de 1000 membres inscrits depuis début 2002
• Articles de fonds techniques
• Forums de discussions, échanges
• Centré sur des thèmes  entreprise 
• Conception et modélisation dapplications n-tiers
• Design Patterns, SOA (Service Oriented
  Architecture)
• Aspect Programming
• Modélisation UML, Généricité, Abstraction
• Une sorte de salon de thé pour architecte

5
Le site
6
Pourquoi ce Symposium ?

• Larchitecture est un sujet de plus en plus
  important
• Les applications deviennent de plus en plus
  complexes
• Empilement de briques technologiques différentes
• Utilisation de Framework objets (.NET ou J2EE)
• Toujours plus dabstraction
• Le métier de développeur évolue !

7
Toujours plus dabstraction

• Débuts Assembleur/Langages machine
• Puis ce fût au tour des applications tirant
  partie de langages procéduraux (C,Ada, Fortran,
  etc..)
• Puis les applications orientées objets (C,
  Smalltalk, Eiffel, Java, C)
• moins de code à écrire (gestion de la mémoire
  automatique, pas de pointeur, API objets, )
• plus de briques à intégrer, design patterns
• Demain architectures orientées services
• intégrer les applications et gérer les évolutions
  technologiques

8
J2EE/.NET plus de 6000 classes !!
System.Web (ASP .NET)
System.Windows.Forms
Services
Design
ComponentModel
HTMLControls
WebControls
System.Drawing
Printing
Drawing2D
Caching
Security
Imaging
Text
Configuration
SessionState
System.Data (ADO .NET)
System.XML
OLEDB
SQLClient
XSL
Serialization
Common
SQLTypes
XPath
Schema
System
Runtime
Collections
IO
Security
InteropServices
Configuration
Net
ServiceProcess
Remoting
Diagnostics
Text
Reflection
Serialization
Threading
Resources
Globalization
9
Les différents types darchitectes

• Les architectes fonctionnels
• Optimisent les processus métier
• Très bonne connaissance des méthodes danalyse
• Les architectes techniques
• Conçoivent des architectures techniques pérennes,
  robustes et évolutives
• Pont entre le chef de projet et les développeurs
• Ce symposium sattardera uniquement sur le rôle
  darchitecte technique

10
Le rôle darchitecte technique

• Anticiper les évolutions technologiques
• Bâtir des architectures pérennes
• indépendance vis-à-vis dun fournisseur
  dAPI/Framework
• Mettre en place un minimum de généricité et
  dabstraction
• Un pont entre développeurs, chef de projet et
  experts métier
• Rôle dévangélisation technologique, sens aigu de
  la communication
• Garant du schéma directeur technique et des choix
  adoptés
• Une culture souvent mixte (.NET/J2EE/Libre)
• Avant tout un rôle et non un métier

11
Industrialisation dapplications
Analyse Use CaseModèles UML
Développement
Architecture/Design
Test/Recette
Itération(s)

• Lavenir nous emmène vers un seul etmême outil
  pour remplir toutes ces tâches

12
SOA (Service Oriented Architecture)
13
Quest-ce que SOA ?

•  Une vision dun système destinée à traiter
  toute application comme un fournisseur de
  services (DNG)
• Tout traitement applicatif est vu comme un
  service potentiellement utilisable par un client
• Le client est découplé de larchitecture
  technique du service quil invoque
• SOA véhicule des Messages et non des objets
• Pour adapter les technologies hétérogènes, on
  fait appel à des Connecteurs/Adaptateurs

14
Bénéfices

• Meilleur retour sur investissement
• Mobilité du code
• Séparation des rôles
• Sécurité accrûe
• Support de clients hétérogènes
• Plus de réutilisation et de maintenabilité
• La clé lagilité

15
Aujourdhui plat de spaghettis
ServeurWeb
Progicielintégré
Base commerciale
Messagerie
Applicationspécifique Y
Applicationspécifique X
16
Demain Architecture urbanisée
Client
Connecteur
Base commerciale
ServeurWeb
Applicationspécifique X
Progicielintégré
MiddlewareAsynchrone
Messagerie
17
Urbanisation et cartographie

•  Lurbanisation a pour objectif de faire évoluer
  le Système d'Information et sa composante
  informatique au même rythme que la stratégie et
  l'organisation des métiers de l'entreprise 
• La cartographie permet de déceler les redondances
  des flux, les doubles saisies, les incohérences
  applicatives
• Pourquoi ne pas imaginer plus tard des Design
  Patterns pour SOA/EAI ? (finalement, on monte
  toujours labstraction dun niveau)

18
Démarche itérative et incrémentale
Basée sur les invariants de lentreprise, cette
vue est souvent une cible à atteindre en se
basant sur la cartographie, état actuel
Système urbanisé
Architecture logicielle
Ilots autonomes
Architecture technique
Cible
Niveau d'Urbanisation
n Etapes
1 ère Etape
Temps
19
Beaucoup dinconnus

• Quelle granularité adopter ?
• Comment intégrer un SI boîte noire ?
• lorsquun seul progiciel prend en charge
  lensemble des processus métier (SAP, etc )
• Comment urbaniser un SI sans risquer de bloquer
  son fonctionnement ?
• Où se situe les interfaces graphiques clientes ?
• Quelle méthodologie pour lurbanisation et la
  cartographie ? Langage de modélisation ?
• Le risque nest-il pas de déplacer la complexité
  du SI au niveau de lEAI ?

20
Le Design

• Un bon Design est toujours la garantie de
  lévolutivité dune application
• Trop de Design tue le design
• Évitez les architectures anti-pattern
• Faire du Design cest un peu comme faire une
  recette de cuisine, il faut choisir les bons
  ingrédients
• Un bon design est souvent associé à une bonne
  architecture technique (séparation des couches,
  n-tiers, etc )

21
Design Quick Dirty vs Code évolutif
utilise MonFournisseurTrace MaClasseCliente
public maMethode1() MonFournisseur.Trace("ce
ci") public maMethode2()
MonFournisseur.Trace("cela") public
maMethodeN() MonFournisseur.Trace()
utilise MonAbstractionTrace MaClasseCliente
public maMethode1() MonAbstraction.Trace("c
eci") public maMethode2()
MonAbstraction.Trace("cela") public
maMethodeN() MonAbstration.Trace()

• Changer de fournisseur de trace revient à
  modifier exponentiellement le code client x
  méthodes y lignes

22
MDA (Model Driven Architecture)

• Démarche pilotée par les modèles
• PIM (Platform Independent Model)
• PSM (Platform Specific Model)

Map PSM to application interfaces, code, GUI
descriptors, SQL queries, etc.
Platform-Independent Model
23
Conclusion

• Larchitecture fait et fera partie des grands
  concepts de demain
• Labstraction des systèmes est de plus en plus
  une nécessité car la technologie évolue à une
  vitesse effrénée
• SOA en est une des facettes
• Attention à ne pas sombrer dans le cas extrême
  lanti-pattern darchitecture
• La maîtrise des évolutions technologiques est la
  clé du succès dans un SI maîtrisé
• Si la référence nest plus lassembleur mais le
  Byte Code, pourquoi ne pas imaginer demain de
  nouvelles puces en terme darchitecture
  matérielle ? (processeurs intégrant une JVM/CLR)

24
Ressources

• Les sites
• http//www.dotnetguru.org
• http//www.dotnet-fr.org (.NET)
• http//www.theserverside.com (J2EE)
• http//www.application-servers.com
• http//www.microsoft.com/net (.NET)
• Les ouvrages
• Design Patterns (Gang of Four)
• Enterprise Architecture (Fowler)
• Pratique de .NET et C (Patrick Smacchia)

25
Architectures multi-couches
Architectures multi-couches, design patterns et
programmation orientée aspects Thomas GIL
DotNetGuru.org Thomas.gil_at_valtech.fr
26
Organisation

• Architectures multi-niveaux
• Historique
• Anti-patterns d'architecture
• Patterns d'architecture
• Design Patterns
• Le besoin d'une approche orientée objet
• Un langage de Patterns
• Quelques Patterns sympa
• Programmation orientée Aspects
• Concepts
• Enjeux
• Stratégies d'implémentations
• AspectDNG

Architecture n-tiers, Design Patters, AOP
27
Architectures multi-niveaux

• Architectures multi-niveaux
• Design Patterns
• Programmation par Aspects

Architecture n-tiers, Design Patters, AOP
28
Victimes de la mode

• Il a existé plusieurs courants architecturaux
• Client passif - Serveur omniscient
• Client sexy - Serveur de données
• Client sexy - Objets distribués
• Architectures client léger revisitées (pour le
  Web)
• Ces "modes architecturales"
• Sont structurantes pour les systèmes
  d'information
• La transition d'une mode à l'autre est complexe
• Pondèrent différemment le développement et le
  déploiement de responsabilités logiques
  constantes
• Jetons un oeil à ces différentes responsabilités
  ...

Architecture n-tiers, Design Patters, AOP
29
Responsabilités logiques
Visualisation
Présentation
Intégration
???
Services
Concepts métier
Accès aux données
Stockage
Architecture n-tiers, Design Patters, AOP
30
Client Serveur, première
Architecture n-tiers, Design Patters, AOP
31
Client Serveur, deuxième
Architecture n-tiers, Design Patters, AOP
32
Architectures 3 niveaux
Architecture n-tiers, Design Patters, AOP
33
Architectures multi-niveaux
Architecture n-tiers, Design Patters, AOP
34
Anti-pattern darchitecture

• Architecture dobjets distribués
• Distribuer les objets du domaine est à proscrire
• Ils exposeraient des méthodes de granularité trop
  fine
• Il ne faut distribuer que des services
• Synchrones
• Asynchrones

Architecture n-tiers, Design Patters, AOP
35
Pattern darchitecture (DTO)

• Les architectures orientées services distribués
• Ne doivent pas nuire aux performances
• Doivent renvoyer aux couches de présentation des
  agrégats de données dune finesse adéquate des
  DTO (Data Transfer Object)
• Faut-il créer un DTO par objet du domaine ?
• Bonnes performances
• Faible maintenabilité (sauf à les générer)
• Faut-il utiliser un DTO générique ?
• Basé sur une Hashtable et lintrospection .NET

Architecture n-tiers, Design Patters, AOP
36
Design Patterns

• Architectures multi-niveaux
• Design Patterns
• Programmation par Aspects

Architecture n-tiers, Design Patters, AOP
37
Conception Orientée Objet

• Le contenu dune couche de responsabilité doit
  être Orienté Objet
• Héritage et polymorphisme permettent
  extensibilité et généralisation
• Atteindre le même niveau de généricité et de
  robustesse avec un langage non Objet est très
  difficile

Architecture n-tiers, Design Patters, AOP
38
Le risque du non-objet

• Adopter une approche procédurale
• Nuit à lévolutivité
• Tout doit être prévu au moment de la compilation
  du programme
• Chaque modification a un impact sur le code
• Ne facilite pas le lien entre les rôles
• Techniques (concepteurs/développeurs, architectes
  techniques)
• Et fonctionnels (analystes, architectes
  fonctionnels)
• Lobjet est donc incontournable sur de gros
  projets à spécifications évolutives

Architecture n-tiers, Design Patters, AOP
39
Design Patterns enjeux

• Apprendre les Design Patterns et les appliquer,
  cest
• Apprendre à bien concevoir Objet
• Acquérir des réflexes, gagner du temps
• Mieux cerner un problème (simplification)
• Limiter le couplage, augmenter lévolutivité
• Elever le niveau de langage, faciliter les
  échanges

Architecture n-tiers, Design Patters, AOP
40
Langage de Patterns

• DotNetGuru est
• Un singleton
• unique, ce site, non ?
• Une fabrique darticles
• à fréquence dinstanciation variable
• Un pool de rédacteurs
• min 2, à incrémentation spontanée
• Les news de DNG sont des smart proxies
• cache dun résumé de linfo lien vers la source
  de linfo
• Les articles sont des mémentos
• ils cristallisent létat de nos connaissances à
  un moment donné
• Chaque commentaire sur les articles est un poids
  mouche
• il ne répète pas le contexte que représente
  larticle
• Yves de la Martinière est un visiteur ou un
  observateur asynchrone
• Les lecteurs de DNG sont des guerriers
• Cest le pattern état desprit

Architecture n-tiers, Design Patters, AOP
41
Quelques patterns sympa

• Couplage faible
• Abstract factory
• Commande
• Adaptation, enrichissement
• Decorateur
• Persistance
• Lazy loading
• Tissage de services techniques
• Proxy, intercepteur
• Parsing (cf. AspectDNG 0.1)
• Visiteur (attention au piège du polymorphisme)

Architecture n-tiers, Design Patters, AOP
42
Programmation par Aspects

• Architectures multi-niveaux
• Design Patterns
• Programmation par Aspects

Architecture n-tiers, Design Patters, AOP
43
Concepts de la POA

• Tisser un aspect
• Permet dajouter des fonctionnalités à du code
  qui ne sen préoccupait pas a priori
• Est proche des patterns décorateur ou
  intercepteur
• Le code en question (code cible)
• Nest pas conscient quil va être enrichi
• Se concentre exclusivement sur son objectif
  initial
• Les Aspects
• Sont souvent génériques
• Peuvent sappliquer à un ensemble de méthodes

Architecture n-tiers, Design Patters, AOP
44
Enjeux de la POA

• Réduire la quantité de code
• Diminuer les temps et coûts de développement
• Limiter le code technique dans les objets métier
• Optimiser les performances
• Améliorer la qualité et la robustesse des applis

Architecture n-tiers, Design Patters, AOP
45
La POA sur .NET

• Approche par intercepteurs
• Reposant sur linfrastructure .NET Remoting
• Approche par tissage
• Statique (cf. AspectDNG)
• Dynamique (JIT Weaving)
• Limplémentation de la POA .NET doit combler son
  retard sur le leader en Java AspectJ

Architecture n-tiers, Design Patters, AOP
46
AspectDNG v0.2
Reflection ILReader
Emit
Légende Assembly XSLT MSILML
Architecture n-tiers, Design Patters, AOP
47
Conclusion

• Tout projet doit soigner son architecture
  technique
• Chaque couche logique gagne à être conçue de
  manière Orientée Objet
• La connaissance et lapplication de Design
  Patterns améliore sensiblement la qualité du
  logiciel, et la flexibilité des applications
• La programmation Orientée Aspects est
  complémentaire à la programmation Orientée Objet

Architecture n-tiers, Design Patters, AOP
48
Les Services Web

• Comprendre les Services Web pour l'entreprise
• Didier GIRARD - IMPROVE
• Didier.Girard_at_improve.fr

Version 1.0 9/10/2003 DNG/002
49
Sommaire

• Architecture Orientée Services SOA
• Services Web
• Retour dexpériences sur les services web

Les Services Web en entreprise
50
Architecture orientée services

• Un service est une fonction qui reçoit des
  messages et qui les restitue après traitement.
• Un service respecte un contrat
• Un service est réutilisable
• Un service est sans état

Service
Message à traiter
Application 1
Contrat
Implémentation
Application 2
Message traité
Service 1
Service 2
Les Services Web en entreprise
51
Architecture orientée services

• Une architecture orientée services est une
  infrastructure permettant de diffuser des
  services.
• SOA Service Oriented Architecture
• WSOA Web Services Oriented Architecture
• SOA nest pas un concept neuf. Les sites centraux
  utilisaient déjà la notion de services.

Les Services Web en entreprise
52
SOA ou Web Services

• La notion de  service  est le concept
  important. Les Services Web sont juste un moyen
  de les implémenter. Peut-être le meilleur.
• Une bonne SOA est une histoire de conception pas
  de technologie.
• Il est très facile de construire des services web
  médiocres. Beaucoup le feront.
• La technologie Services Web ne fait pas votre
  architecture.
• Un bon service doit être  abstrait  il nest
  pas lié à une implémentation.
• Les services web forment un très bon ensemble de
  spécifications pour construire une SOA
  indépendance, sécurité, transaction,
  orchestration,

http//www.looselycoupled.com/opinion/2003/wilkes-
soa-infr0415.html
Les Services Web en entreprise
53
SOA tactique ou stratégie

• La SOA est une vision stratégique pour le système
  dinformation.
• La mise en place de services web est du domaine
  tactique, elle est opportuniste.
• Il existe très peu de sociétés qui ont une vision
  stratégique SOA.
• Think big, start small !

Les Services Web en entreprise
54
Une architecture SOA ?

• Il nexiste pas "une" architecture orientée
  services ou même des techniques caractérisant une
  SOA.
• La mise en place d'une architecture orientée
  services répond à un besoin la réutilisation
  des traitements.
• Le contexte de réutilisation de ces traitements
  va dicter des besoins fonctionnels
  interopérabilité, fiabilité, sécurité,
  hétérogénéité, pérennité, adaptabilité,
  ACIDité...
• De ces besoins fonctionnels vont découler des
  choix technologiques couplage lâche pour
  garantir interopérabilité, asynchronisme pour
  garantir la fiabilité,...
• Les technologies sont au service de
  larchitecture et pas linverse.

Les Services Web en entreprise
55
SOA Fonctionnalités

• Fonctionnalités que peut proposer une
  implémentation
• Indépendance vis à vis de la plate-forme
• Indépendance vis à vis du langage de
  programmation
• Découverte dynamique des services
• Fiabilité
• Sécurité
• Gestion des transactions
• Orchestration des services
• Possibilité denregistrer les séquences de
  messages
• Possibilité de produire des rapports daudit
• Routage intelligent des messages
• Tolérance aux pannes, montée en charge
• Capacité à agir en fonction dindicateur
• Système de versionning

Les Services Web en entreprise
56
SOA Modèle à 5 couches
Client
Interfaces WEB, C/S, PDA ou encore XML,
Objets métiers
Mapping
Lié à ma structure de données
Physique
SGBD, CICS, LDAP,
Les Services Web en entreprise
57
Avantages du modèle à 5 couches

• Garantit des développements industrialisables et
  des applications maintenables, évolutives,et
  réutilisables
• Permet de spécialiser les développeurs
• Casse la créativité des développeurs
•  Les développeurs les plus expérimentés
  demandent à ne plus faire du multicouche ! -
  David DUQUENNE
• Assure le dialogue entre le concepteur et le
  développeur
• Détache le fonctionnel du technique

Les Services Web en entreprise
58
Inconvénients

• Surcoût de conception
• Chaque couche est indépendante, et demande donc
  une documentation qui définit ses interfaces avec
  les autres couches
• Surcoût de réalisation
• Pour une fonctionnalité, il faut impacter
  plusieurs couches, et coder plusieurs éléments
  (éventuellement par des personnes différentes)
• Surcoût en performances
• Certains IDE et technologies permettent de
  prendre des raccourcis ! (triggers, procédures
  stockées, base de données mémoire)
• étudier comment les intégrer dans le
  multicouche,
• trancher entre maintenabilité et performances.

Les Services Web en entreprise
59
Implémentations

• .Net, J2EE, Corba, RMI, Propriétaire

Mapping
Mapping
Connecteurs
Les Services Web en entreprise
60
NON aux objets métiers !

• Les objets métiers ne conviennent pas dans le cas
  des SOA
• A chaque nouveau développement, le fonctionnel
  évolue, et les objets métiers sont sollicités
  différemment, ce qui oblige à migrer tous les
  développements déjà réalisés !

Client
Client
Objets Métiers
Physique
Les objets métiers sont les ennemis de la
réutilisation et de lévolutivité.
 Don Box says SOA paradigms will eclipse OO
programming 
Les Services Web en entreprise
61
Linfrastructure des Services Web

• Les trois piliers des Services Web

SOAP 1.1 Note W3C Simple Object Access Protocol
UDDI 2.0 Microsoft,IBM, HP Universal
Description Discovery and Integration
WSDL 1.0 Note W3C Web Services Description
Language
Transporte
Décrit le contrat
Stocke les descriptions de contrat
XML 1.0 Recommendation W3C - 1998 eXtensible
Markup Language
Les Services Web en entreprise
62
Services Web - Utilisation
Services Web
Applications
Intranet / Internet
Middleware
Requête XML
Interface WSDL
Réponse XML
Vue Entreprise
Vue Utilisateur du service
Les Services Web en entreprise
63
Mise en uvre des Services Web

• SOAP, WSDL et UDDI en action

WSDL


Application (Client)

Application (Serveur)
_at_
SOAP
Les Services Web en entreprise
64
Services Web et système dinformation
Portail dentreprise
Portlets
Portlets
Portlets
Mapping
Mapping
Connecteurs JCA
Les Services Web en entreprise
65
Au delà des services web  jouet 

• La relative simplicité de mise en uvre des Web
  Services ne doit pas masquer les risques que
  peuvent entraîner leur prolifération non
  contrôlée.
• Les questions essentielles Comment minimiser
  limpact
• de la sécurité,
• des contraintes dauthentification ,
• de lhabilitation,
• de la transformation de messages,
• de linteropérabilité,
• de la fiabilité,
• de la gestion des versions,
• de la confidentialité,
• de la vulnérabilité,
• du couplage lâche,
• ...

Les Services Web en entreprise
66
Les attaques

• La sécurité est sans doute le sujet le plus
  important lorsque lon expose son système
  dinformation à travers des services web.
• La sécurité influence fortement larchitecture
  logicielle.
• Types dattaque
• DDOS (Distributed Denial of Service)
• Failles applicatives
• Usurpation didentité
• Sous location de services
• Règle de base dépenser le moins de ressources
  possible pour vérifier quune demande dexécution
  dun service est légitime

http//www.networkmagazine.com/article/NMG20010125
S0003
Les Services Web en entreprise
67
Authentification

• Authentification
• La théorie - WS-Security intégrité,
  confidentialité, authentification
• La pratique solution propriétaire

 Should any authorization be placed inside the
SOAP envelope (i.e., in SOAP headers), or
outside the envelope (e.g., as HTTP headers) ?
One thing is for sure, if I do it one way and
you expect it another, we won't
interoperate.  Sam Ruby
Les Services Web en entreprise
68
Habilitation

• Habilitation
• Ce nest pas parce quune personne est connue de
  votre système quelle est habilitée à utiliser un
  service.
• Lhabilitation doit être validée au plus tôt.

Les Services Web en entreprise
69
Transformation

• Transformation
• Qui impose le format des données qui vont être
  échangées ?
• Le fournisseur du service ?
• Le consommateur du service ?
• Celui qui possède les données ?
• Celui qui a le poids économique le plus important
  ?

Les Services Web en entreprise
70
Gestion des versions des services

• DLL Hell
•  Enfer des DLL - Problème survenant au fil des
  installations, mises à jour, et désinstallations
  de produit d'éditeurs multiples manipulant des
  DLLs communes, ce qui aboutit à la mise en place
  de versions incompatibles, de sorte qu'il n'est
  pas rare que l'installation d'une application ou
  sa mise à jour cause la perte de fonctionnement
  d'une autre application, notamment d'un autre
  éditeur. 

http//www.osinet.fr/code/glo.asp?InitialD
Les Services Web en entreprise
71
Gestion des versions des services

• Web Services Hell.
• Si vous voulez éviter lenfer des services web,
  votre architecture doit supporter un système de
  gestion des version pour les services web.
• Ce système de gestion des versions peut être
  évolué, par exemple
• Appel du service web de version 1.1.3
• Appel du service web de version 1.
• Ne pas prévoir un système de versionnage dans
  votre architecture risque de figer vos services.

Les Services Web en entreprise
72
Couplage lâche

• Pourquoi un couplage lâche ?
• Nimpose pas de plate-forme, de système
  dexploitation ou de langage.
• Permet le changement de localisation du service
• Permet lévolution de limplémentation
• Architecture de services web ouverte
• Si vous voulez que vos services soient
  consommables par le plus grand nombre, vous devez
  imposer le minimum de contraintes.
• Votre architecture doit supporter plusieurs
  systèmes dauthentification, de compression, de
  cryptage.
• Vous ne devez pas être lié à un format de
  messages.

Les Services Web en entreprise
73
Fiabilité - Synoptique

• Composants mis en oeuvre lors du déclenchement
  dun service
• Si la communication est interrompue entre les
  étapes 1 et 2, il y aura un doute sur
  lenchaînement des événements.

http//www-106.ibm.com/developerworks/webservices/
library/ws-phtt/
Les Services Web en entreprise
74
Fiabilité - Communication interrompue

• Conclusions possibles lors de linterruption
  dune communication
• La requête na peut-être pas été transmise au
  récepteur
• La requête a peut être été transmise et traitée
  par le récepteur
• La requête a peut être été transmise et traitée
  correctement par le récepteur
• La requête a été transmise et traitée
  correctement. Mais la réponse a été perdue.
• Il est impossible pour lémetteur de pouvoir
  statuer.
• Pour fiabiliser les services web, il est
  nécessaire de passer par des communications
  asynchrones.

Les Services Web en entreprise
75
Traçabilité

• Objectif de la traçabilité (audit)
• Récolter un certain nombre dinformations
  concernant le fonctionnement des services
  utilisés et des services offerts fournisseur ou
  client, nom du service, heure dappel, heure de
  fin, code derreur,
• La récolte de ces informations doit permettre
  dobtenir des statistiques sur lutilisation
  (nombre dappels), la disponibilité, les horaires
  de fréquentation, les temps de réponse (mini,
  maxi et moyen) et la fiabilité de chacun des
  services.
• Journalisation cross-partenaires
• Les messages échangés doivent être stockés pour
  éviter la répudiation.

Les Services Web en entreprise
76
Validation

• Vérifier quun message XML respecte un schéma est
  une opération qui peut être coûteuse.
• Il peut être intéressant de débrayer le système
  de validation pour certains services web  sûrs .

Les Services Web en entreprise
77
Cache

• Cache Client / Cache Fournisseur

Requête XML
Service Web
Cache
Application
Réponse XML
http//www-106.ibm.com/developerworks/webservices/
library/ws-cach1/
Les Services Web en entreprise
78
Services web et développement

• Il faut mettre en place plusieurs environnements
  dexécution des services web
• Développement
• Intégration
• Recette
• Préproduction
• Production

Les Services Web en entreprise
79
Tests unitaires

• Un service web doit être très robuste
• Mettre en place une politique de tests pour
• Vérifier que le code développé fonctionne
• Garantir que tout le code dune application a au
  moins été exécuté une fois
• Éviter les régressions
• Permettre le refactoring de code

Les Services Web en entreprise
80
Tests Unitaires

•  Boite noire 
•  Boite Blanche 

Unit-testing J2EE applications par Vincent
Massol http//blogs.codehaus.org/people/vmassol/
Les Services Web en entreprise
81
Tests Unitaires

• JUnit, Cactus, NUnit, DBUnit
• Outil classique de tests unitaires qui permette
  de tester votre application
• SOAPtest de Parasoft
• Outil permettant de générer des jeux de tests
  unitaires à partir dun document WSDL
• Propriétaire
• Injection de messages SOAP
• Une politique de tests unitaires pour une
  architecture SOA est difficile à mettre en uvre,
  elle est pourtant fondamentale

Les Services Web en entreprise
82
Architecture

• Avant de déclencher un traitement, un message
  reçu va traverser une couche de traitements
• La chronologie dexécution des traitements permet
  de minimiser une attaque de type DDOS.

SOAP
WSDL
Application (Serveur)
Authentification
Habilitation
Intégrité
Journalisation
Compression
Cryptage
Transformation
Environnement
Versionning
Audit
Les Services Web en entreprise
83
Architecture

• La couche de traitement doit être mutualisée
  entre tous les services web

Les Services Web en entreprise
84
Architecture

• Va-t-on vers un EAI ?

Les Services Web en entreprise
85
Architecture

• Lorsque vous concevez votre architecture, il ne
  faut pas penser RPC
• Mon service est une méthode que je vais
  déclencher
• Cette méthode comprend des paramètres
• Il faut exposer des services qui traitent des
  documents
• Ne pas transmettre des paramètres à une méthode
  mais un document à un service
• Le service web  idéal  est composé de deux
  documents
• Un document contenant les données que le service
  web va devoir traiter
• Un document contenant des metadonnées format,
  versions, domaine dexécution (DEV,Intégration,
  Recette, Production), type dauthentification,
  algorithme de cryptage,

Les Services Web en entreprise
86
Ce quil faut retenir

• Les services web dentreprise ne sont pas aussi
  simples
• Quun attribut .Net (C)
• Ou quun fichier .jws (java/Axis)
• Faites vous aider par un architecte !

lt_at_ WebService Language"c" 
Class"HelloWorld" gt using System.Web.Services
using System.Web.Services.Protocols SoapRpcServ
ice public class HelloWorld WebMethod,
SoapRpcMethod public string greeting()
return "Hello World!"
public class HelloWorld public String
greeting() return "Hello World!"
Les Services Web en entreprise
87
Web Service Extensions for ASP.NET
http//www.newtelligence.com/
Les Services Web en entreprise
88
Web Service Extensions for ASP.NET
Les Services Web en entreprise
89
A travers le web

• Sang Shin 2003 Web services is like teenage
  sex, everybody is talking about it but nobody is
  doing it.
• Sun Technology Evangelist
• Don Box 2003 Read Less Specs, Write More Apps
  
• Coauteur de SOAP
• Architecte services web chez Microsoft
• Clemens Vasters 2003 I want WSDL to die
• MS Regional Director
• David Ing 2003 SOAP, It wasnt Simple, we
  didnt Access Objects and its not a Protocol
• Chief Software Architect - Meridian Project
  Systems
• Phil Wainewright 2003 Contract-oriented
  architecture - Forget service-oriented. It's
  contracts that matter
• Founder of web services information site Loosely
  Coupled
• CEO of Procullux Ventures

Les Services Web en entreprise
90
Conclusion

• SOA nest pas une technologie
• La technologie de base des services web est
  globalement mature
• Le déploiement de services web pour une
  entreprise recèle toutefois de nombreux pièges
• Il est important davoir du recul pour réussir un
  projet Services Web
• Se méfier des outils et des discours sur les
  services web jouets

Les Services Web en entreprise
91
Mapping Objet-Relationnel
Le Mapping Objet-Relationnel est-il un mythe ou
une réalité ? Quelles sont les solutions
existantes ?

• Sébastien Ros
• Directeur Technique et
• Cofondateur de Evaluant

Version 0.8 1/09/2003 DNG/004
92
Présentation des couches daccès aux données

• Motivations et contraintes de réalisation

93
Motivations

• Quelle plateforme de développement ?
• .Net / SQL Server
• J2EE / Oracle
• PHP / MySQL
• Critères de choix
• Prix
• Montée en charge
• Maîtrise fonctionnelle

Le mapping Objet/Relationnel
94
Motivations

• Propriétés communes
• Langage de programmation objet
• Base de données relationnelle
• Raisons
• Bases de données objets plus chères
• Bases de données relationnelles plus performantes
• Méthodologie de programmation la plus utilisée
  actuellement

Le mapping Objet/Relationnel
95
Contradiction

• Manipuler des données dans un monde objet
• Héritage
• Interface
• Composition / Agrégation
• Cardinalité
• Enregistrer celles-ci dans un monde relationnel
• Table
• Enregistrement
• Relations
• Contraintes
• Conséquence
• Implémenter cette transition un moment ou un
  autre

Le mapping Objet/Relationnel
96
DAL

• DAL Data Access Layer
• Couche daccès aux données
• Définition
• La couche de services fournissant et manipulant
  des données directement exploitables, issues
  dune source de données quelconque
• Objectifs CRUD
• Create (Créer)
• Read (Lire)
• Update (Modifier)
• Delete (Effacer)

Le mapping Objet/Relationnel
97
Différentes implémentations

• Mauvaise architecture
• Accès aux données via des requêtes SQL
  directement dans la couche de présentation
• Aucune transformation des données relationnelles
  en objets métiers
• Aucune couche de services
• Exemple MS PetShop 1.0
• Bonne architecture
• Couche de services métiers exposant les
  différents cas dutilisation au développeur
• Couche de services exposant des objets résultant
  de la source de données (DAL )
• Accès aux données implémenté de façon
  indépendante de la source de données
• Exemple MS Petshop 3.2

98
Différents niveaux de services

• DAL standard
• Manipule des données scalaires (entier, chaîne,
  booléen, BLOB)
• Inconvénient Perte des informations objets
• Chaîne dhéritage
• Possession et cardinalité 1-1, 1- ?
• Relations complexes n-m
• DAL objet
• Manipule directement des objets métiers
• Inconvénient Difficulté dimplémentation
• Compétences/Ressources nécessaires
• Coût
• Performances

Le mapping Objet/Relationnel
99
Utilisation dune DAL objet

• Etude pratique de son utilisation dans le
  cadre dune architecture réfléchie

100
Vision Relationnelle des données
SqlConnection c new SqlConnection(myConnectionSt
ring) string q SELECT FROM Customer WHERE
City Paris DataSet ds new
DataSet() SqlDataAdapter ad new
SqlDataAdapter(q, c) ad.Fill(ds,
Customer) float sum0 foreach(DataRow r in
ds.TablesCustomer.Rows )) sum
rAccountAmount
Le mapping Objet/Relationnel
101
Vision Objet des données
DataBase.GetInstance().SetDefaultConnection(myConn
ectionString) string q CustomerCity
Paris CustomerCollection custs Custs
Factory.CustomerFactory.GetCollectionOPath(q) for
each(Customer c in custs) sum
c.AccountAmount
Le mapping Objet/Relationnel
102
Avantages (visibles)

• Indépendance du fournisseur de données
• Sql, OleDb, Oracle -gt DefaultConnection
• Requêtes objets
• SQL -gt OPath
• Entrepôt de données objet
• DataSet -gt Collections fortement typées
• Manipulation dobjets métiers
• DataRow -gt Objet métier (Customer)

Le mapping Objet/Relationnel
103
Exemple Weblog

• Présentation

Le mapping Objet/Relationnel
104
Exemple Weblog

• Diagramme de classes

Le mapping Objet/Relationnel
105
Orchestration
Le mapping Objet/Relationnel
106
Exemple Weblog

• Couche de Services
• public static IBlog GetBlogWithId(string BlogId)
• return Factory.BlogFactory.GetObjectId(BlogId)
• public static IBlog GetDefaultBlog()
• string request "BlogDefaultPage true"
• return Factory.BlogFactory.GetObjectOPath(request
  )
• public static IList GetBlogAll()
• return Factory.BlogFactory.GetCollectionAll()
• public static IList GetArticlesFromBlogId(string
  BlogId)

Le mapping Objet/Relationnel
107
Exemple Weblog

• Utilisation de la couche de services
• IBlog Weblog null
• if(Request"BlogId" ! null)
• Weblog WeblogService.GetBlogWithId(Request"Blo
  gId".ToString())
• else
• Weblog WeblogService.GetDefaultBlog()
• if(Weblog null)
• Response.Redirect("/blogList.aspx")
• blogId Weblog.Id
• if(!Page.IsPostBack)
• DataListArticles.DataSource WeblogService.GetAr
  ticlesFromBlogId(blogId)
• DataListArticles.DataBind()

Le mapping Objet/Relationnel
108
Exemple Weblog
Le mapping Objet/Relationnel
109
Limites des DAL

• Temps de développement
• Coûts
• Compétences disponibles/nécessaires

110
Solutions existantes sous .Net

• Techniques dimplémentation, avantages,
  inconvénients, pérennité

111
Méthodologies

• DB Schema vers Modèle objet
• Avantages
• Réutilisation des anciennes bases de données
• Inconvénients
• Développements plus complexes (mapping manuel)
• Système informatique figé
• Performances
• Modèle objet vers DB Schema
• Avantages
• Modélisation plus souple
• Intégré dans le processus de développement
• Communication plus simple entre les développeurs
• Performances
• Evolutions faciles de la base de données
• Inconvénients
• Rupture avec lexistant, mais importation des
  données possible

Le mapping Objet/Relationnel
112
Techniques

• Réflexivité / Enrichissement
• Non intrusif
• Génération de code
• Intellisense
• Accès au code source / Débogage

Le mapping Objet/Relationnel
113
Outils de mapping O/R

• Mise en place manuelle
• Compétences nécessaires
• Quantité de code
• Rapport (coût dimplémentation)/(apports
  fonctionnels)
• Solution adaptée au besoin nécessité /
  suffisance
• Utilisation dun outil dautomatisation
• Gain de temps
• Fiabilité du code
• Fonctionnalités avancées
• Cache
• Indépendance SGBD
• Requêtes objets
• Concurrence daccès

Le mapping Objet/Relationnel
114
Solutions
115
Démonstration finale

• Utilisation de Data Tier Modeler
• Databinding avancé
• Indépendance du SGBD
• Sérialisation binaire

116
Retour dexpériences

• Evaluant Asset Manager (ASP.NET)
• 1 Million de lignes de code
• 130 classes métier
• 30 généré par le DTM
• Ils ont adopté le mapping O/R sous .NET

117
Pour aller plus loin

• Livre Blanc Mapping Objet-Relationnel
• http//www.dotnetguru.org (section Persistance)
• http//www.evaluant.com (version anglaise)
• Microsoft Data Access Application Block
• http//www.microsoft.com/practices
• Articles de Scott Ambler
• http//www.ambler-consulting.com
• Des questions
• Sébastien Ros (s.ros_at_evaluant.com)

Le mapping Objet/Relationnel