>>C'est bien dommage, car la SGBD est bien mieux faite pour détecter les >>changements des données que Java. >> >> jerome moliere> oui mais par quel moyen ? trigger...
Oui par exemple. Toutes les bases de données "professionnelles" proposent des système de "trigger" (le nom change, mais en gros ça a les même comportements). Je m'attendais à une réponse négative :-( >>1) Coût de licence. Le produit en monoposte doit être abordable. >> jerome moliere> il n'y a pas que weblogic ? :) J'avoue que j'ai téléchargé JBoss :-) Je ne désire pas faire un choix de serveur EJB a priori. Dans mon utopie j'espère pouvoir déployer mon application sur tout serveur EJB 2.0. Weblogic est une solution, tout comme WebSphere ou JBoss, ... Notre produit monoposte est un produit d'appel. La valeur ajoutée prend tout son sens dans le cas clients / serveur. Mais il est plus simple d'installer un monoposte a un prix raisonnable pour montrer notre savoir faire métier et dans un second temps vendre la version client serveur quand le produit est accepté. D'ou un coût de licence de l'ordre de 5 € maximum par poste. > >2) Problème de déploiement. Le produit doit être installé par monsieur tout > >le monde sur son Windows 98 > > jerome moliere> jonas ou jboss, peuvent être installés par un simple dezippage.... Avec les ELB déjà déployés ? Quels sont les contraintes. La couche IP doit elle être installé. Je suis bien conscient que j'installe un produit serveur alors que justement je ne veux pas faire de réseau :-) D'ou mes inquiétudes. Le produit monoposte doit être packagé dans une boite et je vois mal expliqué l'installation de la couche IP en Windows 9x simplement pour installer un logiciel. jerome moliere> oui mais dans une config pareille, t'as pas besoin de grosses montees en > charge donc ce type de serveurs ne mangeront pas trop de ressources... > effictivement weblogic se prete mieux a de gros volumes de donnees et un > nombre important de transactions, mais la carte des serveurs EJB Open Source > doit valoir le coup dans ton cas.... Avez vous une idée de l'empreinte mémoire d'un serveur EJB vide ? Eric LEMAITRE> Une question, en dehors des considérations majeures ci-dessus, c'est de > la persistence transparente qu'il vous faut (on se fout d'être averti > tant quue tout changement dans la liste des étudiants est bien > enregistré), ou au contraire être averti lors d'un changement pour > réagir vous même ? > Car à priori, avec une liste quelconque, comme la référence de la liste > elle même n'est pas modifiée lorsqu'on modifie des éléments, ça > ressemble beaucoup plus à mon sens à un problème JDO de persistence > transparente qu'à un problème EJB. > Mais j'ai pris le train de la discussion en route (dans la tronche peut > être), alors je réponds peut être à côté de mes pompes, désolé si c'est > le cas. Je n'exclu pas JDO. D'ailleurs dans mon mél initial il y avait une section JDO. Pour JDO, se posent : - Les problèmes de licence (ah les contingences financières :-) - La création d'une couche réseau, car j'aimerais le plus possible avoir le même code (disons à 80%) dans le cas monoposte et le cas client/serveur. Les EJBs sont en effet bien pensé pour le client réseau. Merci de vos réponses, -------------------------------------------------------------------- Erik Mazoyer, Chef de projet HyperOffice 6, rue Jacques Daguerre - 92565 Rueil-Malmaison Cedex Tél. 01 41 96 96 76 Fax 01 41 96 96 77 Mél [EMAIL PROTECTED] ----- Original Message ----- From: "Eric LEMAITRE" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 10, 2002 10:49 PM Subject: Re: EJB et JDO (was Re: TR: Class static VS singleton) > Salut tous ! > > Erik Mazoyer wrote: > > >C'est bien dommage, car la SGBD est bien mieux faite pour détecter les > >changements des données que Java. > > > >............... > >Les problèmes que je vois en monoposte : > >1) Coût de licence. Le produit en monoposte doit être abordable. > >2) Problème de déploiement. Le produit doit être installé par monsieur tout > >le monde sur son Windows 98 > >3) Empreinte mémoire (et peut être processeur). Le produit monoposte ne doit > >pas demander 256 Mo ou plus pour tourner avec une efficacité correcte. > > > >Mais peut être est-ce de faux problèmes ! > >Je n'ai pas encore d'expérience réelle d'ou mes questions :-) > > > Une question, en dehors des considérations majeures ci-dessus, c'est de > la persistence transparente qu'il vous faut (on se fout d'être averti > tant quue tout changement dans la liste des étudiants est bien > enregistré), ou au contraire être averti lors d'un changement pour > réagir vous même ? > Car à priori, avec une liste quelconque, comme la référence de la liste > elle même n'est pas modifiée lorsqu'on modifie des éléments, ça > ressemble beaucoup plus à mon sens à un problème JDO de persistence > transparente qu'à un problème EJB. > Mais j'ai pris le train de la discussion en route (dans la tronche peut > être), alors je réponds peut être à côté de mes pompes, désolé si c'est > le cas. > > @++ ! > > -- > Eric LEMAITRE, Home site : http://lemaitre.eric.free.fr/ > CNAM Computer Engineer (MS/CS), SCJP2, SCJD2, CCNA, CCDA, RHCE, RHCX > > >
