IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Les applications J2EE et les Frameworks

01/05/2004




1. Les applications J2EE
1.1. Introduction
1.2. Architecture N-Tiers (architecture décentralisée)
1.3. Les applications J2EE sont modulaires
1.3.1. Les composants J2EE
1.3.1.1. Les clients J2EE
1.3.1.2. Architecture des composants JavaBean
1.3.1.3. Composants web
1.3.1.4. EJB
1.3.2. Les conteneurs
1.3.2.1. Définition
1.3.2.2. Les archives
1.3.2.3. Les services des conteneurs
1.3.2.4. Différents types de conteneurs
1.3. Les services proposés par la plateforme J2EE
1.4. Les API de J2EE
1.4.1. Les services runtime
1.4.2. Les services de transaction
1.5. Les applications J2EE sont distribuées
1.5.1. Les communications
1.6. Description des API
1.6.1. Technologie EJB
1.6.2. API JDBC (Java DataBase Connectivity)
1.6.3. Technologie servlet
1.6.4. Technologie JSP
1.6.5. API JMS (Java Message Service)
1.6.6. API JNDI (Java Naming and Directory Interface)
1.6.7. API JDBC
1.6.8. API JTA (Java Transaction)
1.6.9. API JCA (J2EE Connector Architecture)
1.6.10. API JAAS (Java Authentication and Authorization Service)
1.6.11. API JAXP (Java API for XML Registries)
1.6.12. API JAX-RPC (Java for XML-based RPC)
1.6.13. Résumé
1.7. Les avantages de J2EE
1.8. Différentes Plates-formes J2EE : critères pour faire le bon choix
1.8.1. Typologie du projet
1.8.2. La technologie
1.8.3. Taille de l’entreprise
1.8.4. Open source ou propriétaire ?
1.9. Exemples d’utilisation de J2EE : intégration avec le tiers EIS
1.9.1. Scénarios d’intégration
1.9.1.1. Une Application Internet E-Store
1.9.1.2. Une application Intranet de ressources humaines
1.9.1.3. Une Application d’achats distribuée (B2B)
1.9.1.4. An Order Fulfillment Application
1.9.2. Les technologies d’intégration
1.9.2.1. J2EE Connector architecture
1.9.2.2. Java Message Service (JMS)
1.9.2.3. JDBC and RDBMS Access


1. Les applications J2EE



1.1. Introduction


Aujourd’hui les développeurs veulent de plus en plus écrire des applications transactionnelles distribuées pour les entreprises, et augmenter la vitesse, la sécurité ,la fiabilité et la maintenance des technologies serveurs. Le but de l’informatique distribuée est de permettre à une application sur une machine d’accéder à une fonction d’une autre application sur une machine distante et ce, de la même manière que l’appel d’une fonction locale, indépendamment des plates-formes et des langages utilisés. Trois standards sont aujourd’hui utilisés : CORBA/IIOP (Common Object Request Broker Architecture / Internet Inter-ORB Protocol), DCOM (Distributed Component Object Model) et RMI (Remote Method Invocation). Ces modèles offrent des mécanismes de récupération d’espace mémoire, de sécurité, de gestion du cycle de vie des objets, mais sont complexes, peu compatibles avec les pare-feux, et difficilement interopérables entre eux. Ils restent donc souvent confinés à l’intérieur des entreprises).
Pour réduire les coûts, par une conception et un développement plus rapide, la technologie J2EE (Java2 Enterprise Edition) est la spécification proposée par la communauté Java, et propose une approche orientée composants qui permet de concevoir, développer, assembler et déployer des applications d’entreprise.

J2EE est basée sur J2SE (Java 2 Standard Edition) qui contient les API de bases de Java. La spécification J2EE fournit aux clients une norme qui permet de développer des applications qui s’exécuteront sur toute plate-forme compatible J2EE.
L’architecture standard définie par J2EE prévoit en particulier l’utilisation d’un modèle d’application standard pour le développement des applications multicouches.


1.2. Architecture N-Tiers (architecture décentralisée)


Les architectures à 3 niveaux sont des modèles de programmation qui permettent la répartition d’une application sur 3 systèmes indépendants. Il s’agit généralement :

  • d’une interface exécutée sur les postes de travail locaux (1er niveau : présentation poste client). Cette partie peut-être composée d'une application standalone, d'une application web ou d'applets
  • de processus exécutés sur des serveurs distants (2eme niveau : logique métier)
  • d’une ou plusieurs bases de données, ou d’autres ressources (3eme niveau)


1.3. Les applications J2EE sont modulaires


La nature modulaire de la plate-forme J2EE implique que l’on combine des composants pour créer des modules, et ensuite combiner les modules pour créer des applications. J2EE propose des spécifications pour une infrastructure dans laquelle s'exécute les composants. Ces spécifications décrivent les rôles de chaque éléments et précisent un ensemble d'interfaces pour permettre à chacun de ces éléments de communiquer. Ceci permet de séparer les applications et l'environnement dans lequel il s'exécute. Les spécifications précisent à l'aide des API un certain nombre de fonctionnalités que doivent implémenter l'environnement d'exécution. Pour exécuter ces composants de natures différentes, J2EE défini des conteneurs pour chacun de ces composants et pour chaque composant des interfaces qui leur permettront de dialoguer entre eux lors de leur exécution. Les conteneurs permettent aux applications d'accéder aux ressources et aux services en utilisant les API. Les appels aux applications se font par des clients via les conteneurs. Les clients n'accèdent pas directement aux applications mais sollicite le conteneur.


1.3.1. Les composants J2EE


Les spécifications J2EE définissent les composants suivants :

  • Applications clients et applets (s’exécutent chez le client)
  • Java Servlet et JSP (JavaServerPages) composants Web qui tournent sur le serveur.
  • Composant EJB (Enterprise JavaBean) qui sont des composants métiers qui tournent sur le serveur.

Ces composants sont écrits en Java et sont compilés comme tous les programmes Java. La différence est qu’ils sont assemblés dans une application J2EE, suivant les spécifications J2EE, puis déployés pour la production, ou ils tournent et sont gérés par le serveur J2EE.


1.3.1.1. Les clients J2EE


Ils peuvent être des clients web ou des applications clients.

  • Le Web client (client léger) est constitué des pages dynamiques web (html, xml,etc..) générées par des composants web qui tournent sur le tiers web, et d’un navigateur web qui affiche les pages renvoyées par le serveur. Quand on utilise un client léger, les opérations lourdes sont off-loadées aux EJB qui s’exécute sur les serveurs J2EE.
  • Les applets : Une page web reçu du tiers web peut contenir une applet. Une applet est une petite application client écrite en Java qui s’exécute sur la machine virtuelle java du navigateur.
  • Application client : elle tourne sur la machine client et permet à celui ci d’exécuter des taches dans un environnement graphique plus complexe que ce que peut fournir une page html. Les applications client peuvent accéder directement aux EJB métiers qui tournent dans le tiers métier. Cependant, une application J2EE client peut établir une connexion s’il le faut pour communiquer avec une servlet qui tourne sur le tiers web.


1.3.1.2. Architecture des composants JavaBean


Ils ont des variables d’instances, et des méthodes get et set pour accéder aux données des variables d’instances. On peut les utiliser, mais ils ne font pas partie des spécifications J2EE.


1.3.1.3. Composants web


Un client communique avec le tiers métier qui est sur serveur J2EE , soit directement, soit dans le cas par exemple d’un navigateur, au travers de composants web : pages JSP ou de servlet tournant sur le tiers web.
Une servlet est une petite classe java qui traite dynamiquement une requête et construit les réponses.
Les JSP sont une technologie Java qui permet la génération de pages web dynamiques. La technologie JSP permet de séparer la présentation sous forme de code HTML (coté client) et les traitements sous formes de classes java définissant un bean ou une servlet (coté serveur).


1.3.1.4. EJB


Tous ce qui concerne le domaine métier est pris en charge dans le tiers métier par des EJB. Un EJB reçoit les données du client , les traite si nécessaire, et les envoies vers le tiers système d’information de l’entreprise pour stockage. Il peut aussi faire la manœuvre inverse.
Il existe 3 EJB : session beans, entity beans, et message-driven beans.

  • session bean : représente une conversation transitoire avec le client. Quand le client fini l’exécution, le bean et les données disparaissent.
  • Entity bean : représente une données persistante qui est stockée dans une ligne de table de base de données. Quand le client se déconnecte ou si le serveur s’éteint, les services sous jacents se chargent de sauvegarder l’entity bean.
  • Le message-driven bean combine les caractéristiques du session bean et de l’écouteur de message du JMS (Java Message Service), qui permet à un composant métier de recevoir un message JMS asynchrone.

Enterprise Information System Tier
The enterprise information system tier handles enterprise information system software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. J2EE application components might need access to enterprise information systems for database connectivity, for example.


1.3.2. Les conteneurs



1.3.2.1. Définition


Un conteneur est une interface entre le composant et la fonctionnalité spécifique de bas niveau de la plate-forme qui supporte le composant.
Les conteneurs assurent la gestion du cycle de vie des composants qui s'exécutent en eux. Ils fournissent des services qui peuvent être utilisés par les applications lors de leur exécution.

Pour déployer une application dans un conteneur, il faut lui fournir deux éléments :

  • l'application avec tous les composants (classes compilées, ressources ...) regroupée dans une archive ou module. Chaque conteneur possède son propre format d'archive.
  • un fichier descripteur de déploiement contenu dans le module qui précise au conteneur des options pour exécuter l'application.

Quand une application est déployée, les fichiers sources identifiés par le descripteur de déploiement sont compilés, et installés dans les répertoires gérés par le serveur d’application. Lorsque l’application est déployée, elle peut être exécutée dans l’environnement du serveur d’application.


1.3.2.2. Les archives


Il existe 4 types d'archive correspondant aux 4 modules différents J2EE :

module /package d’archive Contenu Extension Descripteur de déploiement
Module application client / JAR Regroupe des classes jar application-client.jar
Modules Web /JAR Regroupe les servlets et les JSP ainsi que les ressources nécessaires à leur exécution (classes, bibliothèques de balises, images, ...) war web.xml
Module EJB /JAR Regroupe les EJB et leur composants (classes) jar ejb-jar.xml
Module Resource adapter Regroupe des Java Interfaces, des classes, des librairies natives et autres documentations (implemente l’architecture Connecteur pour un EIS particulier) rar Resource-adapter.xml
Une application est un regroupement d'une ou plusieurs modules dans un fichier EAR (Entreprise ARchive). L'application est décrite dans un fichier application.xml lui même contenu dans le fichier EAR. Les serveurs d'application extraient chaque modules du fichier EAR et les déploient séparément un par un. Le fichier EAR est composé au minimum :

  • d'un ou plusieurs modules
  • d’un répertoire META.INF contenant un fichier descripteur de déploiement nommé application.xml


1.3.2.3. Les services des conteneurs


Le processus d’assemblage implique des configurations spécifiques pour chaque composant de l’application J2EE et pour l’application elle même. De plus, les configurations des conteneurs s’adaptent aux besoins des services proposés par le serveur J2EE tels que la sécurité, la gestion des transactions, consultation des Interfaces JNDI (Java Naming and Directory Interface), et connectivité à distance (remote connectivity).

  • Le modèle de sécurité J2EE permet de configurer un composant web ou un EJB afin que les ressources système ne soient accessibles qu’aux personnes autorisées.
  • Le modèle transactionnel J2EE permet de spécifier les relations entre les méthodes qui permettent de faire une unique transaction, afin que toutes les méthodes dans une transaction soient traitées comme une seule unité.
  • Les services de consultation JDNI fournissent une interface unifiée pour différents services de nommage ou d’annuaire de l’entreprise afin que les composants de l’application puissent accéder à ces services.
  • Le modèle de connectivité à distance de J2EE gère les communications de bas niveau entre les clients et les bean métier. Quand un EJB est créé, le client invoque des méthodes sur lui comme si il était dans la même machine virtuelle.

Le fait que l’architecture J2EE permette de configurer les services, implique que les composants de l’application dans la même application J2EE peuvent se comporter différemment suivant là où ils sont déployés. Par exemple ,un EJB peut avoir une configuration de sécurité avec un accès limité sur une base de donnée dans un environnement de production, et un autre niveau de sécurité d’accès à la base dans un autre environnement de production.

Les conteneurs gèrent aussi des services non configurables, comme les cycles de vie des EJB et des servlets, database connection resource pooling, la persistance des données, et l’accès aux APIs de la plate-forme J2EE. Bien que la persistance des données ne soit pas un service configurable, l’architecture J2EE permet de surcharger la persistance gérée par le conteneur en incluant le code approprié dans l’implémentation de votre EJB, si par exemple on souhaite plus de contrôle que ce que le conteneur fournit par défaut.
Par exemple, on peut utiliser un bean qui gère la persistance pour implémenter ses propres méthodes de finder (de recherche), ou bien créé un cache adapté à une base de données.


1.3.2.4. Différents types de conteneurs


Il existe autant de conteneurs que de type d'applications :

  • J2EE serveur : la portion Runtime d’un produit J2EE.Le serveur J2EE fournit le conteneur pour EJB et le web conteneur.
  • Conteneur d’EJB : tourne sur le serveur J2EE
  • Le web conteneur : gère l’exécution des composants pages JSP et des servlets(sur serveur J2EE)
  • Le conteneur d’application client : tourne sur le client
  • Le conteneur d’applet : consiste dans le navigateur web et le Plug-in Java, les 2 sur le client.


1.3. Les services proposés par la plateforme J2EE


Une plate-forme d'exécution J2EE complète implémentée dans un serveur d'application propose les services suivants :

  • service de nommage (naming service)
  • service de déploiement (deployment service)
  • service de gestion des transactions (transaction service)
  • service de sécurité (security service)

Ces services sont utilisés directement ou indirectement par les conteneurs mais aussi par les composants qui s'exécutent dans les conteneurs grâce à leurs API respectives.


1.4. Les API de J2EE


J2EE regroupe un ensemble d'API pour le développement d'applications d'entreprise.

API Rôle
Entreprise Java Bean (EJB) Composants serveurs contenant la logique métier
Remote Méthod Invocation (RMI) et RMI.IIOP RMI permet d'utilisation d'objet java distribué. RMI.IIOP est une extension de RMI pour utiliser avec CORBA.
Java Naming and Directory Interface (JNDI) Accès aux services de nommage et aux annuaires d'entreprises
Java Database Connectivity (JDBC) Accès aux bases de données. J2EE intègre une extension de cette API.
Java Transaction API (JTA)
Java Transaction Service (JTS)
Support des transactions
Java Messaging service (JMS) Support de messages via des MOM (Messages Oriented Middleware)
Servlets Composants basé sur le concept C/S pour ajouter des fonctionnalités à un serveur. Pour le moment, principalement utilisé pour étendre un serveur web
JSP  
Java IDL Utilisation de CORBA
JavaMail Envoie et réception d'email
J2EE Connector Architecture (JCA) Connecteurs pour accéder à des ressources de l'entreprises tel que CICS, TUXEDO, SAP ...
Java API for XML Parsing (JAXP) Analyse et exploitation de données au format XML
Java Authentication and Authorization Service (JAAS) Echange sécurisé de données
JavaBeans Activation Framework Utilisé par JavaMail : permet de déterminer le type mime
J2EE Connector Architecture (JCA) Connection au système d'information de l'entreprise grace à des adaptateurs fournis par des éditeurs tiers (ERP, mainframe ...)

  • Couche de présentation

Fonction Commentaire
JSP
JavaServer Pages
Composant pour générer des pages HTML dynamiques, créées à la volée à partir de contenus structurés et de sources diverses.
Java Servlets Les Servlets définissent la logique de navigation d'un site Web en conjonction avec les JSP (état des cessions, etc.).
JSF
JavaServer Faces
Composant qui étend les capacités des JSP pour faciliter la création et la mise à jour d'objets au sein de l'interface (barre de navigation, etc.).

  • Couche applicative

Fonction Commentaire
EJB
Enterprise JavaBeans
Les transactions J2EE, c'est-à-dire les tâches prises en charge par l'application en tant que telle, peuvent être exécutées ces composants.
J2EE Deployment API J2EE Deployment API définit une méthode pour déployer un composant ou une application Java de façon standardisée.
JAAS
Java Authentication and Authorization Service
JAAS joue le rôle d'un outil de gestion des accès : il traite notamment des processus d'identification et d'authentification des utilisateurs - en lien avec un annuaire d'entreprise par exemple.
JTA
Java Transaction API
L'objectif de JTA est de couvrir les actions d'un gestionnaire transactionnel (équilibrage de charge entre plusieurs serveurs, gestion des erreurs, etc.).
JMX
Java Management Extensions
Cette technologie fournit un socle d'outils pour construire des solutions Web de gestion et de supervision d'applications.

  • Couche d'accès aux données

Fonction Commentaire
JDBC
JDBC data access API
Interface de programmation qui permet au langage Java d'accéder à des bases de données par l'intermédiaire du langage SQL.
EJB
Enterprise JavaBeans
Les EJB offrent aussi une infrastructure conçue pour assurer la correspondance entre les objets métier d'une part et la structure d'une base de données d'autre part.
JNDI
Java Naming and Directory Interface
JNDI fournit un mode d'accès pour faire appel aux données (d'identification et d'authentification) et aux services d'un annuaire d'entreprise.

  • Couche d'intégration (J2EE)

Fonction Commentaire
JMS
Java Message Service
Ce Middleware Orienté Message (MOM) gère les échanges de messages entre applications - de manière asynchrone.
JCA
Java Connector Architecture
Cette infrastructure de code vise à faciliter la mise au point de connecteurs applicatifs (ERP, etc.), utilisables par n'importe quel serveur J2EE.
J2EE Management Model Il s'agit d'un modèle de gestion des informations (J2EE) dessiné pour être invoqué à distance via divers protocoles, SNMP ou pas (CIM, MIB, MEJB, etc.).
CORBA
Common Object Request Broker Architecture
L'architecture Corba dessine un modèle d'interaction de composants en environnement distribué.

  • Couche d'intégration (Web Services)

Fonction Commentaire
JAX-RPC
Java API for XML Remote Procedure Call
Cette interface de programmation d'applications a pour but d'interpréter les messages SOAP (Simple Object Access Protocol).
JAXP
Java API for XML Processing
JAXP assure l’analyse syntaxique des vocabulaires XML (par le biais de feuilles de styles XSLT, SAX et DOM).
JAXM
Java API for XML Messaging
Cette API met en oeuvre l'échange de messages SOAP avec des platesformes tierces, que ce soit en mode synchrone ou assynchrone.
JAXB
Java API for XML Binding
JAXB traduit les classes Java, c'est-à-dire le code de structuration des données manipulées par les composants, dans des formats de description XML équivalents (DTD, etc.).
JAXR
Java API for XML Registry
Java API for XML Registry donne accès aux annuaires de types UDDI et ebXML, ainsi qu'à la description des services applicatifs qu'ils pourraient indexer.
Ces API peuvent être regroupées en trois grandes catégories :

  • les composants : Servlet, JSP, EJB
  • les services : JDBC, JTA/JTS, JNDI, JCA, JAAS
  • la communication : RMI.IIOP, JMS, Java Mail


1.4.1. Les services runtime


Les modules et applications assemblés ont besoin de services runtime fournis par la plateforme. Des services tels que :

  • container-managed persistence, container-managed transactions
  • container-managed security validation, etc....

Lors de l’assemblage on doit donc déterminer quel service de runtime doit être utilisé et le spécifier dans le descripteur de déploiement du J2EE. L’obstacle principal est que chaque module ou application assemblée nécessite une combinaison différente de service runtime.

Les descripteurs de déploiement sont des fichiers xml qui utilisent des tag particuliers qui identifient les composants ou modules utilisés dans l’application.
Exemple :

<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd"> <?xml version="1.0" encoding="UTF-8"?> <application> <display-name>CatalogApp</display-name> <description>J2EE Application CatalogApp</description> <module> <ejb>CatalogData.jar</ejb> <alt-dd>CatalogData.xml</alt-dd> </module> <module> <web> <web-uri>CatalogWebModule.war</web-uri> <context-root>catalog</context-root> </web> <alt-dd>CatalogWebModule.xml</alt-dd> </module> </application>
Dans cet exemple il y a 2 modules (CatalogData et CatalogWebModule) et chaque module dispose de son propre descripteur de déploiement afin que le serveur d’application puisse identifier les fichiers sources des composants individuels J2EE.

Le descripteur de déploiement permet aussi d’indiquer au serveur d’application les services dont l’application va avoir besoin, en y définissant les propriétés des attributs des EJB.


1.4.2. Les services de transaction


Les transactions divisent une application en une multitude d’unités de travail. Un système qui supporte des transactions, assure que chaque unité soit complétée entièrement sans interférence avec les autres processus. Si l’unité est complétée, elle est commited. Autrement le système défait ce qu’il a fait (rolls back) quelque soit la tache effectuée par l’unité. La transaction simplifie le développement de l’application en libérant le fournisseur de composant des problèmes de récupération d’erreurs, ou de la programmation multi-utilisateur.

Les transactions fournies par la plate-forme J2EE ont les caractéristiques suivantes :

  • La transaction et plate, c’est à dire, qu’elle ne peut pas avoir de transaction fille (nested)
  • La plate-forme J2EE gère implicitement différents détails de transaction, comme la propagation d’informations spécifiques à une instance particulière de transaction, et la coordination entre les multiples transaction managers (Les transactions managers fournissent les services et les fonctions de gestion requises pour la synchronisation, la propagation d’un contexte de transaction, la démarcation de transaction (Le service de transaction est intégré en utilisant des règles-policies de démarcation de transaction), et la gestion des ressources transactionnelles)


1.5. Les applications J2EE sont distribuées


Chaque module d’une application J2EE peut être déployé sur une machine différente, et exécuter son propre processus pour créer une application distribuée. On peut ainsi par exemple, implémenter des applications sur des architectures n-tiers. (cf. dessin)

Ex : le module web est déployé sur une machine dédiée aux interactions http avec les utilisateurs. Le serveur d’application utilise les connections http pour envoyer les pages web définies par le module web aux navigateurs qui tournent sur les postes des utilisateurs. Le module EJB est déployé sur une autre machine, dédiée aux opérations avec la base de données. Les connections http entre le navigateur et le module web, et les interactions distribuées entre les 2 modules sont supportés par le serveur d’application J2EE.


1.5.1. Les communications


La plate-forme J2EE fournit différentes technologies pour les communications entre modules :

  • les communications web (sur des connections http)
  • des invocations de méthodes en mode synchrone utilisant java RMI-IIOP
  • des messages en asynchrone, utilisant JMS

J2EE supporte ces différents types d’interaction grâce à différents composant. Par exemple, le message-driven EJB supporte les messages asynchrones entre les modules. Sélectionner le bon mode d’interaction entre les modules d’une application, et choisir le bon type de composant pour supporter cette implémentation d’interaction , fait partie de la conception de l’application. Il faut aussi réaliser des taches comme définir les références EJB (pour implémenter les interactions Java RMI), ou définir les priorités (pour implémenter les interactions de messages JMS).

La plateforme J2EE support aussi les intéractions entre les modules J2EE et les ressources externes utilisées par les applications comme les données externes. Les technologies qui supportent ces interactions inclues :

  • JDBC/JTS
  • container-managed persistence

Losqu’une application est assemblée, il faut aussi être sur que les ressources externes utilisées par l’application déployée sont correctement identifiées. Là encore, c’est le descripteur de déploiement qui permet d’identifier les sources externes.


1.6. Description des API



1.6.1. Technologie EJB


Un composant EJB est un bloc de code avec des champs et des méthodes pour implémenter des modules de logique métier. Chaque bloc peut être utilisé seul ou avec d’autres bean pour exécuter une logique métier sur le serveur J2EE. Comme on l’a vu, il y a 3 types de bean différents (session beans, entity beans, and message-driven beans). Les EJB interagissent souvent avec les bases de données., cependant, il n’est pas nécessaire d’utiliser du SQL ou l’API JDBC pour accéder aux bases de données. Le conteneur EJB le gère pour nous. Toutefois, si on décide de surcharger le conteneur de persistance des données, ou si on veut avoir un bean session pour accéder à la base, il faut utiliser l’API JDBC.


1.6.2. API JDBC (Java DataBase Connectivity)


Cet API permet d’invoquer des commandes SQL à partir des méthodes Java. On l’utilise donc si on décide de surcharger le conteneur de persistance des données, ou si on veut avoir un bean session pour accéder à la base. On peut l’utiliser aussi depuis une servlet ou une page jsp pour accéder directement à la base, sans passer par un bean. L’API a 2 parties : une interface utilisée par les composants de l’application pour accéder à la base, et une interface service provider pour attacher un driver JDBC à la plateforme J2EE.


1.6.3. Technologie servlet


Les servlets sont conçues pour agir selon un modèle de requête/réponse. Tous les protocoles utilisant ce modèle peuvent être utilisé tel que http, ftp, etc ... L'API servlets est une extension du jdk de base, et en tant que tel elle est regroupée dans des packages préfixés par javax.

L'API servlet regroupe un ensemble de classes dans deux packages :

  • javax.servlet : contient les classes pour développer des servlets génériques indépendantes d'un protocole
  • javax.servlet.http : contient les clases pour développer des servlets qui repose sur le protocole http utilisé par les serveurs web.

Une servlet est une classe Java qui implémente l'interface javax.servlet.Servlet. Cette interface définie 5 méthodes qui permettent au serveur de dialoguer avec la servlet : elle encapsule ainsi les méthodes nécessaire à la communication entre le serveur et la servlet. (ex :Les méthodes init(), service() et destroy() assure le cycle de vie de la servlet en étant respectivement appellée lors de la création de la servlet, lors de son appel pour le traitement d'une requète et lors de sa destruction).
L'usage principale des servlets est la création de pages HTML dynamiques. Sun fourni une classe qui encapsule une servlet utilisant le protocole http. Cette classe est la classe HttpServlet . Elle peut aussi réaliser un ensemble de traitements tel que mettre à jour une base de données. En réponse, elle peut générer une page html qui indique le succès ou non de la mise à jour.


1.6.4. Technologie JSP


Les JSP (Java Server Pages) sont une technologie Java qui permettent la génération de pages web dynamiques.La technologie JSP permet de séparer la présentation sous forme de code HTML (coté client) et les traitements sous formes de classes java définissant un bean ou une servlet (coté serveur) ou snippet.


1.6.5. API JMS (Java Message Service)


Le service JMS est un standard de messagerie qui permet à un composant d’application J2EE de créer, envoyer, recevoir et lire des messages. Il permettre un dialogue standard entre des applications ou des composants via des brokers de messages ou MOM (Middleware Oriented Messages). JMS permet donc d'utiliser des services de messaging dans des applications java, comme le fait l'API JDBC pour les bases de données. Il permet des communications distribuées asynchrones,fiables. loosely coupled


1.6.6. API JNDI (Java Naming and Directory Interface)


Cet API fournit une interface unique pour utiliser différents services de nommages ou d'annuaires:

  • LDAP (Lightweigth Directory Access Protocol)
  • DNS (Domain Naming Service)
  • NIS (Network Information Service) de SUN
  • service de nommage CORBA
  • service de nommage RMI , etc..

Un service de nommage permet d'associer un nom unique à un objet et faciliter ainsi l'obtention de cet objet.
Un annuaire est un service de nommage qui possède en plus une représentation hiérarchique des objets qu'il contient et un mécanisme de recherche.

Pour pouvoir utiliser autant de services différents possédant des protocoles d'accès différent, JNDI utilise des pilotes SPI (Service Provider). Trois de ces pilotes sont fournis en standard :

  • LDAP (Lightweigth Directory Access Protocol)
  • service de nommage CORBA (COS)
  • service de nommage RMI

JNDI est composé de 6 packages.

JNDI est un composant important de J2EE car plusieurs technologies comme les EJB utilise JNDI. JNDI est utilisé pour stocker et obtenir un objet Java. D'autres technologies comme JDBC ou JMS peuvent utiliser JNDI.


1.6.7. API JDBC


Cette API fournit une connectivité indépendant de la base de donnée, entre la plate-forme J2EE et une grande quantité de sources de données tabulaire. La technologie JDBC permet à un application component provider to

  • réaliser une connexion et une authentification au serveur de la base
  • gérér les transactions
  • transférer les requêtes SQL à un service de la base de données pour un pre-process et une execution
  • Inspecter et modifier les résultats d’une requête Select

La plate-forme J2EE requière le JDBC 2.0 Core API (inclus dans la plate-forme J2SE) et l’API JDBC 2.0 Extension API, qui fournit row sets, connection naming via JNDI, connection pooling, et un support de transaction distribuée. The connection pooling and distributed transaction features are intended for use by JDBC drivers to coordinate with a J2EE server.


1.6.8. API JTA (Java Transaction)


JTA fournit une interface standard pour les démarcation de transactions (appel de méthode). L’architecture J2EE fournit par défaut un auto commit pour gérer les commits et rollbacks des transactions. Un auto-commit implique que d’autres applications en train de regarder les données vont voir les données updatées après chaque opération de lecture ou de d’écriture sur la base. Cependant, si l’application exécute 2 opérations séparées d’accès à une base qui dépendant l’une de l’autre, l’API JTA permettra de démarquer dans la transaction en entier, comprenant les 2 opérations, où elle commence, rolls back ou commit.
Une transaction JTA est une transaction qui met en œuvre différents composants et manager de ressources. Une transaction resource manager local transaction est une transaction qui est spécifique d’une connexion à un système particulier d’information d’entreprise. Par exemple, chaque requête SQL exécutée sur une connexion JDBC possède sa propre transaction.


1.6.9. API JCA (J2EE Connector Architecture)


Avant la spécification JCA , il n’existait pas (avant v1.3) de moyen standard pour intégrer la plate-forme Java avec les autres applications middlewares existant dans l’entreprise : applications spécifiques, ERP, CRM, etc.. L’intégration se faisait avec des solutions propriétaires.
L’API JCA propose une interface de communication entre le serveur d’applications et le système externe. La communication asynchrone bidirectionnelle est possible. Les communications entrantes sont redirigées vers un Message Driven Bean (MDB). Il est possible de définir des types de messages différents. Par exemple, dans le cas d’une application d’envoi de message d’alerte sous forme de mails, il est envisageable de définir un connecteur qui envoie ce type de message.


1.6.10. API JAAS (Java Authentication and Authorization Service)


JAAS fournit un moyen d’authentifier et d’autoriser l’accès à un utilisateur spécifique ou à un groupe d’utilisateurs, aux applications J2EE. De plus, la spécification Java Authorization Service Provider Contract for Containers (v1.4) permet l’intégration d’une infrastructure d’autorisation existante dans le serveur d’application, lorsqu’un outil fédérateur des autorisations préexiste déjà dans l’entreprise.


1.6.11. API JAXP (Java API for XML Registries)


Permet de lire, de manipuler et de générer, parser et transformer des documents XML. JAXP propose une manière standard d’intégrer un parseur XML dans une application Java, que ce soit un parseur SAX2 (Simple API for XML), un parseur DOM2 (Document Object Model) ou bien encore un transformateur XLST (eXtensible Style Language Transformation). De plus, JAXP supporte les schémas XML (XML Schema). http://www.w3.org/XML/Schema


1.6.12. API JAX-RPC (Java for XML-based RPC)


Définit les API permettant de développer et d’utiliser des services web. JAX-RPC est conforme à la spécification 1.1 du protocole SOAP, et permet donc l’utilisation du XML pour l’invocation de méthodes à travers le réseau.
Les services web sont des applications d’entreprises basées sur le web qui utilisent les standards basés sur le XML (Extensible Markup Language) et des protocoles de transport pour échanger les données avec des clients (SOAP, WSDL, UDDI). La plate-forme J2EE fournit les APIs XML et des outils pour concevoir, développer, tester et déployer des Services web et des clients qui inter opèrent avec d’autres clients ou services web sur plateforme java ou non.
Il est facile de faire des services ou clients web avec les APIs XML, il suffit de passer des paramètres aux méthodes appelées, et de récupérer les données. La traduction des données en un flux de données (data-stream ) basé sur le xml standardisé est ce qui fait que les services et clients écrits avec les APIs XML de J2EE sont totalement inter opérant.


1.6.13. Résumé


  • Les applications J2EE sont modulaires, utilisent des services runtime et sont distribuées.
  • J2EE propose une spécification pour décrire le mode d'assemblage et de déploiement d'une application J2EE, ainsi que les rôles de chaque éléments et précisent un ensemble d'interfaces pour permettre à chacun de ces éléments de communiquer. Les spécifications précisent aussi à l'aide des API, un certain nombre de fonctionnalités que doivent implémenter l'environnement d'exécution.

Les descripteurs de déploiement contiennent les infos concernant :

  • l’identification des composants ou modules utilisés dans l’application.
  • les services runtime fournis par la plateforme dont ont besoin Les modules et applications assemblés
  • d’identifier les sources externes.


1.7. Les avantages de J2EE


  • Grâce à ses caractéristique modulaires :
    - grande flexibilité dans le choix de l'architecture de l'application en combinant les différents composants.
    - permet un découpage de l'application et donc une séparation des rôles lors du développement
    - garantie d’évolutivité de la plate-forme en vue de préparer les montées en charge liées au développement commercial attendu d’une société
  • Technologie Java, donc portabilité
  • Possibilité de s'interfacer avec les systèmes d'informations existants grâce à de nombreuses API : JDBC, JNDI, JMS ...ex : accès facile aux BDD
  • On a un modèle de sécurité unifiée, mais avec différents niveaux de sécurité suivant l’environnement de production, grâce à un système de configuration des services: implantation de systèmes externes d’authentification et d’autorisation.
  • On a un contrôle de transaction flexible
  • Le support de services web permet de déployer des services ou des clients web qui inter opèrent avec d’autres clients ou services web sur plate-forme java ou non
  • Possibilité de choisir les outils de développement et le, ou les serveurs d'application utilisés qu'ils soient commerciaux ou libres
  • Globalement cela simplifie l’intégration des systèmes.


1.8. Différentes Plates-formes J2EE : critères pour faire le bon choix



Plusieurs critères doivent guider ce choix de l’installation d’une plate-forme J2EE :

  • la typologie du projet : infrastructure globale contre projet tactique,
  • la technologie : EJB contre JSP + Servlet,
  • la taille de l'entreprise et son budget : grandes entreprises contre PME,
  • la notion d'ouverture : open source ou propriétaire.


1.8.1. Typologie du projet


Le premier critère à prendre en compte est la dimension de son projet. Un nombre croissant d'entreprises souhaitent en effet s'appuyer sur une infrastructure technique globale et homogène pour l'ensemble de leurs développements. Dans ce cas, une infrastructure applicative globale doit offrir toutes les couches nécessaires au développement d'une application complexe, et faciliter la réutilisation des composants de la couche métier. A l'inverse, un projet tactique ou départemental ne nécessite pas la même infrastructure technique parce qu'il est souvent isolé des autres projets de l'entreprise. On privilégie généralement le coût et la rapidité de mise en oeuvre de la plate-forme.


1.8.2. La technologie


La spécification J2EE comporte pas moins d'une dizaine de composants différents. Les EJB (Enterprise Java Bean) «assurent la distribution et le partage d'une ressource et des services associés au sein d'une entreprise, tout en normalisant l'écriture du code associé d'une part, et l'appel à ce composant (sécurité, transaction, persistance, etc.) d'autre part. En règle générale, les EJB sont métiers. Typiquement l'entité "client" et toutes ses méthodes (créer, modifier, facturer, etc.)
Un EJB seul ne possède aucune couche de présentation. Les JSP (Java Server Pages) ont donc été conçues pour présenter les données et traitements encapsulés dans les EJB. Dans la pratique, les entreprises qui n’utilisent pas les EJB développent l'ensemble de leurs applications - présentation et logique métier - directement à l'aide de servlets et de JSP. Le couple JSP/Servlet est adapté à des applications web simples, tandis que les EJB visent plutôt des projets de très grande envergure (nombreux composants, etc.).

Les serveurs J2EE se divisent en deux catégories: ceux qui supportent uniquement les servlet et les JSP - Tomcat, Resin, Jetty, WebSphere Express et Weblogic Express, etc. - et ceux qui supportent l'ensemble des spécifications J2EE (notamment les EJB et JMS), tels que JBoss, Jonas, Oracle 9iAS, WebSphere, Weblogic, etc.

Cette distinction technique est de taille. En choisissant un serveur qui ne supporte que JSP et les servlets, l'entreprise acquiert une technologie identique à ASP et PHP. Sauf que PHP et ASP sont largement plus répandus, mieux maîtrisés et coûtent moins cher en prestation. Seules, les JSP ont donc peu d'intérêt.


1.8.3. Taille de l’entreprise


Pour la majorité des éditeurs, ce choix technologique s'effectue en fonction de la taille des entreprises: le couple JSP/Servlet pour les PME, les EJB pour les grandes entreprises.


1.8.4. Open source ou propriétaire ?


Le troisième critère à prendre en compte est la dimension open source ou non de la plateforme. Plus que l'absence de coût de licence, les notions de communauté et de code source ouvert peuvent, dans certains cas, contrebalancer le gage de pérennité apporté par l'assise financière d'éditeurs tels que IBM ou Oracle.

Éditeur Éditeur/produit Technologie Prix (en euros)
BEA WebLogic Platform 7.0 J2EE complet 15 000
BEA WebLogic Express JSP, servlet, JDBC 499
Borland Enterprise Server 5.1 J2EE complet 14 120
Borland Enterprise Server Web edition 5.1 JSP, servlet, JDBC 460
IBM WebSphere Application Server 5 J2EE complet n.c.
IBM WebSphere Express JSP, servlet, JDBC 2 000
Iona Orbix E2A App. Server Platform J2EE complet 2 900
Macromedia JRun 4 J2EE complet 1 079
Oracle Oracle 9iAS J2EE complet 10 860
Oracle Oracle 9iAS Java Edition J2EE complet 4 985
Sun SunOne App Server 7 Platform J2EE complet 0 (109 euros pour Solaris)
Sun SunOne App Server 7 Enterprise J2EE complet 12 000
Sybase EAServer J2EE complet 4 456
Open source JBoss, Jonas, Orion J2EE complet 0
Open source Tomcat, Jetty JSP, servlet, JDBC 0
Les prix sont donnés à titre indicatif, observés au moment de la rédaction de cet article. Ils ne sont en aucun cas contractuel. L'auteur ne peut pas être tenu responsable des prix affichés. Pour connaitre les prix actuels, contactez l'éditeur ou votre distributeur habituel.

Parts de marché des éditeurs de serveur d'applications dans le monde (Source Gartner Dataquest) :

  En 2000 En 2001 En 2002
IBM 22% 31% 37%
BEA 33% 34% 29%
Sun 10% 9% 4%
Sybase 1% 1% 2%
Pénétration des serveurs d'application en Amérique du Nord (Source Hurwitz Group) :

  Mi-2001
Oracle (9iAS) 36.5%
IBM (Websphere) 27.0%
BEA (Weblogic) 17.5%
Sybase (EA Server) 16.0%
iPlanet (AS) 16.0%
SilverStream* 5.0%

1.9. Exemples d’utilisation de J2EE : intégration avec le tiers EIS


Ce chapitre illustre l’intégration d’applications d’entreprise avec des EIS (enterprise information systems) et d’autres applications. Les EIS fournissent des informations sur l’infrastructure critique du business process d’une entreprise. Les EIS inclus des bases de données relationnelles, des systèmes ERP (enterprise resource planning), des systèmes mainframe transaction processing, et des legacy database systems.
Il faut donc pouvoir intégrer ces EIS à l’architecture et aux services web. Les EIA (enterprise application integration )essayent d’intégrer les applications et les sources de données des entreprises afin qu’elles puissent facilement partager les business processes les données. Nous allons nous intéresser aux différents aspects des EIA : intégration des applications, des données, et des legacy.


1.9.1. Scénarios d’intégration


Une application J2EE peut être configurée de différentes manières pour accéder à l’EIS. Voici différents scénarios :


1.9.1.1. Une Application Internet E-Store


La société A déploie une application exemple pour créer une Boutique E-Store sur Internet. L’application est composée de différents EJB, de pages JSP, et de servlets qui collaborent pour fournir l’intégralité de la fonctionnalité de l’application. La base de données stocke les données en relation avec les produits de catalogue, des caddies, des inscription de clients, de leur profiles, et des états de commandes.

Le client utilise un navigateur pour initier une transaction de e-commerce avec l’application. Il peut :

  • naviguer dans le catalogue
  • faire une sélection de produits
  • mettre sa sélection dans un caddie
  • entrer un username et pswd pour initier une transaction sécurisée
  • remplir des informations liées à la commande
  • faire une commande

La société A stocke les informations persistantes concernant les clients et leurs transactions dans une BDD préexistante qui contient déjà des infos sur des produits et l’inventaire.


1.9.1.2. Une application Intranet de ressources humaines


La société B a développé et déployé une application self-service pour ses employés basée sur une plate-forme J2EE. Cette application fournit une interface Web à des applications préexistantes de ressources humaines supportées par le système de planning des ressources de l’entreprise du vendeur X et fournit des processus métiers additionnels qui sont configuré pour les besoins de la société B.

Le tiers du milieu est composé d’EJB, et de pages JSP qui fournissent la configuration adaptée du processus métier, et supportent l’interface web standardisée de la société. Cette application permet aux employés (sous les différents rôles de Manager, Hr.manager, ou Employes) de réaliser différentes fonctions de gestion du personnel :

  • Gestion des infos personnelles
  • Gestion du registre de paie du personnel (payroll)
  • Gestion des compensations,
  • Administration des avantages (mutuelles, etc..) (benefits administration)
  • Gestion des voyages
  • Et planification des coûts (costs planning).

Le service IT de la compagnie déploie cette application et le système de planning des ressources dans un environnement sécurisé, situé dans un seul lieu physique.
L’accès à cette application n’est autorisée qu’aux employés de l’organisation suivant leur rôle, et leur privilèges d’accès, au sein d’un intranet d’une large organisation.


1.9.1.3. Une Application d’achats distribuée (B2B)


La société C a une application distribuée d’achat basée sur une interface Web. Un employé peut grâce à cette interface réaliser plusieurs transactions d’achat. Il peut utiliser cette application pour gérer un processus de fourniture (procurement), il peut aller de la création d’une demande d'achat jusqu’à l’obtention de l'approbation de facture (An employee can use the application to manage the procurement process, from creating a purchase requisition to getting invoice approval.)

This application also integrates with the existing financial applications in the enterprise for tracking financial aspects of the procurement business processes. L’application est développée et déployée sur une plate-forme J2EE, composée de pages JSP, d’EJB, et de systèmes d’information préexistants. L’EJB intègre une application logistique qui fournit des fonctions intégrée de gestion d’inventaire et d’achats du vendeur X , et une autre application qui fournit des fonctions de comptabilité financière (financial accounting) du vendeur Y.

La société C est une grande entreprise décentralisée avec des unités et des départements distribués géographiquement. Dans ce scénario, Les Systèmes X et Y sont gérés par différents services IT et ont été déployés dans des centres sécurisés de données, dans différents lieux géographiques. L’application intégrée d’achat est déployée dans un lieu différent des systèmes X ou Y.
Les systèmes X et Y sont dans des domaines sécurisés différents, ils utilisent différentes technologie de sécurité, et ont leur propres politiques et mécanismes de sécurité.


1.9.1.4. An Order Fulfillment Application


Extension du scénario de l’e-store.


1.9.2. Les technologies d’intégration


Pour répondre à ces différents problèmes d’intégration EIS, la plate-forme J2EE fournit différentes technologies.


1.9.2.1. J2EE Connector architecture


Il définit un standard de connexion d' un serveur J2EE à un Enterprise Information System (EIS). L’architecture Connector permet à des adaptateurs externes d’être branché au serveur d’application J2EE. Les applications d’entreprise peuvent donc être développées en utilisant ces adaptateurs pour supporter et gérer des intégrations sécurisées, transactionnelles, et scalables avec les EISs. L’intégration peut être synchrone ou asynchrone.
Si l’adaptateur de ressource est conforme aux spécifications de l’architecture du Connector, il peut être branché dans n’importe quel serveur d’application conforme J2EE , pour fournir une infrastructure de base d’intégration aux EIS. Les 2 collaborent pour maintenir les mécanismes de gestion connexion, transaction et sécurité de manière transparente pour les composants de l’application.
L’architecture de Connector J2EE définie 2 types de contrats (ensemble d’API) pour les accès aux EIS : contrat au niveau application (existe entre le composant de l’application et l’adaptateur), et contrat au niveau système ( existe entre le serveur d’application et l’adaptateur).

Le contrat au niveau application : fournit une interface client commune aux différents types d’EIS. L’interface Common Client Interface (CCI), est un contrat d’application entre l’application et l’adaptateur de ressources (les adaptateurs pouvant être variés suivant les différents EIS). CCI est une API qui est commune , standard et qui permet l’accès à des EIS multiples et hétérogènes.
Les fournisseurs d’application peuvent construire leurs outils sur cet API. On peut typiquement combiner JDBC avec CCI en utilisant l’API JDBC pour accéder aux base de données relationnelles, et CCI pour accéder à d’autres EIS.
Les vendeurs d’EAI (Entreprise Application Integration) n’ont pas à adapter leurs produits à chaque type d’EIS. L’API client CCI repose sur de simples fonctions d’appel à distance pour fournir un accès aux données EIS. Il fournit assez de fonctionnalités pour que l’application puisse créer et gérer des connexions à l’EIS , et accéder aux données enregistrées.
http://www.the-internet-agency.com/adbcwebix/cci.htm

Le contrat au niveau système : il définit un standard de “branchement” entre le serveur d’application et l’EIS. L’EIS implémente de son coté le contrat-système dans un adaptateur, qui est une librairie spécifique d’EIS. (Exemples d’adaptateurs : adaptateur qui se connecte à un système ERP, ou un adaptateur qui se connecte à un mainframe transaction processing system).

Il y a aussi une interface entre l’adaptateur de ressource et son EIS particulier. L’architecture Connector ne définit pas cette interface.
L’architecture Connector définit les services qu’un serveur d’application conforme J2EE doit fournir. Ces services--transaction management, security, and connection pooling sont “tracés” dans les 3 contrats du Connecteur au niveau système. Ces 3 contrats systèmes qui ensembles, forment le SPI (Service Provider Interface), sont les suivants :

  • Connection management contract

Ce contrat permet au serveur de pooler des connexions à un EIS de base, pendant que dans le même temps il permet à des composants de l’application de se connecter à l’EIS. Le pooling de connexion est important pour créer un environnement d’application scalable, particulièrement important quand un grand nombre de clients demandent à se connecter à l’EIS de base.

  • Transaction management contract

Ce contrat est entre le transaction Manager du serveur et l’EIS qui supporte les transactions. Il fournit au transaction manager la capacité de gérer des transactions à travers différents EIS resource managers. (Un resource manager fournit l’accès à un set de ressources partagées.). Le contrat supporte aussi les transactions locales, qui sont des transactions dont l’EIS resource manager s’occupe en interne.

  • Security contract

Ce contrat permet l’accès sécurisé à un EIS et protégé les ressources gérées par l’EIS.


1.9.2.2. Java Message Service (JMS)


Le JMS est une Api standard définie pour les systèmes de messageries d’entreprise. C’est une API qui peut être utilisée à travers différents types de systèmes de messagerie. Une application Java utilise l’API JMS pour se connecter au système de messagerie de l’entreprise. Une fois connectée, l’application utilise les facilités du système de messagerie de base l’entreprise (au travers de l’API) pour créer des messages et communiquer en asynchrone avec 1 ou plusieurs autres applications apparentées.
Un JMS provider implémente l’API JMS pour le système de messagerie de l’entreprise, et fournit l’accès aux services du système de messagerie de base.

La version 2.0 de l’ architecture Connector 2.0 définit un standard pour brancher un JMS Provider dans un serveur d’application, qui permet au JMS Provider d’être traité de manière similaire au resource adapter. Toutefois, un JMS Provider aura une API JMS comme API client pour le système de messagerie de base de l’entreprise.
Une application client, appelée client JMS, utilise une API JMS pour accéder aux installations de messagerie asynchrones fournit par le système de messagerie de l’entreprise. Le tiers EJB est la meilleure place pour implémenter les clients JMS des applications J2EE. Les applis sources ou destinations sont considérés comme des clients du JMS provider.

Un domaine JMS identifie le type de communication asynchrone supporté par le JMS provider et le système de messagerie de l’entreprise. Il existe 2 types de domaines : Le domaine point-à-point basé sur les files d’attente (queue-based point-to-point domain), et le domaine édite-souscrit (publish-subscribe).
Une application Java utilisant JMS a des modèles de programmation différent suivant le domaine JMS. Par exemple, une appli Java utilise une interface JMS-defined queue-based pour intéragir avec un domaine point-à-point.


1.9.2.3. JDBC and RDBMS Access


Les systèmes de gestion des bases de données relationnelles (RDBMS) sont les formes prédominantes de stockage des données dans l’entreprise. La plupart des applications utilisent les API JDBC 2.0 ou 3.0 pour accéder aux bdd relationnelles, pour gérer la persistance des données dans l’application. L’API JDBC est en 2 parties : une API client pour une utilisation directe par les développeurs afin d’accéder aux bdd, et un contrat standard niveau-système entre le serveur J2EE et les drivers JDBC pour supporter les transactions et le pooling des connexions. Conceptuellement, les drivers JDBC sont des resource adapters que l’on peut brancher. Le composant de l’application utilise l’API client JDBC pour des opérations telles que : obtention d’une connexion à la bdd, récupération d’enregistrements de la base, exécution de requêtes et procédures stockées, et autres fonctions de la bdd.



Copyright(c) 2004 ALVARO Véronique.
Ce document issu de http://www.developpez.com est soumis à la licence GNU FDL traduite en français ici.

Mes articles :
Les applications J2EE et les Frameworks
Article sur Jonas
Les autres ressources :
Tous les cours Java
La FAQ Java
Les forums java, j2ee, JBuilder, Eclipse, Autres outils pour java.