Rapport de stage 2003 -...

Rapport de stage FIIFO 3éme année –Emmanuel Digiaro 2003

Préambule

Le deuxième semestre de la troisième année d’étude à la FIIFO correspond à une période deformation en entreprise d’une durée de vingt-quatre semaines que j’ai effectué dans la société d’éditionde logiciel DK-Soft, située à Nanterre dans les Hauts-de-Seine (92).

Ce stage s’est effectué au sein d’une équipe opérationnelle d’ingénieurs et de techniciens, sur unprojet de recherche et de développement.

Ce rapport est la synthèse de ces vingt-quatre semaines de stage.

Remerciements

Je tiens à remercier toute l’équipe de DK-Soft pour m’avoir accueilli et pour m’avoir sifacilement intégré dans leur équipe.

Je remercie plus particulièrement, mon tuteur Olivier Marois pour m'avoir proposé ce stage,pour sa disponibilité, ses conseils, et son aide tout au long du stage.

Je remercie également Laurent Maury pour ses précieuses informations, son assistance et sesconseils.

Egalement messieurs Frédéric Allain, Laurent Berruel et Gilles Puglièse, pour leur accueil, leursoutien et leur bonne humeur. Ils ont su me donner d’excellents conseils pour ma vie professionnelle.

sur 35


Table des matières

PRÉAMBULE........................................................................................................................................................................... 1

REMERCIEMENTS.................................................................................................................................................................1

TABLE DES MATIÈRES........................................................................................................................................................ 2

PRÉSENTATION DE L'ENTREPRISE.................................................................................................................................3

A.ORGANISATION........................................................................................................................................................................3B.PRÉSENTATION DE L’ACTIVITÉ....................................................................................................................................................3

1.Qu’est ce que le Mainframe ?........................................................................................................................................32.Le savoir faire de DKSoft...............................................................................................................................................4

II.PRÉSENTATION DU STAGE............................................................................................................................................ 6

A.OBJECTIF DU STAGE................................................................................................................................................................. 6B.PLAN DU STAGE.......................................................................................................................................................................6C.OBJECTIF POUR DKSOFT..........................................................................................................................................................6

III.PHASE 1 : DÉVELOPPEMENT D’UNE APPLICATION JAVA................................................................................. 7

A.DESCRIPTION DE LA GAMME DE PRODUITS « MAINFRAME/EASYBUS »..............................................................................................7B.ENVIRONNEMENT TECHNIQUE ...................................................................................................................................................7C.DÉVELOPPEMENT DE JSSM......................................................................................................................................................9

1.Mise en œuvre du protocole......................................................................................................................................... 102.Analyse UML................................................................................................................................................................123.Un mot sur le codage................................................................................................................................................... 13

IV.PHASE 2 : DÉVELOPPEMENT D’UN ADAPTATEUR DE RESSOURCES............................................................14

A.LE PROTOCOLE 2-PHASES COMMIT.......................................................................................................................................... 14B.LES SERVEURS D’APPLICATION................................................................................................................................................. 16

1.Définition de l'architecture 3-tiers............................................................................................................................... 162.Avantages d'une architecture 3-tiers............................................................................................................................163.Comprendre le fonctionnement du serveur d’application........................................................................................... 174.Qu’est ce qu’un moniteur transactionnel.....................................................................................................................18

C.DÉVELOPPEMENT DE L’ADAPTATEUR DE RESSOURCES...................................................................................................................201.Les types de transaction j2ee....................................................................................................................................... 202.La déclaration des transactions................................................................................................................................... 213.JCA : Les contrats et les interfaces à implémenter......................................................................................................224.Le codage du connecteur JSSM................................................................................................................................... 235.Paramétrage et déploiement........................................................................................................................................ 246.Installation sur le serveur IBM Websphere v5.0..........................................................................................................24

V.CONCLUSION.................................................................................................................................................................... 26

A.APPORTS TECHNIQUES............................................................................................................................................................ 26B.APPORTS HUMAINS.................................................................................................................................................................26

sur 35


Présentation de l'entreprise

Dynamic Knowledge Software SA ( ) est un éditeur français de logiciels basé à Nanterre(Hauts-de-Seine). Fondée en juin 2000 par un groupe d’experts (architectes, consultants etdéveloppeurs) dans le domaine des architectures distribuées, l’entreprise s’intéresse en particulier aurôle joué par les mainframes au coeur des systèmes d’information.

A. Organisation

DKSoft est dirigé par Laurent BERRUEL (PDG, 34 ans) et Frédéric ALLAIN (DG, 39 ans). Lelaboratoire de R&D est dirigé par Urbain BENNET et Michel BUISSON (créateurs de l’architecture etexperts reconnus en développement de logiciels grands systèmes).

Organigramme de (mai 2003)

B. Présentation de l’activité

Pour comprendre la nature de l’activité de DKSoft, il est nécessaire de donner quelquesdéfinitions et de préciser quelques notions, car le savoir faire de l’entreprise se trouve dans le domainede l’EAI (Entreprise Application Integration) et plus particulièrement autour des mainframes et de leurdécloisonnement. Nous allons donc voir ce que sont les mainframes et pourquoi ils jouent encore unrôle majeur au sein des grandes entreprises.

1. Qu’est ce que le Mainframe ?

Le mainframe est un grand système qui héberge des données et des traitements indispensablesau fonctionnement opérationnel de l’entreprise. Comme l’explique Nicolas Six, journaliste àJDNet.com, les mainframes apparaissent souvent comme des dinosaures qui nous viennent d'une autreépoque. En effet, tout en eux évoque la démesure : leur mémoire vive, qui se compte en Go -, leurpuissance qui tire parti de plusieurs dizaines de processeurs, et leurs mensurations, qui s'apparentent àcelles d'un gros réfrigérateur.

Ces grands systèmes ne cessent d’évoluer depuis trente ans, tant auniveau logiciel (software) qu’au niveau matériel (hardware). Ils sontcapables de traiter de gros volumes de données, de gérer les connexionsde grandes quantités d’utilisateurs simultanément, tout en gardant uneforte disponibilité.

Ces spécificités viennent du fait que le mainframe est un système

sur 35

Direction Générale

Laurent Berruel PDG

Frédéric Allain DG

Direction Marketing Communication - Presse

Laurent Maury

Direction Technique

Olivier Marois

Stagiaire

Emmanuel Digiaro

Support / R&D

Urbain Bennet (B&B)

Michel Buisson (B&B)

Direction des Opérations Commerciales

Gilles Puglièse


cloisonné. Les programmes y sont exécutés dans des espaces mémoire virtuels et ne peuventcommuniquer ni même interférer avec d’autres programmes tournant sur la même machine. Tout celafait que les mainframes n’ont pas d’équivalent aujourd’hui en terme de puissance et de sécurité.

Apparus dans les années 60, bien avant que les PC ne naissent, les mainframes auraient enprincipe dû disparaître au début des années 2000 - selon les conjectures de certains observateurs. Leserveur classique de type Intel/Linux ou Intel/Windows, qui devait pouvoir mieux faire en travaillant enbatteries d'unités décentralisées, était censé les remplacer. Erreur : les mainframes sont toujours là, et ilstiennent la route face aux serveurs classiques. Ils fonctionnent sous un OS propriétaire (OS/390) maisdepuis 18 mois, ils fonctionnent en mode mixte (OS/390 – Linux) ce qui a beaucoup contribué àrelancer l’engouement pour ce matériel.

L’architecture des mainframes a été sensiblement ouverte vers de nouveaux standards. Les grossystèmes souffraient de leur architecture, puisqu'ils étaient conçus pour être placés au coeur même d'unréseau. Il a fallu les rendre capable de communiquer avec d'autres serveurs, en leur intégrantnotamment un module TCP/IP. Ce qui était la moindre des choses à l'heure de l'Internet et de l'Intranet.

En effet avec l’émergence de l’e-business et des nouvelles technologies regroupées sousl’acronyme EAI (Entreprise Application Integration), les entreprises tendent aujourd’hui à adapter lessystèmes d’information existant au développement accéléré de la collaboration en réseau. Se pose alorsun paradoxe lorsque ces systèmes sont des mainframes : il est nécessaire de créer des outils adaptéspermettant de les décloisonner.

Le marché du mainframe représente 74% de la marge d’IBM en 2001 et on compte aujourd’hui8 000 très grands comptes dans le monde (2 000 en Europe et 400 en France), répartis dans toutes lesbranches de l’économie internationale : banque, assurance, industrie, télécoms, administration, …

2. Le savoir faire de DKSoft

L’équipe de DKSoft a conçu et mis au point une architecture logicielle temps réel baptisée DKA(Dynamic Knowledge Architecture) qui facilite les échanges dynamiques d’informations actualisées etpertinentes entre les différentes structures opérationnelles. Les solutions de DKSoft s’adressent auxgrandes entreprises qui souhaitent capitaliser sur le patrimoine applicatif de leurs systèmes centrauxIBM et réduire les coûts et délais de mise en place d’applications e-Business.

DKSoft compte parmi ses références actives, la Banque PICTET & Cie, CICOTITRES, filialedu CIC / Crédit Mutuel, le Groupe Crédit Agricole et le groupe ATOS ORIGIN. L’équipe souhaitepositionner DKSoft comme éditeur spécialiste du temps réel « REAL TIME EAI » et déployer unréseau commercial principalement axé sur des partenariats.

L’offre de DKSoft s’articule autour de deux éléments :

• Une démarche méthodologique qui a pour objectif d’assister les entreprises dans leurs projets detransition vers une informatique orientée services. Un ensemble de prestations de conseil etd’accompagnement sont ainsi proposées par une équipe dédiée (architectes et développeurs,spécialistes du mainframe) de DKSoft.

sur 35

IBM zSeries 990


• Une gamme de logiciels et de services pour grands systèmes IBM, Mainframe/EasyBus.

Les ingénieurs de DKSoft ont développé, au travers du programme IBM "PartnerinDevelopment", une infrastructure technique permettant aux mainframes de participer activement auxarchitectures distribuées orientées services. Cette gamme d’outils et de services systèmes supprime lecloisonnement entre applications sous MVS/OS 390 ou z/OS. Elle permet notamment de mettre enoeuvre des échanges de mémoire à mémoire entre ces applications et évite, grâce à un uniqueconnecteur TCP/IP synchrone, le développement ou l’emploi de connecteurs multiples et hétérogènes.Ces produits ont pour objectif de décloisonner les grands systèmes IBM dans une logique de busapplicatif généralisé et ouvert.

En annexe de ce rapport, se trouve un extrait de dossier publié dans la Décision Micro & Réseaudu 31 mars 2003. Cet article, rédigé par Laurent Maury (directeur marketing DKSoft), présente leproduit Maiframe/EasyBus et le positionne face à ses concurrents sur le marché.

En conclusion, poursuit un double objectif :

• Décloisonner le mainframe• Faciliter le déploiement d’architectures distribuées orientées services

dans le but de permettre aux entreprises d’exploiter pleinement leur Système d’Informationd’Entreprise (données et traitements).

sur 35


II. Présentation du stage

A. Objectif du stage

Le but de mon projet est d’écrire un composant applicatif en Java qui permette unecommunication avec la gamme de produits DKSoft déjà mis en place sur le mainframe, de manière àpouvoir permettre à toute application d’utiliser les ressources du mainframe exploitées par easyBus.

Ce composant permettra d’accéder à un service réalisé par un programme s’exécutant sur lemainframe et qui est mis à disposition (publié) par easyBus.

Un service est un traitement fonctionnel publié et localisé sur le réseau d’entreprise, quis’exécute dans son environnement de manière transparente, à la demande des utilisateurs.

Un des aspects importants à respecter pour la réalisation de ce projet est la garantie de l’intégritédes données sur les systèmes qui ont participés lors de l’exécution du service. La solution choisie pourpalier à ce problème est le support du protocole 2PC (2-phase Commit).

B. Plan du stage

Olivier Marois, mon tuteur, a choisi de découper le projet en deux parties :

La première étape consiste à comprendre et mettre en œuvre les spécifications decommunication avec easyBus, en développant une application Java. Cela permet la mise en pratique dela technologie existante créée par DKSoft, pour mieux me familiariser avec les produits existants etm’intégrer dans les principes de développement de l’entreprise.

La seconde étape est un travail de recherche et développement (R&D) sur l’intégrité de donnéesdans l’environnement Java. Ma mission est d’apporter une solution à un problème réel de DKSoft enutilisant les normes récentes de la communauté Java relatives au mode transactionnel : commentintégrer le composant que j’ai développé dans le système d’information de l’entreprise et quelles sontles principes à respecter pour garantir l’intégrité des données.

C. Objectif pour DKSoft

L’objectif pour DKSoft est d’acquérir des connaissances sur les normes J2EE (Sun) du mondeJava et d’évaluer quels sont les apports potentiels de ces technologies sur son savoir faire.

En effet, DKSoft se positionne sur un marché assez "pointu" et spécifique dans le domaine dessolutions d’entreprise, et il semble très intéressant pour elle de travailler à l’élaboration de nouveauxoutils qui participent au décloisonnement du mainframe.

En outre, après validation de mon travail par mon tuteur, DKSoft envisage d’étudier lessolutions apportées par mon travail et de compléter son offre logiciel en s’appuyant sur les nouvellesconnaissances que je leur ai apporté.

sur 35


III.Phase 1 : développement d’une application Java

A. Description de la gamme de produits « Mainframe/easyBus »

C’est un connecteur mainframe générique et universel qui fonctionne de manière synchrone etqui ne nécessite pas lors de sa mise en place, de modification des programmes existants du back-office(Batch, IMS, CICS…).C’est en partie ce produit qui place le mainframe au cœur de l’architecture orientée service.

Respecte les standardscaractéristiques de

l’architecture orientée service (TCP, XML, UDI)

Optimise les performancespour les applications faisant

appel via easyBus à des services hébergés sur le

mainframeRend plus simple la mise en oeuvre

En offrant une API de type client-serveur

easyBuseasyBus décloisonne le mainframe décloisonne le mainframe EasyBusEasyBus supprime le cloisonnement supprime le cloisonnement

entre MVS/OSentre MVS/OS--390 ou z/390 ou z/ OSOS..

EasyBus rend possible la mise en œuvre des services exécutés au sein d’environnementshétérogènes (CICS, IMS ou Batch) en préservant l’intégrité des données.

L’API de type client/serveur fournie par easyBus permet de faire appel à ces composants demanière homogène. Réduite à un seul ordre (SendReceive – appel de service et attente de la réponse),sa prise en main par les développeurs est immédiate.

B. Environnement Technique

Lorsque je suis arrivé à , il m’a été mis à disposition un ensemble de moyens pouraccomplir ma mission : un PC de bureau neuf 1GHz, munie du système d’exploitation Linux Suse 7.3.

Après avoir obtenu la licence adéquate, j’y ai installé l’environnement de développementJBuilder 8 Entreprise Edition de Borland (d’une valeur de $3000) qui m’a permis de développer moncomposant.

sur 35


fig. 1. L’EDI de JBuilder 8 version Entreprise

Pendant toute la période de développement de mon composant, j’ai eu accès à différentesressources de données sur lesquelles j’ai pu me connecter pour les phases de test.

J’ai notamment eu accès à une machine mainframe (sur laquelle sont installés les produits de lagamme easyBus de DKSoft). Ce mainframe est hébergé dans les locaux d’une autre entreprise nomméeOverlap située à Courbevoie, dans laquelle l’équipe R&D de DKSoft occupe des bureaux.

Sur cette machine, ce trouve un service d’annuaire (programme COBOL CICS), publié sous lenom "ANNUAIRR", qui accède à une base de données (DB2) locale où sont stockées les informationssur les personnes (Nom, prénom, société et ville).

Le service propose un certain nombre de fonctions d’accès aux enregistrements de la base :• LIST pour récupérer l’ensemble des noms des personnes enregistrées dans l’annuaire• GET pour récupérer les informations sur une personne • ADD pour ajouter un enregistrement à la base• REMOVE pour supprimer un enregistrement de la base

De plus, sur ma machine Linux est installé le composant DK-WSSM. Développé en C, ceprogramme est capable d’accepter les connections TCP/IP, met en œuvre le protocole d’easyBus, etpublie le même service d’annuaire que la machine de tests IBM/OS/390. J’ai donc pu l’utiliserlocalement, pour simplifier les tests, lors de la mise au point des requêtes générées par mon composantJAVA.

sur 35


C. Développement de JSSM

Nous avons décidé de baptiser mon composant DK-JSSM pour Java Session Services Manager.Il rentre ainsi dans la gamme de produits DK-SSM, à laquelle appartient aussi l’application DK-WSSMdéveloppée par mon tuteur.

En utilisant l’API de JSSM, une application cliente doit pouvoir :• Se connecter à la machine distante (sessions bi-directionnelles spécialisées pour l’envoi ou la

réception des données)• Demander l’exécution d’un service publié (SendReceive) et recevoir la réponse de manière

synchrone• Terminer la connexion

Le client émet une requête d’appel de service en indiquant le nom logique de celui-ci et leséventuelles données applicatives associées.

Quand JSSM reçoit cette requête, il doit :- localiser le service demandé sur le réseau (serveur distant LINUX ou OS/390)- préparer et envoyer la demande d’exécution du programme concerné vers le serveur

identifié- attendre la réponse correspondante- renvoyer le résultat au client qui a suspendu son exécution en attendant cette réponse

sur 35


1. Mise en œuvre du protocole

Les spécifications du protocole « mainframe/easyBus » sont indiquées dans un document. Ceprotocole définit la structure des messages échangés entre les composants et l’ordre de ces échanges.Exemple avec les messages de mise en session :

Client Serveur

Connect session 1LOGON 01

ACK0

Connect session 1b

LOGON 02 ACK0

Connect session 2LOGON 03

ACK0

Connect session LOGON 04

ACK0

2b

fig. 3 : messages échangés entre le client et le serveur lors d’une mise en session

Ce schéma montre l’échange des messages entre le composant JSSM et le serveur distant, pourune configuration avec 2 sessions logiques. Chaque session logique (bi-directionnelle spécialisée) estcomposée de 2 sessions physiques initialisées par le client.

Pour chaque session logique, la première session physique, appelée session primaire, estréservée aux émissions de messages (Client vers Serveur). La deuxième session physique, appeléesession secondaire, est réservée pour les réceptions de messages (Serveur vers Client).

La connexion et l’envoi du message de LOGON d’une session secondaire s’effectuent aprèsréception de l’acquittement positif de LOGON de la session primaire.

Si le client reçoit un acquittement négatif de LOGON pour une session secondaire, il doit fermerla session primaire correspondante.

Pour chaque "session" il y a donc deux sockets TCP/IP utilisables pour véhiculer les messages.Ces voies ne sont pas liées logiquement.

Elles doivent être utilisées uniquement en fonction de leur sens de sorte que les messagesutilisent au mieux les voies qui leur sont affectées.

sur 35


Voici un extrait du document définissant la structure des messages pour l’envoi d’une requête etla réception de la réponse correspondante.

Envoi d’une requête :

- longueur totale 4 octets binaires- identification de PDU 6 octets = 'REQ '- alignement 2 octets à blanc- préfixe émetteur 24 octets (12 octets de LUWID + 12 octets

réservés)- préfixe DKP :

Mode de la requête 1 octet ('U' pour « Update », 'R' pour« ReadOnly »)

- Champ réservé 3 octets à zéro binaire- Nom du service 8 octets- Code retour DKP/GSO 4 octets numériques (décimal étendu)

initialisé à zéro- Code retour applicatif ISM 4 octets binaires initialisés à zéro- Nom d’utilisateur (sécurité) 8 octets- Mot de passe (sécurité) 8 octets -Champ réservé 20 octets

- longueur message 4 octets binaires (fonction de la requête)- message

- prefixe réservé à MVS-DKP 20 octets- message applicatif (8 octets à 32K)

Réception d’une réponse :

- longueur totale 4 octets binaires- identification de PDU 6 octets = 'ACKREQ'- alignement 2 octets à blanc- préfixe émetteur 24 octets (12 octets de LUWID + 12 octets

réservés)- préfixe DKP :

Mode de la requête 1 octet ('U' pour « Update », 'R' pour« ReadOnly »)

- Champ réservé 3 octets à zéro binaire- Nom du service 8 octets- Code retour DKP/GSO 4 octets numériques (décimal étendu) retourné

par DKP/GSO- Code retour applicatif ISM 4 octets binaires retourné par les services de

type IMS- Nom d’utilisateur (sécurité) 8 octets effacés par DKP/GSO- Mot de passe (sécurité) 8 octets effacés par DKP/GSO-Champ réservé 20 octets

- longueur message 4 octets binaires (fonction de la requête)- message

- prefixe réservé à MVS-DKP 20 octets- message applicatif (8 octets à 32K)

sur 35


2. Analyse UML

Avant de me lancer dans le codage de JSSM proprement dit, je suis bien sûr passé par la phasede conception en UML. Le schéma montre la vue d’ensemble simplifiée du package JSSM.

fig. 4 : schéma UML du package JSSM

Par souci de lisibilité, toutes les classes ne sont pas représentées sur le schéma. Notamment, lesclasses permettant la fabrication des d’en-tête de messages envoyés et le décodage des messages reçus.

Les sous-classes JSSMInit, JSSMQr et JSSMTerm contiennent respectivement les méthodespour l’établissement des connexions, les méthodes de d’envoi et de réception de messages, et enfin lesméthodes déconnexion. La classe JSSMConfigManager est chargée de récupérer les informations durépertoire de configuration.

C’est la classe JSSMProtocol qui gère l’écriture des données en binaire dans les sockets.

sur 35


3. Un mot sur le codage

Au cours du développement de JSSM, j’ai pu tester le bon déroulement de mon programme endialoguant localement avec WSSM, plutôt qu’avec la machine mainframe distante. WSSM propose lesmêmes services que le mainframe (dont le service d’annuaire).

J’avais en outre accès aux fichiers de traces d’exécution de WSSM, où sont stockées toutes lesinformations sur le déroulement du programme. Cela qui m’a permis de pouvoir déterminer les causesd’un refus de connexions par exemple, en déchiffrant le contenu des messages TCP/IP échangés par lesdeux composants.

Voici par exemple, un extrait d’un de ces fichiers de log :

20030505-114413 DKLNX27I - TCP/IP process initialization in progress...20030505-114413 ...20030505-114413 DoTcpIpConnection - receiving (logon)...20030505-114413 ReceiveIp - length to receive: 13820030505-114413 ReceiveIp - length received: 13820030505-114413 ********** ReceiveIp **********20030505-114413 0000008A4C4F474F4E202020202020202020202020202020202020202020202020030505-114413 434C49454E545F4A53534D20202020202020202020202020202020202020202020030505-114413 203032203032203030312030303220030505-114413 ********** **********20030505-114413 DoTcpIpConnection - message received - LG:142 - LOGON 20030505-114413 client name=CLIENT_JSSM server=SERVEUR_WSSM20030505-114413 DKLNX26I - Establishing session with remote client CLIENT_JSSM20030505-114413 ********** SendIp **********20030505-114413 0000008541434B4C474E2020202020202020202020202020202020202020202020030505-114413 3020303020534552564555525F5753534D20202020202020202020202020202020030505-114413 202020202020303032

fig. 5 : extrait d’un fichier de trace de WSSM

De mon coté, durant les phases de déboguage de JSSM, je n’avais au début aucun moyen dedéterminer les causes d’un disfonctionnement, à part les levées d’exceptions Java. Sous les conseils demon tuteur, j’ai donc décidé, de mettre en place un système de trace de la même manière que dansWSSM, et d’imprimer dans un fichier de trace les logs de tous les événements et le contenu desmessages échangés en binaire. Cela m’a grandement facilité le déboguage pour la suite.

20031428-121436.188 - Creation of a new logical session20031428-121436.450 - JSSMPduHeader.lenPdu (Wrote)=13820031428-121436.504 - JSSMPduHeader.lenMsg (Wrote)=4620031428-121436.699 - JSSMPduHeader.lenPdu=13320031428-121436.701 - JSSMPduHeader.pduId=ACKLGN20031428-121436.702 - JSSMPduHeader.lenMsg=4120031428-121436.703 - rcv_acklgn : ACKLGN 20031428-121436.734 - one connexion to SERVEUR_WSSM by port 800020031428-121436.753 - Service found on serveur_wssm20031428-121436.757 – send request to SERVEUR_WSSM : len= 2048 20031428-121436.759 - JSSMPduHeader.lenPdu (Wrote)=214020031428-121436.800 - JSSMPduHeader.lenMsg (Wrote)=204820031428-121436.906 – received : ACKREQ ; len = 30420031428-121436.909 - JSSMPduHeader.lenMsg=212

fig. 6 : extrait d’un fichier de trace de JSSM

sur 35


IV.Phase 2 : développement d’un adaptateur de ressources

Une fois la phase de développement de JSSM terminée et validée par mon tuteur, la secondephase du stage a consisté à adapter JSSM de manière à ce qu’il soit placé sous le contrôle d’unmoniteur transactionnel qui va superviser les échanges.

Cette partie présente les fruits de mes recherches sur des notions qui m’étaient inconnues avantd’effectuer ce stage, car elles ne sont pas enseignées à FiiFO, du moins jusqu’en troisième année.

A. Le protocole 2-Phases Commit

Les données hébergées sur le mainframe et qui sont accédées au travers de EasyBus peuvent êtremises à jour lors d’une transaction impliquant plusieurs sources de données. C’est pourquoi easyBussupporte le "two-phase commit protocol" (2PC protocol ou protocole de validation à deux phases). Ilpermet d'assurer, en cas de pannes, l'atomicité des mises à jour effectuées sur différents sites par unetransaction répartie. Ce protocole garanti que les sources de données sont synchronisées. Lesmodifications apportées aux données sont toutes validées ou toutes annulées.

Le but de cette opération est d'assurer que chaque participant d'une transaction effectue la mêmeopération (tous procèdent à la validation ou à l'annulation).

Pendant la vie d'une transaction, tout participant peut unilatéralement décider de l'interrompre.

Description du protocole de validation à deux phases :

La première phase correspond à la phase depréparation.

Les participants de la transaction distribuéedoivent indiquer si leur travail peut être validé. Sile travail d'un participant peut être validé, on ditque le participant est prêt. Une fois prêt, leparticipant accepte le résultat fourni parcoordinateur de la transaction. Il ne peut plusabandonner la transaction unilatéralement. Lerésultat final d'une transaction (ou la fin d'unetransaction) dépend du résultat individuel dechaque participant à la transaction.

Dans la phase de résolution, une transaction estvalidée si tous les participants peuvent procéder àla validation. Toutefois, si un ou plusieursparticipants abandonnent, la transaction estannulée.

sur 35

fig. 7 : schématisation du protocole 2-phase commit


Pour chaque transaction utilisant plusieurs sources de données, il faut donc identifier ce que l’onappelle une Unité Logique de Travail (LUWID = Logical Unit of Work Identifier). Il s’agit d’unidentifiant unique qui est communiqué à chacune des sources de données lors des mises à jour et qui vapermettre de retrouver les données qui doivent être validées ou annulées lors de la validation à deuxphases.

Dans cette première étape de mon projet, le numéro de LUWID est généré par le client. D’aprèsle protocole, ce numéro est codé sur 12 octets. Pour être certain de tirer un numéro unique, ce numéroest directement généré à partir de la date et de l’heure courante (le format est AMjjhhmmssSSS, Sreprésentant les millisecondes)

Le client signale le début d’une transaction en communiquant ce numéro à JSSM parl’instruction startLUW(LUWID). Tant qu’il ne signale pas la fin de la transaction avec l’instructionendLUW(), toutes les requêtes seront affectées de ce numéro, et participeront donc à la même unitélogique de traitement.

Voici plus en détails les méthodes que doit appeler un client pour établir la connexion, puiseffectuer une requête (ici la commande est "LIST"), et enfin fermer la session :

/* * JSSMClient.java 1.0 * Created on 17 fevrier 2003, 11:11 * (c) Copyright Dynamic Knowledge Software SA 2003 */

import jssm.* ;

/** * @author Emmanuel Digiaro * @version 1 */

public class JSSMClient {

public static void main(String args[]) throws Exception { //creation of JSSM instance JSSM comJssm = new JSSM();

/*creation of a unique LUWID*/ DateFormat current = new SimpleDateFormat("MddHHmmssSSS"); byte[] luwid = current.format(new Date()).getBytes(); //init. of the communication (read configuration directory) comJssm.init("CONF", luwid); comJssm.startLUW(luwid); // requete QR comJssm.setPrefix('U', "ANNUAIRW", "", ""); comJssm.setMessage("get"); RC = comJssm.qr(luwid);

comJssm.endLUW(luwid, 0);

comJssm.term(); } catch (Exception e) {JSSMClient.log.print(e.getMessage()); }}}

fig. 8 : exemple de client utilisant le package JSSM

sur 35

Génération d’un numéro de LUWID unique

Création d’une nouvelle instance de JSSM

Etablissement des connexions réseau

Début d’une unité de traitement

Fin de l’une unité de traitement

Déconnexion (logoff) et fermeture des sockets

Appel de service + commande + données

import du package JSSM


B. Les serveurs d’application

1. Définition de l'architecture 3-tiers

Une architecture 3-tiers est composée de trois éléments, ou plus précisément dans ce cadre là detrois couches. En effet dans ce contexte, et dans la philosophie qui a guidé l'élaboration de cettearchitecture, il est plus adéquat de parler de couche fonctionnelle où à chacune d'elle est attachée unélément/entité logique.

Il faut donc distinguer trois couches/éléments :• La couche présentation associée au client qui de fait est dit "léger" dans la mesure où il

n'assume aucune fonction de traitement à la différence du modèle 2-tiers. • La couche fonctionnelle : le serveur applicatif, segmenté lui même en couches de

o présentation, qui construit l'IHM (souvent Web) destinée au client o métier qui réunit l'ensemble des processus exécutés par l'application o intégration, chargée des échanges entre serveur applicatif et serveur(s) de données.

• La couche de données hébergeant les données (SGBD, mainframe, etc.…)

2. Avantages d'une architecture 3-tiers

Malgré une expertise de développement qui semble plus longue à acquérir que dans le cadred'une architecture 2-tiers et des coûts de développement plus élevés au début, l’architecture 3-tiers serévèle être très rentable à long terme, d'après une étude du cabinet Gartner group (1998) :

Dans un système d’information possédant une architecture 3-tiers, le déploiement d'unenouvelle application se résume à la gestion des autorisations de l'utilisateur vis-à-vis de l'application(droit d'utilisation des différentes fonctions offertes par l'application) et formation du nouvel utilisateur.Aucun déploiement de programmes sur le poste client n'est nécessaire (à l'exception, une fois pour

sur 35


toutes, des composants techniques : navigateur, services de communication…). L'administrationglobale du système s'en trouve considérablement simplifiée, par rapport à celle d’un système possédantune architecture client serveur classique.

3. Comprendre le fonctionnement du serveur d’application

a) Définition

Un serveur applicatif héberge une ou plusieurs applications auxquelles il fournit uneinfrastructure d'exécution. En se reposant sur cette infrastructure technique, les applications :

• sont plus et mieux structurées (car s'adaptant au modèle imposé par l'infrastructure) • sont développées plus rapidement (car ne développant elles-mêmes pas cette infrastructure

technique)

Un serveur applicatif se situe dans la couche centrale d'une architecture 3-tiers. L'infrastructurequ'il fournit est généralement constituée d'un ensemble de frameworks intégré, adaptés aux besoins dechaque couche logique de l'application :

Coucheapplicative

Présentation (Web) Métier Intégration

Framework Conteneur Web JavaBeans

Conteneur EJB JCA

Composants JSP

Servlets applicativesou système (serveurWeb, administration,

etc.)

Cette couche accède parfoisà d'autres composants plus

généraux, propres audomaine métier (communs

à plusieurs applications)

Adaptateur deResource

(RA) pour unEIS

JDBC

b) Serveur J2EE

La plate-forme Java2 Enterprise Edition (J2EE) est un standard en la matière de plate-formed’entreprise. Elle propose un modèle d’application distribuée, à base de composants EJB (EnterpriseJava Beans), et fondé sur une architecture multi-tiers et des clients légers.

Elle propose un cadre de travail pour la définition, l’intégration et le déploiement de composantsmétier. Elle définit un modèle de programmation basé sur une architecture multi-tiers, des APIsstandardisées (JNDI, JDBC, JMS,…) et des normes (RMI, CORBA, XML,…)

Elle spécifie des règles d’écriture et de déploiement des composants, et comprend quatreéléments majeurs : une base de données, un serveur d’application, un ou plusieurs conteneurs et descomposants.

L’architecture multi tiers est une alternative aux architectures client serveur traditionnelles (dites 2tiers). Elle est indépendante des serveurs et des middlewares, et permet de déployer des applications

sur 35


distribuées à grande échelle. De plus, elle est particulièrement bien adaptée aux applicationsIntranet/Extranet/Internet.

SUN propose avec J2EEun modèle d’architecturedistribuée orientéeservices qui exploiteessentiellement leslangages Java, HTML etXML

Donnéeslocales

PagesHTML

AppletsJava

JSP ServletsJava

Données

ERP

DonnéesEJBsession

Container Web

Container EJBContainer Client

EJBentité

EJBmsg

HTTPRMI- IIOP

RPCJMS

CORBA…

Client lourdou léger

Serveur / Middle-tier EIS

fig. 11 : architecture 3-tiers avec J2EE

4. Qu’est ce qu’un moniteur transactionnel

C’est un composant logiciel assurant le contrat de la faisabilité d’une transaction commercialeen temps réel et l'équilibre de la charge de traitement entre les différents serveurs. Le moniteurtransactionnel surveille ainsi toutes les requêtes du client et appelle les fonctions correspondantes sur leserveur. CICS system (IBM), Top End (NCR) et Tuxedo (BEA Systems) sont des exemples demoniteurs transactionnels. En outre, ce composant prend en charge la garantie de l’intégrité desdonnées qui sont mises à jour.

D’une manière générale, pour garantir l'intégrité des données, les transactions doivent respecterquatre principes, connus sous l'acronyme ACID (on parle de transactions et de systèmes ACIDes, etmême d'ACIDité transactionnelle) :

• A (Atomicity), atomicité. Tout échange avec le SGBD (ou un autre système prenant part à latransaction) doit être considéré comme une unité de traitement indissociable, entièrementexécutée ou entièrement annulée

• C (Coherence), cohérence. Toute action portant sur les données doit préserver la cohérence deces dernières. Elle opère sur un système cohérent et son exécution ne peut remettre en causecette cohérence

• I (Isolation), isolation. Deux transactions concurrentes doivent être isolées l'une de l'autre.Ainsi, les effets résultant de la mise à jour des données dans le cadre de la transaction T1 neseront visibles par une autre transaction que lorsque l'exécution de T1 sera terminée. Celle-cis'achève par une validation (commit) ou une annulation (rollback)

• D (Durability), durabilité. Les effets résultant de l'exécution d'une transaction sont persistants.Les valeurs des données concernées demeurent stables dans le temps tant qu'aucune autretransaction ne provoque leur mise à jour.

L'intégrité des données découle du respect de l'ACIDité transactionnelle. Elle devientparticulièrement complexe à garantir dans le cas de bases de données réparties. La localisation desdonnées dans une telle base doit rester complètement transparente du point de vue de l'application.

sur 35


En environnement distribué homogène (lorsque plusieurs instances du même système de gestionde données sont impliquées dans l'exécution d'une transaction distribuée), de nombreux SGBDproposent des extensions spécifiques. La solution technique la plus couramment utilisée est le protocolede validation à deux phases (Two-Phase Commit - 2PC).

Le principe de fonctionnement de ce protocole est très simple. Sur demande de l'application, lesystème assurant la coordination des mises à jour réparties (un SGBD, un moniteur transactionnel…) :

• émet un message PTC vers chaque gestionnaire de données prenant part à la transaction. PTCsignifie Prepare To Commit (préparer la validation de la transaction). Les gestionnaires dedonnées mettent en œuvre les traitements de préparation demandés, mais restent en attente devalidation définitive avant de considérer la transaction comme achevée et de rendre les mises àjour persistantes et de libérer les ressources éventuellement verrouillées.

• Si la préparation de tous les systèmes de gestion de données s'avère fructueuse, le système decoordination émet alors un message de confirmation (validate commit) ; la transaction estvalidée, ses mises à jour sont persistantes

• Si au moins un des gestionnaires de données ne parvient pas à préparer la validation de latransaction, le coordinateur émet alors k un message d'annulation (rollback) à l'attention de tousles gestionnaires concernés. Aucune mise à jour n'est retenue, la base répartie retrouve son étatinitial.Les besoins applicatifs nécessitent parfois de procéder à des mises à jour de données

hétérogènes au sein d'une même unité transactionnelle dont il convient de garantir l'ACIDité.L'utilisation de passerelles d'accès (gateways) fournies par les éditeurs de SGBD ne peut résoudre leproblème. Le protocole 2PC n'est que rarement supporté par ces passerelles. Le comité X/OPEN, quis'intéresse aux standards relatifs aux systèmes ouverts, a proposé une solution normalisée, connue sousl'acronyme X/OPEN-XA, qui décrit comment les systèmes de coordinations (et en particulier lesmoniteurs transactionnels) doivent gérer le protocole 2PC dans le cas de transactions portant sur desbases de données réparties, homogènes ou hétérogènes.

Le coordinateur dialogueavec les systèmes degestion de données (deuxau minimum) afin degarantir que la transactiondistribuée sera soitentièrement réalisée, soitentièrement annulée

BD2

Gestion descommandesGestion descommandes

SGBD

BD1

Prepare to commit

Validate commit

12 Prepare to commit

1

Validate commit

2

Validation / Commit

Annulation2 Annulation

2

2 Si commit = OK2 Si commit = échoué

fig. 12 Mise en œuvre du protocole de validation à deux phases

De nombreux SGBDR et moniteurs TP sont désormais conformes à la norme X/OPEN-XA.

Certaines situations complexes ne peuvent toutefois être traitées par les produits courants dumarché. Dans pareil cas, les solutions consistent à :

• Modifier l'architecture applicative afin de simplifier le contexte d'exécution (réécriture

sur 35


d'applications, migrations, adaptations lourdes…)• Développer ''manuellement'' des passerelles techniques d'intégration (développements

complexes et très coûteux, solutions souvent hasardeuses, peu évolutives et très sensibles auxmises à jour des systèmes - upgrades)

• Tolérer certains risques maîtrisés et documentés de perte d'intégrité, au moins de manièretemporaire.

C. Développement de l’adaptateur de ressources

Un adaptateur de ressources est un composant logiciel qui est utilisé par des applications pourse connecter aux systèmes d’information de l’entreprise (EIS). Le but est maintenant d’apporter lestransformations nécessaires à JSSM pour le transformer en adaptateur de ressources. Sur le serveurd’application, JSSM sera de cette manière considéré comme une driver de connexion à une ressourcede données externe (les mainframes), au même titre que JDBC, driver pour l’accès aux bases dedonnées relationnelles dans le monde Java .

1. Les types de transaction j2ee

Les applications J2EE sont déployées dans des conteneurs fournis par le serveur d'application.Elles interagissent avec les systèmes de données (EIS) grâce à leurs composants qui accèdent demanière transactionnelle aux gestionnaires de ressources propres à chaque EIS.

Les acteurs de la transaction sont : Le "ressource manager (RM)" ou gestionnaire de ressource qui est la porte d'entrée d'un

système de données. Le RM peut être associé à un système de persistance, un système d'annuaire ou unconnecteur vers un système de données. C'est lui qui reçoit les instructions dans un langage approprié etqui les traduit pour assurer le maintien des données sur le système de données.

Le "transaction manager" ou gestionnaire de transaction est l'arbitre impartial de latransaction et il est unique pour une transaction. C'est lui qui s'assurera que toutes les étapes sontfranchies et que la ou les ressources sont en phase pour procéder au commit ou rollback global de latransaction.

Une transaction peut regrouper des opérations sur 1 ou plusieurs gestionnaires de ressources

Lorsque l'on a un seul SGBDR compatible JDBC avec une même source de données ou "DataSource ", on peut grouper les ordres SQL d'update par exemple en une seule transaction, mêmes'ils s'effectuent par exemple de manière séquentielle au sein d'un dossier, ou dans une suite d'EJB.

Cependant lorsque l'on a affaire à une transaction avec des ressources distinctes, il faut trouverdes capacités transactionnelles supérieures. Le RM de chaque ressource ne peut se charger de gérerl'ensemble de la transaction localement à son niveau et l'on est obligé d'avoir recours aux transactionsglobales selon la norme JTA/XA.Ainsi :Pour 1 seul RM concerné dans une transaction on peut opter pour :

• transactions locales au RMpour cela le RM fait aussi office de transaction manager, le langage utilisé est celui de ceressource manager via une API Spécifique (exemple un SGBDR compatible JDBC)

sur 35


Pour 1 ou plusieurs RM concerné(s) dans une transaction : • transactions globales avec JTA/XA (Java Transaction API / Transaction Authority) :

pour cela le RM se base sur un transaction manager externe implémenté par l'API JTA, leprotocole d'échange nécessite alors un système de données compatible XA en cas deplusieurs RM et dans ce cas chaque RM doit implémenter l'interface XARessource pourpermettre le dialogue avec le transaction manager

Remarque : L'interface pour les transactions globales la plus répandue est X/Open XA, qui est acceptépar la plupart des pilotes de SGBDR. Il s'agit d'un standard, qui permet d'effectuer des déploiements enenvironnement hétérogène et de gérer l'interopérabilité entre des gestionnaires de ressources dedifférents éditeurs.Le modèle est le suivant :

L'utilisation de transactions globales nécessite que le transaction manager puisse réaliser le commit àdeux phases (2PC). En effet son rôle sera aussi de s'assurer que toutes les ressources de la transactionsont au même état.

2. La déclaration des transactions

Selon le type de transaction J2EE, la démarcation des transactions peut être très simplifié à laprogrammation sachant qu elle peut se révéler superflue, ou être gérée implicitement par les conteneursd'EJB.

sur 35


"Démarquer" une transaction consiste à indiquer quand elle débute et quand elle doit finir.Généralement la méthode begin() et respectivement commit() et rollback() remplissent cerôle sur l'instance de la transaction que l'on a initialisé.

Dans le cas de transaction locale au ressource manager, ce dernier se charge de gérerimplicitement les transactions et il n'y a pas de nécessité de gérer explicitement une transaction.Cependant les ordres de début et de fin doivent être donnés sur l'interface à ce RM. (ce qui reviens àpeu de chose prés à la démarcation d'une transaction).

L'exemple classique est un SGBDR géré via l'API JDBC. Les ordres SQL transmis sont alorsvalidés par une instruction de commit ou annulée via un rollback. Le RM se charge des niveauxd'isolation. Le tout peut être optimisé par un outil de gestion objet-relationnel qui peut lui-aussi gérerles niveaux d'isolation.

Dans le cas de transactions globales, l'accès au transaction manager externe sera implémentépar les API JTA(Java Transaction API) et JTS (Java Transaction Service).Il y a alors deux manières d'initier une transaction :

o de manière explicite en utilisant l'interface javax.transaction.UserTransaction o de manière implicite ou automatique dans le cadre d'un conteneur EJB dans le cas ou l'option "

transaction gérée par le conteur " est activée.o

Le principal bénéfice de JTA en démarquant la transaction de manière anonyme est de combineren une transaction différents composants d'accès à des systèmes de données distincts.

Il est toujours recommandé d'accéder à un système de données via l'interface JTA. En effetcela permet à l'application transactionnelle de rester indépendante du ressource manager utilisé et del'interface Java correspondante (exemple : JDBC)

Outre la connaissance des techniques, l'utilisation de transactions dans le contexte J2EEnécessite de connaître les multiples limitations techniques propres aux acteurs que ce soient les "ressource manager ", les " drivers " le " transaction manager JTA/XA ", ou encore le serveurd'application et les conteneurs propres à un éditeur.

3. JCA : Les contrats et les interfaces à implémenter

Un connecteur JCA est un driver (appelé adaptateur de ressources) qui s'installe dans un serveurd'application Java. Au moment de l'installation, l'adaptateur devient une ressource du serveur. Leserveur doit lui fournir un ensemble de services techniques au travers de contrats dits systèmes. Avec laspécification 1.0, ces services sont au nombre de trois : connexion, transaction et sécurité.

sur 35


fig. 13 Serveur J2EE et le support JCA

Le service de connexion impose l'implémentation par le serveur d'application d'un pool deconnexions pour l'adaptateur de ressources. L'utilisation du pool améliore la performance desapplications qui utilisent JCA. Auparavant, chaque éditeur de connecteur pouvait fournir son proprepool propriétaire pour son système. JCA standardise la notion de pool de connexion.

Le service de sécurité permet un accès sécurisé aux ressources des EIS via un mécanisme de« sign-on » standardisé. Il inclut :

o un système d'identification et d'authentification ; o un contrôle d'accès aux ressources. Le service de sécurité de JCA améliore le modèle de sécurité de J2EE en y incluant une

connexion sécurisée et standard aux systèmes cibles. Au travers de ces services, JCA 1.0 améliore techniquement et standardise la connexion entre

un système cible et un serveur d'application. Le développeur apprend un seul mode opératoire etmanipule une interface de programmation commune : Common Client Interface (CCI).

4. Le codage du connecteur JSSM

Les packages javax.resource et javax.transaction ne sont pas inclut par défaut dans la JDK 1.3.J’ai donc du les télécharger sur le site de java/sun et ajouter l’ensemble des classes dans les librairiesadéquates.

Un adaptateur de ressources (resource adapter) doit implémenter un certain nombre d’interfacesde manière à le rendre normalisé pour que l’intégration et l’installation dans le serveur d’applicationsoient automatisées.

La phase de recherche dans les documentations de spécifications de la norme J2EE ConnectorArchitecture Specification, téléchargée sur le site de Sun, m’a permis de comprendre le processuscomplexe de connexion à une EIS via un resource adapter tel que va le devenir JSSM.

Sans rentrer dans les détails, présentons les interfaces à implémenter. Elles sont nombreusesmais peuvent être regroupées en trois catégories. Ainsi, on trouve les interfaces qui prennent en chargela création de la connexion (connexion TCP/IP physique, pooling, …) :

Connection Management InterfacesConnectionFactoryConnectionRequestInfoManagedConnectionFactoryConnection

Les interfaces permettant de gérer les transactions (délimitation, implémentation du protocole 2PC, …):Transaction Management Interfaces

ManagedConnectionLocalTransactionXAResource

Enfin, les classes regroupant les méthodes dites d’interaction c’est à dire d’exécution de requête sontregroupées dans les interfaces suivantes

Interaction InterfacesConnectionEventListenerImplInteraction

sur 35


InteractionSpecConnectionSpec

D’autres interfaces, par exemple celles définissant la nature des données échangées (suffixéespar MetaData), doivent être implémentées. Pour plus d’informations, consulter le document J2EEConnector Architecture Speficication).

fig. 14 : Les interfaces “connection management” illustrentla manière dont les applications vont interagir avec l’EIS.

L’implémentation de toutes ces interfaces a été facilitée grâce à JBuilder 8, qui propose dans sesmenus la possibilité d’implémenter une interface pour créer le "squelette" de l’interface. Une fois queJBuilder a créé le cadre de travail, il ne reste plus qu’à écrire le code qui implémente chaque méthodede l’interface.

5. Paramétrage et déploiement

Ces classes, une fois les méthodes implémentées, définissent donc un ensemble de contrats àrespecter entre le serveur d’application et l’EIS. Pour procéder au déploiement du nouvel adaptateur deressources créé, il faut "packager" l’ensemble des classes dans un fichier archive Java (JAR), formatéavec l’extension .rar. Ce package doit aussi contenir un fichier XML qui est le descripteur de déploiement décrivant lesspécificités de l’adaptateur de ressources.

6. Installation sur le serveur IBM Websphere v5.0

Pendant mon stage à DKSoft, j’ai eu la chance de pouvoir participer à plusieurs formations etséminaires, organisés par des grandes entreprises comme IBM ou SUN.Notamment, j’ai participé à un workshop sur les produits IBM : une formation sur deux jours destinéeaux développeurs. Cette formation m’a permis de me former sur les produits e-business proposés parIBM, parmi les plus efficaces et les plus répandus sur le marché.

J’y ai notamment appris à installer, configurer et maintenir un serveur d’application IBM

sur 35


WebSphere v5.

Quelques semaines plus tard, j’ai eu l’occasion d’appliquer ce que m’avait été enseigné, puisquej’ai installé un serveur Websphere sur ma machine pour déployer mon resource adapter.Grâce à une console d’administration (voir figure ci-dessous) qui fonctionne dans le navigateurNetscape, l’intégration de mon composant s’est révélé simplissime et j’ai pu immédiatement le mettreen œuvre et me lancer dans la phase de tests.

fig. 15 : La console d’administration de Websphere Application Server 5

sur 35

Le connecteur JSSM est installé etopérationnel sur le serveur d’application


V. Conclusion

Mon stage chez DKSoft s’est révélé être une de mes meilleures expériences dans le monde dutravail. Voici les bénéfices que j’ai su tirer de cette période de stage.

A. Apports techniques

Sur le plan des méthodes de travail, ce stage m’a permis de confirmer ce qui m’est enseigné à laFiiFO. La conception d’une application ne se fait pas au hasard et le développeur, avec son équipe, doitrespecter les étapes qui garantissent au final un travail réussi :

- La phase d’analyse (avec recherche des points critiques)- La conception- La production - Les tests et validations

Au niveau du travail de développement, la première phase de mon stage m’a permis de mieuxm’insérer dans l’équipe de développement et de comprendre l’environnement technique de manièreapprofondi. Grâce à cette phase, j’ai pu non seulement me perfectionner dans le langage Java, maisaussi me concentrer sur le respect des règles de programmation énoncées par mon tuteur. Ces règlesconcernent par exemple la documentation, la maintenance ou l’évolutivité des applications.La deuxième étape, quant à elle, m’a permis de mener à bien (et de bout en bout) un travail derecherche et développement sur une technologie Java toute nouvelle.

B. Apports humains

Les bénéfices que j’ai tirés de ce stage ne sont pas exclusivement techniques. En effet, à ,j’ai eu la chance de travailler au sein d’une équipe formée de personnes sérieuses, professionnelles maiscependant très agréables à côtoyer. J’ai pu rencontrer des personnes au parcours professionnelprestigieux et qui m’ont apporté leurs conseils et leur vision du monde du travail.

En outre, les formations auxquelles j’ai participé, bien que orientées techniques, ont étél’opportunité pour moi de rencontrer des acteurs majeurs du marché de l’informatique, d'échanger aveceux, et de constituer un réseau de connaissances qui me servira plus tard lors de mon arrivée sur lemarché du travail.

sur 35


Liste des annexes

Annexe A :

Extrait de dossier publié dans la revue spécialisée Décision Micro & Réseau du 31 mars 2003. Cet article, rédigé par Laurent Maury (directeur marketing DKSoft), présente le produitMaiframe/EasyBus et le positionne face à ses concurrents sur le marché.

Le rapport ne contient pas d’autres documents en annexe.

sur 35


sur 35

Rapport de stage 2003 -...

Documents

Transcript of Rapport de stage 2003 -...