GROUPE TECHNIQUE OPENGCOS7

1
GROUPE TECHNIQUE OPEN/GCOS7
Comparaison Serveurs dApplication
J2EE et Moniteurs Transactionnels (TDS
GCOS7) Christian GOURSAUD / MINISTERE DE
LINTERIEUR OCTOBRE 2003
2
1) LES DIFFERENTES ARCHITECTURES TRANSACTIONNELLES

• Constantes des applications transactionnelles
• des échanges interactifs avec les utilisateurs,
• des traitements,
• des données.
• Évolution des architectures dans le temps
• années 1980
• architecture centralisée (Moniteurs
  Transaction.).
• années 1990
• architecture à 2 niveaux (Client/Serveur).
• années 2000
• architecture N tiers
• (Serveurs dapplication (SA) Internet).

3
1.1 - ARCHITECTURE CENTRALISEE(Mainframes)

• Applications monolithiques
• tous les constituants (présentation, données,
• traitements), situés sur un même serveur,
• accès par des terminaux passifs.
• Règne des moniteurs TP (TDS ou CICS).
• Applications dites patrimoniales (legacy)
• capital de lentreprise en termes
• financiers,
• de compétences,
• de connaissances,
• stratégiques (détiennent les règles de gestion)
• Encore très nombreuses aujourdhui.
• Leur migration est longue et coûteuse .

4
1.2 - ARCHITECTURE 2 NIVEAUX(Client/Serveur)

• Traitements séparés entre client et serveur.
• Client
• tâches de présentation (interface graphique),
• logique métier.
• Serveur
• hébergement SGBD,
• traitements des requêtes clients.
• Gros problèmes de
• coordination et synchronisation des mises à jour
• entre le système central et tous les postes
  clients,
• cohabitation de nombreux logiciels sur le
  client.
• Coûts et délais prohibitifs de qualification,
  dintégration et déploiement.
• Architecture non étudiée ici.

5
1.3 - ARCHITECTURE 3 NIVEAUX(N TIERS)

• Le système dinformation doit évoluer
• Nouveaux besoins (NTIC) utilisateurs et D.A.
• Obligations réglementaires.
• Nouveaux utilisateurs (clients, usagers,
  partenaires).
• Interopérabilité entre différentes applications.
• Réduction des coûts et délais de
• développement et maintenance,
• déploiement (vs Client/Serveur).
• Opportunité Internet et nouveaux MIDDLEWARES
• 3 niveaux logiques distincts (séparation entre
  les
• parties stables et celles qui peuvent évoluer)
  
• niveau 1 Front-Office (interaction
  utilisateur),
• niveau 2 Middle-Office (domaine des SA),
• niveau 3 Back-Office (SGBD, mainframes).

6
2) SERVEURS DAPPLICATION VS MONITEURS
TRANSACTIONNELS

• Avertissements
• Comparaison entre SA/J2EE et TDS/GCOS7.
• Critères identifiés pour le choix dun SA,
• puis comparés aux critères TDS les plus
  proches.
• Énoncée avantages / inconvénients de chacun.
• Mise en évidence des caractéristiques communes
• (souvent une différence de vocabulaire).
• Architectures conçues à 25 ans dintervalles.
• Besoins utilisateurs relativement différents.
• Support technologique très différent.
• Portée fonctionnelle différente.
• Différence de maturité.
• Tous les critères nont pas le même poids .
• Comparaison forcément  arbitraire 

7
A - ARCHITECTURE GENERALE

• A.1 - Structure

TDS
SA (J2EE)

• Application monolithique,
• autonome, complète.
• Centralisée (1 seul serveur
• (mainframe DPS7000).
• 1 seul OS (GCOS7).
• 1 seule administration.
• Presque tous les composants
• et les services sont intégrés.
• Très peu de dépendance
• avec des composants
• externes.

• Le serveur dapplication
• niveau 2 de larchitecture.
• Support dapplications
• naturellement distribuées,
• sur un nombre variable de
• serveurs (autant dOS).
• Un SA J2EE est en soi un
• assemblage de composants.
• Utilisation intensive de
• fonctions et de services
• externes (API, connecteurs).

8
A - ARCHITECTURE GENERALE

• A.2 - Facilité de mise en uvre et dévolution

TDS
SA (J2EE)

• Architecture maîtrisée, facile
• à concevoir, à configurer,
• à administrer, à contrôler.
• 1 seul niveau logique.
• 1 seul niveau physique.
• Évolution simple (génération
• TDS facile et rapide).
• Tous les composants étant
• intégrés au TDS, pas de
• problème de cohabitation.
• Par contre, évolutions
• fonctionnelles coûteuses
• (programmation COBOL).

• Architecture très complexe
• (architecte et/ou intégrateur).
• Multiplication des niveaux
• logiques et physiques.
• Administration complexe.
• Qualification longue et
• complexe à chaque évolution
• de lun des composants.
• Mais, évolutions fonctionnelles
• facilitées par la programmation
• objet (modularité, réutilisation).
• Grande flexibilité.

9
A - ARCHITECTURE GENERALE

• A.3 - Standards et normes

TDS
SA (J2EE)

• GCOS7 est un système
• propriétaire Bull.
• TDS nest donc pas un
• produit standard.

• Standard J2EE.
• Langage unique Java.
• Développement J2EE ouvert
• (Sun, IBM, HP, Oracle, ).
• Protection investissements.
• Mais évolutions fréquentes.
• Effets de mode.

10
A - ARCHITECTURE GENERALE

• A.4 - Communications

TDS
SA (J2EE)

• Réseau propriétaire DSA.
• La meilleure des sécurités.
• Cohabitation avec des
• réseaux TCP/IP.
• Encapsulation ISO/DSA
• sous IP.
• TDS TCP/IP.

• Protocole unique TCP/IP
• (protocole dInternet).
• Standard, universel.
• Problèmes de
• maîtrise,
• performances,
• supervision,
• régulation,
• sécurité.

11
B - CONCEPTION / DEVELOPPEMENT

• B.1 - Programmation

TDS
SA (J2EE)

• Traditionnelle, procédurale,
• simple, performante (COBOL).
• Unité de programmationTPR
• Séparation des données
• et des traitements.
• Évolutions fonctionnelles
• longues et complexes.

• Technologie Objet (Java).
• Intégration étroite entre
• données et traitements dans
• un objet (encapsulation).
• Données de session (temp).
• Programmation riche mais
• complexe (experts).
• Très bonne productivité des
• développeurs
• nombreux services,
• réutilisation,
• Internet.

12
B - CONCEPTION / DEVELOPPEMENT

• B.2 - Modularité

TDS
SA (J2EE)

• Possible, non implicite.
• Programmation structurée
• (COBOL 85).
• Code réutilisable (S/prog).
• Code partageable (SM).
• Mais faible réutilisation.

• Implicite, systématique (Objet)
• Réutilisation (héritage)
• récupération en interne,
• achat de composants,
• recherche sur Internet.
• Incorporation de routines
• écrites en C ou C
• (interface JNI).

13
B - CONCEPTION / DEVELOPPEMENT

• B.3 - Séparation des traitements

TDS
SA (J2EE)

• Tous les traitements sont
• intégrés dans les TPR.
• Possibilité de centraliser et
• disoler certaines fonctions
• structuration (PERFORM),
• sous-programmes linkés
• aux TPR ou à TDS (USE).

• Implicite et formelle.
• Niveau 1 Interface utilisateur,
• serveur Web.
• Niveau 2 logique présentation,
• applicative, métier,
• conteneur Web.
• Niveau 3 logique métier et
• persistance des données,
• conteneur EJB.
• Niveau 4 SGBD et règles de
• gestion,
• serveur de données.

14
C - GESTION DES ECHANGES

• C.1 - Présentation

TDS
SA (J2EE)

• Assurée par FORMS.
• Grilles formatées (statiques).
• Client léger
• terminal passif ou
• PC en émulation,
• déport des grilles (TCS),
• téléch. émulateur (PC).
• Lien très étroit grille - TPR.
• Webisation possible
• émulation HTML,
• transformation en HTML,
• programmation HTML.

• Assurée par le serveur Web
• (N1), le SA neffectuant que
• louverture vers ce serveur Web.
• Client léger avec navigateur.
• Génération de pages HTML (ou
• XML ou XSL) dynamiques ou
• parfois statiques.
• Cette séparation garantit une
• totale indépendance entre la
• couche présentation et les
• traitements.

15
C - GESTION DES ECHANGES

• C.2 - Gestion des sessions et des échanges

TDS
SA (J2EE)

• Échanges assurés par
• serveur Web (Apache, IIS),
• conteneur Web (Tomcat)
• applications simples,
• conteneur EJB (JBoss,
• JOnAS, WebLogic Express)
• applications complexes.
• Conteneurs Web EJB SA.
• Principaux SA WebLogic,
• WebSphère, Oracle9iAS.
• Sessions gérées par Servlets.
• Contextes gt objets de session.
• Moteurs de Servlets ou JSP.

• Totalement intégrée à TDS.
• Sessions permanentes
• (du LOGON au LOGOUT).
• Multiplexage des ressources
• niveau GCOS7 ou TDS,
• montée en charge,
• performances stables.
• Utilisateurs actifs
• mappés (voie de simu)
• attente sur sémaphore.
• Utilisateurs inactifs swappés.
• Échanges implicitement
• synchrones.

16
C - GESTION DES ECHANGES

• C.3 - Échanges asynchrones

TDS
SA (J2EE)

• Les serveurs dapplication avec
• composante EJB, peuvent gérer
• des échanges synchrones,
• des échanges asynchrones.
• Les échanges asynchrones sont
• assurés par le connecteur JMS
• (Java Message Service).
• Ce sont des échanges MOM
• (Middleware Oriented Message)
• parfois aussi performants,
• mais plus sécurisants,
• que les échanges synchrones
• (accès bases distribuées).

• Implicitement synchrones.
• Échanges asynchrones
• possibles avec
• terminal passif ou virtuel
• imprimante,
• autre application,
• via transactions spawnées.
• Échanges asynchrones avec
• MQSeries,
• OracleMQ,
• ...
• via la solution MOM Connect.

17
D - TRAITEMENTS ET DONNEES

• D.1 - Gestion des transactions

Propriétés ACID

• Pour que la qualité dune transaction soit
  réputée indiscutable, elle
• doit respecter les 4 critères (initiales ACID)
  suivants
• Atomicité une transaction doit être exécutée
  totalement ou pas
• du tout (COMMIT en cas de fin normale, sinon
  ROLLBACK).
• Cohérence une transaction comprenant des
  mises à jour doit
• faire passer la (ou les) base(s) quelle
  accède, dun état cohérent
• à un autre état cohérent.
• Isolation le traitement dune transaction ne
  doit pas être
• affecté par dautres traitements effectués en
  même temps.
• Durabilité lensemble des mises à jour
  résultant dune
• transaction terminée normalement doit résister
  à un incident.
• Le résultat doit être définitif et visible de
  lextérieur.

18
D - TRAITEMENTS ET DONNEES

• D.1 - Gestion des transactions

TDS
SA (J2EE)

• Les serveurs dapplication sont
• conçus pour respecter les
• propriétés ACID mais
• complexité du distribué,
• techniques non matures,
• variantes, insuffisances.
• Transactions naturellement
• distribuées (accès à différents
• SGBD par des connecteurs),
• mais également centralisées
• grâce au connecteur JTA
• (Java Transaction API).
• Commit à 2 phases (Drivers XA).

• Caractéristique fondamentale
• du TDS qui garantit les
• propriétés ACID grâce à
• son gestionnaire GAC,
• ses reprises sur incident,
• ses journaux,
• sa gestion des CU, ...
• Transactions implicitement
• centralisées (locales).
• Possibilité dexécuter des
• transactions distribuées avec
• autre TDS (XCP1),
• TDS ou CICS (XCP2).

19
D - TRAITEMENTS ET DONNEES

• D.2 - Accès aux données

TDS
SA (J2EE)

• Les données pérennes sont
• gérées au niveau 3 (4) par des
• SGBD (ou par des applications
• patrimoniales), donc hors des
• serveurs dapplication.
• Principaux SGBD
• éditeurs (Oracle, Sybase),
• libres (Postgres, MySQL).
• Laccès aux SGBD se fait par
• des connecteurs JDBC (Java
• DataBase Connectivity).
• Le changement de SGBD est
• (relativement) facile.

• Accès direct aux bases de
• données UFAS et IDS2.
• Verbes de manipulation
• inclus dans COBOL.
• Fichiers et SGBD éprouvés,
• fiables et performants.
• Accès possible aux SGBDR
• Oracle (V7) ou SQL Server,
• mais de manière indirecte
• (précompilation de primitives).
• Changement pour un autre
• SGBD quasiment impossible.

20
D - TRAITEMENTS ET DONNEES

• D.3 - Protection des données

TDS
SA (J2EE)

• Elles est assurée directement
• par le SGBD (ou lapplication
• patrimoniale).
• Elles est (le plus souvent)
• comparable à celle fournie par
• TDS.

• Elle est garantie par
• les procédures de
• sauvegardes/restauration
• des fichiers,
• les journaux BEFORE
• et AFTER,
• les outils de reprise sur
• incident
• (RERUN, ROLLBACK,
• ROLLFORWARD),
• ...

21
D - TRAITEMENTS ET DONNEES

• D.4 - Accès concurrent (niveau données)

TDS
SA (J2EE)

• Il est assuré sur les données
• pérennes conjointement par le
• SGBD et le mode de
• programmation des transactions.
• JDBC spécifie 4 niveaux
• disolation des transactions
• READ-UNCOMMITED (sale),
• READ_COMMITED (stat),
• REPETABLE_READ (shared),
• SERIALISABLE (exclusive).
• Un utilisateur peut donc être
• confronté aux incohérences
• dues à la lecture sale.

• Il est assuré par GAC, au
• niveau enregistrement
• physique (CI), sur les fichiers
• UFAS et les bases IDS2.
• GAC permet
• la lecture statistique,
• la lecture partagée,
• la lecture exclusive.
• Dans tous les cas, TDS
• garantit lutilisateur contre les
• incohérences dues à la
• lecture sale (DIRTY READ).

22
D - TRAITEMENTS ET DONNEES

• D.5 - Accès concurrent (niveau TX)

TDS
SA (J2EE)

• Voir point précédent.

• Il est assuré par TDS grâce à
• la possibilité de rendre des
• transaction totalement ou
• partiellement non
• concurrentes les unes par
• rapport aux autres
• TX1 MANUALLY NON
• CONCURRENT WITH TX2.
• Jamais de lectures sales.

23
D - TRAITEMENTS ET DONNEES

• D.6 - Persistance des données (niveau Objets)

TDS
SA (J2EE)

• Par principe les données objets
• sont éphémères et volatiles.
• Elles nexistent quen mémoire.
• Durée de vie la session.
• Pour les conserver, techniques
• de persistance des données
• (proches des techniques
• traditionnelles des mainframes)
• accès pessimiste (exclusif),
• accès optimiste (partagé).
• Mais techniques immatures, non
• standard, complexes, multiples.

• La notion de persistance
• ne sapplique quaux données
• objets.
• Cette notion nexiste ni dans
• TDS ni dans GCOS7.
• TDS gère cependant, en toute
• intégrité, des données
• temporaires (de type
• variables de contextes
• variables locales (STACK)
• TX-STORAGE,
• COMMON-STORAGE,
• SHARED-STORAGE, ...

24
D - TRAITEMENTS ET DONNEES

• D.6 - Persistance des données (niveau Objets)

TDS
SA (J2EE)

• Le concepteur doit choisir entre
• une persistance gérée
• au niveau EJB (EJB entity),
• au niveau du SGBD,
• par le développeur.
• Il existe des Frameworks de
• persistance (Toplink dOracle).
• SUN avec Java propose une
• solution non standard (JDO).
• Attention aux dénominations
• accès optimiste naïf,
• accès optimiste vérifié.
• Cest encore un réel problème.

25
E - SERVICES COMPLEMENTAIRES

• E.1 - Accès aux applications patrimoniales

TDS
SA (J2EE)

• Les serveurs dapplications
• peuvent se connecter à tout type
• dapplications patrimoniales à
• condition quil existe un
• connecteur spécifique de type
• JCA (Java Connector Architecture).
• Solutions daccès à GCOS7
• HOOX (solution générique)
• JTDS (accès TDS en mode
• ligne)
• JUFAS (accès fichiers UFAS)
• JESP7 (accès TDS mono-
• échange).

• TDS sait accéder à
• dautres TDS via 2LTP,
• XCP1 ou XCP2/CPI-C.
• dautres transactionnels
• étrangers comme CICS
• ou TUXEDO, via CPI-C,
• un DTF GCOS6 vu comme
• un terminal.
• SOCKG7 permet à un TDS (vu
• comme un client) déchanger
• des données avec des
• applications SOCKET dun
• système ouvert (serveur).

26
E - SERVICES COMPLEMENTAIRES

• E.2 - Sécurité logique

TDS
SA (J2EE)

• Fragilité du réseau IP,
• universalité dInternet,
• nombreux risques dattaques.
• Les nouvelles architectures
• doivent donc mettre en place
• des pare-feu,
• du cryptage (SSL, TrustWay),
• des ruptures de protocole,
• des échanges asynchrones.
• Les conteneurs EJB proposent
• les service JAAS et JACC.
• Possibilité dun système de PKI,
• certificat, annuaire, carte à puce.

• Sécurité du protocole DSA.
• Sécurités de base de GCOS7
• FIRMWARES (exceptions,
• RING, étanchéité tâches)
• logicielles (codes de
• retour, ABORT, CRASH),
• volumes (AVR, droits),
• fichiers (droits, CATALOG,
• GAC, journaux).
• Sécurité TDS (codes autorité)
• Solutions intégrées
• (PW7, Sécur Access).
• Solution externe (OpenAccess)

27
E - SERVICES COMPLEMENTAIRES

• E.3 - Logiciels libres

TDS
SA (J2EE)

• Quelques références de
• serveurs dapplication libres
• Tomcat (conteneur Web),
• Jetty (conteneur Web),
• JBoss (conteneur EJB),
• JOnAS (conteneur EJB),
• etc.
• Attention aux problèmes de
• montée en charge,
• de support,
• de documentation.

• Par définition, il ny a pas de
• logiciels libres dans lunivers
• GCOS7.

28
E - SERVICES COMPLEMENTAIRES

• E.4 - Outillage complémentaire

TDS
SA (J2EE)

• Progiciels du marché
• (LOAD-RUNNER ou OPENSTA).
• Quantité de services internes
• (dans les conteneurs EJB) ou
• externes (connecteurs), sans
• équivalent sous TDS
• service de nommage ou
• dannuaire (JNDI),
• gestion des e.mails
• (Javamail) ou de pièces
• jointes (JAF),
• XML, SOAP, WebServices,
• Mais attention à la prolifération.

• Simulateur de charge TILS
• (mais aussi outil du monde
• ouvert tel que LOAD-RUNNER)
• Surveillance système SBR.
• Débugging interactif PCF.
• TRACE TDS.
• Commandes maître TDS en
• langage évolué (GCL).
• Quelques progiciels GCOS7
• spécifiques (peu nombreux et
• figés).
• ...

29
F - CRITERES FONCTIONNELS

• F.1 - Disponibilité, fiabilité, performance

TDS
SA (J2EE)

• Les SA ont 5 ans dexpérience.
• Ils ne sont quau début du
• processus de maturation.
• A charge égale (nb. utilisateurs,
• débit), une application J2EE
• nécessite des ressources (CPU)
• très supérieures à celles que
• demande un TDS.
• Arrêt fréquent des applications
• pour anticiper (voire corriger)
• les pannes, les saturations,
• les blocages.
• Haute-dispo matériel ou SGBD.

• Fiabilité et robustesse de
• GCOS7 reconnues.
• LInterior Decor de GCOS7
• conçu pour le transactionnel.
• Couple TDS/IDS2, lun des
• tous meilleurs au monde.
• Avec 25 ans dexpérience,
• TDS est beaucoup plus mûr et
• plus stable que tous les SA.
• Disponibilité remarquable.
• Solutions de haute-dispo
• (TDS-HA, RDDF7, ).

30
F - CRITERES FONCTIONNELS

• F.2 - Montée en charge (scalabilité)

TDS
SA (J2EE)

• Tous les SA nont pas les
• mêmes capacités de support de
• la montée en charge.
• Les produits libres moins que les
• produits éditeurs (benchmark).
• Assurée par la multiplication des
• instances logicielles (horiz.) ou
• des serveurs physiques (vertic.).
• Technique du Clustering.
• Impacts sur ladministration.
• Au sein des SA, multithreading.
• Plus doptions dévolutivité que
• TDS, mais pb. de performance.

• TDS bénéficie de lexcellence
• de Bull et de GCOS7 dans la
• gestion du multiprocessing.
• Gestion très sophistiquée des
• CPU par le DISPATCHER
• (piloté via ARM).
• Processus TDS performant
• de gestion des voies de simu.
• Ce double multiplexage
• permet une montée en charge
• maîtrisée.
• Surveillance fine par SBR.

31
F - CRITERES FONCTIONNELS

• F.3 - Maturité

TDS
SA (J2EE)

• Les SA sont encore globalement
• peu matures.
• Assemblage de nombreux
• composants internes.
• Énorme dépendance avec de
• nombreux composants externes.
• Évolutions fonctionnelles
• fréquentes (effets de mode).
• Il faudra attendre plusieurs
• années pour quils acquièrent
• une maturité comparable à celle
• des moniteurs transactionnels.

• Interdépendance profonde de
• TDS avec GCOS7 depuis plus
• de 25 ans.
• La très grande maturité du
• TDS nest plus à prouver.

32
F - CRITERES FONCTIONNELS

• F.4 - Portabilité

TDS
SA (J2EE)

• Portabilité du code sur de
• nombreuses plates-formes (y
• compris certains Mainframes).
• Protection totale des
• investissements.
• Mais attention à lutilisation
• dAPI propriétaires ou de Plug-in
• spécifiques sur le navigateur.

• Par principe, portabilité
• inexistante.
• TDS est un produit
• propriétaire limité aux seules
• plates-formes supportant
• GCOS7.
• Migrations complexes,
• imparfaites et coûteuses.

33
F - CRITERES FONCTIONNELS

• F.5 - Pérennité

TDS
SA (J2EE)

• La pérennité des SA dépend
• de léditeur, pour les
• produits propriétaires,
• de la communauté, pour les
• produits libres.
• Mais le risque est limité avec
• des produits respectant le
• standard J2EE (portabilité ou
• changement pour un produit
• similaire).

• GCOS7 a 30 ans.
• TDS a 25 ans.
• Grâce à Diane (puis grâce à
• Novascale), les applications
• GCOS7 pourront encore
• tourner pendant au moins
• 10 ans.

34
G - CRITERES ORGANISATIONNELS

• G.1 - Compétences

TDS
SA (J2EE)

• Les compétences SA
• modélisation et
• programmation objet,
• langage Java,
• nouvelles architectures,
• sont encore rares (parce que
• très complexes), mais en forte
• progression.
• Elles sont plutôt dans les SSII et
• chez les constructeurs que
• chez les utilisateurs (évolution
• parfois difficile des personnels).
• Formations nombreuses.

• Pendant très longtemps, les
• compétences TDS ont été
• nombreuses, de haut niveau
• conception MERISE,
• développement COBOL,
• exploitation GCOS7,
• chez Bull, chez les
• utilisateurs, dans les SSII.
• Les formations étaient
• nombreuses et de qualité.
• Aujourdhui, les unes comme
• les autres deviennent de plus
• en plus rares.

35
G - CRITERES ORGANISATIONNELS

• G.2 - Support utilisateur

TDS
SA (J2EE)

• La qualité (voire lexistence) de
• support pour les SA dépend tout
• à fait des produits.
• Elle est fonction
• de léditeur, pour un produit
• propriétaire,
• du dynamisme de la
• communauté ou de
• lappartenance à un
• consortium (JOnAS avec
• ObjectWeb),
• pour un produit libre.

• Support TDS et GCOS7 chez
• Bull en diminution, mais
• encore bonne qualité et
• bonne réactivité.
• Cependant, les besoins en
• corrections ou évolutions sont
• de plus en plus rares.

36
G - CRITERES ORGANISATIONNELS

• G.3 - Aspects financiers

TDS
SA (J2EE)

• Les applications NTIC (dont les
• SA ne sont quun exemple) se
• caractérisent par un empilage
• de produits logiciels,
• de serveurs physiques,
• de briques de sécurité,
• etc.,
• Elles posent des problèmes
• multiples de licensing
• SGBD (Oracle),
• Intersticiels (TUXEDO),
• SA (WebLogic),
• Compétences rares et chères.

• TDS est une solution
• propriétaire.
• Les coûts sont réputés
• élevés, mais ils sont identifiés,
• stables et maîtrisés.
• En réalité, quand on les
• compare avec ceux des
• applications NTIC,
• et si on les compare
• complètement,
• ils sont tout à fait compétitifs,
• voire tout à fait avantageux.

37
3) CONCLUSION

• TDS et les SA ont beaucoup de points communs.
• Mais ils sont pourtant de nature bien
  différente.
• TDS est au cur du Back-Office.
• Les SA sont au cur du Middle-Office.
• TDS possède une architecture centralisée,
• Les SA permettent de bâtir des applications
  distribuées.
• Utilisateurs TDS internes, identifiés (nombre et
  sécurité),
• Utilisateurs NTIC externes, non identifiés, non
  maîtrisés.
• La comparaison est donc effectivement difficile.

38
3) CONCLUSION

• Mais,
• Il nest ni nécessaire de vouloir les opposer ni
  de
• vouloir systématiquement remplacer lun par
  lautre.
• Le SI doit évoluer mais il nest pas
  indispensable de jeter
• nos applications patrimoniales, qui sont la
  mémoire et la
• richesse de lentreprise.
• Il faut tirer profit du meilleur des deux
  mondes, en
• intégrant, chaque fois que cest possible, les
  applications
• TDS comme dernier niveau des nouvelles
  architectures.

39
3) CONCLUSION

• Merci de votre attention.