Reprise du message précédent :

 
Ah mais je le sais!
Parceque:
1- ça fait serieux
2- "le système ne tiendra pas avec les outils actuels, j'ai déjà vu que..." (réponse du chef qui a 15 ans de metier dans les BDD, qui est habitué a travaillé sur des gros systèmes, veut avoir raison et n'a pas spécialement suivi les évolutions - ne connait pour ainsi dire que DB2 et OracleDB)
 
Re-précision: face au chef qui a 15 ans de metier, un débutant qui plus est non-développeur, n'a que peu d'arguments
 
Re-edit: et franchement, en tant que débutant, ça me botte de découvrir ces architectures  

 
Un Application Server n'a rien à voir avec un SGBD. Si c'est un problème de persistence et d'accès aux données, ca n'a rien à voir avec J2EE.
 
Je crois qu'on tourne en rond. Essaie de définir clairement tes besoins et y a moyen de discuter sur base de ça. La c'est trop vague

 
Ok!
Comme je présente l'exposé demain, je demanderais s'il est sûr que l'on part dans la bonne direction. En fait, les solutions "tout intégrée" semblent sympa car l'homogénéité permet d'éviter les problèmes que l'on a eu en Jscript avec les objets MS ou les problèmes d'ODBC que l'on rencontre parfois
 

 
Le besoin est simple comme bonjour:
- un programme qui reçoit (en https) une transaction, la stocke dans une BD, envoie la transaction à la banque, attend la réponse (10 minutes maxi) et renvoie le résultat au client en mettant à jour la base.
- un site pour permettre de calculer le CA, gérer les remboursements en temps réel pour nous
- un site pour permettre au client de voir ses transactions en temps réel. Il se loggue et voit pour chaque transaction(date, numéro, état, montant)
 
Une chose très simple somme toute mais que nos outils ne nous permettent pas de gérer de manière propre (manque d'homogénéité)
 
EDIT: Je repete que je ne suis pas développeur donc je raconte ce que l'on me communique comme infos et qu'il se peut que je sorte une énormité, merci de me le signaler

 
Un Application Server ne contient pas de SGBD ... Qu'est ce que tu appelles une solution tout intégré? Webshpere ne contient pas DB2 hein
 
Edit: concernant tes besoins, il me semble que tu as besoin d'une gestionnaire transactionnel (JTA en Java). Je ne pense pas qu'il y ait ce genre de support dans tomcat donc effectivement tu devrais te tourner vers J2EE (en ce qui concerne Java)
 

faut pas oublier que derriere tout ça y'aura un travail de developpement, que les consultants j2ee sont chers et que 50% d'entre eux ne connaissent pas la moitié de ce qu'ils prétendent ou croient connaitre.
 
alors quitte à se casser la gueule, autant pas avoir une dette de 100.000? envers IBM ou BEA.

 
D'après ce que j'ai lu (et compris surtout), Websphere privilégie le support DB2
 
Merci pour ton conseil, et bonne nuit  

d'un autre côté t'as plus de chance d'avoir un consultant qu'y s'y connait en WEbshpere qu'en JBoss malheureusement
 
(sauf si ils veulent nous engager )

forcément.
 
de meme qu'oas va pas te conseiller d'aller utiliser access

d'un autre coté, s'il connait *vraiment* un des deux, il devrait pas avoir de mal a passer à l'autre.

 
bin c'est un produit à eux c'est normal. Il n'empeche que c'est pas une solution tout intégré  
c'est 2 produits différents
 
tu pourrais très bien lui coller un SGBD gratuit au cul sans problème

 
non c'est pas vrai. Tu connais mon passé et mon expérience. Passer a JBoss n'a pas été simple

bah j'ai pas dit que ça se faisait en 2jours...
et puis si tu fais des trucs standards, le reste c'est que de la config et du tuning du serveur

   
tu pousses un peu là, c'est quand même très lié ...

 
bin non

ben et les Entity Bean CMP ??

 
Tu veux dire que ce n'est pas simplement du Java

 
Bien entendu mais l'ODBC (et donc à priori JDBC), on a déjà donné... Donc s'il y a moyen d'avoir un système fiable sans passer la une surcouche, c'est plaisant (car je pense que le support DB2 est intégré - et bien - à Websphere). C'est en ça que je parle d'homogénéité.
 
Le problème de base reste quand même la migration sur une BDD plus "costaud" que MSDE.

 
J'ai rien contre ta participation au débat mais là je ne comprends pas  

Une grosse partie de la norme EJB (pilier de J2EE) concerne le mapping objet <-> base relationelle. Ce sont les Entity Bean. Pour les EntityBean CMP (Container MAnaged Persistence), c'est le conteneur AJB (le serveur d'(application quoi) qui est chargé de gérer entièrement ce mapping (en fonction d'un paramétrage préalable).
 
Je vois pas pkoi dark dit que la persistence des données n'a rien à voir avec J2EE ...

 
bin c'est un moyen comme un autre ca.
 
Moi je parlais du problème de stockage / performance d'accès aux données, pas un moyen d'y accéder

 
C'est l'ODBC qui est de la merde, pas JDBC. ET en Java ca sera de toutes façon un driver JDBC (normallement)
 
donc ton DB2, il communique avec Websphere avec un driver JDBC. Faut pas tout mélanger

 
ce n'est pas ce que j'ai voulu dire. Je parlais de perf

 
D'accord, merci pour cette précision. Je pensais que DB2 avait des fonctions spéciales rien qu'à lui (comme les fonctions mysql_* en php)

ha ok ...
 

[hs]
performance et java dans le meme topic  
 
EDIT: c'est de l'auto dérision vu que de toutes les matieres c'est java qu'je préfere.
[/hs]

Bon ben après la présentation de WSA, OIAS, les bases Oracle et DB2 et la technologie .NET, on est pas plus avancé...
 
 
En tout cas merci à tous pour vos interventions

aie aie aie...

 
Raah! J'aime pas ça... Tu en dis trop ou pas assez.

 
je pense qu'il veut dire que tu n'es pas du tout apte à prendre la décision. Vous avez une équipe de développement non? Si vous demandiez à vos développeurs ce qu'ils en pensent?

ben tu dis que tu veux pas de surcouche, mais les ejb, c'est (au moins) une surcouche en plus entre ta base et tes applis. et la couche en question ne se fait pas automatiquement.
y'en a qui y croient mais jsuis tjs pas convaincu
quoi que ds certains cas, c jouable. n'empeche qu'il faut des developpeurs qui puissent le faire