EJB3, WebServices et JDBC

Un petit complément d'info, j'utilise:
MySQL 5
Java 5
SunAppServer 9

Je suis aussi préoccupé par la gestion du cache des EJB3 dans un tel
environnement (mais je pense que le fait que le C++ ne puisse que lire
va aider...).

Merci pour vos conseils.

Raphael Tagliani wrote:

Bonjour,

J'ai quelques problèmes pour me décider concernant une architecture:

J'ai une appli C++, qui doit communiquer avec une base de données.
Pour l'instant, j'ai créé un Webservice pour que le C++ puisse accéder à
un serveur glassfish avec des EJB3, et les performances sont bonnes pour
les premiers tests.

Cependant, l'appli C++ a été développée il y a longtemps, et elle aurait
besoin de faire des requêtes SQL directement sur la DB.

Il y a énormément de tables (+de 200) et énormément de données dans les
tables (jusqu'à 500'000 tuples dans une table).

De plus, la plupart du code métier sera en java, sur le serveur.

Je voudrais donc que:
- le code java profites des EJB3
- mais avoir accès à la DB via le webservice pour le C++, et passer
directement par JDBC pour exécuter une requête SQL99 et obtenir un
ResultSet (Le C++ pourrait uniquement LIRE dans la DB)

Ma question: est-ce que c'est une idée valable, ou est-ce que je vais
tomber sur de gros problèmes de concurrence, p.ex avec les transactions?

Merci a tous!

Un petit complément d'info, j'utilise:
MySQL 5
Java 5
SunAppServer 9

Je suis aussi préoccupé par la gestion du cache des EJB3 dans un tel
environnement (mais je pense que le fait que le C++ ne puisse que lire
va aider...).

Merci pour vos conseils.

Raphael Tagliani wrote:

Bonjour,

J'ai quelques problèmes pour me décider concernant une architecture:

J'ai une appli C++, qui doit communiquer avec une base de données.
Pour l'instant, j'ai créé un Webservice pour que le C++ puisse accéder
à un serveur glassfish avec des EJB3, et les performances sont bonnes
pour les premiers tests.

Cependant, l'appli C++ a été développée il y a longtemps, et elle
aurait besoin de faire des requêtes SQL directement sur la DB.

Il y a énormément de tables (+de 200) et énormément de données dans
les tables (jusqu'à 500'000 tuples dans une table).

De plus, la plupart du code métier sera en java, sur le serveur.

Je voudrais donc que:
- le code java profites des EJB3
- mais avoir accès à la DB via le webservice pour le C++, et passer
directement par JDBC pour exécuter une requête SQL99 et obtenir un
ResultSet (Le C++ pourrait uniquement LIRE dans la DB)

Ma question: est-ce que c'est une idée valable, ou est-ce que je vais
tomber sur de gros problèmes de concurrence, p.ex avec les transactions?

Merci a tous!

Bonjour,

Pouvez-vous préciser si vous avez mis en place des EJB3 entité (ou juste
des sessions sans état pour faire office de façade aux services) ?

Si c'est le cas, précisez également quel est le pourcentage de votre
schéma estcouvert par de telles entités ?

Enfin, il faudra nous en dire plus sur le role de l'appli C++ par
rapport à d'autres eventuelles appli (utilisant Java EE ou SE) par
exemple ..

AMHA et en m'avançant un peu sur vos réponses, je pense que mise à part
le fait d'être "capilotracté" (et donc délicat à maintenir), je ne vois
pas de problème tant que les modifications passent par un contexte
transactionel. Au plus, il faudra bien faire attention à bien configurer
d'éventuels caches (entités ou autres) interferant avec le webservice.

A+
TM

Bonjour,

Pouvez-vous préciser si vous avez mis en place des EJB3 entité (ou juste
des sessions sans état pour faire office de façade aux services) ?

Si c'est le cas, précisez également quel est le pourcentage de votre
schéma estcouvert par de telles entités ?

Enfin, il faudra nous en dire plus sur le role de l'appli C++ par
rapport à d'autres eventuelles appli (utilisant Java EE ou SE) par
exemple ..

AMHA et en m'avançant un peu sur vos réponses, je pense que mise à part
le fait d'être "capilotracté" (et donc délicat à maintenir), je ne vois
pas de problème tant que les modifications passent par un contexte
transactionel. Au plus, il faudra bien faire attention à bien configurer
d'éventuels caches (entités ou autres) interferant avec le webservice.

A+
TM

Bonjour,

Merci infiniment pour votre réponse, en fait, j'esperait que ce soit
vous qui répondiez, comme j'ai déjà constaté souvent que vous donniez de
très bons conseils.

J'ai mis des EJB3 entité et des SessionBeans Stateless, tous les accès
passent par les session beans.

Tout mon schéma de DB est couvert par les entités. 90% des accès sont en
lecture uniquement.

L'appli C++ est le client (très) lourd pour l'application. C'est
principalement une GUI, mais on lui délègue aussi les processus lourds,
histoire de ne pas surcharger le serveur. Elle permet d'afficher des
statistiques sur des graphiques 3D openGL, et une multitude de tâches
qui permettent de saisir des formulaires, et de faire des recherches...

Je prévois de mettre a disposition certaines tâches par JSP et d'autres
avec un client SWING.

En gros, on aurait quelque chose comme ça:
Ergonomie Installation, portabilité
C++ *** *
SWING ** **
JSP * ***

Le client C++ existe déjà, il a des fonctionnalités impressionnantes,
qui prendront beaucoup de temps à rattraper en java. C'est pourquoi
j'essaie de le conserver.

Voici la solution que j'entrevois:

Le C++ a accès à la DB en "direct" (web service + JDBC dans un
SessionBean), uniquement en lecture.
Tout le côté java (SWING+JSP+code métier) accède à la DB par les entity
beans, et a le droit de modifier la DB.

Lors d'une action dans la GUI C++ pouvant altérer les données (modifier,
nouveau, supprimer), le C++ recharge les données nécessaires à
l'accomplissement de la modification.
L'utilisateur fait ses modifications, et il clique sur valider.
Le java métier vérifie la validité de la saisie, et si les données qui
sont dans la DB sont celles de la préimage. Si c'est le cas, il écrit la
modification dans la DB, sinon, il refuse, et renvoie une erreur à
l'utilisateur, en lui affichant quelles sont les données qui ont changé
entre-temps.

Est-ce que vous pensez que cette idée tient debout? Est-ce que je
devrais plutôt utiliser des transactions?

Bonne journée!

Bonjour,

Pouvez-vous préciser si vous avez mis en place des EJB3 entité (ou
juste des sessions sans état pour faire office de façade aux services) ?

Si c'est le cas, précisez également quel est le pourcentage de votre
schéma estcouvert par de telles entités ?

Enfin, il faudra nous en dire plus sur le role de l'appli C++ par
rapport à d'autres eventuelles appli (utilisant Java EE ou SE) par
exemple ..

AMHA et en m'avançant un peu sur vos réponses, je pense que mise à
part le fait d'être "capilotracté" (et donc délicat à maintenir), je
ne vois pas de problème tant que les modifications passent par un
contexte transactionel. Au plus, il faudra bien faire attention à bien
configurer d'éventuels caches (entités ou autres) interferant avec le
webservice.

A+
TM

Bonjour,

Merci infiniment pour votre réponse, en fait, j'esperait que ce soit
vous qui répondiez, comme j'ai déjà constaté souvent que vous donniez de
très bons conseils.

J'ai mis des EJB3 entité et des SessionBeans Stateless, tous les accès
passent par les session beans.

Tout mon schéma de DB est couvert par les entités. 90% des accès sont en
lecture uniquement.

L'appli C++ est le client (très) lourd pour l'application. C'est
principalement une GUI, mais on lui délègue aussi les processus lourds,
histoire de ne pas surcharger le serveur. Elle permet d'afficher des
statistiques sur des graphiques 3D openGL, et une multitude de tâches
qui permettent de saisir des formulaires, et de faire des recherches...

Je prévois de mettre a disposition certaines tâches par JSP et d'autres
avec un client SWING.

En gros, on aurait quelque chose comme ça:
Ergonomie Installation, portabilité
C++ *** *
SWING ** **
JSP * ***

Le client C++ existe déjà, il a des fonctionnalités impressionnantes,
qui prendront beaucoup de temps à rattraper en java. C'est pourquoi
j'essaie de le conserver.

Voici la solution que j'entrevois:

Le C++ a accès à la DB en "direct" (web service + JDBC dans un
SessionBean), uniquement en lecture.
Tout le côté java (SWING+JSP+code métier) accède à la DB par les entity
beans, et a le droit de modifier la DB.

Lors d'une action dans la GUI C++ pouvant altérer les données (modifier,
nouveau, supprimer), le C++ recharge les données nécessaires à
l'accomplissement de la modification.
L'utilisateur fait ses modifications, et il clique sur valider.
Le java métier vérifie la validité de la saisie, et si les données qui
sont dans la DB sont celles de la préimage. Si c'est le cas, il écrit la
modification dans la DB, sinon, il refuse, et renvoie une erreur à
l'utilisateur, en lui affichant quelles sont les données qui ont changé
entre-temps.

Est-ce que vous pensez que cette idée tient debout? Est-ce que je
devrais plutôt utiliser des transactions?

Bonne journée!





J'ai perdu le début de ce fil, et je ne sais pas quel type de WAS est

utilisé.
Tu pourrais regarder du coté de Hibernate 3 qui intègre la fonctionalité
Java Transaction Manager pour gérer les accés DB issus de la chaine
C++/WebServices et de la chaine pur Java.

J'ai perdu le début de ce fil, et je ne sais pas quel type de WAS est
utilisé.
Tu pourrais regarder du coté de Hibernate 3 qui intègre la fonctionalité
Java Transaction Manager pour gérer les accés DB issus de la chaine
C++/WebServices et de la chaine pur Java.
Merci,

J'utilise Glassfish dernière version. Je crois que sa couche de
persistence repose sur Hibernate.
Bonne journée!

Raphael Tagliani wrote:

J'utilise Glassfish dernière version. Je crois que sa couche de
persistence repose sur Hibernate.

Non, c'est Toplink Essentials
https://glassfish.dev.java.net/javaee5/persistence/

Lionel wrote:

Raphael Tagliani wrote:

J'utilise Glassfish dernière version. Je crois que sa couche de
persistence repose sur Hibernate.

Non, c'est Toplink Essentials
https://glassfish.dev.java.net/javaee5/persistence/


Ok, merci. Je vais donc jeter un coup d'oeuil à Hibernate 3.

On 30 août, 14:55, Raphael Tagliani <raphael.tagli...@gmail.com>
wrote:

Voici la solution que j'entrevois:

Le C++ a accès à la DB en "direct" (web service + JDBC dans un
SessionBean), uniquement en lecture.
Tout le côté java (SWING+JSP+code métier) accède à la DB par le s entity
beans, et a le droit de modifier la DB.
Donc, si le C++ attaque des session beans, votre problème se résume à

développer un ensemble de beans (session + entity) qui résolve bien
votre problème. Et ceci est indépendant de l'utilisation du C++ pour
le client. Selon vos besoins transactionnels, le paramétrage de vos
beans devraient pouvoir vous offrir toutes les bonnes garanties, ce
d'autant plus facilement si vous n'utilisez qu'un serveur.
Bon courage pour la suite.

Bonjour,

Je prends le train en route.

Bien sûr que vous allez tomber dans un problème de concurrence:
1. Au niveau de la base ca c'est à 100%
2. Au niveau de la mémoire (voir du coté de ehcache)
3. Au niveau du traitement qui doit inclure la notion de 'synchronize'
dans les méthodes Java qui pourraient manipuler le même objet par
différentes personnes.

Donc le conseil est le suivant
a. Inclure les transactions est un must car en plus en cas de panne
vous pouvez retrouver l'état de la base au moment de la panne avec des
tables MySQL InnoDB et pas MyIsam à paramétrer soit dans les défauts
de MySQL ou rajouter la clause MySQL nécessaire lors de la création
des tables
b. Manipuler les tables toujours dans un même ordre dans la
transaction cela vous évitera les problèmes de deadlock/exclusion
mutuelle/etreinte fatale
c. Si vous utilisez Java5, les EJB3 entities sont à utiliser avec les
annotations appropriées
d. Quand au C++ et les webservices ne font que ralentir votre système
particulièrement dans un enviromment intranet il y a d'autres technos
utilisés en pareils cas (RMI, CORBA)

Voilà un conseil à chaud, j'espère que cela va vous aider

Merci beaucoup pour vos précieuses indications.
Je ne suis pas d'accord concernant le ralentissement du système qui
serait dû aux webservices. Nous avons menés des tests, et les résultats
sont très bons (bien sûr, nous essayons de limiter les appels de méthode
du webservice au minimum nécessaire). De plus, utiliser des webservices
permet d'envisager de déployer le client lourd en dehors de l'intranet,
en donnant des garanties de sécurité facilement (webservice sécurisé).

Mohamed wrote:

Bonjour,

Je prends le train en route.

Bien sûr que vous allez tomber dans un problème de concurrence:
1. Au niveau de la base ca c'est à 100%
2. Au niveau de la mémoire (voir du coté de ehcache)
3. Au niveau du traitement qui doit inclure la notion de 'synchronize'
dans les méthodes Java qui pourraient manipuler le même objet par
différentes personnes.

Donc le conseil est le suivant
a. Inclure les transactions est un must car en plus en cas de panne
vous pouvez retrouver l'état de la base au moment de la panne avec des
tables MySQL InnoDB et pas MyIsam à paramétrer soit dans les défauts
de MySQL ou rajouter la clause MySQL nécessaire lors de la création
des tables
b. Manipuler les tables toujours dans un même ordre dans la
transaction cela vous évitera les problèmes de deadlock/exclusion
mutuelle/etreinte fatale
c. Si vous utilisez Java5, les EJB3 entities sont à utiliser avec les
annotations appropriées
d. Quand au C++ et les webservices ne font que ralentir votre système
particulièrement dans un enviromment intranet il y a d'autres technos
utilisés en pareils cas (RMI, CORBA)

Voilà un conseil à chaud, j'espère que cela va vous aider