NOUVEAU MODELE DE MATURITE SOA (SERVICE-ORIENTED ARCHITECTURE) - WHITE PAPER
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
WHITE PAPER NOUVEAU MODELE DE MATURITE SOA (SERVICE– ORIENTED ARCHITECTURE)
Pour encourager l'adoption la plus large possible du nouveau modèle de maturité SOA,
vous êtes autorisé à copier, distribuer et utiliser (et notamment créer des produits
dérivés) des “Matériels SOA” pour votre compte ou celui de votre société,
conformément aux restrictions énoncées dans le présent document.
"Matériel(s) SOA" désigne l'ensemble des images, icônes, modèles, whitepapers et
autres matériels fournis dans le cadre du modèle de maturité SOA, y compris les
légendes et textes associés.
Vous ne devez pas supprimer les avis de copyright ou autres avis de droits propriétaires
contenus dans les matériels SOA ou associés qui vous sont fournis. Vous vous engagez
également à inclure (sous forme d'attribution) l'avis de copyright contenu dans les
matériels SOA dans le produit dérivé que vous créez, p.ex. “Votre produit est basé sur le
nouveau modèle de maturité New SOA Maturity Model © 2005 développé par Sonic
Software Corporation, AmberPoint Inc., BearingPoint, Inc., Systinet Corporation. Tous
droits réservés." Sonic Software Corporation, AmberPoint Inc., Bearing Point, Inc., et
Systinet Corporation sont dans les présentes individuellement désignés sous le terme
“Titulaire du copyright”, et collectivement désignés sous le terme “Titulaires du
copyright”. Sauf indication contraire dans le présent avis, le nom d'un Titulaire du
copyright ne sera pas mentionné dans les publicités ou autres support pour promouvoir
la vente, l'utilisation ou tout autre usage des Matériels SOA sans le consentement écrit
préalable de celui-ci.
Vous assumez l'entière responsabilité de l'utilisation des Matériels SOA en combinaison
avec d'autres matériels. LES MATERIELS SOA SONT FOURNIS “EN L'ETAT”, SANS
AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS DE MANIERE NON
LIMITATIVE, DE COMMERCIALISATION, D'ADAPTATION A UN USAGE PARTICULIER ET
DE NON VIOLATION. LES TITULAIRES DU COPYRIGHT NE SERONT EN AUCUN CAS
RESPONSABLES DES DOMMAGES DIRECTS, SPECIAUX, INDIRECTS OU CONSECUTIFS,
OU DE TOUT DOMMAGE RESULTANT DE LA PERTE D'UTILISATION, DE DONNEES OU DE
PROFIT, QUE CE SOIT DANS LE CADRE DE L'EXECUTION DU CONTRAT, PAR NEGLIGENCE
OU AUTRE ACTION MALHONNETE, DECOULANT DE OU EN RAPPORT AVEC
L'UTILISATION OU L'EXECUTION DES MATERIELS SOA.
Vos droits concernant l'utilisation des Matériels SOA seront immédiatement résiliés si
vous ne respectez pas les termes et conditions énoncés dans les présentes. Sonic
pourra immédiatement résilier votre licence s'il juge, à sa seule discrétion, que cette
résiliation est nécessaire pour protéger ses droits de propriété intellectuelle ou autres.
Copyright ©2007. Progress Software Corporation. All rights reserved.
SOMMAIRE
> Avant-propos 2
> 1.0 Introduction et motivation 3
> 2.0 Définition de l'architecture SOA (Service-Oriented Architecture) 5
> 3.0 Le modèle de maturité SOA 7
3.1 Maturité SOA niveau 1 - Services initiaux 10
3.2 Maturité SOA niveau 2 - Services d'architecture 12
3.3 Maturité SOA niveau 3 - Services métier et collaboratifs 14
3.4 Maturité SOA niveau 4 - Services métier mesurés 18
3.5 Maturité SOA niveau 5 - Services métier optimisés 20
> 4.0 Conclusion 21
1
AVANT-PROPOS
Le présent whitepaper et le modèle qu'il présente sont le fruit d'une collaboration étroite
entre les leaders du SOA : Progress-Sonic Software, Systinet, AmberPoint et
BearingPoint. Il a pour but d'améliorer la souplesse des entreprises via la mise en
oeuvre d'une architecture SOA (Service-Oriented Architecture). Le modèle de maturité
SOA présenté dans ce document a été spécialement conçu pour aider les responsables
à démontrer la valeur ajoutée de leur vision SOA, et à évaluer l'adoption de cette
technologie au sein de leur entreprise.
N'hésitez pas à nous faire part de vos remarques et commentaires concernant ce
modèle, car ils nous permettront de poursuivre le développement de son contenu et de
partager avec vous les succès de l'approche SOA.
2 Copyright ©2007. Progress Software Corporation. All rights reserved.
1.0 INTRODUCTION ET MOTIVATION
Dans un contexte où la valeur stratégique de l'informatique est fortement remise en
question1, où chaque société de développement logiciel et chaque département
informatique subissent de fortes pressions visant à réduire ses coûts, le simple fait
d’aborder le thème de la valeur stratégique de la technologie s'avère peine perdue.
L'attention se porte bien davantage sur les méthodes de réduction des coûts, telles
que l'outsourcing et l'offshoring, que sur la valeur stratégique des technologies
émergentes.
Ce document a pour objectif de fournir une méthode impliquant une nouvelle approche
de conception et de déploiement de l'informatique, et plus particulièrement de
l'architecture OA (Service-Oriented Architecture), servant de base commune aux
organisations technologiques et commerciales pour améliorer leurs résultats à
plusieurs niveaux, notamment en termes de réduction des coûts et de simplification de
la mise en oeuvre de nouveaux business modèles.
La technologie SOA est une approche de conception, d'implémentation et de
déploiement de systèmes à partir de composants mettant en oeuvre des fonctions
spécifiques. Ces composants, appelés “Services”, peuvent être distribués sur
l'ensemble des sites et entreprises, puis reconfigurés en nouveaux processus métier
si nécessaire.
Tout ce qui concerne les nouvelles technologies étant considéré avec scepticisme, en
quoi l'architecture SOA se différencie-t-elle des autres approches développées par le
passé ? Les facteurs clés sont les suivants :
> L'architecture SOA est conçue sur des standards Web permettant des mises en
oeuvre rentables à l'échelon mondial, avec support étendu des fournisseurs.
> Les services sont “étroitement combinés” et offrent ainsi une bien meilleure
souplesse que les anciennes technologies en termes de réutilisation et de
recombinaison des services, pour créer de nouvelles fonctions à la fois dans et
entre les entreprises.
1
Carr, Nicholas G., Does IT Matter?, Harvard Business School Press, 2004.
Copyright ©2007. Progress Software Corporation. All rights reserved. 3
> Les meilleures pratiques SOA permettent de créer des conceptions qui supportent les
processus métier et améliorent la capacité à les externaliser et à les étendre aux
partenaires commerciaux.
> La technologie SOA permet de tirer parti des systèmes et processus existants, et ainsi
de préserver, voire même d'optimiser les investissements existants.
Cette combinaison de facteurs fait de l'architecture SOA l'approche par excellence pour
l'ensemble des parties concernées car elle permet:
> Au département Finance de réduire les coûts.
> Au département Commercial d'améliorer et d'étendre les business modèles (tel
quedémontré dans les exemples ci-après).
> Au département Informatique d'assurer la prise en charge des clients, de répondre aux
objectifs de service, et de disposer de la souplesse nécessaire pour satisfaire les
besoins futurs grâce à une souplesse accrue.
Les entreprises ne sachant pas comment tirer parti de l'architecture SOA, comment
justifier les investissements requis, par où commencer, et quelle vision adopter, des
conseils leur sont donc nécessaires. La solution présentée dans ce document consiste à
introduire un modèle de maturité SOA (SOA MM) visant à démontrer les impacts positifs
de l'adoption de l'architecture SOA sur l'activité. Ce modèle est issu de deux facteurs
clés:
> Le succès du modèle CMM (Capability Maturity Model®) et du modèle CMMISM (CMM
Integration)2 développés par le SEI (Software Engineering Institute), qui fournissent un
cadre commun de définition et d'évaluation de l'amélioration des processus logiciels
et autres efforts d'ingénierie.
> Les articles, à l'instar de ceux publiés par Randy Heffner de Forrester Research3, qui
démontrent le succès des diverses approches adoptées par les entreprises optant
pour l'architecture SOA.
2
Software Engineering Institute, Capability Maturity Model® Integration, http://www.sei.cmu.edu/cmmi.
3
Heffner, Randy, “Your Paths to Service-Oriented Architecture”, Forrester Research, Dec. 2004.
4 Copyright ©2007. Progress Software Corporation. All rights reserved.
L'introduction de la technologie SOA dans un cadre similaire au modèle CMM® nous
permet de présenter les objectifs, les caractéristiques et les prérequis des impacts de
l'architecture SOA, en fonction des niveaux suivants :
Nouvelle Réduction Réactivité de Transformation Optimisation
fonctionnalité des coûts l’entreprise de l’activité de l’activité
Le modèle SOA MM permet de déterminer les objectifs, l'étendue et les avantages de
chaque niveau, les standards clés, les meilleures pratiques, et les facteurs de succès
stratégiques, tant au niveau technologique qu'organisationnel. Il fournit ainsi les conseils
nécessaires pour définir la vision SOA et une méthodologie permettant d'évaluer
l'adoption de cette technologie au sein de l'entreprise.
Forrester Research indique que les entreprises adoptent des approches différentes
concernant l'architecture SOA, chacune d'entre elles présentant des avantages, des
exigences et des atouts distincts. Pour certaines sociétés, la préoccupation majeure
portera davantage sur l'intégration interne et le workflow, alors que pour d'autres elle
concernera l'intégration des partenaires. Au fur et à mesure que les entreprises adoptent
les approches spécifiques adaptées à leurs besoins, elles les corrèlent avec le modèle de
maturité pour déterminer leurs besoins organisationnels, leurs besoins technologiques et
leurs objectifs à mesure qu'elles progressent dans les différents niveaux de maturité
SOA.
2.0 DÉFINITION DE L’ARCHITECTURE SOA (SERVICE-ORIENTED
ARCHITECTURE)
Le concept SOA est une évolution de l'informatique distribuée, conçue pour permettre
l'interaction de composants logiciels appelés “services” sur l'ensemble d'un réseau. Les
applications sont créées à partir d'une combinaison de ces services, qui peuvent être
partagés entre plusieurs applications.
Par exemple, une application de gestion des ressources humaines pourrait être créée à
partir des services suivants :
> Service Administration des employés permettant de gérer les embauches, les
changements de statut et la résiliation des contrats.
> Service Administration des performances et des salaires permettant de gérer les
salaires et les performances des employés conformément aux normes de l'entreprise.
Copyright ©2007. Progress Software Corporation. All rights reserved. 5> Service Administration des avantages permettant de mettre en place ou de supprimer
des avantages, et de traiter les inscriptions annuelles.
> Service Mise en oeuvre et sécurité informatique permettant de gérer l'ajout et la
suppression des droits d'accès des employés, selon leur rôle et leur statut dans
l'entreprise.
> Service Paie fourni en toute sécurité sur Internet par un fournisseur externe.
> Service Portail du département RH permettant aux membres d'accéder à une interface
de navigation Web incluant les fonctions des services ci-dessus.
> Service Gestion des processus métier permettant de gérer les processus de
notification et d'approbation.
La technologie SOA permet aux entreprises d'optimiser la réutilisation des actifs
existants, et de répondre plus rapidement aux évolutions de la demande. Ces avantages
sont attribuables à plusieurs éléments stratégiques de l'architecture SOA :
> Les services prennent en compte les activités logiques. Chaque service exécute
généralement plusieurs opérations pour une fonction spécifique, par exemple le
service Paie exécute les opérations “émettre des chèques”, “émettre des formulaires
W2” et “fournir le rapport des cycles de paie”. Plus important encore, ces services
tiennent compte des concepts de processus métier, et non pas des fonctionnalités ou
API définies par les progiciels traditionnels.
> De nouveaux services peuvent être ajoutés ou créés en combinant des services
existants sans que cela affecte les mises en oeuvre de service actuelles. Dans
l'exemple ci-dessus, un composant "Libre-service employé" pourrait donc être ajouté
en utilisant les services existants, en filtrant les données et opérations appropriées
pour les utilisateurs en libre-service. Cela permet d'obtenir une approche de
"développement incrémentiel" de la mise en oeuvre des services.
6 Copyright ©2007. Progress Software Corporation. All rights reserved.> Les services peuvent être installés sur des systèmes hétérogènes sur l'ensemble des réseaux et sites, ce qui permet une indépendance vis-à-vis de la plate-forme et une transparence vis-à-vis du site. Il n'est pas nécessaire que chaque service soit mis en oeuvre à l'aide de la même technologie logicielle ou matérielle, ni qu'il soit installé sur le même réseau ou dans le même site. Le service Administration des performances et des salaires pourrait être mis en oeuvre dans un environnement J2EE sur un serveur Linux dans un pays donné, alors que le service Mise en oeuvre et sécurité informatique pourrait l'être dans un environnement Microsoft .NET sur un serveur Windows dans un pays différent. > Les services communiquent par protocoles standards, ce qui permet une interopérabilité à grande échelle. Le plus souvent, et particulièrement en ce qui concerne la connexion des systèmes hétérogènes, il s'agit de protocoles basés sur des standards Web. Les "services Web" sont les mises en oeuvre de services utilisant ces standards. Amazon et eBay sont de parfaits exemples d'entreprises qui ont rendu leurs applications de base accessibles sur Internet sous forme de services Web. > Les systèmes d'application en place peuvent être intégrés sous forme de service, ce qui permet d'optimiser les investissements existants. La technologie SOA fournit des mécanismes permettant de mettre au premier plan les systèmes existants par l'intermédiaire d'une interface de services, sans qu'aucune modification ne soit nécessaire. En outre, elle permet aux éditeurs ERP traditionnels de proposer rapidement les fonctionnalités de leurs applications sous forme de services Web. > Les services sont dotés d'une interface et d'une conception orientée message. La fonctionnalité fournie par les services est définie par des métadonnées décrivant l'interface avec le service et ses opérations. Les informations sont transmises de et vers les services sous forme de messages. La définition de l'interface et des messages est davantage orientée sur le résultat que sur la méthode utilisée. La méthode utilisée fait partie intégrante de la mise en oeuvre du service. Les applications SOA sont généralement “pilotées par événements” et répondent ainsi aux messages dès qu'ils arrivent. Une mise en oeuvre SOA s'appuie sur des compétences, des méthodes et une infrastructure permettant d'assurer une prise en charge fiable, évolutive et sécurisée de l'application. Cette nouvelle approche inclut notamment les éléments de base suivants: > Méthodologies d'analyse, de conception et de mise en oeuvre permettant de guider les chefs de projet, les développeurs et le personnel chargé des opérations informatiques, dans la conception, l'assemblage et la réutilisation rapides des composants SOA. Copyright ©2007. Progress Software Corporation. All rights reserved. 7
> Outils de modélisation et de développement permettant de spécifier et de créer les
services ainsi que les processus métier qui les connectent.
> Bus ESB (Enterprise Service Bus)4 établissant des communications distribuées,
évolutives et fiables, ainsi que des transformations de données entre les services, et
fournissant des adaptateurs aux mises en oeuvre multifournisseurs et technologies
existantes.
> Référentiel et registre des politiques et services permettant d'organiser, de maîtriser
et de gérer de manière centralisée les informations SOA, incluant un catalogue des
services disponibles, leurs définitions d'interface, et les politiques régissant leur
utilisation.
> Outils de gestion d'infrastructure et de mise en oeuvre permettant de fournir les
éléments traditionnels des meilleures pratiques informatiques d'une mise en oeuvre
SOA, et notamment la surveillance des performances des services et l'exploitation des
mesures de Qualité des Services (QoS : Quality of Serices). L'orientation métier de
l'architecture SOA permet également un pilotage BAM (Business Activity Monitoring)
au niveau fonction/processus.
3.0 LE MODÈLE DE MATURITÉ SOA
L'introduction de l'architecture SOA permet à l'organisation technologique et
commerciale d'une société de répondre aux objectifs communs de l'entreprise. Le
modèle de maturité SOA fournit des objectifs et des conseils sur les impacts positifs de
cette technologie sur l'activité.
La Figure 1 (ci-dessous) présente les cinq niveaux de maturité SOA ainsi que les
principaux impacts sur l'activité, en allant du niveau le moins mature à celui le plus
mature: Services initiaux, Services d'architecture, Services métier et Services
collaboratifs (deux approches de niveau 3), Services métier mesurés, et Services métier
optimisés. Les niveaux CMMISM5 correspondants sont également indiqués pour
référence.
4
Chappell, David, Enterprise Service Bus, O’Reilly, 2004
5
En résumé : CMMISM Exécution signifie que les fonctions sont exécutées, CMMISM Définition signifie que les
processus standards sont définis, CMMISM Gestion signifie que les processus standards sont mis en oeuvre et
gérés, CMMISM Gestion quantitative signifie que les résultats des processus sont mesurés par rapport aux
objectifs, CMMISM Optimisation signifie qu'un processus d'amélioration continue est mis en oeuvre en fonction
des mesures.
8 Copyright ©2007. Progress Software Corporation. All rights reserved.Le Tableau 1 (page suivante) présente les attributs de chaque niveau de maturité, notamment l'impact sur l'entreprise, l'étendue, les facteurs de succès critiques et les standards concernés. Conformément à l'approche adoptée par le SEI pour le modèle CMM (Capability Maturity Model®), les pratiques et objectifs de chaque niveau de maturité sont spécifiés dans le Tableau 2. L'atteinte de ces objectifs et la mise en oeuvre de ces pratiques déterminent l'atteinte d'un niveau de maturité. Chaque niveau de maturité a comme prérequis l'atteinte des objectifs et pratiques des niveaux inférieurs. Dans bien des cas, les objectifs seront atteints, les pratiques seront mises en oeuvre et les technologies seront utilisées à des niveaux inférieurs à ceux indiqués dans les Tableaux 1 et 2. C'est ce qui est attendu et encouragé selon les priorités de l'entreprise. Les sections suivantes analysent chacun des niveaux de maturité SOA.3.1 Copyright ©2007. Progress Software Corporation. All rights reserved. 9
Tableau 1 : Modèle de maturité SOA
Niveau de Principaux Portée Facteurs de succès technologiques Facteurs de succès Standards associés
maturité avantages humains et
organisationnels
1. Services Nouvelle Projets d'expéri- Standards, Intégration des systèmes • Acquisition de XML, XSLT, WSDL,
initiaux fonctionnalité mentation R&D, existants compétences en SOAP, Java, .NET
Projets pilotes Site développement de
Web, Portail, service par les
Intégrations développeurs
personnalisées, • Sponsoring des
Nombre limité de développeurs
services
2. Services Réduction et Applications Support des systè-mes hétérogènes et • Groupe d'archi- UDDI,
d'architecture contrôle des coûts intégrées multiples distribués, Messagerie fiable, Médiation, tectures assurant WSReliableMessa
informatiques Facilité de déploie-ment, Intégration de le leadership du ging, WS-Policy,
bases de don-nées, Gestion des versions, centre de WSAddressing,
Sécurité interne, Gestion des compétences SOA XQuery, WS-
performances • Sponsoring des Security, SAML
directeurs
informatiques
3.a. Services Réactivité de Processus métier Réutilisation, Facilité de modification, • Collaboration WS-BPEL
métier l'activité: sur l'ensemble de Disponibilité, Règles de processus métier, informatique et
modification rapide l'entité ou de Processus pilotés par événement, commerciale sur
et efficace des l'entreprise Applications composites l'ensemble des
processus métier départements
3.b. Services Réactivité de Services Exécution des services externes, Sécurité • Gouvernance du RosettaNet, ebXML,
collaboratifs l'activité : accessibles aux inter-entreprises, Conversion des cycle de vie SOA WS-Trust
collaboration avec partenaires protocoles inter-entreprises, Transactions • Engagement de la
les partenaires externes, Inter- de longue durée direction
commerciaux et de entreprise • Gestion des flux
trading d’événements
• Sponsoring des
directeurs "
4. Services Transformation Entité ou entreprise, Pilotage BAM (Business Activity • Evaluation et
métier mesurés d'une activité Inter-entreprise Monitoring), Technologie ESP (Event réponse continues
réactive en activité Stream Processing), Technologie CEP des processus
temps réel, (Complex Event Processing), alertes et métier
Conformité aux tableaux pilotés par événements • Sponsoring des
mesures de directeurs
performance financiers "
5. Services Optimisation de Entité ou entreprise, Automatisation pilotée par événement • Politique
métier optimisés l'activité-réactivité Inter-entreprise d'amélioration
et réponse continue
automatiques Sponsoring des
PDG
10 Copyright ©2007. Progress Software Corporation. All rights reserved.Tableau 2 : Objectifs et pratiques du modèle de maturité SOA
Niveau de Objectifs Pratiques
maturité
1. Services 1. Intégrer la technologie SOA dans les 1. Créer des définitions de services.
initiaux projets R&D et pilotes. 2. Intégrer l'approche SOA dans la
2. Appliquer la technologie SOA aux méthodologie de développement de projet.
besoins organisationnels immédiats. 3. 3. Quantifier les coûts, le temps, et les
Définir des mesures de rentabilité ini-tiales avantages des projets pilotes.
pour les projets SOA et les appliquer aux
projets initiaux.
2. Services 1. Institutionnaliser l'utilisation de l'ar- 1. Spécifier les standards technologiques de
d'architecture chitecture SOA. l'architecture SOA.
2. Mettre en place un leadership d'ar- 2. Intégrer la technologie SOA dans le
chitecture pour la technologie SOA. processus de développement à l'échelle de
3. Démontrer les avantages de l'utilisa-tion l'entreprise.
de la technologie basée sur des standards. 3. Fournir un centre de compétences et une
formation SOA à l'échelle de l'entreprise.
4. Utiliser l'intégration incrémentielle.
3.a. Services 1. Créer un partenariat continu entre les 1. Spécifier les politiques d'utilisation de
métier organisations commerciales et tech- l'architecture SOA dans le cadre de la
nologiques pour la gouvernance SOA. création ou de la modification des
2. Supporter l'ensemble des processus processus métier.
métier via l'architecture SOA. 2. Tirer parti des fonctionnalités orientées
3. Démontrer les avantages de la événement et de médiation des technologies
réutilisation des services et la réactivité au SOA, tout particulièrement en ce qui
changement. concerne l'amélioration/l'extension des
processus métier.
3.b. Services 1. Créer un partenariat continu entre les 1. Spécifier les politiques d'utilisation de
collaboratifs organisations commerciales et tech- l'architecture SOA en collaboration avec les
nologiques pour la gouvernance SOA. partenaires commerciaux et de trading
2. Etendre les processus métier SOA aux 2. Mettre en oeuvre une sécurité inter-
organisations externes. entreprises.
3. Démontrer les avantages de l'utilisa-tion
des services de collaboration.
4. Services métier 1. Transformer les processus réactifs en 1. Collecter et analyser les mesures des
mesurés processus métier temps réel. performances temps réel orientées
2. Définir et respecter les mesures de processus métier.
performance orientées activité. 2. Mettre en oeuvre l'évaluation et la
reconfiguration des processus métier.
5. Services métier 1. Assurer le leadership à l'échelle de 1. Mettre en oeuvre des processus métier
optimisés l'entreprise pour l'activité et la de correction automatique.
gouvernance SOA.
2. Démontrer les avantages de
l'amélioration continue des technologies
SOA.
Copyright ©2007. Progress Software Corporation. All rights reserved. 113.1 MATURITÉ SOA NIVEAU 1–SERVICES INITIAUX
La maturité SOA niveau 1 correspond aux Services initiaux (voir Tableau 1 et Tableau 2).
Ceux-ci représentent la phase initiale d'apprentissage et de mise en place de l'adoption
de la technologie SOA. A cette phase, il s'agit généralement de répondre simultanément
à un besoin spécifique de mise en oeuvre des fonctionnalités, tout en testant des
technologies spécifiques et une approche de l'architecture SOA. Ce niveau de maturité
inclut également des activités R&D de test des technologies SOA en laboratoire.
Généralement, l'introduction de l'architecture SOA est pilotée par l'organisation chargée
du développement des applications, souvent dans le cadre d'un projet d'intégration. De
nouvelles compétences en développement sont acquises, et des tentatives de
quantification de la rentabilité sont effectuées.
C'est à ce niveau que les normes SOA de base développées par W3C6 sont introduites,
telles que XML pour la définition des formats de message, WSDL pour la définition des
interfaces des services, et SOAP pour l'appel des services.
6
World Wide Web Consortium, “Web Services Activity”, http://www.w3.org/2002/ws/.
12 Copyright ©2007. Progress Software Corporation. All rights reserved.La Figure 2 présente un exemple de projet initial qui consiste à lier directement le portail Web de l'équipe commerciale d'une entreprise, à un nouveau serveur d'applications mettant en oeuvre le service de prévision et de suivi des ventes, et à une application CRM existante dotée d'un adaptateur de services Web frontal. L'interface de services” (présentée dans cet exemple et les suivants) établit la liaison et la conversion nécessaires entre la mise en oeuvre de l'application et les protocoles de communication choisis. Les Interfaces de services peuvent être fournies par divers types de produits, tels qu'un serveur d'applications ou un adaptateur ESB comme décrit ci-après. Ce projet initial présente l'avantage de fournir les fonctionnalités requises tout en permettant l'acquisition de compétences dans le développement et le déploiement d'une application SOA de base. Une mise en oeuvre de ce type utiliserait le protocole SOAP entre le serveur de portail et les services de support, tout comme le service de prévision et de suivi des ventes pour obtenir des informations de l'application CRM. Copyright ©2007. Progress Software Corporation. All rights reserved. 13
Cependant, même une application initiale de base pourrait tirer parti de l'utilisation de
certains des composants d'infrastructure SOA supplémentaires. Au-delà de l'expérience
acquise par leur utilisation précoce, la raison la plus importante de l'introduction de ces
technologies dans les projets initiaux est la mise en place d'une technologie évolutive
permettant à l'architecture SOA d'englober davantage de fonctions, les bases
appropriées étant déjà en place. Par exemple, la Figure 3 présente ce même exemple
avec l'ajout :
> D'un bus ESB (Enterprise Service Bus) du type de celui développé par Sonic, qui
fournit un modèle d'interaction standard aux composants SOA incluant des services
Web et des bases de données relationnelles comme infrastructure distribuée, facile à
déployer et évolutive. Le bus ESB fournit un grand nombre d'adaptateurs permettant
aux services mis en oeuvre dans des technologies disparates d'échanger des
messages et, par exemple, à une application .NET de communiquer avec une
application J2EE au niveau services.
14 Copyright ©2007. Progress Software Corporation. All rights reserved.> D'un service de gestion du niveau de service du type de celui développé par
AmberPoint, qui assure la visibilité des mesures de niveau de service et des
performances des services Web.
> D'un registre de services du type de celui développé par Systinet, qui supporte le
standard UDDI. Celui-ci fournit une base centralisée de définitions de service sur
l'ensemble des projets initiaux, ainsi qu'un point unique de références pour les
développeurs.
3.2 MATURITÉ SOA NIVEAU 2–SERVICES D’ARCHITECTURE
La maturité SOA niveau 2 correspond aux Services d'architecture (voir Tableau 1 et
Tableau 2). C'est à ce niveau que sont définis les standards concernant la gouvernance
technique de la mise en oeuvre SOA, généralement sous la supervision de l'équipe
architecture. L'avantage essentiel de ce niveau est la réduction des coûts de
développement et de déploiement, via l'utilisation de composants et d'une infrastructure
SOA standards, par rapport à l'utilisation de technologies précédentes ou aux coûts
cumulés générés par plusieurs projets uniques spécifiques. Ces avantages sont encore
plus importants dans les environnements hétérogènes caractérisant la plupart des
entreprises.
Les technologies de mise en oeuvre des standards architecturaux sont définies en
fonction de l'expérience acquise et du feedback provenant des services initiaux au
niveau de maturité 1. Par exemple, des standards sont définis pour :
> Les protocoles SOA à utiliser, choisis parmi les standards du secteur, en particuliers
ceux de W3C, OASIS7 et WS-I8.
> Les plates-formes de mise en oeuvre à utiliser.
> Les politiques de réutilisation, conformité et sécurité.
> Le processus de révision technique pour la définition de nouveaux services et la
réutilisation des services existants.
7
OASIS, “OASIS Committees by Category: Web Services and SOA”, http://www.oasis-open.org/committees/tc_cat.php?cat=ws.
8
WS-I, Web Services Interoperability Organization, http://ws-i.org
Copyright ©2007. Progress Software Corporation. All rights reserved. 15La Figure 4 présente un exemple de déploiement SOA au niveau de maturité 2 pour un
service de trading financier. Le niveau 2 inclut l'utilisation des composants clés indiqués
précédemment à la Figure 3, dont la gestion du niveau de services et le bus ESB, ainsi
que les aspects supplémentaires indiqués dans cet exemple :
> Un référentiel des politiques et services tel que celui développé par Systinet, qui
étend le registre de services afin de fournir un référentiel de stockage et de support
des informations de gouvernance SOA, impliquant des politiques et des définitions de
service. L'utilisation d'un référentiel de ce type, associée au développement et au
support runtime, est indispensable pour les processus prenant en charge les services
d'architecture de niveau 2.
> Un service de gestion des exceptions tel que celui développé par AmberPoint, qui
fournit un mécanisme de détection, de diagnostic et de résolution automatique des
erreurs au niveau système et application.
> Un service de transformation de message permettant l'intégration de services
hétérogènes dans les formats ou contenus attendus. Cela s'effectue par l'appel de
transformations XLST appliquées à un message XML, et dans cet exemple sous forme
de fonction de “médiation” sous contrôle du bus ESB.
> Un service d'accès par authentification unique prenant en charge l'authentification et
l'autorisation des utilisateurs sur l'ensemble de l'entreprise. Ce type de service,
généralement assuré par un fournisseur, pourrait être basé sur le standard OASIS
SAML pour l'échange des informations d'authentification et d'autorisation.
16 Copyright ©2007. Progress Software Corporation. All rights reserved.Copyright ©2007. Progress Software Corporation. All rights reserved. 17
3.3 MATURITÉ SOA NIVEAU 3–SERVICES MÉTIER ET SERVICES
COLLABORATIFS
La maturité SOA niveau 3 concerne le partenariat entre les organisations technologiques
et commerciales, visant à assurer que l'utilisation de l'architecture SOA garantit la
réactivité de l'entreprise. La valeur ajoutée de la SOA réside dans la liaison entre les
processus métier et les processus numériques tel qu'indiqué dans la Figure 5.
La maturité SOA niveau 3 est définie par deux approches complémentaires permettant
d'atteindre ces objectifs: d'une part les services métier, ciblés sur l'amélioration des
processus internes, et d'autre part les services collaboratifs, ciblés sur l'amélioration
des processus collaboratifs avec les partenaires externes (voir Tableau 1 et Tableau 2).
Ces deux approches permettent certainement de tirer le meilleur parti de l'architecture
SOA, mais la maturité niveau 3 ne peut être atteinte qu'avec celle convenant le mieux à
l'entreprise concernée.
10
“The Big Strategic Impact Of Organic Business And Service-Oriented Architecture”, Forrester Research, Inc., June 2004.
18 Copyright ©2007. Progress Software Corporation. All rights reserved.La Figure 6 présente un exemple de déploiement SOA au niveau de maturité 3 pour l'exemple de trading financier. La mise en oeuvre des services métier repose sur: > Un système de gestion des processus métier (BPM, Business Process Management) impliquant la gestion des processus de longue durée, incluant des messages séquentiels entre les services. Il pourrait s'agir par exemple du serveur SOS (Sonic Orchestration Server) qui gère l'état de chaque processus ainsi que les résultats intermédiaires. Copyright ©2007. Progress Software Corporation. All rights reserved. 19
La Figure 7 présente l'évolution des services métier avec :
> Amélioration simple des processus métier. L'un des principaux avantages de
l'architecture SOA est sa capacité à modifier les processus métier via la
reconfiguration des services. Dans cet exemple, un nouveau service nécessaire pour
la conformité réglementaire est inséré dans le flux de messages entre le service de
gestion des ordres et le service de trading, sans qu'il soit nécessaire de modifier la
mise en oeuvre des services existants.
> Réutilisation des services. Dans cet exemple, la réutilisation est présentée dans le
cadre d'une application multicanaux (p.ex. permettre l'accès à la même application via
des méthodes de communication client différentes), dans laquelle le service de
gestion des ordres est partagé par le service centre d'appel et le service en ligne.
20 Copyright ©2007. Progress Software Corporation. All rights reserved.Au niveau de maturité 3, l'autre alternative concerne les services collaboratifs, qui se
concentrent sur la liaison avec les partenaires externes. La Figure 8 présente un exemple
où la société de trading a développé une nouvelle activité de transactions de change sur
Internet.
Les caractéristiques clés de cette mise en oeuvre des services collaboratifs sont les
suivantes:
> Utilisation de protocoles SOA standards prenant en charge la fonctionnalité B2B
(business-to-business) tels que ceux définis par RosettaNet10 , qui inclut des fonctions
de messagerie XML standards pour les opérations inter-entreprises, telles que
l'obtention d'informations sur les produits et les stocks, et la gestion des commandes.
> Serveur de collaboration tel que celui développé par Sonic, qui met en oeuvre des
protocoles B2B et assure les transformations nécessaires entre les messages internes
à l'entreprise et ceux requis pour les processus externes.
> La connexion ECN est passée d'un protocole propriétaire à un protocole de services
standard, et est donc gérée via le serveur de collaboration.
11
RosettaNet, ”Standards”, http://rosettanet.org/standards
Copyright ©2007. Progress Software Corporation. All rights reserved. 213.4 MATURITÉ SOA NIVEAU 4–SERVICES MÉTIER MESURÉS
Alors que la maturité SOA niveau 3 se concentre sur la mise en oeuvre des processus
métier internes et/ou externes, la maturité SOA niveau 4 se concentre sur la mesure et la
présentation de ces processus au niveau entreprise, afin de fournir un retour
d’informations continu sur les performances et l'impact des processus de niveau 3 (voir
Tableau 1 et Tableau 2).
La Figure 9 présente un exemple de processus de configuration, commande et
fabrication, les services de chaque fonction étant distribués sur l'ensemble des sites
géographiques. Les caractéristiques de cet exemple sont les suivantes:
> Traitement des flux d'événements en temps réel qui, dans cet exemple, collecte
l'ensemble des événements RFID dans une base de données et filtre les événements
significatifs pour l'entreprise, puis les transmet pour une utilisation dans d'autres
services. Comme expliqué dans The Power of Events11 et “Event Stream Processing -
A New Physics of Software”12, le traitement des flux d'événements et le “traitement
d'événements complexes” permet la transformation des processus métiers réactifs en
processus basés sur des informations en temps réel.
> Pilotage BAM (Business Activity Monitoring) qui fournit un feedback à la direction
concernant les mesures de performance en temps réel, présentées ici sous forme de,
ableau. Le service de gestion du niveau de service, tel que celui développé par
AmberPoint, assure ce type de surveillance pour les événements directement associés
l'infrastructure SOA. Dans d'autres scénarios, les événements générés par ce service
pourraient être traités et affichés par des services plus génériques.
12
Luckham, David, The Power of Events, Addison-Wesley, 2002.
13
Palmer, Mark, “Event Stream Processing - A New Physics of Software”, DM Direct Newsletter, July 29, 2005,
http://www.dmreview.com/editorial/newsletter_archive.cfm?nl=dmdirect&issueid=20226.
22 Copyright ©2007. Progress Software Corporation. All rights reserved.Copyright ©2007. Progress Software Corporation. All rights reserved. 23
3.5 MATURITÉ SOA NIVEAU 5–SERVICES MÉTIEROPTIMISÉS
La maturité SOA niveau 5 concerne les services métier optimisés, et fournit une réponse
automatique aux mesures et résultats du niveau 4. De cette manière, le système
d'informations SOA devient le “système nerveux de l'entreprise”, et réagit en fonction
des événements qui se produisent au niveau métier, conformément aux règles
d'optimisation des objectifs (voir Tableau 1 et Tableau 2).
La Figure 10 présente le processus de configuration, commande et fabrication amélioré,
dans le but de fournir une tarification dynamique en fonction du statut des matériaux et
des produits en cours de fabrication dans l'usine. Par exemple, si les pièces d'une
version spécifique d'un article sont en nombre limité, une promotion spéciale peut être
définie afin d'encourager les acheteurs à commander un article utilisant d'autres pièces.
Cet exemple est inspiré du succès de l'utilisation par Dell Corporation de la tarification
dynamique, ans laquelle la pénurie d'un disque d'une capacité donnée, par exemple,
entraîne la création dynamique d'une offre spéciale visant à encourager les acheteurs à
configurer leur ordinateur avec un disque de capacité supérieure.14, 15 L'utilisation de
composants SOA permet de faire évoluer et de mettre plus facilement en oeuvre une
approche de ce type, plutôt qu'en construisant des systèmes propriétaires.
14
Friedman, Thomas L., The World is Flat, Farrar, Straus and Giroux, 2005.
15
McWilliams, Gary, “Lean Machine: How Dell Fine-Tunes Its PC Pricing to Gain Edge in a Slow Market”, The Wall Street
Journal, June 8, 2001.
24 Copyright ©2007. Progress Software Corporation. All rights reserved.Copyright ©2007. Progress Software Corporation. All rights reserved. 25
4.0 CONCLUSION
Le modèle de maturité SOA fournit un cadre supportant à la fois la vision et l'évaluation
des avantages croissants de l'adoption de l'architecture SOA. Les niveaux et les
avantages clés sont les suivants :
La clé du succès de l'architecture SOA repose sur un partenariat évolutif entre les
organisations technologiques et commerciales. Ce partenariat est basé sur la capacité
de l'organisation technologique à prendre en charge l'activité, à la fois en répondant à la
concurrence et en mettant rapidement en oeuvre de nouveaux business models tels que
de nouveaux canaux de distribution, de nouveaux produits de services d'information et e
nouveaux modèles de tarification, afin d'amélioration la rentabilité et la satisfaction
client.
L'objectif de l'architecture SOA est de permettre cette souplesse d'une manière
novatrice et supérieure à celle proposée par les technologies précédentes: novatrice,
par l'utilisation des standards Web, la souplesse inhérente aux architectures SOA,
l'intégration des systèmes existants, et la disponibilité immédiate des services et de
l'infrastructure SOA. Finalement, le succès d'une société cherchant à atteindre un
niveau de maturité supérieur, dépendra de la méthodologie et de la rigueur, adoptées au
sein de l'entreprise ou mises en oeuvre par un intégrateur de systèmes.
26 Copyright ©2007. Progress Software Corporation. All rights reserved.Worldwide Headquarters
Progress Software Corporation,
14 Oak Park, Bedford, MA 01730 USA
Tel: +1 781 280-4000 Fax: +1 781 280-4095
www.progress.com
For regional international office locations and contact information, please refer to www.progress.com/worldwide
© Copyright 2007 Progress, DataXtend, Actional, Sonic ESB are registered trademarks of Progress Software
Corporation or one of its subsidiaries or affiliates in the US and other countries. Any other trademarks contained
herein are the property of their respective owners.
prod code 7630
0000113862Vous pouvez aussi lire
