Les applications J2EE et les Frameworks01/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
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.
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).
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.
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.
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.
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 ...) |
| 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.). |
| 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.
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.
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.
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.
- 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.
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.
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.
|
