Cours JAVA

Composants logiciel java guide de formation complet


Télécharger Composants logiciel java guide de formation complet

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


Composants logiciel java guide de formation complet

Composants Java a. Java Beans

Les Java Beans (ou beans) sont des composants Java, qui fonctionnent aussi bien chez un client que chez un serveur réseau et qui peuvent être de trois types : visuels (comme des boutons, des icônes etc.), non visuels (accès à une base de données) ou composites (feuilles de calculs, calendriers, etc.). Ils peuvent être utilisés dans n’importe quel programme Java, que ce soit une applet, une application, une servlet ou même une page JSP. Le bean est caractérisé par :

- Les services offerts (méthodes publiques par défaut)

- Ses propriétés (ou attributs) définis d’après ses méthodes publiques dont les signatures doivent respecter des conventions précises. Par exemple, l’existence des méthodes :

Public T getP() Public setP(T val)

Définira une propriété P de type T. Il peut y avoir plusieurs types de propriétés : des propriétés indexées (tableaux de valeurs de même type), et des propriétés liées (aux événements).

- Ses événements (dont le fonctionnement est similaire à ceux des bibliothèques AWT ou Swing, c’est-à-dire basés sur un abonnement et des notifications).

- La possibilité de l’éditer visuellement (via un environnement de développement de type BeanBox ou JBuilder).

- Une introspection pour visualiser ses caractéristiques depuis un environnement de développement sans avoir accès aux sources.

- Une instanciation en mémoire, qui détermine son contexte d’exécution (dans un programme final ou un environnement de développement) ou si c’est un bean visuel ou non.

- Une sérialisation pour sauvegarder son état courant. - Sa forme de distribution (un package de type Jar).

- La possibilité de le connecter à d’autres beans, via un modèle de communication par événements.

Pour respecter ces caractéristiques, le bean doit obéir à des conventions lors de son développement. Ceci peut se faire de manière « manuelle » par le programmeur ou par le biais d’une interface, java.beans.BeanInfo (pour l’introspection). Cette interface est d’ailleurs surchargeable pour particulariser l’introspection. Dans le cadre d’un bean visuel, celui-ci doit hériter de java.awt.Component. Il peut être complété avec d’autres classes, le tout devant être déployé sous forme de package Jar.

  1. EJBs – Enterprise Java Beans

Les EJBs sont des Java Beans dont les fonctionnalités ont été étendues et ne fonctionnant que dans des environnements serveurs les prenant en compte. Ils sont disponibles dans la version Entreprise de Java. Alors que les Java Beans peuvent être utilisés à des fins très diverses, les EJBs sont dédiés à l’encapsulation de la logique métier d’une application et sont très spécialisés. Ils n’interviennent pas par exemple au niveau d’une interface utilisateur. En fait, ils s’apparentent plus à une servlet ou à une JSP qu’à un Java Bean.

Concrètement, un composant EJB est un ensemble de classes et d’un fichier XML permettant de le configurer. Les classes doivent respecter une certaine spécification (la spécification EJB), et le tout doit être dans un fichier unique pour former une entité (Jar). Ces composants, comme les beans, peuvent être accessibles par tous types de clients : des servlets, des JSP, des clients Java via Java RMI (Remote Method Invocation) ou via l’interface de Corba. Mais ce qui les caractérisent, ce sont la nécessité d’être dans un conteneur, appelé conteneur EJB. Il est nécessaire de distinguer deux catégories de ces composants :

  • Les EJBs session

Ce type de bean sert un client à la fois et peut être vu comme une extension du client chez le serveur. Il peut par exemple servir de panier à un client dans le cadre d’un site commercial. Sa durée de vie doit être inférieure à celle du client.

  • Les EJBs entité

Les beans entité servent à représenter selon un modèle objet des données d’une base de données. Ils peuvent être accédés par plusieurs clients simultanément et leur durée de vie est calquée sur celle des données qu’ils représentent. La relation intervenant entre la base et le bean, à la base du concept de persistance, peut être paramétrée par le développeur ou de manière automatique par le conteneur.

Le déploiement des EJBs consiste à produire un fichier Jar muni d’un fichier de configuration XML (dont la génération peut être automatisée) et à le mettre dans un répertoire reconnu par le conteneur. Celui-ci, dans l’environnement Java, n’est rien d’autre qu’un logiciel agissant comme une extension du serveur Web (au même titre qu’un moteur de servlets pour les JSP et les servlets). JBoss est un exemple de conteneur EJB Open Source.



Java/Corba

Services Java

  1. Services Java

Ci-dessous sont présentés quelques services que peuvent offrir des plates-formes comme J2SE et J2EE pour aider à prendre en charge ce type de conception par composants, en dehors des bibliothèques pour les créer.

  1. RMI – Remote Invocation Method

Java RMI appartient au monde des applications distribuées et permet, en ayant une vision très générale, d’accéder à des objets à distance. Le modèle de communication utilisé par les EJBs sur les réseaux étend Java RMI. RMI est disponible dans la version standard de Java.

  1. J2EE Deployment API

J2EE Deployment API est une méthode permettant de déployer une application ou un composant Java de manière standardisée.

  1. JNDI - Java Directory and Naming Interface

JNDI intervient dans le milieu des services de nommages et des annuaires (qui sont des services de nommages munis d’une hiérarchie et de possibilité de recherches). Ces services font partie des éléments essentiels dans les environnements répartis et la programmation par composants. Ils peuvent être utilisés au sein des entreprises pour créer des bases d’informations sur les utilisateurs, le matériel, et ... les composants. Ceci dans le but de retrouver et localiser un élément rapidement depuis son nom sur un réseau (comme par exemple le fait DNS (Domain Name Service), qui est un annuaire, pour retrouver un site depuis son nom de domaine). En ce qui concerne JNDI, il s’agit d’une interface permettant d’utiliser ces services depuis une application Java, pour obtenir et stocker des objets et composants.

  1. JMS - Java Messaging Service

JMS est un ensemble d’APIs qui s’utilise aussi avec les EJBs. Il s’agit, comme son nom l’indique, d’un service de messages, qui interviennent entre composants et applications de manière asynchrone.

Java/Corba

Corba

III. Corba

Corba est un framework (ou plutôt des frameworks) assez vaste implémentant notamment son propre modèle de composants (CIF – Component Implementation Framework), ses conteneurs et une infrastructure de communication (CCM – Corba Component Model). Cette infrastructure est adaptée aussi à d’autres langages de programmation que le langage de Corba (CIDL – Component Implementation Definition). Plus concrètement, ce framework de Corba est un environnement client/serveur pour les applications réparties, ayant son propre langage et ses propres services. Son objectif est de masquer l’hétérogénéité des langages de programmation et des machines, via un langage « intermédiaire » d’interface (IDL : Interface Definition Language) permettant l’interopérabilité des langages, un bus spécifique pour l’acheminement des requêtes en IDL (ORB : Object Request Broker) et des services pour la programmation des applications réparties. Corba concurrence les services Web (qui seront traités au sein du chapitre sur .net), pour faire des applications distribuées hétérogènes (utilisant des composants reposant sur des plates-formes ou programmés dans des langages différents).

 Java/Corba

Après avoir vu comment des composants peuvent être implémentés au sein du framework Java et être utilisés, on peut distinguer deux catégories : le composant dans le sens large du terme, à l’image du Java Bean, et le composant beaucoup plus technique, à l’image de l’EJB, qui ne s’exécute que dans un environnement particulier et via un conteneur. Java a été traité pour montrer ces deux types de composants et les services qui peuvent être offerts comme JNDI, RMI à la base de la communication vers EJBs dans des applications distribuées essentiellement Java, et plus généralement toutes les bibliothèques permettant de réaliser la COM (Component Object Model). Quant à Corba, il a été décrit brièvement pour montrer le rôle qu’il tient dans ces environnements par composants, c’est-à-dire à la fois celui de modèle de composants mais aussi celui d’infrastructure à la base de la communication inter composants hétérogènes, au même titre que les services Web.

Framework .net

On parle souvent de .net comme étant le concurrent de Java. Ce n’est pas exactement cela dans le sens où .net et Java ne sont pas de simples langages (C# pour .net) mais des frameworks apportant chacun leurs concepts dans le but de réaliser des applications distribuées sur les réseaux et des applications Internet (pour être très général). En cela, ce n’est pas « Java » que concurrence .net mais la spécification J2EE.

Pour situer .net dans l’optique des composants, on peut le placer au niveau des structures d’accueil (plate-forme d’exécution en plus d’intervenir en tant que plate-forme de développement).



Nous allons voir dans ce chapitre assez vaste, la philosophie de .net, pour décrire globalement ce qu’il apporte, puis ensuite une présentation du développement et de l’exécution des applications dans cet environnement, les modèles de composants COM et ActiveX et leurs évolutions dans .net, , le langage C# qui est le langage majeur de .net, ASP.net qui est à la base des applications Internet, les services Web, ce qu’ils sont et en quoi .net intervient, le framework ADO.net à la base de la persistance des composants et enfin en conclusion, quels intérêts y a t il dans .net pour Microsoft et pour les entreprises.

 I- Philosophie .net

Voila bientôt 3 ans que l’on parle de .net, et pourtant peu de gens savent ce que c’est réellement. .net et plus particulièrement le framework .net est un environnement qui se veut le plus universel à tout point de vue.

En informatique, pour mener à bien un projet, il faut avoir des connaissances dans divers domaines et savoir manier différents outils spécifiques à un système, un langage ... (debugger, OS). La philosophie de .net est tout contraire à cela. En effet le nouveau slogan DO MORE WITH LESS que prône Microsoft peut se prêter à cette idée (ce n’est pas le syllogisme de ce slogan).

Tout informaticien, qu’il soit analyste programmeur, technicien, chercheur (bien que le .net ne soit pas fait pour cela), chef de projet ou même administrateur réseau a des préférences au niveau du langage, de l’OS et même des outils, et ce choix lui est propre. En effet, des personnes vont préférer par exemple développer en Scheme car ils vont se sentir plus à l’aise, souvent pour des raisons de syntaxe (bien que les derniers langages se ressemblent syntaxiquement parlant), alors que d’autres préfèrent le C. Cette préférence se traduit souvent par le fait, qu’une personne qui va aimer Pascal va savoir faire des choses, par manipulation du langage, que d’autres n’auraient même pas pensées. On retrouve la même idée au niveau des OS, certaines personnes préfèrent un environnement graphique, convivial et accessible, alors que d’autres, qui y trouvent moins d’intérêt, préfèrent manipuler, utiliser la robustesse du système.

Et maintenant, imaginons un environnement de travail et d’exécution multi plateforme et multi langage. Notre pro du Pascal pourra, grâce à la richesse des APIs fournies, manipuler directement des bases de données sans passer par SQL, faire des Macros ou autre scripts. Tous ça avec le même langage. Et son application pourra tourner, sans aucune retouche, ni aucune recompilation, sur tous les systèmes présents comme Windows XX, Unix, MAC OS, mais aussi sur toutes les plates-formes présentes et à venir (PDA, Pocket PC, SmartPhone, montres, réfrigérateurs etc. Ce n’est rien de moins que l’objectif de .net.

II- En termes techniques

Avec le framework .net est apparu de nouveaux termes : MSIL, CLR, CLS ...

Pour vous expliquer le plus simplement possible comment marche .net, on va voir comment se déroulent les différentes étapes de la programmation à l’exécution d’une application :

  1. Le développement

Il faut bien entendu passer par là. Coder son programme dans le langage que l’on désire parmi les 24 langages actuellement supportés par le framework. Enfin, ce n’est pas exactement vrai. En fait, ce n’est pas 24 langages que reconnaît le framework, mais 24 syntaxes qui sont propres aux langages. Je m’explique. Si vous faites du C, généralement, pour utiliser la puissance de ce langage, vous allez utiliser les pointeurs, et donc faire des mallocs. Or malloc appartient à la bibliothèque stdlib qui, elle-même, appartient à la bibliothèque C, mais pas à l’API du framework. Donc il est interdit de faire des mallocs si vous voulez construire des applications .net. L’exemple le plus flagrant est Java, le J# reprend toute la syntaxe de java, mais on ne peut pas utiliser l’API de Sun. Mais pourquoi l’avoir renommé J# ? Certain langages ont subi des transformations pour pouvoir être utilisé. C’est le cas, par exemple, de Visual Basic qui, par les transformations apportées à son passage à .net, est devenu un nouveau langage.

Le nombre de langages (syntaxes) supporté augmente de plus en plus. On parle de S# pour Smalltalk, X# pour un langage basé sur le XML ... Pourquoi refaire ces langages ? Et bien disons que chaque langage a sa spécificité et qui de ce fait peut le rendre très compliqué. Si certaines propriétés ne sont pas développées par le framework, alors on créé un nouveau langage, reprenant les mêmes principes, mais dépourvu de tout ce qui est incompatible .net. C’est le cas pour Cobol et Smalltalk. Voici les langages actuellement disponibles :

Bien que tous ces langages aient perdu le droit d’utiliser leurs bibliothèques, ils se voient enrichis d’une API énorme optimisée pour le framework.

Pour faire cohabiter tous ces langages, Microsoft à dû adopter un système de type commun à tous les langages de la plateforme, la CLS, qui formalise les conditions nécessaires à l’interopérabilité des langages.

En fait, pour qu’un nouveau langage puisse être compatible avec le framework .net, il faut que ce dernier remplisse une sorte de cahier des charges reprenant les caractéristiques de cet environnement. La CLS est ce fameux cahier des charges. Chaque langage possède ses propres mots clés, ses constantes. Imaginons que l’on se trouve dans le cas où vous développez une application A en VB .net, et qu’elle soit utilisée par un serveur S écrit en C#. Imaginons maintenant que dans le code de A se trouve une fonction dont la signature est utilisée par la syntaxe du C#. La compilation de S engendrerait une erreur. Pour y remédier, la CLS possède dans son jeu d’instructions un caractère d’échappement ‘@’ qui permet de spécifier qu’on a développé l’instruction qui suit ce caractère.



Mais il est vrai, et ce TE le montre, que cette première partie va progressivement diminuer dans le développement de projet informatique (sans jamais réellement disparaître) par l’intégration de composants dans notre application.

  1. La compilation

Une fois le programme écrit, on passe à la compilation. Cette étape fait un prétraitement de notre langage préféré en le transformant en CIL (aussi appelé MSIL) : Le CIL, ou Commun Intermediate Language, est en fait le seul langage qui pourra permettre l’exécution dans le framework. Ce langage est déposé à l’ECMA () .C’est lui qui permet l’interopérabilité, au même titre que le java Byte Code, mais ici, on est pas contraint de développer en Java. On obtient alors un fichier avec comme extension .modules ce qui correspond au .class de Java.

Respectent la Common Language Specification (CLS)

Indépendant de la plate-forme hardware

Le CIL nous permet de mieux comprendre de quelle façon, il est possible de relier entre eux des composants et des programmes écrits dans des langages différents et avoir un seul runtime.

La phase d’édition de lien consiste simplement à rassembler plusieurs fragments de code IL, avant d’arriver à l’exécutable final. Il est donc très facile d’ajouter des composants de langages différents. Une fois l’assemblage finit, on obtient un assembly (.dll) au même titre qu’on obtenait un .jar en Java.

  1. L’exécution

Arrivé à ce niveau, il nous reste plus qu’à exécuter notre programme. Lors de la première exécution, la framework commence par rassembler tout le code IL, et toutes les fonctionnalités des classes unifiées qu’il utilise dans un seul code. C’est lors de cette phase que les notions de sécurités rentrent en compte. En effet, il est fort probable que le contenu des composants que vous utilisez vous soit inconnu, surtout si on utilise les services Web. On fait appel à des services externes, donc à partir de là, il faut une sécurité optimale. C’est la CLR (ou Common Language Runtime) qui se charge de cela. Cette dernière gère tous les aspects de sécurité et d’exécution. C’est grâce à sa robustesse, que votre programme pourra être exécuté en toute sécurité.

Juste après cette vérification, le compilateur JIT (Just In Time) va transformer le code IL en code natif de la plate-forme courante, afin de gagner en vitesse d’exécution. C’est pour cette raison que la première exécution d’un programme .net est toujours plus lente, mais les suivantes se font à pleine vitesse.

En fait le principe est simple, le programmeur développe son programme en communiquant avec la CLR qui elle communique avec les APIs système. C’est pour cette raison, qu’il faut un framework par système.

  1. L’enfer des DLL

Tous les développeurs qui travaillaient sur Windows connaissent bien l’expression « l’enfer des DLL ». En fait cela représente bien l’atmosphère de maintenance dans ce système. Si vous voulez faire des mises à jours d’un programme, il fallait, jusqu’à maintenant, développer de nouvelles DLL qui remplaceraient les anciennes. Mais, si un programme utilisait les anciennes, un bug apparaissait. Avec .net, toute cette confusion est finie. En effet, on accompagne chaque assembly d’un fichier de configuration écrit en XML, à l’intérieur duquel on indique la version de la DLL à utiliser. Vous l’aurez bien compris, chaque assembly contient un nom pour l’identifier, une clé de sécurité et un numéro de version.

Le choix du standard XML permet une facilité de lecture (texte), mais il est avantageux par le fait qu’il soit multi plateforme et qu’il passe par les firewalls (ce qui n’est pas le cas des fichier .ini).

L’avantage de ce système est qu’on peut regrouper toute nos assemblies dans un répertoire spécial, appeler GAC ($WINDIR\assemblys) qui permet de les rendre accessibles par tous. On peut conserver nos anciennes versions toute en ayant dans le même répertoire la mise à jour possédant le même nom, mais pas le même numéro de version. Les programmes utilisant nos assemblies n’auront qu’à indiquer le numéro de version nécessaire à leur bon fonctionnement dans le fichier de configuration correspondant.

  1. Mise en œuvre

Voici un exemple qui nous montre l’interopérabilité de .net. Nous allons faire un programme qui va calculer la somme et le carré d’un nombre. Pour ce faire nous allons écrire une classe ComplexMath en C# qui va contenir une fonction Square calculant le carré de notre nombre, et une classe SimpleMath en Visual Basic .net qui va contenir la fonction Add et Sub calculant respectivement la somme et la différence de deux nombre entier.



1982