SYSTEME À OBJETS DISTRIBUES DANS LE CADRE D’UN B2B

Introduction aux différentes tendances actuelles des systèmes d’information (SI)

               Il est vrai que les TIC sont un des secteurs porteurs et dont l’évolution des différentes technologies mises en œuvre sont parmi celles qui présentent une forte croissance. Cette évolution offre alors une variante de choix technologique dans l’utilisation de TIC. D’ailleurs, il y a tellement de solutions proposées pour l’exploitation des TIC et les technologies associées que les décideurs n’arrivent plus à distinguer lesquelles sont viables économiquement et lesquelles ne sont pas pénalisantes en terme de maîtrise et de temps de mise en œuvre. Toutefois, actuellement parmi les différents choix proposés, deux tendances semblent s’imposer : La solution de mise en œuvre des TIC sur la base de plate-forme de la société Microsoft se basant sur la mise en œuvre des technologies telles que : DCOM, COM+, environnement Windows et .NET. A noter que cette plate-forme est une plate-forme propriétaire et dont la mise en œuvre génère un coût d’exploitation. En effet, la solution Microsoft nécessite le paiement de licence pour l’utilisation de ces différents composants. La solution de mise en œuvre basée sur le plate-forme J2EE (Java 2 Edition Enterprise) proposée par la société SUN Microsystems et dont l’architecture de modélisation s’appuie sur l’architecture dite MVC pour modèle, vue et contrôle. Cette solution quant à elle prône l’usage des produits libres et dont l’environnement d’exploitation est multiple. Pour notre part, on a choisi la deuxième solution pour la réalisation du projet. En conséquence, les composants suivants ont été utilisés :
1. Environnement système : Windows
2. Plate-forme système distribué : J2EE
3. Architecture système distribué : MVC
4. Architecture client/serveur : client/serveur répartis ou n-tiers
5. Base de données : Pointbase de SUN Microsystems
6. Langage de développement : Java
7. Conteneur WEB : TOMCAT
8. Conteneur EJB : SUN Application Server
Ces différents composants feront l’objet de description détaillée à partir de la chapitre II du présent document. Dans l’absolu, l’interopérabilité consiste à utiliser conjointement des fonctionnalités d’applications basées sur des technologies différentes (J2EE, .NET, PHP, C++, etc.). Une des motivations peut provenir de la volonté de consommer depuis ses applications des services métier gérés par des partenaires externes (vente d’assurances, suivi d’envois de colis, etc.). Le véritable objectif est alors de permettre cette interopérabilité le plus simplement possible, en abstrayant à la fois aux utilisateurs finaux et aux développeurs la complexité et la diversité des environnements. Cependant l’administration technique du SI ne doit pas s’en trouver complexifiée outre mesure. Il est important que les équipes responsables de cette administration puissent facilement prendre le contrôle et gérer ces solutions. Prenons l’exemple d’une agence de voyage souhaitant déléguer le service de paiement d’un package voyage complet au SI de sa banque, et les services de réservation des billets d’avions et des chambres d’hôtel aux services respectifs de ses partenaires. Au-delà de simples appels de fonctions sur des applications de ces différents SI, des besoins de sécurité (paiement par carte bancaire), de gestion transactionnelle (réservation, etc.) ainsi que de transmission de données « brutes » (photos de la destination, plan d’accès, etc.) doivent être gérés. Et tout cela de manière la plus transparente possible et avec la plus grande facilité d’administration!

Client/Serveur à objet distribué : système réparti (Application n-tiers)

                Cette architecture fait l’objet de ce mémoire. Ce genre d’architecture se compose de différents niveaux que l’on peut subdiviser de la façon suivante :
‰ Interface utilisateur : couche chargée de gérer les interactions entre l’utilisateur et l’application (application de bureau, navigateur WAP, navigateur internet, …) ;
‰ Logique de présentation : elle permet de définir ce que doit afficher l’interface utilisateur et la manière comment les requêtes doivent être traitées ;
‰ Logique métier modélise les règles métiers d’entreprise ;
‰ Service d’infrastructure : fonctionnalités fournies aux composants (connexions, transactions, …) ;
‰ Données : données de l’entreprise.
L’apparition dans l’industrie de la technologie objet offre une solution plus complète que le RPC. En 1989, une association à but lucratif l’OMG (Object Management Group) est créée pour promouvoir un modèle d’architecture à objet distribué : CORBA. CORBA est basé sur l’utilisation d’un nouveau type de middleware : ORB. L’ORB est chargé de transmettre des requêtes entre les objets situés dans la mémoire d’ordinateur relié entre eux par un réseau. Associé la POO (Programmation Orientée Objet), CORBA autorise une répartition des traitements et des données presque transparentes. En outre CORBA est une architecture normalisée, supportée et mise en œuvre par de nombreux acteurs du marché. Cette architecture ressemble beaucoup à l’architecture 3-tiers. Les principales différences sont les suivantes :
‰ CORBA est standardisé et objet, alors que l’architecture 3-tiers ne l’est pas ;
‰ Les requêtes RPC propriétaires sont remplacées par des requêtes IIOP ;
‰ Le middleware RPC est remplacé par un ordre quelconque comme ORBIX ou VISIBROKER. On peut avoir un ordre donné du côté du client et un autre du côté serveur (c’est que l’on entend par interopérabilité) ;
‰ Il y a souvent plus qu’un serveur à objet distribué alors qu’on se limitait à un serveur d’application.

Fonctionnement d’un Entreprise Bean

                  Les développeurs du Beans doivent créer les interfaces et les classes suivantes : L’interface locale du Bean : qui définit les méthodes utilisées par le client pour créer, localiser et détruire les instances d’un Entreprise Bean. L’interface distante du Bean : qui définit les méthodes métiers implémentées dans le Bean. Un Client accède à ces méthodes via l’interface distante. La classe de l’Entreprise Bean : qui implémente la logique métier pour le Bean. Le client accède à ces méthodes via l’interface distante du Bean. Une fois le Bean est déployé dans le conteneur EJB, le client appelle la méthode create() définie dans l’interface locale pour instancier le Bean. L’interface locale n’est pas implémentée dans le Bean lui-même mais par le conteneur. D’autres méthodes, déclarées dans l’interface locale, permettent au client de localiser une instance d’un Bean et de supprimer l’instance d’un Bean lorsqu’elle n’est plus nécessaire. Lorsque l’Entreprise Bean est instancié, le client peut appeler les méthodes métiers qu’il contient. Toutefois, le client n’appelle jamais de méthode directement dans l’instance du Bean. Les méthodes accessibles au client sont définies dans l’interface distante du Bean, et celle-ci est implémentée par le conteneur. Lorsque le client appelle une méthode, le conteneur reçoit la demande et la délègue à l’instance du Bean.

Les EJB Entity

              Un Entity Bean représente une donnée persistante. Une application métier, par exemple, pourrait employer une base de données pour stocker des objets Entity métier tels que comptes, clients, ordres et produits. A l’intérieur du J2EE serveur, cette application représenterait les objets Entity métier avec les Entity Bean. Les attributs de l’objet (EJB) doivent être stockés via un mécanisme de persistance : par la sérialisation vers un fichier (ancienne mode), ou par assignations de bases de données relationnelles via JDBC. Les Entity Bean diffèrent des sessions Bean de plusieurs manières. Les Entity Bean sont persistantes, permettant l’accès partagé et ont des clés primaires. L’assignation relationnelle d’objet stocke chaque objet dans un enregistrement (tuple) d’une table (ou plusieurs) d’une base de données. Une colonne de la table de la base de données est associée à chaque attribut de la classe.
1. La persistance : Etant donné que l’état d’une Entity Bean est sauvegardé dans un mécanisme de stockage, il est persistant. La persistance signifie que l’Entity Bean existe au-delà la durée de vie de l’application ou du processus J2EE. Server. Les données dans une base de données sont persistantes parce qu’il existe encore même après avoir arrêté le serveur de base de données ou les applications. Il y a deux types de persistance : le Bean Managed Persistence (BMP) et le Container Managed Persistence (CMP). On déclare le type de persistance avec « Application Deployment Tool », qui stocke les informations dans un fichier « Deployment Descriptor ». Avec BMP, les codes de l’Entity Bean qu’on écrit contiennent les appels qui accèdent à la base de données. La méthode ejbCreate(), par exemple, créera les instructions « sql insert ». On est responsable du codage de « sql insert » et tout autre appel SQL nécessaire. Si le container gère la persistance de l’Entity Bean, il gère automatiquement les appels nécessaires à l’accès à la base de données. Par exemple, quand un client crée une Entity Bean, le container génère des instructions de « sql insert ». Le code de l’Entity Bean n’inclut aucun appel SQL. Le container synchronise aussi les variables d’instance de l’Entity Bean avec les données dans la base de données. Ces variables d’instance sont souvent référées comme des champs qui gèrent le container. On déclare ces champs gérés par le container avec l’outil de déploiement d’application, qui entre dans la liste des champs dans le fichier description de déploiement.
2. L’accès partagé : Les Entity Bean peuvent être partagées par des multiples clients. Puisque les clients pourraient vouloir modifier les mêmes données, il est important que les Entity Bean travaillent au sein des transactions. Le EJB container fournit la gestion de transaction. On spécifie les attributs de la transaction dans le fichier description de déploiement du Bean. On ne doit pas coder les limites de la transaction dans le Bean, c’est le container qui marque les limites.
3. La clé primaire : Chaque Entity Bean a un identifiant unique d’objet. Une Entity Bean client, par exemple, pourrait être identifiée par un numéro de client. L’identifiant unique ou clé primaire permet au client de situer une Entity Bean particulier. Une clé primaire est une valeur (ou combinaison de valeurs) identifiant l’instance de manière unique. Par exemple, une table de base de données contenant des enregistrements sur des employés peut utiliser leur numéro de sécurité sociale comme clé primaire. L’Entity Bean créé sur cette table des employés peut aussi utiliser le numéro de sécurité sociale comme clé primaire. Pour les Entreprises Beans, la clé primaire est représentée par un type String ou Integer, ou une classe Java contenant les données uniques. La classe de clé primaire peut être n’importe quel type classe valide pour RMI-IIOP. Cela signifie que la classe doit étendre l’interface Java.io.Serializable et implémenter les méthodes Object.equals(Objet objet) et Object.hashCode(), dont héritent toutes les classes Java. La classe de clé primaire peut être spécifique à une classe d’Entity Bean particulière. Chaque Entity Bean peut donc définir sa propre classe clé primaire que plusieurs Entity Bean peuvent partager. La gestion de la persistance par le container (CMP) a de nombreux avantages comparés à la gestion par le Bean (BMP). De tels Beans sont plus faciles à coder, Ils requièrent moins de code :
‰ Il ne contient pas les appels d’accès à la base de données, le code est indépendant de toutes données particulières stockées, telle qu’une base de données relationnelle.
‰ Les détails de la gestion de la persistance peuvent être modifiés sans changer ni recompiler le Bean Entity. En effet, le déployeur ou l’assembleur d’application peut modifier le descripteur de déploiement.
‰ La complexité du code diminue, ainsi que le risque d’erreurs. En tant que développeur du Bean, vous pouvez vous concentrer sur la logique métier du Bean et non sur les systèmes sous-jacents.
La persistance gérée par le conteneur a toutefois quelques limites. Par exemple, le conteneur peut charger l’état global de l’objet Entity dans les champs de l’instance du Bean avant d’appeler la méthode ejbLoad(). Cela peut créer des problèmes de performance si le Bean possède beaucoup de champs. La gestion des connexions à la base dans le cas de la persistance et de la transaction Container Managed nous évite de gérer des pools de connexion. Cette technique Container Managed permet une portabilité du code maximal. Il suffit de paramétrer les accès à la base soit dans les descripteurs XML On doit pouvoir passer par exemple à Oracle ou MS Access sans trop de problème.

WEB Container

                Une application web est une collection de documents HTML/XML, de composants web (Servlets et JSP) et d’autres ressources, dans une structure de répertoires ou sous forme d’une archive appelée fichier .war (Web ARchive). Une application web réside sur un serveur central et fournit des services à des variétés de clients. Sun Microsystems a fourni les dernières versions du code source des JavaServer Pages (JSP) et des Servlets à l’Apache Software Foundation pour qu’elles soient développées et diffusées à des processus de développement d’Apache comme implémentation de référence officielle de JSP 1.1/Servlet 2.2. Apache, Sun, ainsi que d’autres sociétés et des indépendants, développent ouvertement une implémentation de référence robuste, disponible gratuitement à toutes les sociétés ou à toute personne individuelle. Cette implémentation de référence, développée dans le cadre du projet Jakarta et sous le nom de code Tomcat, sera la seule implémentation de référence disponible. Cette implémentation disponible pour toute société ou pour tout développeur, peut-être utilisée dans les outils de développement de serveurs web pour créer des sites web dynamiques et interactifs.

Table des matières

NOMENCLATURE
INTRODUCTION
CHAPITRE I LES ARCHITECTURES DES SYSTEMES D’INFORMATION
I.1 Introduction aux différentes tendances actuelles des systèmes d’information (SI)
I.2 Typologie technique
I.2.1 Type de données
I.2.2 Type de communication ou dialogue
I.2.3 Structure et localisation des applicatifs
I.2.4 Le middleware
I.3 Les architectures Client/Serveur
I.3.1 Les types d’architectures des systèmes d’information
I.3.1.1 Client/Serveur à client passif (Architecture 1 tiers)
I.3.1.2 Client/Serveur de données (Application 2 tiers)
I.3.1.3 Client/Serveurs distribués (Application 3 tiers)
I.3.1.4 Client/Serveur à objet distribué : système réparti (Application n-tiers)
I.4 Evolution Client/Serveur avec interface
I.4.1 Standardisations des protocoles
I.4.2 Influence de la sécurité
I.4.3 Client/Serveur basé sur l’internet
I.4.3.1 L’architecture Client/Serveur HTML/WEB
I.4.3.2 Architecture Client/Serveur à code mobile
CHAPITRE II APPLICATION D’ENTREPRISE MULTI-NIVEAU SOUS JAVA
II.1 Architecture et application J2EE
II.1.1 Les avantages de l’architecture J2EE
II.1.2 Architecture J2EE
II.1.3 J2EE Application
II.1.3.1 Composants d’une J2EE application
II.1.3.2 Format de fichier
II.1.4 Architecture de service
II.2 EJB Container
II.2.1 Les types d’Enterprise Bean
II.2.2 Fonctionnement d’un Entreprise Bean
II.2.3 Les EJB sessions
II.2.4 Les EJB Entity
II.2.5 Le cycle de vie de l’Entreprise Bean
II.2.5.1 Le cycle de vie d’un Session Bean Stateless
II.2.5.2 Le cycle de vie d’un Session Bean Stateful
II.2.5.3 Le cycle de vie d’une Entity Bean
II.2.5.4 Le cycle de vie de Message-Driven Bean
II.3 WEB Container
II.3.1 Servlets
II.3.2 JavaServer Pages
II.4 Base de données
II.4.1 Connexion des session Bean et BMP (Bean Managed Persistance)
II.4.2 Connexion au Container Managed Persistance (CMP)
CHAPITRE III PARTIE APPLICATION
III.1 Présentation du projet
III.2 Choix des outils de conception et de développement
III.3 Conception et création de la base de données
III.3.1 Conception de la base de données
III.3.2 Création de la base de données sous PointBase
III.4 Développement de l’application EJB
III.4.1 Les Entreprises JavaBeans
III.4.1.1 Session Bean
III.4.1.2 L’Entity Bean
III.4.2 Web Client
III.4.2.1 Les applications JSP
III.4.2.2 Les Servlets
III.5 Compilation et organisations des fichiers sources
III.6 Assemblage et déploiement des applications EJB
III.6.1 Création de JDBC Data Source
III.6.2 Assemblage de l’Entreprise Bean
III.6.2.1 Assemblage des Entity Beans
III.6.2.2 Assemblage des Session Beans
III.6.3 Assemblage du WEB Client
III.6.4 Déploiement des applications
III.6.5 Résultats des applications
III.6.5.1 Les pages destinées aux Clients
III.6.5.2 Les pages destinées aux Personnels (Service Intranet)
CONCLUSION
ANNEXES
Annexe 1 Le script SQL de création de vue COMMANDE_TRAVAUX.sql
Annexe 2 Le script SQL de création de vue COMTRADO.sql
Annexe 3 Le fichier de compilation Ant Build Scripts : build.xml
Annexe 4 J2EE Descriptor B2BApplication : application.xml
Annexe 5 Application Server Descriptor B2BApplication : sun-application.xml
BIBLIOGRAPHIE

Télécharger le rapport complet