Les principes de la conception SOA Pour Les Nuls, · licence de la marque Pour les Nuls, ... Le...

Les principes de la conception SOA

ÉDITION LIMITÉE IBM

Claus T. Jensen

Ces documents sont protégés par le copyright © 2014 John Wiley & Sons, Inc. Toute divulgation, toute distribution et tout usage non autorisés sont strictement interdits.

Les principes de la conception SOA pour les Nuls®, Édition limitée IBMPublié par John Wiley & Sons, Inc. 111 River St. Hoboken, NJ 07030-5774 www.wiley.com

Copyright © 2014 John Wiley & Sons, Inc., Hoboken, New Jersey

Publié par John Wiley & Sons, Inc., Hoboken, New Jersey

Aucun extrait de cette publication ne peut être reproduit, stocké dans un système d’extraction de données ou transmis, sous quelque forme ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement, numérisation ou autre), sauf aux conditions autorisées aux alinéas 107 et 108 de la loi américaine sur le droit d’auteur (Copyright Act) de 1976, sans l’autorisation écrite préalable de l’Éditeur. Les demandes d’autorisation doivent être adressées par courrier à Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030 USA, par téléphone au +1 (201) 748-6011, par télécopie au +1 (201) 748-6008, ou en ligne à l’adresse http://www.wiley.com/go/permissions.

Marques : Wiley, le logo Wiley, pour les Nuls, For Dummies, le logo Dummies Man, A Reference for the Rest of Us!, The Dummies Way, Dummies.com, Making Everything Easier et les appellations commerciales afférentes sont des marques ou des marques déposées de John Wiley & Sons, Inc. et/ou de ses filiales aux États-Unis et/ou dans d’autres pays, et leur utilisation est interdite sans autorisation écrite. IBM et le logo IBM sont des marques déposées d’IBM. Toutes les autres marques citées sont la propriété de leurs détenteurs respectifs. John Wiley & Sons, Inc., n’est lié à aucun des produits ou fournisseurs cités dans cet ouvrage.

LIMITATION DE RESPONSABILITE/EXCLUSION DE GARANTIE : L’EDITEUR ET L’AUTEUR S’ABS-TIENNENT DE TOUTE DECLARATION OU GARANTIE CONCERNANT L’EXACTITUDE OU L’EX-HAUSTIVITE DU CONTENU DE CET OUVRAGE, ET EXCLUENT EN PARTICULIER TOUTE GARAN-TIE, Y COMPRIS, NON LIMITATIVEMENT, LA GARANTIE D’ADEQUATION AVEC UN USAGE PAR-TICULIER. AUCUNE GARANTIE NE PEUT ETRE CONSENTIE OU ETENDUE AU TITRE D’UN DOCU-MENT COMMERCIAL OU PROMOTIONNEL. LES CONSEILS ET LES STRATEGIES PRESENTES ICI RISQUENT DE NE PAS CONVENIR A TOUTES LES SITUATIONS. CET OUVRAGE EST COMMERCIA-LISE, SACHANT QUE L’EDITEUR NE DISPENSE AUCUN SERVICE JURIDIQUE, COMPTABLE OU PROFESSIONNEL. SI UNE ASSISTANCE PROFESSIONNELLE EST REQUISE, LES SERVICES D’UN PROFESSIONNEL COMPETENT DEVRONT ETRE SOLLICITES. NI L’EDITEUR, NI L’AUTEUR NE POURRONT ETRE TENUS RESPONSABLES DES DOMMAGES DECOULANT DES PRESENTES. LE FAIT QU’IL SOIT FAIT REFERENCE, DANS CET OUVRAGE, A UN ETABLISSEMENT OU A UN SITE WEB DANS UNE CITATION ET/OU A TITRE DE SOURCE POTENTIELLE D’INFORMATIONS COM-PLEMENTAIRES NE SIGNIFIE EN AUCUN CAS QUE L’AUTEUR OU L’EDITEUR APPROUVE LES INFORMATIONS SUSCEPTIBLES D’ETRE COMMUNIQUEES PAR CET ETABLISSEMENT OU CE SITE WEB OU SES RECOMMANDATIONS. EN OUTRE, LE LECTEUR EST INFORME QUE LES SITES WEB CITES DANS CET OUVRAGE PEUVENT AVOIR EVOLUE OU DISPARU ENTRE LE MOMENT OU CE LIVRE A ETE ECRIT ET CELUI OU IL EST LU.

Pour toute information d’ordre général sur nos autres produits et services, ou pour obtenir les informations nécessaires pour créer un ouvrage personnalisé pour votre entreprise ou votre organi-sation, veuillez contacter notre service de développement commercial aux États-Unis par téléphone au 877-409-4177, adresser un courrier électronique à l’adresse [email protected], ou visiter le site www.wiley.com/go/custompub. Pour de plus amples informations sur l’exploitation sous licence de la marque Pour les Nuls, contactez BrandedRights&[email protected].

ISBN 978-1-119-02355-5 (pbk); ISBN 978-1-119-02356-2 (ebk)

Produit aux États-Unis

10 9 8 7 6 5 4 3 2 1


http://www.wiley.com

SommaireIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

À propos de cet ouvrage ......................................................................1Comment ce livre est organisé ............................................................1Les icônes utilisées dans ce livre ........................................................2

Chapitre 1 : Concevoir le futur avec SOA . . . . . . . . . . . . . . . . . . 3Savoir d’où vient l’architecture SOA — et où elle va......................3

Le passé : les environnements contrôlés ..............................4Le présent : la fin du contrôle

centralisé de l’informatique .................................................4Rendre les entreprises ouvertes .............................................5

Connaître les trois aspects fondamentaux de l’architecture SOA ............................................8

Chapitre 2 : Les éléments d’une bonne conception SOA . . .11L’essentiel sur l’orientation services ...............................................12L’intégrité des processus à l’échelle de l’Internet .........................13L’intégration avec les capacités

de l’entreprise et les systèmes centraux ....................................14Arbitrage et intégration avec un ESB ...................................15Intégration en périphérie ........................................................15

L’assise des standards de l’industrie ...............................................16Exploiter et étendre les technologies open source ......................17Mettre en œuvre une plateforme

pour un écosystème dynamique ..................................................18

Chapitre 3 : Intégrer la mobilité avec l’architecture SOA . .19L’importance de la mobilité ...............................................................19Les éléments fondamentaux d’une architecture SOA Mobile ....21

Les API ........................................................................................21Applications ...............................................................................23Apps Stores ................................................................................24

Chapitre 4 : Mettre en œuvre les réseaux sociaux avec l’architecture SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Interagir avec les médias sociaux .....................................................27Relier les personnes et les connaissances .....................................29


Les principes de la conception SOA pour les NULS, Édition limitée IBM iv

Chapitre 5 : Avoir la tête dans le Cloud avec l’architecture SOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Introduire le Cloud dans les affaires ................................................32Effectuer la transition vers le Cloud computing ............................32

Chapitre 6 : Extraire les connaissances enfouies dans le Big Data grâce à l’architecture SOA . . . . . . . . . . .35

Exploiter les flux de données existants ...........................................35Exploiter les données ..............................................................36Prédire l’avenir ..........................................................................37

Utiliser les données issues de sources hétérogènes ....................38Produire des connaissances métier .................................................39


RemerciementsNous sommes fiers d’avoir réalisé cet ouvrage et de tous ceux qui y ont collaboré. Pour de plus amples détails sur la démarche nécessaire pour créer un ouvrage personnalisé pour votre entreprise ou votre organisation, envoyez un courrier électronique à l’adresse [email protected] ou visitez le site www.wiley.com/go/custompub. Pour de plus amples informations sur l’exploitation sous licence de la marque Pour les nuls avec des produits ou services, contactez BrandedRights&[email protected]. Parmi ceux qui ont participé à la création et à la commercialisation de cet ouvrage, figurent les personnes suivantes :

Acquisitions, éditorial et sites web spécialisésÉditrice de projet : Carrie A. BurchfieldResponsable éditorial : Rev MengleReprésentante du développement

commercial : Sue BlessingSpécialiste de projet d’édition spécifique :

Michael Sullivan

Services de compositionCoordinatrice de projet : Kristie ReesMise en page et infographie : Carl ByersCorrectrice : Debbye Butler

Publication et rédaction pour les ouvrages technologiques de la série Pour les NULS

Richard Swadley, vice-président et éditeur en chef du groupeAndy Cummings, vice-président et éditeurMary Bednarek, directrice exécutive, AcquisitionsMary C. Corder, directrice éditoriale

Publication et rédaction pour les ouvrages grand public de la série Pour les NULS

Kathleen Nebenhaus, vice-présidente et éditriceServices de composition

Debbie Stailey, directrice des services de compositionDéveloppement commercial

Lisa Coleman, directrice, nouveaux marchés et développement de la marqueRemerciements à IBM

L’assistance concernant le marketing et la communication ont été assurés par le personnel d’IBM et Robert Sawyer, responsable marketing produit.


Introduction

A ujourd’hui, la plupart d’entre nous considérons les commu-nications mobiles, le Social business, le Cloud computing

et le Big Data comme une « innovation tendance ». Cependant, ces « innovations tendance » ne tombent pas du ciel. Comme toutes les initiatives nouvelles et réussies, elles se fondent sur des processus d’ingénierie et des principes de conception éprouvés, ce qui nous amène à l’architecture orientée services, ou SOA.

La notion de SOA de base, ou SOA centré sur l’informatique, repose sur l’application des principes SOA pour l’intégration flexible du parc informatique d’une entreprise. Mais contrôler les interactions au travers de services et d’interfaces parfaitement définis s’applique à l’évidence aussi aux environnements mobiles, de réseaux sociaux, de Cloud et de Big Data. L’approche SOA est tout simplement une bonne méthode d’intégration de l’informatique et des solutions métier dans un monde de plus en plus connecté et distribué.

À propos de cet ouvrageJe suis persuadé de la puissance d’une bonne méthode de concep-tion SOA et de la nécessité de mettre en œuvre des solutions inédites sur des bases méthodologiques stables et éprouvées. Cet ouvrage est destiné à vous guider dans l’application des principes de conception d’une architecture SOA pour résoudre les problèmes métier d’aujourd’hui, bien au-delà des problématiques informatiques d’hier. Vous y découvrirez comment utiliser la démarche orientée services et l’intégration à base de standards pour assurer l’intégrité des processus et la gestion des connaissances métier à l’échelle du réseau Internet.

Comment ce livre est organiséVous pouvez lire cet ouvrage d’un bout à l’autre, ou si vous préférez, commencer par un sujet qui vous intéresse particulièrement. Voici les domaines abordés dans chacun des chapitres :


Les principes de la conception SOA pour les NULS, Édition limitée IBM 2 ✓Le chapitre 1, « Concevoir le futur avec SOA », décrit

succinctement comment la démarche SOA était utilisée dans le passé, et ce qu’apportent les nouvelles approches.

✓Le chapitre 2, « Les éléments d’une bonne conception SOA », présente les principes de conception SOA.

✓Le chapitre 3, « Intégrer la mobilité avec l’architecture SOA », est le premier des quatre chapitres consacrés aux nouvelles utilisations de SOA dans l’entreprise.

✓Le chapitre 4, « Mettre en œuvre les réseaux sociaux avec l’architecture SOA », vous permet de découvrir comment appliquer SOA au contexte Social business.

✓Le chapitre 5, « Accéder au Cloud avec l’architecture SOA », décrit l’application des principes de conception SOA au Cloud computing.

✓Le chapitre 6, « Extraire les connaissances enfouies dans le Big data grâce à l’architecture SOA », décrit comment générer des connaissances métier en puisant dans le flux d’interactions circulant dans votre entreprise.

Les icônes utilisées dans ce livreCe livre utilise les icônes suivantes pour attirer votre attention sur les informations que vous pouvez trouver utiles :

Cette icône indique les suggestions qui vous seront utiles dans votre propre démarche.

Cette icône vous signale les concepts importants à retenir.

Cette icône signale les endroits où des sujets techniques sont évoqués en détail. Vous pouvez donc les ignorer si vous voulez.

Accordez une attention particulière aux paragraphes signalés par cette icône. Elle met en valeur des informations que vous devez connaître pour des raisons juridiques, entre autres.


Chapitre 1

Concevoir le futur avec SOA

Dans ce chapitre▶Découvrir la démarche du passé, centrée sur l’informatique▶Comprendre le futur, centré sur les activités métier, avec SOA▶Définir une entreprise ouverte▶Découvrir trois aspects de SOA

N ombre d’éminents spécialistes de l’industrie considèrent l’architecture orientée services (SOA) comme sans intérêt

simplement parce qu’elle s’est banalisée. Mais la vérité est que SOA s’est répandu parce qu’il permet d’appliquer ses capacités à de nouveaux défis essentiels pour l’entreprise. Dans les faits, les démarches nouvelles concernant l’entreprise et les technologies de l’information - communications mobiles, Social business, Cloud computing, Big Data - nécessitent une intégration accrue (et plus complexe que jamais).

Savoir d’où vient l’architecture SOA — et où elle va

Dans cette partie, je vous propose de découvrir d’où vient l’approche SOA pour savoir où la démarche nous mène.


Les principes de la conception SOA pour les NULS, Édition limitée IBM 4

Le passé : les environnements contrôlésHistoriquement (avec ou sans SOA), les départements informa-tiques se sont organisés pour contrôler l’intégration en mettant en œuvre un environnement de développement géré et en déployant des solutions utilisant des middleware et des moteurs d’exécution approuvés. Les principes de conception SOA ont été principalement appliqués pour assurer une intégration flexible de l’ensemble de l’informatique de l’entreprise, dans un environnement étroitement contrôlé.

Le problème aujourd’hui est que cette approche ne fonctionne plus.

Le présent : la fin du contrôle centralisé de l’informatiqueAujourd’hui, les développeurs (sauf s’ils en sont empêchés) téléchargent et utilisent des bibliothèques ou des outils open source recommandés par leurs pairs sur les réseaux sociaux. Fondamentalement, l’informatique centralisée n’a plus aucun contrôle sur l’environnement de développement et d’exécution. En voici quelques exemples :

✓Les entreprises externalisent la création d’applications mobiles auprès d’agences.

✓Les partenaires assurent de plus en plus le fonctionnement de l’informatique centrale pour les opérations métier.

✓Les adolescents souhaitent construire leurs propres applications mashup sur leurs téléphones mobiles.

✓Les entreprises souhaitent vendre de l’information et des données sous la forme de prestations banalisées et commercialisables.

La figure 1-1 illustre ce fait : n’importe lequel d’entre nous peut être considéré comme un développeur ; les applications fonctionnent sur tous les appareils possibles, depuis les téléphones mobiles jusqu’aux réfrigérateurs; les transactions ont lieu partout et à tout moment, et il est impossible de prédire qui est susceptible d’influen-cer votre activité ou d’accéder aux informations que vous proposez.

Faute d’un environnement informatique contrôlé et centralisé, il est nécessaire d’aller au-delà de l’application exclusive de SOA aux problèmes informatiques. Le simple fait que le monde ait changé ne signifie pas que vous deviez rester inactif et vous lamenter. Ces changements constituent une opportunité d’agir dans un


Chapitre 1: Concevoir le futur avec SOA 5contexte à la fois plus étendu et important, ce que nous verrons dans la partie suivante.

Qu'est-ce qu'une application ?

Tout

Qui peut accéder à vos informations ?

Tout le mondeQui influe sur votre activité ?

N'importe qui

Qui sont les développeurs ?

N'importe qui

Où les transactions ont-elles lieu ?

Partout

Figure 1-1 : Le développement et le contrôle ne concernent plus seulement les départements informatiques.

Rendre les entreprises ouvertesSOA n’a pas été exclusivement conçu pour assurer l’intégration des applications dans l’entreprise. Mais contrôler les interactions au travers de services et d’interfaces parfaitement définis s’applique à l’évidence aussi aux environnements mobiles, de réseaux sociaux, de Cloud et de Big Data — même, ou peut-être en particulier, dans un environnement dans lequel ni le développement ni les opérations ne sont contrôlés totalement par l’entreprise. Il est préférable d’exploiter la puissance et l’intérêt des bonnes méthodes de conception SOA pour des problèmes métier plus larges et complexes. (Ces méthodes sont abordées en détail au chapitre 2.)

Évoluer vers une organisation ouverte est l’une des priorités absolues de la plupart des entreprises aujourd’hui. Ce qui distingue


Les principes de la conception SOA pour les NULS, Édition limitée IBM 6une entreprise ouverte des autres, c’est d’avoir su opérer une métamorphose pour passer d’un modèle centré sur les transactions à un autre, axé sur les interactions (voir Figure 1-2).

Cloud public

Entrepriseouverte

Données desréseaux sociaux

et Internet

Communautés dedéveloppeurset de clients

Communautésde partenaires commerciaux

Internetdes objets

TPV mobiles,distributeurs

de billets

Big Data

.NET

DBPattern

Pattern

DBDB

.JCAPsDMZ DMZ

SAP

ODM

MDM

BPM

WASWAS

BPM

ODM

360°Cloudprivé

Figure 1-2 : Une entreprise ouverte est centrée sur les interactions.

Dans une entreprise centrée sur les interactions,

✓Deux participants, voire plus, au sein d’un réseau d’entreprise mettent en œuvre des interactions métier offrant un intérêt pour l’entreprise en utilisant des systèmes qui ne sont pas tota-lement sous son contrôle. Le plus souvent, l’interaction n’est pas définie à l’avance ; elle se produit au moment voulu.

✓Les participants à ces interactions sont constitués des sys-tèmes informatiques, des équipements et des personnes, qui peuvent être en interaction à l’intérieur de l’entreprise ou à dis-tance (via les appareils mobiles ou dans le Cloud). Souvent, les participants interagissent simultanément sur différents canaux.

✓La plupart des interactions ne sont pas, par nature, transactionnelles et ne s’accompagnent d’aucun contrat ou engagement.

✓Enfin, l’entreprise elle-même n’a pas à prendre part aux interac-tions métier. Elle peut avoir besoin de savoir et de comprendre ce qui se dit sur elle sur les médias sociaux, par exemple, mais cela ne fait pas d’elle un participant à ces interactions — elle sera au plus un observateur intéressé.


Chapitre 1: Concevoir le futur avec SOA 7

Mettre en évidence (et saisir) les opportunitésDevenir une entreprise ouverte ne se limite pas à innover en interne avec des développeurs. Vous devez trouver les approches nécessaires pour tirer parti des innovations existantes dans les communautés extérieures — des communautés que vous ne contrôlez pas, mais sur lesquelles vous avez tout au plus une influence. Votre objectif est de jouer le rôle d’intermédiaire entre des participants liés par des relations libres, d’assurer la transparence en termes de localisation et de temps, et de transformer les interactions spontanées en conversations structurées et en connaissances métier, ce qui vous permettra de développer l’évolution dynamique de transactions intelligentes.

Concrètement, vous pouvez favoriser l’ouverture au sein de votre entreprise en appliquant le modèle SOA le plus élémentaire, que j’aborde dans la section suivante.

Maîtriser l’Enterprise Service Bus (ESB)Le modèle Enterprise Service Bus (ESB) (voir Figure 1-3) constitue la fondation des systèmes à base de SOA, dont la nature est d’établir des relations libres. La médiation est une approche essentielle dans le cadre de ce modèle.

Partenaires

Clients

Fournisseurs

Modèles

ServicesCloud

Applications

API

Développeurs

Figure 1-3 : Le modèle ESB assure la médiation entre les consommateurs et les fournisseurs.

La plupart des personnes concernées gardent à l’esprit les notions de consommateur et de fournisseur de ce modèle, mais omettent souvent la démarche de médiation qui permet de les mettre en relation. Dans le contexte d’une entreprise ouverte, toutefois, la médiation est sans doute l’élément le plus important.


Les principes de la conception SOA pour les NULS, Édition limitée IBM 8De manière classique, les ESB disposent de formats et de protocoles de message et d’autres caractéristiques informatiques utilisées dans le contexte des transactions informatiques. Dans une entreprise ouverte, toutefois, la médiation se fonde sur les notions de com-pétence, de disponibilité et de localisation. Une entreprise ouverte relie et met en communication des personnes, des équipements, des environnements Cloud, etc., et se fonde sur le modèle ESB.

Connaître les trois aspects fonda-mentaux de l’architecture SOA

Selon votre point de vue, vous serez peut-être intéressés par les services, qui constituent une partie des solutions SOA ; vous pouvez également être intéressés par l’architecture de ces services et la manière dont ils interagissent avec les processus métier qui les utilisent ; mais vous pouvez également être intéressés par une approche orientée services dans la façon dont vous envisagez votre activité. Les trois aspects fondamentaux présentés ici sont caracté-ristiques de SOA :

✓Service : Tâche métier récurrente (par exemple la vérification d’un crédit client ou l’ouverture d’un nouveau compte).

✓Orientation service : Représentation de votre activité au moyen de services liés et des résultats qu’ils produisent.

✓SOA : Approche architecturale centrée sur l’activité, basée sur des principes d’orientation services.

De manière classique, certaines méthodes de conception ont été associées avec SOA :

✓Contrats de services standardisés,

✓Couplage libre,

✓Abstraction de services,

✓Réutilisabilité des services,

✓Autonomie des services,

✓Indépendance des origines des services,

✓Capacité d’inventaire des services,

✓Capacité de composition en modules des services.


Chapitre 1: Concevoir le futur avec SOA 9Ces principes permettent d’englober largement les caractéristiques des services plutôt que celles des systèmes étendus associés à ces services. Les méthodes de conception des services restent importantes, mais vous devez également considérer les aspects conceptuels des systèmes décrits au chapitre 2.


Chapitre 2

Les éléments d’une bonne conception SOA

Dans ce chapitre, il sera question de :▶Reconnaître une bonne méthode de conception▶Découvrir les méthodes de conception SOA

E n quoi une entreprise ouverte est-elle satisfaisante, et quelles sont les méthodes de conception qui vous permettent d’y

parvenir ? Même si le modèle de référence IBM SOA (voir Figure 2-1) indique les composants technologiques nécessaires pour constru-ire, exécuter et gérer des solutions SOA, ils ne vous aident en rien à créer de bonnes solutions métier. Pour y parvenir, il faut bien sûr d’abord commencer par réfléchir en termes de services. Cependant, une démarche orientée services ne suffit pas. Il faut également une bonne conception SOA, comme le décrit ce chapitre.

Servicesd'interaction

Servicesde processus

Servicesd'information

Servicesdes partenaires

Services desapplications

métier

Servicesd'accès

Services de stratégie et de planification

Services d'infrastructure

Services de cycle de vie

Services des actifs et des registres

Enterprise Service Bus

Services et événements métier

Services dedéveloppement

Servicesde gestion

Figure 2-1 : Le modèle de référence IBM SOA définit une bonne plateforme SOA.


Les principes de la conception SOA pour les NULS, Édition limitée IBM 12Du point de vue de la démarche d’une entreprise ouverte (voir Chapitre 1), l’essentiel pour vous est probablement de développer et de contrôler les interactions métier importantes pour l’entreprise. Dans ce contexte, considérer SOA comme une bonne méthode de conception revient à affirmer que votre entreprise l’utilise comme fondation dans ses activités en concevant des solutions intégrant les systèmes d’ouverture avec les systèmes d’information.

Les bonnes méthodes de conception SOA constituent un outil d’accompagnement contribuant à l’avènement d’une entreprise ouverte. Ces principes sont les suivants :

✓L’orientation services au cœur de la démarche.

✓L’intégrité des processus à l’échelle du réseau Internet.

✓L’intégration avec les capacités de l’entreprise et les systèmes centraux.

✓L’assise des standards de l’industrie.

✓L’exploitation et l’extension des technologies open source.

✓La mise en œuvre d’une plateforme pour un écosystème évolutif.

Dans ce chapitre, je vous propose d’examiner de manière plus détaillée ces principes et de découvrir comment les appliquer à une entreprise ouverte.

L’essentiel sur l’orientation servicesL’orientation services n’est pas une affaire de technologie ; il s’agit davantage d’un état d’esprit destiné à orienter la réflexion concernant votre entreprise et son environnement, en termes de composants fonctionnels. Réfléchir en termes de services et de pro-cessus permet de dépasser la notion de canal ou de division opéra-tionnelle particulière et d’aborder la question sous l’angle d’une architecture de médiation uniforme, capable de relier l’essentiel des parties prenantes à l’intérieur comme à l’extérieur de l’entreprise.

Puisque vous ne pouvez contrôler totalement l’environnement de développement ou d’exécution (sujet que nous avons abordé au chapitre 1), la meilleure solution consiste à contrôler les interfaces entre les systèmes d’ouverture et les capacités essentielles de votre entreprise.

La démarche orientée services concerne tout simplement la mise en œuvre d’interfaces parfaitement définies (les services), assorties d’une sémantique métier précise et de politiques de sécurité et de traitement appliquées au moment de l’exécution.


Chapitre 2 : Les éléments d’une bonne conception SOA 13

Baptiser ces interfaces services ou API métier dépend essentielle-ment du contexte et du public concerné ; les deux concepts sont dérivés des principes de l’orientation services.

L’intégrité des processus à l’échelle de l’Internet

Vous êtes-vous déjà trouvé dans l’une de ces situations ?

✓Vous appelez un service public local pour résoudre un pro-blème. Le répondeur vocal de cet organisme vous pose dif-férentes questions avant de vous mettre en contact avec une personne — et la première chose que fait cette personne est de vous poser les mêmes questions.

✓Vous vous trouvez devant un comptoir d’enregistrement d’aéroport et vous découvrez que la compagnie a oublié de vous informer de l’annulation de votre vol.

✓Vous n’avez pas reçu un article commandé par e-mail, car un interlocuteur, chez le fournisseur, a oublié de saisir votre com-mande dans le système de gestion des commandes.

Rien n’est plus agaçant que de découvrir qu’une entreprise a oublié les interactions qu’elle a eues avec vous ou n’a pas réussi à tenir ses engagements. L’intégrité — quel que soit le cas — est très impor-tante pour vos clients, et d’elle découle la perception qu’ils ont de votre entreprise.

Les processus métier sont omniprésents — non seulement sous la forme de flux automatisés de processus, mais également dans toutes les séquences structurées d’interactions métier, qui font partie intégrante du réseau opérationnel de l’entreprise. Toutefois, il est difficile d’assurer une exécution parfaite des processus vitaux pour l’entreprise. En effet, l’intégrité des processus s’appuie sur trois élé-ments principaux :

✓Intégrité des transactions : Permet de s’assurer que les mises à jour spécifiques de ressources métier et informatiques sont liées et traitées sous la forme d’une unité de travail unique, et que toutes les opérations ont été soit effectuées en totalité, soit annulées.

✓Intégrité des interactions : Permet de s’assurer que les conte-nus des interactions des personnes avec les systèmes métier et informatiques sont intacts et mémorisés, quels que soient le lieu et le moment où ces interactions ont lieu.


Les principes de la conception SOA pour les NULS, Édition limitée IBM 14 ✓Intégrité des informations : Facilite l’acheminement

d’informations fiables et sécurisées vers les processus métier, indépendamment du canal d’acheminement, de la plateforme opérationnelle (informatique ou personne), et l’origine de l’information.

Chacun des éléments est activé par une infrastructure SOA robuste.

De manière classique, la notion d’intégrité des transactions a été limitée à un conteneur exécutable unique et à une plage de temps mesurée en microseconde. L’avènement des applications BPM (ges-tion des processus métier) a étendu la notion de traitement des transactions à des processus métier horizontaux. Une entreprise ouverte a donc besoin d’assurer l’intégrité de ces processus à l’échelle du réseau Internet.

La notion d’échelle concernant le réseau Internet va bien au-delà des questions de variations erratiques des volumes de transactions ; elle concerne aussi (voire même davantage) l’extension de l’intégrité aux notions de temps, d’espace, de localisation et de canaux. L’intégrité des processus à l’échelle du réseau Internet nécessite donc une transition entre des principes transactionnels centrés sur les bases de données (par exemple, une validation en deux phases) et des modèles de transaction impliquant des couplages plus libres, assor-tis de processus de compensation et de reprise, mieux adaptés à des interactions métier de long terme ou asynchrones.

Dans une entreprise ouverte, les processus métier ne sont pas limi-tés aux activités internes. La capacité à effectuer des changements et à intégrer ces changements aussi bien à l’intérieur qu’à l’extérieur de l’entreprise est essentielle pour l’efficacité de la démarche.

L’intégration avec les capacités de l’entreprise et les systèmes centraux

Le service de banque en ligne accessible sur votre mobile montre-t-il un solde de compte différent de celui qui vous est proposé sur un distributeur de billets ? Vous êtes-vous trouvé dans une situation où vous ne pouviez pas effectuer une transaction en ligne en étant ren-voyé à une page vous indiquant de contacter quelqu’un par fax ou par téléphone ? Ces scénarios (parmi d’autres) montrent l’absence d’intégration entre les systèmes d’ouverture de l’entreprise et ses systèmes d’information.


Chapitre 2 : Les éléments d’une bonne conception SOA 15

Arbitrage et intégration avec un ESBL’intégration avec les systèmes centraux transactionnels de l’entreprise est très importante pour les développeurs qui sou-haitent intégrer de nouveaux modèles métier et des écosystèmes étendus. Le modèle de base de l’ESB constitue une excellente base pour assurer un couplage libre des participants externes et internes. Comme indiqué au chapitre 1, la partie médiation du modèle ESB est souvent sous-estimée et sous-évaluée, bien qu’elle soit néces-saire pour interfacer les API métier externes et les services internes sans exiger de nouvelles programmations ou d’extension des pro-grammes centraux transactionnels existants.

Pour en savoir plus sur le bus ESB, revenez au chapitre 1.

Intégration en périphérieJe serais tenté de dire la chose suivante : « Il est bien sûr nécessaire d’assurer l’intégration des services avec le système central. Sinon, à quoi servent les services ? » Mais savez-vous exactement ce qui doit être intégré et comment contrôler cette intégration alors que vous ne maîtrisez pas le développement de l’utilisateur du service ? Dans l’univers d’une entreprise ouverte (voir Figure 2-2), le point de passage n’est pas un framework d’interface utilisateur, mais une passerelle périphérique — c’est-à-dire un point à la périphérie de l’entreprise où les éléments non contrôlés sont au contact de ceux partiellement contrôlés.

Cloud privé

Cloud public

Enterprise

Communauté de partenairesPasserelle périphériqueCapteurs

Équipements mobiles

Internet

Figure 2-2 : S’ouvrir sur le monde grâce à une passerelle périphérique.

La notion d’utilisation d’une passerelle périphérique pour contrôler le périmètre de l’entreprise n’est en rien nouvelle en termes de sécu-rité et de contrôle d’accès. Mais dans une entreprise ouverte, une passerelle périphérique doit aller bien au-delà :


Les principes de la conception SOA pour les NULS, Édition limitée IBM 16 ✓Les traitements doivent être contrôlés à la périphérie.

Ce contrôle doit inclure la surveillance et l’application des contrats de niveau de service (SLA) avec les partenaires et les consommateurs.

✓La notion de comptabilité périphérique est nouvelle. Il est non seulement nécessaire d’appliquer les contrats de niveau de service, mais également dans de nombreux cas, les consommateurs d’un service ou API doivent payer pour cette utilisation dans le cadre d’un business model indirect.

✓L’analyse des transactions périphériques est importante. Une entreprise ouverte doit comprendre, analyser et appren-dre de la totalité de ses interactions métier, dont la plupart ne sont visibles qu’à la périphérie, étant donné qu’appliquer des changements intrusifs dans tous les systèmes centraux est rarement possible.

L’assise des standards de l’industrieVous auriez peut-être souhaité utiliser votre modèle de proces-sus avec un nouvel outil convivial, mais vous avez constaté l’impossibilité de le faire. Peut-être aussi espériez-vous créer un « mashup » avec un autre service, pour vous apercevoir finalement que cet autre service n’était pas compatible « REST ». Peut-être aussi avez-vous été gêné que votre système tiers à base d’événements ne s’intègre pas avec votre ESB. Pour résumer, vous avez connu la déception provoquée par l’incompatibilité de votre application avec les standards de l’industrie.

Bien entendu, les entreprises ont, depuis des décennies, mis en place leurs propres standards d’intégration des applications. Cependant, avec SOA, un standard d’entreprise ne suffit pas : l’intégration à l’échelle d’une entreprise ouverte doit être basée sur des standards de l’industrie.

Le besoin en standards de l’industrie est évident. Lorsque vous ne contrôlez pas certains éléments d’un environnement, vous ne pouvez pas exiger que les autres suivent des standards d’entreprise exclusifs. Vous ne pouvez pas imposer vos règles au monde entier — pas plus que quiconque. Plus les relations et les interactions sont variées, plus elles introduisent des structures d’influence variables.

Cependant, quelles sont les fonctionnalités pour lesquelles la stan-dardisation est essentielle ? En voici quelques-unes :

✓Styles des interactions : Il est nécessaire de pouvoir gérer dif-férents styles d’interaction. Certains utilisateurs ont associé


Chapitre 2 : Les éléments d’une bonne conception SOA 17très étroitement SOA avec les standards WS*, mais tous les ser-vices ne sont pas des services web. Concrètement, une entre-prise ouverte doit pouvoir gérer toutes les interactions à base de messages, d’interfaces, de ressources (par exemple REST) et d’événements.

✓Capacités de traitement en périphérie : Des standards fiables sont nécessaires pour les politiques, la comptabilisation et toutes les fonctionnalités nécessaires dans les traitements péri-phériques (voir « Intégration à la périphérie » plus haut dans ce chapitre).

✓Collecte et traitement des informations : La standardisation est nécessaire pour spécifier comment collecter et traiter les informations concernant les interactions métier lorsque vous cherchez à obtenir des connaissances.

✓Standards spécifiques à chaque canal : Enfin, des stan-dards sont nécessaires pour chaque canal. À ce titre, il suffit d’observer les équipements mobiles et le réseau Internet où différents opérateurs et fabricants participent et interagissent sur un même réseau.

Exploiter et étendre les technologies open source

N’importe quel directeur de systèmes d’information vous dira que les technologies open source sont au cœur de l’évolution straté-gique des outils et du middleware. Bien qu’elle ne soit pas toujours au même niveau que les capacités offertes par les fournisseurs, la technologie open source est souvent adaptée pour les éléments les plus standardisés d’une infrastructure informatique. En outre, dans le contexte d’une entreprise ouverte, les applications peuvent être créées par des tiers (par exemple, les clients et les partenaires) qui utilisent pour ce faire la technologie open source.

La technologie open source est durable. Vous ne pouvez pas la limiter ou la contraindre à un environnement distinct et isolé ; bien au contraire, vous devez vous y engager et la développer. Vous ne pouvez pas éviter que les développeurs alternatifs (ces personnes plus ou moins autodidactes, ayant grandi avec l’Internet et con-nectées en permanence à leurs réseaux, etc.) ne téléchargent des bibliothèques ou des outils open source à leur goût ou recomman-dés par des collègues. Il est donc préférable de mettre en place des infrastructures pour déployer et gérer leurs solutions. Définissez des standards qui permettront de détecter ce qui se passe dans


Les principes de la conception SOA pour les NULS, Édition limitée IBM 18l’environnement d’exploitation et d’y réagir. Faites valoir la néces-sité de disposer de connaissances consolidées avec le soutien de l’entreprise.

S’il est facile de créer des solutions, il est plus difficile de gérer ce que vous avez créé. Comprendre ce phénomène et envisager active-ment de vous ouvrir aux communautés de développeurs facilitera votre démarche.

Mettre en œuvre une plateforme pour un écosystème dynamique

Ne vous êtes-vous jamais posé la question de savoir auprès de qui votre nouveau développeur plein de talents prenait ses conseils, puisque ce n’est certainement pas auprès d’un « vieux loup » comme vous ? Ou à l’inverse, êtes-vous un développeur talentueux et pensez-vous que votre entreprise est mal avisée en vous empêchant d’interagir avec vos pairs et de rester en phase avec la concur-rence ?

Comme je l’ai indiqué dans la partie précédente, les communautés de pairs sont très importantes pour les développeurs alternatifs comme source d’inspiration et de conseils. Il est donc important pour une entreprise ouverte de comprendre ces communautés et d’être en interaction avec elles. Vous devez, par exemple, savoir :

✓Ce que la communauté de développeurs dit à propos de votre entreprise,

✓Comment convaincre les développeurs d’utiliser vos services lorsqu’ils construisent des solutions,

✓Comment faciliter les interactions avec vous, en vous plaçant en position de partenaire et de fournisseur privilégié, à la place de vos concurrents.

La notion d’API et de gestion des API — avec l’idée que les interfaces métier externes peuvent être codifiées et publiées — est essenti-elle pour permettre la mise en œuvre d’un écosystème étendu et évolutif. Les API sont des services métier assurant une interface gérée pour l’interaction aux limites de l’entreprise, ce qui permet de bénéficier pleinement de la puissance de SOA pour créer et gérer des API métier, y compris la notion de registres API (souvent appelés « catalogues API ») pour assurer la publication et la publicité de l’entreprise externalisée.


Chapitre 3

Intégrer la mobilité avec l’architecture SOA

Dans ce chapitre, vous pourrez :▶Découvrir pourquoi la communication mobile est importante▶Préciser les éléments fondamentaux de SOA pour la mobilité

U ne jeune femme vérifie le solde de son compte en banque dans son train à destination de la ville, un client averti utilise

un service de comparaison de prix lors de ses achats en supermar-ché, ou un enfant achète un logiciel de montage de film pour son iPad — ces scènes, parmi tant d’autres, sont devenues courantes dans le quotidien de notre société moderne. Dans ce chapitre, je vous propose de découvrir pourquoi le passage à la mobilité est important et de quelle manière vous pouvez utiliser les méthodes de conception d’une architecture orientée services (SOA) pour amélio-rer vos solutions mobiles.

L’importance de la mobilitéDu point de vue technologique, comme l’indique la Figure 3-1, les solutions mobiles constituent une évolution naturelle de l’informa-tique d’entreprise, chaque génération de solutions nouvelles étant reliée de manière de plus en plus libre aux systèmes d’information de l’entreprise. Cependant, l’impact de la technologie mobile va bien au-delà de la sphère d’influence des départements informatiques. Les notions de mashup ou d’applications font partie intégrante des conversations quotidiennes. Le volume des accès et des traitements des informations en dynamique augmente si rapidement que dans dix ans, il devrait surpasser le volume de transactions électroniques traditionnelles. Concrètement, l’utilisation des appareils mobiles ne transforme pas seulement les canaux, mais aussi le business model.



Web/Informatique de bureau

Mobile/Sans fil/Cloud

Hôte/Mainframe

Client/Serveur

Figure 3-1 : L’informatique mobile constitue une évolution significative des systèmes d’information d’entreprise.

Par rapport aux transactions classiques, les interactions mobiles surviennent dans différents contextes :

✓Vous pouvez utiliser un équipement mobile partout et l’avoir en main quel que soit l’endroit où vous vous trouvez.

✓Vous pouvez accéder à n’importe quelle information ou contac-ter toutes vos relations à tout moment.

✓Les interactions mobiles peuvent être asynchrones. Elles per-mettent non seulement d’extraire des messages, mais égale-ment d’en envoyer.

✓Le développement des médias sociaux a fait apparaître des consommateurs qui entendent faire valoir leur opinion et choi-sissent les équipements mobiles pour interagir avec le monde. (La question du Social business est abordée au chapitre 4.)

Manifestement, ces caractéristiques transforment la manière dont les interactions doivent être orchestrées, gérées et surveillées. En effet, si vous n’êtes pas présent à l’instant T, vous êtes tout simple-ment absent. Les consommateurs mobiles sont impatients et n’ont aucune tolérance lorsqu’ils ne peuvent pas obtenir ce qu’ils sou-haitent, au bon endroit et au bon moment.


Chapitre 3 : Intégrer la mobilité avec l’architecture SOA 21

Les éléments fondamentaux d’une architecture SOA Mobile

Dans cette partie, je vous propose de découvrir trois des principes fondamentaux de la mobilité — les API, les applications et les apps stores — remis en perspective avec les méthodes de conception SOA.

Les APIAPI (voir chapitre 2) est un terme recyclé, utilisé aujourd’hui pour représenter une entité publique (ou persona) pour votre entreprise — entité accessible par les clients, les éditeurs de logiciels (ISV) et les partenaires commerciaux. Généralement, une entité performante bénéficie des caractéristiques suivantes :

✓Simple en termes de champ d’application (par exemple, au tra-vers d’un petit nombre d’API uniques).

✓Omniprésente au travers de différentes architectures (par exemple, avec la compatibilité avec différents protocoles et modèles de programmation pour l’accès aux services et aux données).

✓Présentée sous la forme d’un modèle de données simple (par exemple, avec JavaScript Object Notation, JSON).

✓Permettant le contrôle au moyen de règles (par exemple, un quota qui limite le nombre d’appels à cette API d’un utilisateur donné pendant une période spécifique).

Les API constituent les aspects externalisés des services. Elles ne doivent pas être considérées comme des alternatives à SOA, mais comme des éléments d’une entreprise orientée services bien archi-tecturée. Comme l’indique la Figure 3-2, les API constituent tout sim-plement la manière dont une entreprise ouverte choisit d’exposer de manière maîtrisée ses services métier auprès d’un public élargi.



Activité utilisateur

La plateforme

Enterprise

Informatique API

Développeur d'applications

Les entreprises souhaitent accéderà l'innovation au travers d'une large

communauté de développeurs, et passeulement les développeurs internes.

Client

Applications

Figure 3-2 : Les API métier constituent une entité externe (persona) représentant une entreprise ouverte.

Cependant, les API forment un type spécifique de services, dont le cycle de vie est centré sur la consommation externe. Cet aspect n’est pas une simple nuance : il impose de donner priorité à la sim-plicité, à la sécurité et à la compatibilité avec des systèmes externes fondés sur des standards.

Gestion des API métierLa gestion des API métier est essentielle pour étendre le périmètre d’influence d’une entreprise à de nouveaux canaux offerts par les solutions mobiles et SaaS (Software as a Service). Cette transfor-mation est pour l’essentiel un phénomène analogue à celui de l’e-business à la fin des années 1990. L’objectif de l’e-business était de placer des plateformes web en interface d’applications stockées sur des mainframes pour étendre ces applications au web sans déstabiliser les transactions métier. Les entreprises se développent aujourd’hui au-delà de leurs limites en utilisant des API pour exter-naliser leurs services internes de manière responsable.

Relier les API métier via les passerelles périphériquesLa liaison entre les API métier et les systèmes d’information s’ac-compagne de différentes problématiques, notamment en termes de sécurité, d’authentification et d’évolutivité :


Chapitre 3 : Intégrer la mobilité avec l’architecture SOA 23 ✓Les API métier permettent de relier des clients élastiques à des

systèmes d’information qui le sont moins, ce qui impose des fonctionnalités de gestion du trafic et des débits.

✓Les modèles de sécurité ont à prendre en compte différents degrés d’autorité pour les API privées, les API de partenaires protégées et les API publiques ouvertes.

✓Le trafic doit être surveillé pour assurer la comptabilisation et le respect des contrats de niveau de service.

En elles-mêmes, ces problématiques ne sont pas nouvelles, mais elles créent un niveau inédit d’urgence concernant le domaine des API. Alors que les entreprises intègrent la mobilité dans un nombre croissant de leurs secteurs d’activité, le contrôle de différentes applications dans un contexte non maîtrisé et la gestion de leurs performances en continu peut facilement surcharger inutilement un département informatique. D’où l’intérêt d’une bonne stratégie de passerelle périphérique. Lorsqu’une telle passerelle est en place, elle devient tout simplement, du point de vue de l’intégration, un nou-veau canal pour votre ESB (voir chapitre 1). Ce canal se régule de manière autonome et permet de libérer l’ESB des problématiques de sécurité, de mise en mémoire cache et de gestion de trafic pour les interactions effectuées en périphérie entre les systèmes d’interface et les systèmes d’information.

Il est également nécessaire de réfléchir à l’intégration de nouveaux liens (pensez à la démarche REST) et à l’application de la gestion des changements, de manière cohérente pour tous les types de services et les API, car la plupart de ces API constituent tout simplement des fonctions de restitution externes d’un service interne.

ApplicationsLes API permettent la mise en œuvre d’applications. Dans le contexte présent, une application (app) est un composant d’une application distribuée se trouvant à l’extérieur des limites de votre entreprise. L’un des exemples les plus courants est une application pour téléphone mobile stockée dans un magasin d’applications externe (voir « Apps Stores », ci-après dans ce chapitre).

Les applications vont toutefois bien au-delà. Elles peuvent être exploitées sur n’importe quel équipement (par exemple, une voiture ou un boîtier décodeur), transmettre des données collectées à partir d’un réseau de capteurs (par exemple, un compteur électrique com-municant ou un pacemaker), ou représenter une application exécu-


Les principes de la conception SOA pour les NULS, Édition limitée IBM 24tée dans un environnement externe de fournisseur de logiciels SaaS. Enfin, une application est aussi un élément de code externe, déve-loppé par différentes entités, qu’il s’agisse de développeurs en entre-prise ou de clients mobiles, qui interagissent avec vos API publiées.

Mettre en œuvre des applicationsLorsque vous mettez en œuvre des applications, vous favorisez l’innovation. Bien que vous soyez le seul créateur de votre propre entité (se référer à la partie « API », plus haut dans ce chapitre), vous souhaitez encourager le plus grand nombre à étendre cette entité en construisant des applications et en atteignant des marchés que vous ne pourriez pas toucher par vous-même. Les applications com-posites sont donc des éléments essentiels permettant d’étendre les services de l’entreprise à des parties prenantes externes.

Créer des applicationsAlors que les API métier publiées doivent être relativement stables, les applications varient de manière plus rapide et large. La faible durée de vie des applications est exacerbée par le fait que les applications sont en général spécifiques, conçues avec un objectif particulier et mises à jour fréquemment pour une multiplicité d’envi-ronnement (en fonction des équipements et des prestataires SaaS).

Pour favoriser une création performante d’applications, vous avez besoin d’un kit de développement de logiciels d’applications hau-tement performant qui vous permettra de créer différentes applica-tions externes (en particulier mobiles) pour différentes plateformes. Vous avez également besoin d’une solution de gestion des terminaux qui vous permette d’étendre l’automatisation et le déploiement à l’environnement mobile (voir Figure 3-3).

Apps StoresComme les API, les applications nécessitent une publication dans votre propre apps stores, ou ailleurs. Les décisions concernant la manière de gérer les apps stores sont en général un élément important du modèle métier d’une entreprise pour les plateformes mobiles. Vous avez à ce titre plusieurs possibilités :

✓Fournir vos applications à titre gracieux. Choisissez cette option lorsque les applications ont un intérêt pour le consommateur, mais ont pour simple objectif de promouvoir l’entreprise, de renforcer la marque et les relations avec les clients, etc.


Chapitre 3 : Intégrer la mobilité avec l’architecture SOA 25 ✓Facturer l’utilisation des applications, mais utiliser des apps

stores de distribution pour les déployer et en gérer la comp-tabilité. Choisissez cette option si vous souhaitez valoriser les applications, mais sans avoir à assumer les difficultés de gestion d’un app store (vous n’avez d’ailleurs peut-être pas la capacité à atteindre les communautés concernées).

✓Mettre en œuvre votre propre app store. Dans ce cas, vous maîtrisez totalement la démarche et vous pouvez générer de la valeur grâce à la création par des communautés (point de passage). Cette stratégie est difficile à mettre en œuvre sans l’acceptation de la communauté.

✓Servir de distributeur pour tous et intégrer l’app store dans le chiffre d’affaires de votre entreprise. Choisissez cette option si la mise en œuvre d’apps stores fait partie de votre activité, et pas seulement pour faciliter cette activité.

Agent et consolede gestioncommune

Déploiementquasi-instantanéde fonctionnalitéset d'applications

nouvelles

Gestiondes systèmes

Gestionde la sécurité

Gestionnaire de terminaux

Terminalmobile

Terminal spécialiséTerminal ordinateur de bureau/ordinateur portable/serveur

Figure 3-3 : Étendre la visibilité, le contrôle et l’automatisation aux équipements mobiles.



Publier des applications et des APIDisposer d’API et d’applications performantes ne vous aidera en rien si personne ne les connaît. Publier de manière responsable les applications et les API de votre entreprise à des emplacements clés hors de votre entreprise permet à d’autres de découvrir et d’utiliser de manière efficace ces ressources.

Que vous les publiiez sur votre propre portail d’API ou ailleurs, le

processus de publication implique une démarche marketing. Vous devez pouvoir alerter, suivre, mesurer et surveiller ces ressources au sein de communautés d’intérêt. Après avoir mis à jour une API, par exemple, vous pouvez accéder à Twitter et poster un tweet, avec un hashtag comme #ACME-API pour informer les développeurs qu’une nouvelle version de l’API ou de l’application Acme est disponible.


Chapitre 4

Mettre en œuvre les réseaux sociaux avec

l’architecture SOADans ce chapitre, nous verrons comment :▶Utiliser les réseaux dans le contexte des médias sociaux▶Établir des relations avec des personnes et des connaissances

T witter, Facebook et LinkedIn font partie intégrante des réseaux sociaux reliant des personnes et des professionnels — autant

d’approches au travers desquelles les utilisateurs et les entreprises s’engagent dans l’ère de l’Internet. Ce chapitre aborde la manière dont une entreprise ouverte peut mettre en œuvre les réseaux sociaux avec SOA.

Interagir avec les médias sociauxSi vous avez parcouru tous les chapitres de cet ouvrage jusqu’ici, vous vous posez peut-être la question : « Ne vous êtes vous pas con-tenté de décrire les aspects communautaires de SOA, et n’est-ce pas, en fait, l’essentiel concernant le Social Business et SOA ? » Ce n’est pas certain. En fait, pas du tout.

En réalité, les systèmes intégrant des personnes collaborent, com-muniquent et utilisent des données issues des réseaux sociaux, des analyses et des réseaux pour effectuer leur travail quotidien. L’intégration de la collaboration, de la communication et des analy-ses des réseaux sociaux s’accompagne de fonctions humaines plus instrumentées et orchestrées, voire même encadrées. En effet, la révolution des médias sociaux métamorphose la manière dont chacun interagit et crée de nouvelles relations s’appuyant sur ce que je nomme le social graph (voir Figure 4-1).



Figure 4-1 : Interaction dans le graphe social.

Le social graph représente la manière dont les personnes se con-nectent et interagissent au travers des différents médias sociaux, non seulement par des interactions directes, mais plus souvent également par un certain nombre d’intermédiaires. Pour permettre à une architecture SOA d’intégrer un tel réseau social, l’ensemble des terminaux du réseau SOA doit être développé de manière éten-due pour inclure les personnes et les connaissances constituant autant de ressources accessibles. Immergées dans un contexte de réseaux sociaux, les interactions des personnes ne procèdent pas par messages ; elles sont plutôt fondées sur des connaissances, des questions et des réponses. Par ailleurs, la médiation ne s’appuie plus sur des protocoles et des formats, mais sur l’identité des personnes à contacter et la localisation des informations les plus pertinentes pour répondre à une question particulière.

Devenir un partenaire de réseau social est un ingrédient important pour renforcer les relations client et étendre le périmètre d’une com-munauté. Considérer les personnes comme des terminaux acces-sibles — considérées comme un élément d’un réseau SOA — permet à une entreprise ouverte de conduire les interactions humaines au moyen du canal idéal, de fournir une information optimale repla-cée dans son contexte, et d’autoriser les interactions des clients non seulement avec les systèmes informatiques, mais également directement avec les employés et les partenaires. Cependant, cette démarche nécessite une extension significative de la notion de médi-ation dans le cadre d’un ESB.


Chapitre 4: Mettre en œuvre les réseaux sociaux avec l’architecture SOA 29

Relier les personnes et les connaissancesLes frontières entre l’humain et les systèmes informatiques ne ces-sent de s’estomper. Il est probable que vous pourrez bientôt intera-gir au sein d’un réseau de connaissances connectées omniprésent dans la société. La plupart de ces informations transiteront par les médias sociaux, et les architectures métier intègreront des termi-naux associés à des personnes et à des systèmes, reliés à un bus de connaissances commun. Ce bus de connaissances constitue une évolution naturelle de l’ESB (voir Chapitre 1). Plutôt que d’assurer l’interface de messages et de fonctionnalités, fonction principale d’un ESB, un bus de connaissances effectue une médiation de con-naissances.La démarche Social business concerne les personnes, et les per-sonnes recherchent des réponses à des questions — et pas seule-ment des réponses à des demandes. Elles ont besoin de réponses intelligibles, d’où la nécessité, dans une interaction, d’adopter une sémantique humaine. Les personnes recherchent également une médiation en termes de temps, de localisation et de communauté, tout simplement dans le cadre de leur sphère sociale. Lorsque j’observe la manière dont ma fille de 11 ans communique déjà avec ses amis, en combinant des supports audio, vidéo, des textes, et même des jeux, il me paraît évident que très bientôt, les personnes et les connaissances seront reliées au sein d’un réseau social fondé sur les principes de conception SOA.

Grâce à la démarche SOA, vous pouvez décrire et connecter des per-sonnes, les connaissances dont elles disposent, et la manière dont elles peuvent interagir sous forme synchrone ou asynchrone. Toute personne pouvant donner une réponse est, du point de vue du con-cept SOA, capable de fournir un service métier de valeur. Ce qui ne signifie pas que les personnes seront traitées comme des robots ; les interactions basées sur SOA doivent au contraire devenir plus humaines, en intégrant le fait que les humains sont rarement cer-tains à 100 % de la bonne réponse à une question, pas plus qu’une certitude absolue n’est indispensable pour que l’information reçue ait une valeur réelle.

Savez-vous, par exemple, ce que j’ai trouvé étonnant en regardant le super ordinateur Watson d’IBM participer au jeu télévisé Jeopardy! en 2011 ? Pour moi, l’essentiel était que Watson ne se contentait pas de fournir une réponse à une demande ; il montrait également le degré de certitude qu’il avait concernant ses réponses en évalu-ant des indices pour en faire des preuves. C’est ce qui rendait l’interaction avec Watson si proche de celle possible avec un être humain. En effet, la notion d’informatique probabiliste est un


Les principes de la conception SOA pour les NULS, Édition limitée IBM 30catalyseur essentiel de la collaboration centrée sur l’humain (tout comme l’enrichissement du contexte et de la sémantique pour les informations circulant dans le réseau social). Cette notion s’applique aussi bien aux interactions entre humains ou entre humains et sys-tèmes informatiques.

Pour être réalisable du point de vue des principes de conception SOA, un réseau social nécessite les éléments suivants :

✓Mettre en place des standards pour les canaux et les connais-sances,

✓Mettre en œuvre une démarche orientée services permettant de codifier les services métier offerts et demandés par les per-sonnes concernées,

✓Incorporer les écosystèmes situés à l’intérieur et à l’extérieur de l’entreprise,

✓Assurer l’intégrité de toutes les interactions, faute de quoi les utilisateurs perdront rapidement confiance dans une source d’information ou un service particulier, au détriment des inter-actions métier ultérieures.


Chapitre 5

Avoir la tête dans le Cloud avec l’architecture SOA

Dans ce chapitre, nous verrons :▶De quelle manière le Cloud impacte le Business model▶Comment adopter le Cloud computing

B eaucoup a déjà été écrit sur le lien entre le Cloud et SOA. Les environnements Cloud apportent des services définis au

moyen des principes de conception SOA, eux-mêmes bâtis sur une fondation SOA.

La démarche orientée services permet la standardisation des offres proposées via un modèle de Cloud computing. Concrètement, ces offres sont tout simplement des services fondés sur des fonction-nalités et des interfaces parfaitement définies. La virtualisation d’une infrastructure dynamique permet de mettre à disposition ces services Cloud d’une manière élastique et flexible — virtualisation elle-même fondée sur la gestion de ces capacités d’infrastructure informatique sous la forme de services pouvant être provisionnés et libérés en fonction des besoins. L’association de la démarche SOA et d’une infrastructure dynamique permet donc la mise en œuvre d’un environnement de Cloud computing. Les aspects informatiques élé-mentaires du Cloud se résument à ces notions.

Dans ce chapitre, j’aborderai l’impact métier des solutions fondées sur l’environnement Cloud et la manière dont les principes de conception SOA s’appliquent à ce contexte.



Introduire le Cloud dans les affairesLe modèle de Cloud computing adopté a un impact considérable sur le business model informatique. Cet impact résulte en particulier du changement d’approche concernant les investissements infor-matiques, en adoptant un modèle basé sur les coûts d’exploitation plutôt que sur les coûts d’investissement. D’où la nécessité pour les opérateurs Cloud externes et internes de penser en termes de tréso-rerie, de profit et d’autres facteurs incontournables pour la mise en œuvre d’une activité — dans le cas présent, l’activité informatique.

En outre, du point de vue de l’organisation métier, l’entreprise doit prendre des décisions sur différents sujets, notamment les autorisations d’utiliser une interface en libre-service conduisant à un provisionnement et à une facturation immédiats de ressources informatiques supplémentaires. L’impact économique, jusqu’ici mesurable en semaines, voire en mois, se compte aujourd’hui en secondes, et il n’existe aucun bouton d’annulation pour revenir sur une réservation de ressources déjà effectuée.

Les enjeux concernant l’entreprise et l’informatique vont probable-ment nécessiter des changements dans les processus existants de gestion intégrée des services, notamment le provisionnement, la découverte, la sécurité et la surveillance. L’organisation et la mise en œuvre de cette transition sont donc essentielles pour la réussite d’une démarche Cloud.

Effectuer la transition vers le Cloud computing

La transition vers le Cloud computing soulève différentes questions concrètes :

✓Comment déployer des solutions dans le Cloud en utilisant un modèle de prestations en continu ?

✓Comment provisionner les environnements de test nécessaires pour les solutions hybrides qui se trouvent en partie sur site et en partie dans l’environnement Cloud ?

✓Qui est responsable de la sécurité dans un environnement Cloud, et qui paie si une atteinte à la sécurité survient ?


Chapitre 5 : Avoir la tête dans le Cloud avec l’architecture SOA 33 ✓Comment vérifier si vos contrats de niveau de services sont

respectés ?

✓Comment identifier les services selon qu’ils sont disponibles sur site, dans l’environnement Cloud ou dans l’environnement mobile ?

Pour apporter des réponses simples à toutes ces questions, parmi d’autres, il suffit d’appliquer les bonnes méthodes de conception SOA, décrites ici :

✓Le cœur de la démarche orientée services permet d’obtenir des services exploitables parfaitement définis, assortis de poli-tiques, et dont la consommation peut être surveillée et gérée.

✓L’intégrité des processus à l’échelle du réseau Internet conduit à des exigences parfaitement définies en termes d’élas-ticité et de mise en œuvre des transactions pour l’ensemble d’un environnement.

✓L’intégration avec les capacités de l’entreprise et les systèmes centraux permet la création de solutions hybrides, conjuguant des capacités intégrées à l’environnement Cloud et sur site.

✓Les standards de l’industrie ont permis de mettre au premier plan le Cloud computing ; l’approche joue également un rôle important dans la création et la gestion des services intégrés des solutions hybrides.

✓L’utilisation et l’extension des technologies open source entre en jeu, car de nombreux environnements Cloud sont basés sur un noyau open source. Les institutions du secteur de l’enseignement et de l’administration publique en particu-lier continueront sans aucun doute à utiliser les technologies open source comme composants clés de leurs infrastructures d’exploitation.

✓La mise en œuvre d’une plateforme associée à un écosys-tème évolutif concerne le Cloud computing, car le Cloud lui-même est un parfait exemple d’environnement centré sur les écosystèmes, permettant l’échange de biens et de services au-delà des frontières traditionnelles de l’entreprise.

Pour en savoir plus sur ces méthodes et sur d’autres principes de conception SOA, revenez au chapitre 2.


Chapitre 6

Extraire les connaissances enfouies dans le Big Data grâce à l’architecture SOA

Dans ce chapitre, nous verrons comment :▶Exploiter les flux de données existants▶Utiliser des données hétérogènes▶Permettre l’extraction des connaissances

P eut-être imaginez-vous que je suis complètement perdu — et qu’il n’y a aucune corrélation directe entre le Big Data et

la démarche SOA. N’en soyez pas si sûr. Pour moi, le Big Data est complètement lié aux principes de conception SOA. En effet, trois questions permettent de mettre en évidence la relation étroite entre le Big Data et SOA. Ces questions sont les suivantes :

✓Comment exploitez-vous les flux de données existants ? ✓Comment accédez-vous et gérez-vous les données appartenant

à un ensemble hétérogène de sources d’informations ? ✓Comment produisez-vous des connaissances métier pour vos

solutions de haut niveau ?Dans ce chapitre, j’apporte des réponses à ces trois questions.

Exploiter les flux de données existantsConsidérons la question de la méthode nécessaire pour accéder aux données circulant dans l’ensemble de votre entreprise — en particulier, les interactions métier intéressant une entreprise ouverte. Comment collectez-vous et traitez-vous les informations en équipant les applications d’instruments permettant de produire un


Les principes de la conception SOA pour les NULS, Édition limitée IBM 36« flux de connaissances », de manière non intrusive, sachant que la plupart de ces applications ont été développées sans aucun contrôle de votre part ?La réponse est toute simple : il suffit d’instrumenter le middleware ESB transportant les interactions entre les systèmes de communica-tion et les systèmes d’informations, en extrayant les informations issues des interactions associées à un terminal à l’intérieur de l’entreprise. La Figure 6-1 illustre le processus.

Connectivité et intégration

Expériencecumulée

Activitésen cours

Situations etévénements

Figure 6-1 : Instrumentation du middleware ESB.

Bien que cette solution ne couvre pas toutes les informations con-cernées, notamment les événements survenant au sein d’une com-munauté de réseau social (voir chapitre 4), elle répond à la plupart des problématiques de visibilité. Cependant, l’adoption de cette approche conduit à un défi relatif au traitement du Big Data.

Exploiter les donnéesL’instrumentation de l’ESB produit un énorme volume de données, et il est probable que vous souhaitiez utiliser ces données de différ-entes manières, par exemple dans les situations suivantes :

✓Mieux connaître votre client : Localiser votre client, le con-tacter immédiatement et utiliser des informations réputées fiables dans toutes les interactions. Les clients s’attendent à ce que vous sachiez qui ils sont et où ils se trouvent. (Ils ne souhaitent pas avoir à décliner de nouveau leur identité et les raisons pour lesquelles ils entrent en contact avec vous.)

✓Déterminer la meilleure action possible : Déterminer immé-diatement l’action la plus pertinente, en exploitant les connais-sances stratégiques issues des informations collectées au fil de la relation. Les clients considèrent que vous êtes suffisamment intelligent pour suggérer une séquence d’interactions perti-


Chapitre 6 : Extraire les connaissances enfouies dans le Big Data grâce à l’architecture SOA 37nentes ; si ce n’est pas le cas, ils se détourneront de vous. (Ils n’apprécieront pas que vous leur proposiez une solution qu’ils ont refusé la semaine précédente.)

✓Vous adapter en fonction de la situation et du contexte : Faire en sorte que les solutions déployées soient adaptées, et doter vos processus d’instruments permettant de réagir à la situation et au lieu présents. Les clients n’ont aucune patience lorsqu’ils ont affaire à des processus qui ont visiblement été créés sans tenir compte de leur situation personnelle. (Ils n’ont pas envie d’être en contact téléphonique avec une personne qui suit un script et répète cinq étapes qu’ils ont déjà effectués.)

✓Améliorer la conformité : Vérifier les qualifications et les politiques en cours de transaction, tenir compte des excep-tions d’une manière structurée, et gérer les risques relatifs aux informations collectées. Les autorités, en interne comme à l’extérieur, souhaitent que vous appliquiez à tout moment les politiques et les réglementations en vigueur, et que vous puissiez le prouver. (Les entreprises ne souhaitent pas se trou-ver dans une situation dans laquelle elles sont incapables de produire une preuve formelle de leur conformité à la réglemen-tation en vigueur.)

Prédire l’avenirL’une des approches communes à l’ensemble des utilisations pos-sibles des données est le souhait d’adopter progressivement une approche plus prédictive (voir Figure 6-2), ce qui, en retour, impose d’abandonner la notion de vérité absolue.Résultatsmétier

Que devons-nousfaire dans le futur ?

Disponibilité des données

Que devons-nousfaire prochainement ?

Que vient-ilde se passer ?

Que se passe-t-ilen ce moment ?

Que va-t-il se passerdans le futur ?

Historique

Réactif

Prévisionnel

Récent

Que va-t-il sepasser ensuite ?

Temps réel

PrescriptifQue devons-nousfaire maintenant ?

Que s'est-ilpassé ?

Que va-t-il se passerprochainement ?

Figure 6-2 : Devenir progressivement plus prédictif.



Une entreprise ouverte doit donc, dans le cadre de ses activités, prendre en compte les notions de probabilité et de risque.

Utiliser les données issues de sources hétérogènes

Comment accéder à des sources d’information hétérogènes et les contrôler ? La réponse consiste à appliquer de bonnes méthodes de conception SOA, standardiser l’accès aux informations en flux continu, décrire ces accès en terme de services parfaitement définis, assurer l’intégration avec les informations contenues dans les sys-tèmes de bases de données et maintenir l’intégrité de l’information pour l’ensemble de l’infrastructure d’une entreprise ouverte.

Le Big Data et les quatre VUne entreprise ouverte se doit d’intégrer la notion des quatre V concernant son approche du Big Data :

✓ Volume : Le volume d’informations à traiter augmente exponentielle-ment du fait de l’Internet des objets (notamment les capteurs, les appa-reils mobiles, les appliances et les automobiles), etc.

✓ Vitesse : La plus grande partie des informations ayant un intérêt pour une entreprise n’est pas stockée dans un magasin de données. Le stockage de ces informations serait de toute façon pratiquement impossible, et il est donc néces-saire de les traiter au fil de l’eau. Prenez par exemple les capteurs RFID qui vous indiquent lorsqu’un client très important est entré dans votre magasin, ou imaginez les don-nées issues du Big Hadron Collider,

chargé de rechercher les particules atomiques furtives en un million-ième de seconde.

✓ Variété : Les informations intéres-santes sont rarement conformes à un modèle défini de manière cen-trale. Pas moins de 80 % des don-nées échangées dans le monde — e-mails, interactions de réseaux sociaux, journaux d’historique, etc. — sont non structurées, c’est-à-dire sans schéma prédéfini.

✓ Véracité : Toutes les informations ne sont pas dignes de confiance. Il est donc nécessaire d’en quantifier la fiabilité en fonction de la source et du type d’information (notamment les opinions postées sur un blog, les tweets ou des informations issues de partenaires dont les opinions reposent sur des démarches pro-pres).


Chapitre 6 : Extraire les connaissances enfouies dans le Big Data grâce à l’architecture SOA 39

En exposant à la fois les flux d’information et les capacités d’analyse sous la forme de services définis avec précision, vous créez des couplages libres intéressants entre les sources d’information, le moteur d’analyse et l’application métier qui a besoin de connais-sances. Intéressez-vous aux capacités technologiques permettant de conjuguer le Big Data et l’approche SOA, au lieu de vous appuyer en permanence sur des approches traditionnelles d’entrepôts de données.

Le chapitre 4 décrit la nécessité, pour une entreprise ouverte, de relier des personnes et des équipements, et d’assurer la média-tion entre eux. Cette même entreprise, dans un contexte de besoin d’information, doit évoluer d’une approche centrée sur les charges transactionnelles vers une démarche consistant à induire et exploiter les connaissances métier. Faute de connaître les per-sonnes, leurs motivations et leurs besoins, il est difficile d’optimiser les interactions métier qui les concernent.

Produire des connaissances métier

Comment conjuguer différents types de connaissances pour en tirer un avantage stratégique ? Si la démarche SOA en elle-même ne crée pas de connaissances, elle vous permet d’appliquer les connais-sances obtenues de la bonne manière, au bon moment et au bon endroit. Elle vous permet également de collecter des preuves sur ce qui se produit dans l’environnement opérationnel, et peut con-tribuer à identifier des besoins métier.

Outre les apports de la démarche SOA, la plupart des applications d’analyse métier doivent être capables de collecter et de rap-procher des informations — autant de fonctionnalités qu’apportent les solutions de Master Data Management (gestion des données de référence). Au-delà de la gestion des données de référence, les solutions les plus avancées en matière de connaissances métier s’appuient sur des fournisseurs d’informations spécialisés ; au final, la performance d’une analyse résulte de la pertinence des informa-tions auxquelles elle s’applique. La démarche SOA ne se substitue en aucun cas aux fonctionnalités de gestion de l’information, mais en conjuguant la démarche SOA et la gestion de l’information, vous pouvez libérer pleinement le potentiel du Big data.


Notes


Les principes de la conception SOA Pour Les Nuls, · licence de la marque Pour les Nuls, ... Le...

Documents

Transcript of Les principes de la conception SOA Pour Les Nuls, · licence de la marque Pour les Nuls, ... Le...