Passer au contenu

J2EE : une architecture distribuée pour Java

Avec J2EE, Sun définit un modèle standard pour le développement, l’assemblage et le déploiement d’applications à base de composants métiers Java en architecture distribuée.

Maîtrise des coûts, capacité d’évolution des applications et indépendance vis-à-vis des technologies constituent aujourd’hui les leitmotive des directions informatiques. Des exigences que Sun tente de satisfaire en proposant J2EE (Java 2 Enterprise Edition), dont la première spécification date de 1999. J2EE dessine un modèle de développement d’applications distribuées, prônant la réutilisation de composants applicatifs et le partage de services techniques. J2EE s’appuie principalement sur trois composants. Tout d’abord, un modèle général de développement des applications Java multitiers sous forme de composants fonctionnels (services métiers) interopérables. Ensuite, une plate-forme technique d’intégration, c’est-à-dire un ensemble de composants système (services techniques) permettant de déployer aisément les applications au sein d’architectures distribuées. Enfin, CTS (Compatibility Test Suite) spécifie des procédures de test destinées à garantir la compatibilité d’un développement Java avec l’architecture J2EE. Ces procédures s’adressent essentiellement aux éditeurs de logiciels désireux de commercialiser des services applicatifs ou techniques compatibles avec le standard de Sun.

Faire appel au système d’information

Dans le modèle J2EE, une application se compose de trois parties distinctes qui peuvent être librement déployées sur de multiples systèmes au sein d’architectures distribuées : l’interface utilisateur, la logique applicative (composants fonctionnels) et les services système partagés fournis par l’architecture J2EE elle-même (plate-forme d’intégration des applications distribuées). Naturellement, seule la production des deux premières parties est à la charge des développeurs d’applications. La logique applicative nécessite parfois de faire appel au système d’information : les composants fonctionnels Java sont installés sur le serveur J2EE et accèdent au système d’information central de l’entreprise (aux services fournis par un PGI ou directement aux bases de données gérées par un SGBD situé sur un système propriétaire, par exemple), grâce à un logiciel middleware tel qu’un connecteur JDBC ou une interface avec un MOM (par JMS).J2EE a pour principal objectif d’alléger le travail des développeurs en facilitant la réutilisation de composants fonctionnels et techniques. Les applications J2EE sont donc des assemblages de composants, c’est-à-dire de briques logicielles indépendantes et autonomes destinées à prendre part à l’architecture J2EE au moment de leur déploiement. J2EE fournit des services spécifiques sous la forme d’un ensemble d’interfaces assurant la communication entre composants par l’intermédiaire de la procédure d’invocation RMI-IIOP, et entre un composant et l’architecture technique de bas niveau.

Des services librement configurables

Ces interfaces sont regroupées dans des “Containers” adaptés à chaque type de composant. De nombreuses tâches partagées sont ainsi déléguées à l’architecture : gestion de la sécurité et des contrôles d’accès, gestion des transactions, persistance des données, annuaires, utilisation des ressources système, etc.Ces services sont librement configurables pour chaque composant. La configuration spécifique à un composant doit donc être clairement décrite lors de son développement. Elle dépend principalement du contexte applicatif au sein duquel il sera déployé. Ces déclarations comportementales, écrites en XML, sont stockées dans des fichiers autonomes et séparées du code Java des applications à produire. Une telle séparation permet aux intégrateurs, responsables du déploiement des composants, d’adapter le comportement global d’une application sans avoir à modifier le code Java de chacun de ses éléments. Remarquons que, avec J2EE, Sun fait une avancée significative vers la notion de qualité de service (sans toutefois proposer à ce jour la gestion de contrats de services) et permet, par exemple, de gérer la répartition dynamique de charge entre Containers d’EJB.Une application J2EE se compose d’une ou de plusieurs “unités applicatives” devant respecter le modèle général de développement. Chaque unité applicative contient un ensemble de composants fonctionnels (Enterprise JavaBeans, pages JSP, servlets, applets, etc.), un fichier d’identification qui décrit le contenu applicatif de l’unité (ce qu’il fait) et un fichier XML de déclarations J2EE standardisé décrivant les règles comportementales de chaque composant (comment il le fait). Ainsi, l’étape de déploiement consiste simplement à installer les composants au sein d’une architecture distribuée, à valider le comportement de chacun d’eux vis-à-vis des services techniques fournis par J2EE et enfin à contrôler et enrichir la liste des utilisateurs habilités à utiliser l’application.J2EE est ainsi une architecture mature qui s’appuie sur la souplesse du langage Java dont elle réunit les diverses spécifications (servlets, JSP, EJB, etc.) autour d’une démarche unifiée de développement. En ce sens, J2EE va au-delà des architectures distribuées Corba et COM. Son seul concurrent sérieux pourrait bien être.NET de Microsoft.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.


Laurent Maury