3.6.2.2 Choix de
l'outil de développement :
Vu la multidisciplinarité et sa domination
croissante, plusieurs outils de développement de Java ne cessent de voir
le jour. On peut rencontrer pas mal d'Environnement de Développement
Intégré (EDI) Java. Certains sont en open source et d'autres
commerciaux.
Citons quelques uns :
Ø Borland de JBuilder :
Doté d'un EDI, il est placé parmi les logiciels
les plus performants pour le développement des applications en java.
Ecrit en Java 2 permet ses applications d'être exécutés
sous plusieurs plateforme.
Ø IBM Visual Age for Java :
Il s'agit d'un EDI développé par IBM. Il est
trop puissant avec son ergonomie. L'utilisation au début est difficile
mais sa persévérance est intéressante.
Ø NetBeans:
NetBeans est un environnement de développement en java
open source écrit en java. Le produit est composé d'une partie
centrale à laquelle il est possible d'ajouter des modules tel que
Poseidon pour la création avec UML.
Ø JCreator :
JCreator existe en deux versions : la version "LE" est en
freeware et la version "PRO" est en shareware. Il est particulièrement
rapide car il est écrit en code natif.
Ø Le projet Eclipse :
Eclipse est un projet open source à l'origine
développé par IBM pour ces futurs outils de développement.
Le but est de fournir un outil modulaire capable non seulement de faire du
développement en java mais aussi dans d'autres langages et d'autres
activités. Cette polyvalence est liée au développement de
modules réalisés par la communauté ou des entités
commerciales.
Dans un esprit de défi, et vouloir mettre en oeuvre les
connaissances qu'on a acquis durant notre formation, on a opté JCreator
Pro pour le développement de notre application. Ce logiciel est
dépourvu d'un EDI donc pour arriver à nos fins on était
obligé d'écrire ligne par ligne le code de notre application ce
qui est fait malgré plusieurs problèmes rencontrés.
3.6.2.3 Choix du
SGBD :
De nombreux SGBD sont disponibles sur le marché, partant
des SGBD gratuits jusqu'aux SGBD destinés spécialement aux
professionnels, comportant de plus nombreuses fonctionnalités, mais plus
coûteux.
On va essayer de faire comme d'habitude une étude
comparative d'une sélection de quelques SGBD et choisir un pour notre
application.
En guise de cause on mentionne quelques facteurs subjectifs qui
influent souvent sur le choix du SGBD :
Ø La politique sécuritaire
Ø Le budget à disposition
Ø Les compétences déjà acquises en
terme de développement et d'administration et au besoin du prix de la
formation
Ø Le système d'exploitation hébergeant
Ø Les architectures logicielles et matérielles
Ensuite viendront des points tels que :
Ø La richesse fonctionnelle du SGBDR
Ø Les ressources (disques, mémoire, CPUs,
Transactions par secondes, nombre de connexions simultanées)
Ø L'attente que vous avez vis-à-vis du support
technique
Ø Les compétences déjà acquises en
termes de développement et d'administration
Ø Le type d'accès aux données (OLTP,
décisionnelle, reporting, mixte)
Faisons l'étude de quelques uns qui sont connus par un
grand nombre du public :
3.6.2.3.1 Oracle
Database
Oracle n'est pas un SGBDR optimisé pour de petites
bases de données. Sur de petits volumes de traitements (2 Go par
exemple) et peu d'utilisateurs (une trentaine).
Avantage :
· Procédures stockés en PL-SQL (langage
propriétaire Oracle, orienté ADA) ou ... en JAVA (depuis la
8.1.7) ce qui peut s'avérer utile pour les équipes de
développement.
· Assistants performants via Oracle Manager Server,
possibilité de gérer en interne des tâches et des alarmes
· Gestion centralisée de plusieurs instances
· Concept unique de retour arrière (Flashback)
· Pérennité de l'éditeur : avec plus de
40% de part de marché, ce n'est pas demain qu'Oracle disparaîtra
· Réglages fins : dans la mesure où l'on
connait suffisamment le moteur, presque TOUT est paramétrable.
· Accès aux données système via des
vues, bien plus aisément manipulable que des procédures
stockées.
· Services Web
· Support XML
· Ordonnanceur intégré
Inconvénients
· Prix exorbitant, tant au point de vue des licences que des
composants matériels (RAM, CPU) à fournir pour de bonnes
performances
· Fort demandeur de ressources, ce qui n'arrange rien au
point précité, Oracle est bien plus gourmand en ressource
mémoire que ses concurrents, ce qui implique un investissement
matériel non négligeable. La connexion utilisateur
nécessite par exemple près de 700 Ko/utilisateur, contre une
petite centaine sur des serveurs MS-SQL ou Sybase ASE. Gourmand aussi en espace
disques puisque la plupart des modules requièrent leur propre
ORACLE_HOME de par le versionning de patches incontrôlés.
· Porosité entre les schémas = difficile de
faire cohabiter de nombreuses applications sans devoir créer plusieurs
instances. Il manque réellement la couche "base de données" au
sens Db2/Microsoft/Sybase du terme.
· Méta modèle propriétaire, loin de la
norme.
· Tables partitionnées, RAC... uniquement possible
à l'aide de modules payants complémentaires. Parallélisme
mal géré sur des tables non-partitionnées.
· Gestion des verrous mortels mal conçue (suppression
d'une commande bloquante sans roll back)
· Pauvreté de l'optimiseur (ne distingue pas les
pages en cache ou en disque, n'utilise pas d'index lors de tris
généraux, statistiques régénérées par
saccade...)
· Pas de prise directe sur les tables système (vues
système)
· Une quantité de bugs proportionnels à la
richesse fonctionnelle, surtout sur les dernières versions
· Gestion erratique des rôles et privilèges
(pas possible de donner des droits sur des schémas particuliers sans
passer par leurs objets, désactivation des rôles lors
d'exécution de packages...)
· Nombreuses failles de sécurités liées
à l'architecture elle-même
| 
