19
DSCG : Management des SI Architectures Table des matières ARCHITECTURE PHYSIQUE................................................................................................................ 2 COMMUTATEUR........................................................................................................................................ 2 ROUTEUR............................................................................................................................................... 2 FIREWALL.............................................................................................................................................. 2 VLAN............................................................................................................................................. 3 Types de VLAN :.......................................................................................................................................................................3 Intérêt des VLAN.......................................................................................................................................................................3 VPN............................................................................................................................................... 3 DMZ............................................................................................................................................... 4 DECT............................................................................................................................................. 4 DATACENTER......................................................................................................................................... 4 Composantes physiques ..........................................................................................................................................................4 Composantes réseau ...............................................................................................................................................................5 Composantes applications .......................................................................................................................................................5 ARCHITECTURES APPLICATIVES...................................................................................................... 6 CLIENT/SERVEUR :.................................................................................................................................. 6 Les principes de base ...............................................................................................................................................................6 5 couches..................................................................................................................................................................................7 MIDDLEWARE.......................................................................................................................................... 8 VUE EN NIVEAUX...................................................................................................................................... 8 1 Tier.........................................................................................................................................................................................8 2 Tier.........................................................................................................................................................................................8 n Tier.........................................................................................................................................................................................8 L'architecture Web 3 tier.......................................................................................................................................................8 Architecture J2E....................................................................................................................................................................9 L'ÉVOLUTION DES ARCHITECTURES LOGICIELLES............................................................................................ 10 L'architecture en silos .............................................................................................................................................................10 Le plat de spaghettis ...............................................................................................................................................................10 EAI, pour intégration d'applications d'entreprise .....................................................................................................................10 Plates-formes d'EAI.............................................................................................................................................................11 La gestion des processus métier.............................................................................................................................................13 L'architecture orientée services ..............................................................................................................................................13 Objectifs..............................................................................................................................................................................13 Caractéristiques essentielles...............................................................................................................................................14 SOA et SI............................................................................................................................................................................14 Le peer-to-peer .......................................................................................................................................................................15 ARCHITECTURES FONCTIONNELLES............................................................................................. 15 B2E : BUSINESS TO EMPLOYEE............................................................................................................... 15 B2C : BUSINESS TO CONSUMER ......................................................................................................... 15 B2B : BUSINESS TO BUSINESS ........................................................................................................... 17 CLOUD COMPUTING ............................................................................................................................... 17 Les formes de Cloud Computing.............................................................................................................................................18 Différents modèles de Cloud...................................................................................................................................................18 1/19

COURS MSI Architectures

Embed Size (px)

Citation preview

Page 1: COURS MSI Architectures

DSCG : Management des SI Architectures

Table des matières

ARCHITECTURE PHYSIQUE................................................................................................................2

COMMUTATEUR........................................................................................................................................ 2ROUTEUR............................................................................................................................................... 2FIREWALL.............................................................................................................................................. 2VLAN............................................................................................................................................. 3

Types de VLAN :.......................................................................................................................................................................3Intérêt des VLAN.......................................................................................................................................................................3

VPN............................................................................................................................................... 3DMZ............................................................................................................................................... 4DECT............................................................................................................................................. 4DATACENTER......................................................................................................................................... 4

Composantes physiques ..........................................................................................................................................................4Composantes réseau ...............................................................................................................................................................5Composantes applications .......................................................................................................................................................5

ARCHITECTURES APPLICATIVES......................................................................................................6

CLIENT/SERVEUR :.................................................................................................................................. 6Les principes de base ...............................................................................................................................................................65 couches..................................................................................................................................................................................7

MIDDLEWARE.......................................................................................................................................... 8VUE EN NIVEAUX...................................................................................................................................... 8

1 Tier.........................................................................................................................................................................................82 Tier.........................................................................................................................................................................................8n Tier.........................................................................................................................................................................................8

L'architecture Web 3 tier.......................................................................................................................................................8Architecture J2E....................................................................................................................................................................9

L'ÉVOLUTION DES ARCHITECTURES LOGICIELLES............................................................................................10L'architecture en silos .............................................................................................................................................................10Le plat de spaghettis ...............................................................................................................................................................10EAI, pour intégration d'applications d'entreprise .....................................................................................................................10

Plates-formes d'EAI.............................................................................................................................................................11La gestion des processus métier.............................................................................................................................................13L'architecture orientée services ..............................................................................................................................................13

Objectifs..............................................................................................................................................................................13Caractéristiques essentielles...............................................................................................................................................14SOA et SI............................................................................................................................................................................14

Le peer-to-peer .......................................................................................................................................................................15

ARCHITECTURES FONCTIONNELLES.............................................................................................15

B2E : BUSINESS TO EMPLOYEE...............................................................................................................15B2C : BUSINESS TO CONSUMER .........................................................................................................15B2B : BUSINESS TO BUSINESS ...........................................................................................................17CLOUD COMPUTING ............................................................................................................................... 17

Les formes de Cloud Computing.............................................................................................................................................18Différents modèles de Cloud...................................................................................................................................................18

1/19

Page 2: COURS MSI Architectures

DSCG : Management des SI Architectures

Architecture physiqueL'architecture physique (également nommée architecture technique) décrit l'ensemble des composants matériels supportant les applications. Ces composants peuvent être

• des calculateurs (ou serveurs matériels) • des postes de travail • des équipements de stockage (baie de stockage, SAN,) • des équipements de sauvegarde • des équipements réseaux (routeurs, firewalls, switches, load-balancers, accélérateurs SSL).

CommutateurUn commutateur réseau, ou switch, est un équipement qui relie plusieurs segments (câbles ou fibres) dans un réseau informatique et de télécommunication et qui permet de créer des circuits virtuels.

Dans les réseaux locaux (LAN), il s'agit le plus souvent d'un boîtier disposant de plusieurs ports Ethernet (entre 4 et plusieurs centaines), il a donc la même apparence qu'un concentrateur (hub).

Contrairement à un concentrateur, un commutateur ne reproduit pas sur tous les ports chaque trame qu'il reçoit : il sait déterminer sur quel port il doit envoyer une trame, en fonction de l'adresse à laquelle cette trame est destinée.

RouteurUn routeur est un équipement d'interconnexion de réseaux informatiques permettant d'assurer le routage des paquets entre deux réseaux ou plus afin de déterminer le chemin qu'un paquet de données va emprunter.

Dans la configuration d'un poste de travail le routeur est appelé « passerelle par défaut »

Un routeur marque la limite d'un réseau local.

FirewallUn pare-feu, ou firewall est un logiciel et/ou un matériel, permettant de faire respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types de communication autorisés sur ce réseau informatique.

Un système pare-feu contient un ensemble de règles prédéfinies permettant :

• D'autoriser la connexion (allow) ;

• De bloquer la connexion (deny) ;

2/19

Page 3: COURS MSI Architectures

DSCG : Management des SI Architectures

• De rejeter la demande de connexion sans avertir l'émetteur (drop).

L'ensemble de ces règles permet de mettre en œuvre une méthode de filtrage dépendant de la politique de sécurité adoptée par l'entité. On distingue habituellement deux types de politiques de sécurité permettant :

• soit d'autoriser uniquement les communications ayant été explicitement autorisées :

• soit d'empêcher les échanges qui ont été explicitement interdits.

VLANVLAN (Virtual LAN), est un réseau informatique logique indépendant. De nombreux VLAN peuvent coexister sur un même commutateur réseau.

Types de VLANTypes de VLAN ::

• VLAN de niveau 1 (ou VLAN par port) : on y définit les ports du commutateur qui appartiendront à tel ou tel VLAN. Cela permet entre autres de pouvoir distinguer physiquement quels ports appartiennent à quels VLAN.

• VLAN de niveau 2 (ou VLAN par adresse MAC) : on indique directement les adresses MAC des cartes réseaux contenues dans les machines que l'on souhaite voir appartenir à un VLAN, cette solution est plus souple que les VLAN de niveau 1, car peu importe le port sur lequel la machine sera connectée, cette dernière fera partie du VLAN dans lequel son adresse MAC sera configurée.

• VLAN de niveau 3 (ou VLAN par adresse IP) : même principe que pour les VLAN de niveau 2 sauf que l'on indique les adresses IP (ou une plage d'IP) qui appartiendront à tel ou tel VLAN.

Pour déployer des VLAN cela sous entend que le commutateur utilisé soit gérable et qu'il gère les VLAN du niveau désiré, à savoir également que plus le niveau de VLAN est élevé, plus le commutateur sera cher à l'achat.

Intérêt des VLANIntérêt des VLAN• Améliorer la gestion du réseau ;

• Optimiser la bande passante ;

• Séparer les flux ;

• Segmentation : réduire la taille d'un domaine de broadcast ;

• Sécurité : permet de créer un ensemble logique isolé pour améliorer la sécurité. Le seul moyen pour communiquer entre des machines appartenant à des VLAN différents est alors de passer par un ou plusieurs routeurs.

VPNVirtual Private Network (Réseau Privé Virtuel) est vu comme une extension des réseaux locaux et préserve la sécurité logique que l'on peut avoir à l'intérieur d'un réseau local.

Il correspond en fait à une interconnexion de réseaux locaux via une technique de « tunnel ». On parle de VPN lorsqu'un organisme interconnecte ses sites via une infrastructure partagée avec d'autres organismes. Il existe deux types de telles infrastructures partagées : les « publiques » comme Internet et les infrastructures dédiées que mettent en place les opérateurs pour offrir des services de VPN aux entreprises. C'est sur Internet et les infrastructures IP que se sont développées les techniques de « tunnel ».

Un bon compromis consiste à utiliser Internet comme support de transmission en utilisant un protocole de « tunnellisation » (en anglais tunneling), c'est-à-dire encapsulant les données à transmettre de façon chiffrée. On parle alors de VPN pour désigner le réseau ainsi artificiellement créé. Ce réseau est dit virtuel car il relie deux réseaux « physiques » (réseaux locaux) par une liaison

3/19

Page 4: COURS MSI Architectures

DSCG : Management des SI Architectures

non fiable (Internet), et privé car seuls les ordinateurs des réseaux locaux de part et d'autre du VPN peuvent accéder aux données en clair.

Le VPN permet donc d'obtenir une liaison sécurisée à moindre coût, si ce n'est la mise en œuvre des équipements terminaux. En contrepartie, il ne permet pas d'assurer une qualité de service comparable à une ligne spécialisée dans la mesure où le réseau physique est public, donc non garanti.

Le VPN vise à apporter certains éléments essentiels dans la transmission de données : l'authentification (et donc l'identification) des interlocuteurs, la confidentialité des données (le chiffrement vise à les rendre inutilisables par quelqu'un d'autre que le destinataire).

DMZUne DMZ, de l'anglais demilitarized zone (zone démilitarisée) est un sous-réseau séparé du réseau local et isolé de celui-ci et d'Internet par un pare-feu. Ce sous-réseau contient les machines accessibles depuis Internet.

Le pare-feu bloquera donc les accès au réseau local pour garantir sa sécurité. Et les services susceptibles d'être accédés depuis Internet seront situés en DMZ.

En cas de compromission d'un des services dans la DMZ, le pirate n'aura accès qu'aux machines de la DMZ et non au réseau local.

Le nom provient à l'origine de la zone coréenne démilitarisée.

DECTDigital Enhanced Cordless Telephone (Téléphone sans-fil numérique amélioré),est une norme de téléphonie sans-fil numérique destinée aux particuliers comme aux entreprises sur la gamme de fréquence 1 880 à 1 900 MHz (micro-ondes). Cette norme, est aujourd'hui principalement utilisée pour des communications vocales.

DataCenterUn centre de traitement de données (data center ) est un site physique sur lequel se trouvent regroupés des équipements constituants du système d’information de l’entreprise (mainframes, serveurs, baies de stockage, équipements réseaux et de télécommunications, etc.). Il peut être interne et/ou externe à l’entreprise, exploité ou non avec le soutien de prestataires.

C'est un service généralement utilisé pour remplir une mission critique relative à l'informatique et à la télématique. Il comprend en général un contrôle sur l'environnement (climatisation, système de prévention contre l'incendie, etc.), une alimentation d'urgence et redondante, ainsi qu'une sécurité physique élevée.

Un centre de traitement de données peut occuper une pièce, un étage ou un immeuble en entier. On y retrouve des serveurs 1U (surnommés « boîtes à pizza ») ou plus, « U » correspondant à une unité de hauteur de 4,445 cm (soit 1,75 pouce) empilés dans des racks, lesquels sont arrangés pour former des rangées simples, ce qui permet de circuler facilement parmi les serveurs, tant à l'avant qu'à l'arrière. Quelques appareils, ordinateurs centraux par exemple, sont de dimensions semblables à ces racks. Ils sont souvent placés à leurs côtés.

Les bases de données étant souvent cruciales au fonctionnement des entreprises, celles-ci sont très sensibles à leur protection. Pour cette raison, ces centres maintiennent de hauts niveaux de sécurité et de service dans le but d'assurer l'intégrité et le fonctionnement des appareils sur place.

Composantes physiques Composantes physiques

• Climatisation précise et stable

• Contrôle précis de la poussière environnante

• Unité de distribution de l'énergie

• Bloc d'alimentation d'urgence, ainsi qu'une unité de secours

• Système perfectionné d'alerte d'incendie

• Extinction automatique des incendies par micro-gouttelettes ou gaz inerte

• Plancher surélevé

• Conduites pour câbles au-dessous et au-dessus du plancher

4/19

Page 5: COURS MSI Architectures

DSCG : Management des SI Architectures

• Surveillance par caméras en circuit fermé

• Contrôle des accès, ainsi que sécurité physique

• Surveillance 24/7 des serveurs dédiés (ordinateurs)

• Gardes de sécurité continuellement présents

• Câbles de paires torsadées de cuivre en Ethernet (Fast ou Gigabit)

• Fibres optiques pour liaisons inter-sites ou inter-[switches/routeurs/firewall]

Composantes réseau Composantes réseau

• Routeurs

• commutateurs

• Pare-feu

• Passerelles

• Système de détection d'intrusion logicielle

• Etc.

Composantes applications Composantes applications Les missions principales du centre sont d'offrir une bonne connexion réseau (internet, intranet, ...) et une haute disponibilité du système d'information. En conséquence, il est possible de déployer différentes applications logicielles pour les tâches essentielles à l'activité métier des clients. Parmi ces applications, on retrouve des gestionnaires de bases de données, des serveurs de fichiers et des serveurs d'applications.

Un serveur de fichiers permet de partager des données à travers un réseau. Le terme désigne souvent l'ordinateur (serveur) hébergeant le service applicatif. Il possède généralement une grande quantité d'espace disque où sont déposés des fichiers. Les utilisateurs peuvent ensuite les récupérer au moyen d'un protocole de partage de fichier.

Un serveur d'applications est un logiciel d'infrastructure offrant un contexte d'exécution pour des composants applicatifs. Le terme est apparu dans le domaine des applications web. Dans un sens strict les composants hébergés par le serveur d'applications ne sont pas de simples procédures ou scripts mais de réels composants logiciels conformes à un modèle de composants (EJB, COM, Fractal, etc.).

Les clients des serveurs d'application sont : des programmes autonomes (stand alone application) ou d'autres composants.

La structuration en couches des différents composants mis à disposition par le serveur d'application permet une prise en compte des besoins métier, des interactions avec les utilisateurs, des connexions avec les bases de données, etc.

Les serveurs d'applications sont des logiciels occupant la couche centrale dans une architecture multicouches, qu'elle soit classique 3-tier (postes clients, serveur d'applications, serveur de données) ou étendue (n-tiers) lorsqu'elle intègre par exemple des serveurs d'acquisition (données de terrain, données de process, de back-office, etc.) et/ou des serveurs d'interface (gateways, systèmes coopérants externes, etc.).

Dans un sens plus large, un serveur d'application peut être une machine servant à héberger des applications soit pour permettre leur exécution depuis un poste client (mode client serveur de données, généralement partage de fichiers et politiques de gestion des accès) ou pour déporter l'affichage sur le poste client (mode client serveur d'affichage).

5/19

Page 6: COURS MSI Architectures

DSCG : Management des SI Architectures

Architectures applicatives

Client/Serveur :• Le serveur est à l'écoute, prêt à répondre aux requêtes envoyées par des clients.

• Les clients sont généralement pilotés par des utilisateurs. Ils prennent l'initiative d'envoyer des requêtes au serveur, puis attendent la réponse pour la donner, le cas échéant, à l'utilisateur.

• Un serveur est capable de servir plusieurs clients simultanément, jusqu'à plusieurs milliers.

• Le serveur et le client utilisent le même protocole de communication.

L'architecture trois tier est une extension de l'architecture client-serveur.

L'architecture client/serveur correspond à une architecture à deux niveaux :

• les règles de gestion, les traitements et les accès aux données sont réalisés sur le serveur central,

• les contrôles de saisie, les enchainements des dialogues sont effectués sur les postes client.

Ce modèle minimise les flux sur le réseau et tire partie de la puissance des machines locale et centrale.

Les principes de base Les principes de base

Le client/Serveur repose sur une communication d’égal à égal entre les applications.

La Communication est réalisée par dialogue entre processus deux à deux : Un processus est le client, l’autre le serveur. Les processus ne sont pas identiques mais forment plutôt un système coopératif.

Le résultat de cette coopération se traduit par un échange de données, le client réceptionne les résultats finaux délivrés par le serveur.

Le client initie l’échange, le serveur est à l’écoute d’une requête cliente éventuelle.

Le modèle client/serveur constitue un système coopératif sans distinction à priori entre les différents membres du réseau.

Chaque membre peut alternativement :

• être client et/ou serveur ;

• demander un service ;

• réaliser un service donné pour un ou plusieurs autres membres du réseau.

L'exécution d'un service nécessite beaucoup de ressources machine (CPU, mémoire résidente, mémoire secondaire, …)

On peut décomposer fonctionnellement une application informatique en trois parties : la première concerne l’interface utilisateur, c’est à dire tout ce qui à trait au dialogue entre l’utilisateur et l’application (Présentation). La seconde partie représente l’ensemble des traitements et leur enchaînement logique (Logique Applicative). Enfin la troisième porte sur la gestion des données proprement dite.

Le gartner group, cabinet d’étude nord-américain, a publié une classification des différents modes client-serveur reposant sur cette décomposition applicative. On y retrouve ces trois composants fonctionnels appelés respectivement « Présentation », « Logique applicative », et « Gestion des données ».

6/19

Page 7: COURS MSI Architectures

DSCG : Management des SI Architectures

Classification des modes client-serveurs (source Gartner Group) en architecture 2 tier :

Présentation Distribuée

Présentation Déportée

Logique Distribuée

Gestion de données Déportée

Gestion de données

Distribuée

Gestion des données

Gestion des données

Gestion des données

Gestion des données

Gestion des données

Serveur Logique d’application

Logique d’application

Logique d’application

Présentation

Gestion des données

Client Logique d’application

Logique d’application

Logique d’application

Présentation Présentation Présentation Présentation Présentation

Dans cette classification, on ne raisonne plus seulement en termes de programmes, client ou serveur, mais en termes de postes. Ainsi, la localisation de chacun des trois composants fonctionnels sur le poste client ou sur le poste serveur détermine le type d’architecture de l’application.

5 couches5 couches

● Présentation○ Interface Graphique

■ restitution de l'état du système sur un terminal graphique ■ saisie de données ■ demande d'exécution de traitements

○ IHM■ Client léger

● Navigateur Web● écrans de l'application générés en temps réel côté serveur et téléchargés par le

poste client ■ client lourd

● écrans de l'application stockés ou générés sur le poste client ● une complexité croissante va de pair avec une taille croissante de l'application à

télécharger ■ client riche

● compromis entre client léger et client lourd ● Code IHM directement exécuté dans le navigateur

● Coordination○ cinématique des écrans○ invoque les appels de services○ erreurs et les exceptions ○ sessions / espace de travail utilisateur○ habilitations et les droits d’accès

● Services○ traitements qu’effectue l’application○ représente l’implémentation de la logique des cas d’utilisation ○ implémenter la logique métier ○ gérer la sécurité applicative ○ gérer les transactions étendues (processus, compensation) ○ gérer l’intégrité transactionnelle (transactions locales et distribuées)

7/19

Page 8: COURS MSI Architectures

DSCG : Management des SI Architectures

○ gérer les appels aux objets métiers de la couche Domaine ● Domaine

○ gère l'intégrité du modèle « métiers » ○ recense les objets métiers manipulées par l’application

● Persistance○ Données structurées ou non structurées, gérées entre autres via un SGBDR, annuaire

LDAP, transaction CICS, ...○ Fourniture des services de stockage des données, moteurs relationnels, bases objets,

bases XML...○ Création, Modification, Suppression d'occurrences des objets métiers

● Couches transverses○ Sécurité

■ SSO■ Authentification■ Gestion des habilitations■ Intégrité■ Non- répudiation

○ Services Techniques (Core Services) ■ gestion des traces statistiques et logs ■ gestion des erreurs ■ gestion des propriétés de configuration ■ gestion des fichiers de messages (internationalisation, messages d’erreurs) ■ monitoring...

MiddlewareLe middleware est un logiciel ou un ensemble de logiciels qui permet :

• de faire communiquer à travers un réseau des programmes pouvant être situés sur des machines différentes et pouvant fonctionner avec des systèmes d'exploitation différents ;

• de faciliter le travail des informaticiens pour l 'élaboration d'applications nouvelles en fournissant toute une série de services qui évitent du travail de programmation ;

• de masquer à l'utilisateur la répartition des données et des traitements d'une application.

Vue en niveaux

1 Tier1 Tier● binaire dans lequel s’exécutent toutes les couches, de la présentation à la persistance ● application sur système central ● données stockées sur un fichier local ou partagées sur un serveur de fichiers

2 Tier2 Tier● client/serveur " première génération"● utilisation de moteurs de bases de données relationnelles.

n Tiern Tier● mis en œuvre dans le cadre des projets web

L'architecture Web 3 tier

L'architecture 3 tier est utilisée dans les sites Web dits dynamiques, c'est à dire ceux qui nécessitent l'interrogation d'une base de Données. L'application la plus connue est le site commercial.

Au premier niveau, on trouve le client Web, au deuxième le serveur applicatif qui offre une vision métier de l'application et au troisième niveau les Données exploitées par le serveur applicatif.

8/19

Page 9: COURS MSI Architectures

DSCG : Management des SI Architectures

1. L'utilisateur (le client au sens strict du terme) interroge un site web commercial via son navigateur :

2. le client envoie la requête http://www.site_voyage.com.

3. Le serveur Web répond en envoyant une page au client.

4. Le client fait un choix parmi les diverses destinations proposées.

5. Le serveur Web en fonction du choix du client, lance une requête dans la Base de Données pour vérifier les opportunités à offrir

6. Le serveur Base de Données répond au serveur Web qui met en page les offres possibles

7. et envoie le résultat au Client qui l'affiche dans son navigateur.

Etc...

Les outils nécessaires pour faire fonctionner l'architecture précédente :

Sur le poste de Travail Sur le poste de Travail

Un logiciel de Client Universel : un navigateur ( Internet Explorer, Firefox, Opéra, ...)

Un langage de programmation : JavaScript, pour faire des contrôles en local.

Sur le serveur WebSur le serveur Web

Un logiciel serveur de pages Web (Apache ou IIS )

Un langage de traitement des pages (Java, PHP, ASP...)

Sur le Serveur de Gestion des DonnéesSur le Serveur de Gestion des Données

Un logiciel de Gestion de Base de données

Un langage de Manipulation des Données : SQL

Architecture J2E

9/19

Page 10: COURS MSI Architectures

DSCG : Management des SI Architectures

L'évolution des architectures logicielles

L'architecture en silos L'architecture en silos Derrière le concept d'urbanisation du système d'information se cache l'idée d'une informatique d'entreprise concevable à la manière d'une ville, par quartier présentant chacun une fonction particulière.

La première génération de système d'entreprise se présentait sous la forme d'une architecture dite "en silos". Chaque application ou base de données de l'entreprise reposait sur une plate-forme propriétaire, l'isolant du reste de l'écosystème informatique.

Ce modèle remonte aux débuts des grands systèmes centralisés, dans les années 1970 et à l'aube des années 1980, à une époque où les travaux de standardisation d'Unix au sein de l'Open Group en étaient à leurs balbutiements.

Le plat de spaghettis Le plat de spaghettis

Dans les années 1990, l'avènement des serveurs d'applications conduit à une multiplication de systèmes et applications technologiquement hétérogènes au sein du SI.

Un ensemble de briques dont il fallait gérer l'interopérabilité. Aux premiers middleware pour grands systèmes (CICS notamment), s'ajoutent alors d'autres moniteurs transactionnels propriétaires, de type Encina ou Tuxedo.

D'application propriétaire en application propriétaire, les départements informatiques empilent les couches et les systèmes. Des logiciels dont l'intégration est réalisée au fil des projets souvent sans vision à long terme. Les traitements par lots (batch) se multiplient sans grande rationalité, aboutissant à l'image d'un plate de spaghettis.

EAI, pour intégration d'applications d'entreprise EAI, pour intégration d'applications d'entreprise

Au batch, les outils d'EAI qui arrivent à la fin des années 1990 préfèrent un mode de transport des données par messages, une technique permettant de réduire les volumes transférés en découpant plus finement les échanges interapplicatifs.

Combinée à des fonctions de transformation et de routage des flux, l'EAI proposait une solution d'intégration intéressante face à l'hétérogénéité grandissante du système d'information. Les connecteurs permettant au final de faire dialoguer les applications.

Au modèle de l'EAI, s'est associé très vite celui de l'ETL, historiquement centré sur le traitement de gros volumes de données entre bases.

10/19

Page 11: COURS MSI Architectures

DSCG : Management des SI Architectures

Plates-formes d'EAI

Pour automatiser les échanges entre les environnements et applications hétérogènes du système d'information, l'entreprise peut recourir à une plate-forme EAI.

Les solutions d'EAI se divisent principalement entre deux catégories : les solutions tactiques et celles dites d'infrastructure.

Les plates-formes d'EAI intègrent le plus souvent des référentiels de processus métier ainsi qu'un ensemble de connecteurs techniques et applicatifs.

L'ensemble des plates-formes d'EAI supporte les services Web (WSDL, SOAP...) de même que les instructions et appel de programmes externes (C, DLL...).

Les solutions du marchéLes solutions du marché

Les solutions d'EAI (Enterprise Application Integration) se divisent principalement entre deux catégories : les solutions tactiques et celles dites d'infrastructure.

Alors que les solutions tactiques seront essentiellement déployées sur de petits périmètres, celles d'infrastructure englobent l'ensemble du système d'information.

5 des 10 solutions évaluées ici adressent les deux catégories de besoins.

La grande majorité des solutions s'articule autour d'un moteur de modélisation des processus, le plus souvent propriétaire.

Nature des solutions, modélisation et gestion des référentiels

Editeur/SolutionEAI

tactiqueEAI

d'infrastructure

Moteur de modélisation

natifGestion

BEA / Weblogic X Propriétaire mais en option

Uniquement via une solution BPM* externe

IBM / Websphere Business Modeler

X (propriétaire) Outil de BPM intégré

Intersystems / Ensemble X X (non propriétaire : Rational Rose)

Suivi graphique d'exécution et maintient de l'état

Microsoft / BizTalk (propriétaire)Définition, administration et

déploiement des règles de gestion

Oracle / BPEL Process Manager X(propriétaire : Oracle BPEL

designer)

Console Web d'administration, gestion des versions, multi-

instances

SeeBeyond (Sun) / Java Integration Suite X X (non propriétaire) Référentiel basé sur une base de

registre XML (UDDI***)

Sterling Commerce / Gentran Integration Suite

X X (propriétaire) Outil de BPM intégré

Sunopsis/ Sunopsis Active Integration Platform X

(non propriétaire : Common Format

Designer)

Uniquement via une solution BPM externe

Vitria / BusinessWare X X (propriétaire) Outil de BPM intégré

WebMethods / Webmethods Fabric

X X (propriétaire) Outil de BPM intégré

Les connecteursLes connecteurs

Moins de la moitié des solutions peuvent se connecter à la fois aux serveurs d'applications J2EE et à la plate-forme .NET de Microsoft.

Du point de vue des connecteurs - aussi bien techniques qu'applicatifs -, la variété est de mise... ce qui est naturel tant l'offre de connecteurs est absolument essentielle pour s'imposer sur ce marché où tout repose sur la capacité des solutions à s'interfacer avec un grand nombre d'applicatifs.

Une grande majorité de plates-formes d'EAI est par ailleurs dotée de kits de développements de connecteurs.

Connecteurs techniques et applicatifs

11/19

Page 12: COURS MSI Architectures

DSCG : Management des SI Architectures

Editeur/SolutionConnexion aux

serveurs d'applications

Connecteurs techniques

Connecteurs applicatifs

Kits de dév. natif

BEA / Weblogic J2EE et .NET JDBC, EDI, XML, SOAP, Telnet...

SAP, Oracle, Baan... x

IBM / Websphere Business Modeler J2EEJDBC, ODBC, EDI,

XML, LDAP...SAP, Siebel... x

Intersystems / Ensemble J2EE et .NETJDBC, EDI, XML, SOAP, Telnet...

Iway XTE Server (250

connecteurs)x

Microsoft / BizTalk .NET JDBC, EDI, XML... SAP, Oracle, Baan...

Oracle / BPEL Process Manager J2EE et .NET Via Iway Via Iway* Via Iway*

SeeBeyond (Sun) / Java Integration Suite

J2EE HTTP, FTP... SAP, Siebel... Via Iway*

Sterling Commerce / Gentran Integration Suite

J2EE et .NETJDBC, EDI, XML, SOAP, Telnet...

SAP, Siebel, i2, Vantive, Tuxedo

et Movex x

Sunopsis/ Sunopsis Active Integration Platform J2EE

JDBC, ODBC, EDI, XML, LDAP...

SAP/R3, Siebel, Hyperion, Essbase...

Vitria / BusinessWare J2EEEDI, SWIFT,

HIPAA...SAP, Siebel...

WebMethods / Webmethods Fabric J2EE et .NET JDBC, EDI, XML... SAP, Oracle, Lotus, Baan... x

*Iway est la filiale d'Information Builders spécialisée dans l'intégration. L'éditeur propose notamment un bus de service d'entreprise.

Prix et référencesPrix et références

Le transport de données entre applications hétérogènes est notamment assurée via des MOM* propriétaires ou bien par des messageries inter-applicatives asynchrones (serveur de message Java Message Service ou JMS).

Les plates-formes d'EAI sont interopérables avec les principaux systèmes d'exploitation du marché, sachant que celles bâties autour de JDK (Java Development Kit) ne connaissent aucune limitation d'installation.

On observe enfin un différentiel certain (et logique) en termes de tarification entre les solutions dites EAI tactique et EAI d'infrastructure, tandis que l'ajout de connecteurs ou de modules d'interfaces graphiques (modélisation des processus) fera grimper la facture.

Environnement d'exploitation et informations commerciales

Editeur/Solution MOM* Systèmes d'exploitation

Tarifs Clients

BEA / Weblogic Propriétaire Windows, Linux et Unix NCBouygues Telecom, CHU

Tours, Groupama...

IBM / Websphere Propriétaire Windows, Linux et Unix dès 104 000euros

NC

Intersystems / Ensemble JBOSS MQSeries

Windows (NT4, 2000 et XP), Linux (Red Hat,

SuSe) et Unix (Solaris, AIX, HP-UX...), Mac OSX

et Open VMS

dès 45 000euros

Arès, CHU Brest, CHU Roubaix...

Microsoft / BizTalkPropriétaire et

Serveur de message JMS

Windows (NT4, 2000 et XP) NC NC

Oracle / BPEL Process Manager

Serveur de message JMS et IBM

Websphere MQWindows, Linux et Unix

dès 42 000euros

Agence spatiale européenne, Gemplus,

Thyssen Krupp...

SeeBeyond (SUN) / Java Integration Suite

Serveur de message JMS

Windows, Linux, Unix, OS/390

NC SNCF, AXA, Carrefour...

12/19

Page 13: COURS MSI Architectures

DSCG : Management des SI Architectures

Sterling Commerce / Gentran Integration Suite

Serveur de message JMS

Windows (NT4, 2000 et XP), Linux (Red Hat,

SuSe) et Unix (Solaris, AIX, HP-UX...), iSeries

dès 40 000euros

Géodis, LVMH, Leica...

Sunopsis/ Sunopsis Active Integration Platform

Propriétaire (Sunopsis MQ)

Windows, Linux, Unix et tout OS disposant d'une

JDK 1.4

dès 95 000euros

Groupe Auchan, Cofidis, La mondiale...

Vitria / BusinessWare Propriétaire Windows, Linux et Unix NC NC

WebMethods / Webmethods Fabric

Serveur de message JMS et JBOSS

MQSeries

Windows, Linux, Unix, AS400 et Mac OSX

dès 100 000euros

EDF, France Télécom et Société Générale...

La gestion des processus métierLa gestion des processus métier

Au fil des années, les EAI ont été complétés par des couches d'exécution de processus métier (BPM). Adossée à la fonction d'orchestration d'applications des EAI, elles combinent des composants issus de divers systèmes de l'entreprise et en assurent l'exécution.

Le BPM permet ainsi de supporter des processus transverses, par exemple l'ouverture des dossiers clients dans une banque, ou encore la gestion de commande sur un site de e-commerce. Et ce de bout en bout en gérant les interactions avec les différentes applications (financière, CRM, etc.), ainsi qu'avec les responsables métier impliqués dans l'exécution ou la validation des différentes étapes. Au début des années 2000, de nombreux projets voient le jour sur ce terrain.

L'architecture orientée services L'architecture orientée services

Conceptualisée au début des années 2000 par le Gartner Group, l'architecture orientée services (SOA) renvoie à la conception d'une informatique composé de systèmes exploitables ou réexploitables au sein de processus métier par le biais d'interfaces standardisées.

Ce modèle s'apparente à un EAI normalisé, basé sur un système de connexion universel permettant de créer des catalogues de composants réutilisables de projet en projet. Quelques grands projets d'urbanisation basé sur ce modèle font déjà école, chez Essilor ou Bouygues Telecom notamment.

Le SOA est l’ensemble des normes, standards, processus, produits des différents acteurs de l’industrie informatique qui permet de mettre en place les infrastructures aptes à construire des applications composites, associant des éléments existants ou à développer, pour livrer de nouveaux services à ses clients, partenaires et fournisseurs. .

Plusieurs aspects caractérisent une architecture SOA dont le Bus de Services d’Entreprise, le Référentiel de Services ou le couplage souple d’applicatifs ou composants. La mutualisation, la réutilisation, la flexibilité, les processus transverses, la connectivité standardisée, les standards de communications ou de développement justifient couramment la mise en place du SOA.

Toute application du système d’information est traité comme un fournisseur de services.

Objectifs

Réutilisation et composition : partage de modules entre applications

13/19

Page 14: COURS MSI Architectures

DSCG : Management des SI Architectures

Pérennité : implique le support des technologies existantes et à venir

Évolutivité : la majeure partie des applications sont amenées à évoluer dans le temps afin de pouvoir répondre aux nouveaux besoins fonctionnels

ouverture et interopérabilité : partager des modules applicatifs entre plates-formes et environnements

Distribution : pouvoir utiliser ces modules à distance et les centraliser au sein de l'entreprise par exemple

performance

Caractéristiques essentielles

Service sans état : l'utilisation d'un service par un consommateur ne doit pas dépendre de son utilisation par d'autres consommateurs

Services peuvent etre composés : un service peut utiliser d'autres services. L'exécution d'un service est ININTERRUPTIBLE

• boite NOIRE (mode request / reply)

• message envoyé aux abonnés (mode event)

interface indépendante de la technologie d'implantation du service

l'utilisation d'un service doit se faire dans le cadre d'un contrat de service

SOA et SI

certaines fonctionnalités des applications existantes (Legacy : Héritage) converties en "service"

Progiciels ouvrent les fonctionnalités sous forme de services. les nouvelles applications deviennent

modulaires

évolutives

réutilisables

Exemple : l'approche Renault

AvantagesAvantages

s'affranchir du cloisennement traditionnel du SI en "Silos"

facilite l'automatisation des processus métiers transverses

ouverture du SI de l'entreprise sur l'extérieur (partenaires, marché, parties du SI externalisé)

Réponse plus rapide aux besoins "métier"

Résolution de la problématique "multicanal" avec mutualisation des fonctions de "Front Office" et de "Back Office"

14/19

Page 15: COURS MSI Architectures

DSCG : Management des SI Architectures

Intégration plus rapide des SI dans le cas d'une fusion

Le peer-to-peer Le peer-to-peer

D'environnements de services (au sens de composants applicatifs universels), la plupart des experts s'accorde à penser que les systèmes d'information s'orienteront dans l'avenir vers des architectures de terminaux intégrés.

Des galaxies informatiques dans lesquelles tout type d'appareils informatiques ou électroniques (jusqu'aux ordinateurs de bord, systèmes de sécurité d'immeuble, ascenseurs, etc.) pourront s'échanger des informations.

Un terrain sur lequel on compte déjà quelques projets. En France, ELM Leblanc (Filiale de Bosch) a notamment mis en place un dispositif de diagnostique à distance de chaudières.

Architectures Fonctionnelles

B2E : Business to EmployeeL'entreprise vers ses collaborateurs

Famille de besoin

Enjeux métiers et "business" Architecture cible

B2E

Mieux communiquer en interne entre collaborateurs

Construire un intranet

Mieux communiquer en interne et partager des référentiels communs

Accéder à l'intranet dans une optique "Accès au référentiel d'information"

Mieux communiquer en interne et partager des processus communs

Accéder à l'intranet dans une optique "Accès au référentiel applicatif"

Mieux communiquer avec les collaborateurs physiquement éloignés de l’entreprise

Accéder hors entreprise à l’intranet au travers un portail de services

B2C : Business to Consumer L'entreprise vers ses clients

15/19

Page 16: COURS MSI Architectures

DSCG : Management des SI Architectures

Famille de besoin

Enjeux métiers et "business" Architecture cible

B2C

Mieux communiquer avec les clients Accéder à l'Internet

Fournir des informations aux clients Etre présent sur l'Internet

Fournir des services aux clients Devenir Fournisseur d'accès Internet

Fournir des services aux clients Offrir l’accès à un bouquet de services

Donner aux clients la possibilité d’acheter en ligne

Offrir l’accès des services marchands

16/19

Page 17: COURS MSI Architectures

DSCG : Management des SI Architectures

B2B : Business to Business L'entreprise vers ses partenaires (fournisseurs, distributeurs...)

Famille de besoin

Enjeux métiers et "business" Architecture cible

Donner aux clients la possibilité d’acheter en ligne

Offrir l’accès des services marchands

B2B

Mieux échanger avec les partenaires Mettre en place et/ou accéder à des services web EDI

Mieux travailler avec les partenaires Mettre en place et/ou accéder à un extranet

Mieux commercer avec les clients potentiels

Accéder à une place de Marché

Mieux commercer avec les fournisseurs potentiels

Mettre en place une Place de Marché

Famille de besoin

Enjeux métiers et "business" Architecture cible

Toutes Bien conduire les projets

Intégrer l’ensemble des services dans une architecture cohérente

Bien exploiter les systèmes Animer les sites et développer les contenus

Cloud Computing L'informatique dans les nuages ( Cloud Computing) consiste en une interconnexion et une coopération de ressources informatiques, situées au sein d’une même entité ou dans diverses structures internes, externes ou mixtes. et dont les modes d’accès sont basés sur les protocoles et standards Internet.

Les solutions Cloud reposent sur des technologies de virtualisation et d’automatisation. Trois caractéristiques clés du Cloud le différencient des solutions traditionnelles :

• Services avec mise à jour en continu et automatique, en lieu et place de produits technologiques

• Self-service et paiement à l’usage (en fonction de ce que l’on consomme)

17/19

Page 18: COURS MSI Architectures

DSCG : Management des SI Architectures

• Mutualisation et allocation dynamique de capacité (adaptation élastique aux pics de charge)

Pour les entreprises utilisatrices il s'agit d'une forme d'infogérance où on loue un droit d'usage de ressources informatique de différentes natures et où les usagers ignorent où sont stockées leurs informations et les ressources qu'ils utilisent. Les ressources sont accessibles via Internet.

Le recours à des prestations externalisées apporte une visibilité des coûts pour une meilleure maîtrise et permet de bénéficier de l'expertise du prestataire pour obtenir un service de qualité au coût le plus juste. De plus, il est plus facile d'ajuster la ressource aux besoins par négociation avec un prestataire externe que lorsque la prestation est réalisée en interne.

Au-delà de l'infogérance, le cloud computing permet d'externaliser non seulement la gestion des ressources sur site mais de déporter celles-ci « dans le nuage ».

Les formes de Cloud ComputingLes formes de Cloud Computing

• IaaS (Infrastructure as a Service) : concerne les serveurs, moyens de stockage, réseau,...Le modèle IaaS consiste à pouvoir disposer d’une infrastructure informatique hébergée. L’accès à la ressource est complet et sans restriction, équivalent de fait à la mise à disposition d’une infrastructure physique réelle. Ainsi une entreprise pourra par exemple louer des serveurs Linux, Windows ou autres systèmes, qui tourneront en fait dans une machine virtuelle chez le fournisseur de l’IaaS.

• PaaS (Platform as a Service) : concerne les environnements middleware, de développement, de test,... Le modèle PaaS consiste à mettre à disposition un environnement prêt à l’emploi, fonctionnel et performant, y compris en production ; l’infrastructure hébergée étant totalement transparente. Par exemple une plate-forme PaaS peut être un environnement de développement et de test.

• SaaS (Software as a Service) : concerne les applications d’entreprise : CRM, outils collaboratifs, messagerie, BI, ERP,... Le modèle SaaS permet de déporter une application chez un tiers. Ce modèle convient à certaines catégories d’applications qui se doivent d’être globalement identiques pour tout le monde, la standardisation étant un des principes du cloud. Le terme SaaS évoque bien un service dans le sens où le fournisseur vend une fonction opérationnelle, et non des composants techniques requérant une compétence informatique pour l’utilisateur.

Différents modèles de CloudDifférents modèles de Cloud• Cloud privé/privatif : Il peut s’agir d’un « nuage » interne à la DSI (propriétaire des

infrastructures) ou d’un Cloud entièrement dédié et accessible via des réseaux sécurisés, hébergé chez un tiers, mutualisé entre les différentes entités d’une seule et même entreprise. Ouvert aux partenaires privilégiés de l’entreprise (fournisseurs, bureaux d’études, grands

18/19

Page 19: COURS MSI Architectures

DSCG : Management des SI Architectures

clients, institutions financières, prestataires-clés...) voire à un groupement professionnel, le Cloud peut être également de type « communautaire ».

• Cloud public : Il est externe à l’organisation, accessible via Internet, géré par un prestataire externe propriétaire des infrastructures, avec des ressources partagées entre plusieurs sociétés.

• Cloud hybride : Ici, il s’agit de la conjonction de deux ou plusieurs Cloud (public+privé) amenés à « coopérer », à partager entre eux applications et données.

19/19