Discussion :

[butane]

Hello,

J'ai une application java que j'aimerais faire évoluer en EJB. Cette application est composée d'un noyau qui sert à exécuter des commandes en fonction des demandes faites par les clients (Web, GUI, ...) qui sont connectés. Après avoir lu divers tutoriaux concernant le développement JEE et les EJB, je n'arrive pas a voir comment je peux réaliser mon noyau. En effet, si j'ai bien compris, tout ce qui est métier devrait se trouver au niveau des sessions. Malheureusement, les sessions prennent vie uniquement quand un client est présent (et en plus, chaque client a sa propre session...). En pour ce qui est des entités, ces dernières prennent vie sur accès aux données (et donc ne convient pas pour réaliser un noyau)...

Je demande donc votre aide pour m'éclairer sur la méthode à adopter (si elle existe chose que je commence à remettre en question )

Merci

[Heimdal]

Salut,

pour faire ton noyau les EJB3 conviennent parfaitement.

Trois choses principales sont à faire:

- Définir ta couche de service, généralement avec des Stateless session Bean (que dois-je fournir au client?)

- Mapper ton modèle de données avec des EntityBean (des outils permettent de les générer automatiquement depuis le modèle de ta BDD)

- Éventuellement t'interroger s'il n'y a pas des informations propres à chaque client et que tu veux conserver le temps de la session de l'utilisateur et dans ce cas les faire porter par un Statefull session bean

J'espère que ca clarifie un peu la démarche à adopter.

Banzai

[butane]

Hello,

Je vois bien la différence entre les beans entité, session stateful / stateless et compagnie... (je viens de finir la lecture du tuto JEE de sun )

Se que je n'arrive pas à voir, c'est comment faire pour que mon noyau tourne comme une tâche de fond indépendamment des différents clients qui s'y connectent. En effet si je fait mon noyau dans une session, ce noyau aura, au mieux (session stateful), la même durée de vie que la session... De plus chaque client aura une instance différente du noyau ce qui n'est pas possible dans mon cas...

[Heimdal]

Tes EJB sont disponibles en permanence et leurs durée de vie ne sont par défaut pas liées à une session utilisateur.

Ils sont tranquillement dispo dans le pool et tu fais appel à eux quand tu en as besoin.

Je ne vois pas vraiment ton problème.

Peut-être qu'en nous basant sur un petit exemple de service que tu veux proposer ce sera plus clair.

[butane]

Tes EJB sont disponibles en permanence et leurs durée de vie ne sont par défaut pas liées à une session utilisateur.

Sa c'est ok, mais la durée de vie des sessions dépend du client (ou la doc sun est fausse). J'ai compris que plusieurs clients peuvent avoir accès au même EJB mais que chacun avait une instance de session différente...

Ce que j'ai besoins, sans parler techno, c'est :

1. Plusieurs clients (de type différent : WEB, GUI Java, ...) doivent pouvoir se connecter et se déconnecter du noyau n'importe quand.
2. Quand ces derniers sont connectés, ils peuvent passer des commandes se qui a pour conséquence (en fonction du déroulement de ces commandes) de notifier tous les clients connectés au noyau.
3. Même sans client, le noyau doit pouvoir continuer a exécuter des commandes.

Maintenant, en parlant EJB, qu'est ce qui est quoi ?

[butane]

Je crois que j'ai réglé le problème pour le noyau. Apparemment, dans les spécifications de JEE 6 il y a des Singleton Session Beans se qui règle le problème d'avoir un noyau pour tous les clients qui tourne "en tâche de fond".

Donc, dernier problème, est-ce que c'est possible de faire communiquer les sessions ensembles (genre que les sessions spécifiques aux web, GUI java et autre communiquent avec la session singleton noyau) ?

[nathieb]

Bonjour,

Dans la dernière spécification, un singleton est une instance unique pour tous les clients dans le conteneur EJB. Précédemment il avait raison de t'aiguillé vers un bean session stateless ( sans état ) . Comme en HTTP il appelle le bean sans être lié à une session utilisateur.

Sinon si tu veux un client <-> un objet ( avec la session en prime) alors statefull ( avec état )

Le singleton est une notion plus subtile, pas de notion de session mais juste l'idée qu'un objet existe qu'une seule fois.

rien ne t'empêche donc de créer un stateless qui va contrôler tes scripts, par contre si tu veux mémoriser le retour par client alors statefull.
Je l'ai déjà effectué pour de la genération de documents en ligne.

Il faut penser simple, et surtout essayé, avant de se prendre la tête avec des mégas full power concepts de la mort.

olivier

[manblaizo]

Bonjour,

Je crois qu'il n'y a grand-chose à ajouter à ce qu'ont déjà dit les autres. Tu peux très bien développer ce que tu appelles "noyau" en utilisant des ejb session beans qui accèdent à la base de données à travers des entités jpa. Et ensuite rendre cette application "noyau" accessible par différents clients (Web, GUI, web services...)

J'ai une application java que j'aimerais faire évoluer en EJB. Cette application est composée d'un noyau qui sert à exécuter des commandes en fonction des demandes faites par les clients (Web, GUI, ...) qui sont connectés. Après avoir lu divers tutoriaux concernant le développement JEE et les EJB, je n'arrive pas a voir comment je peux réaliser mon noyau. En effet, si j'ai bien compris, tout ce qui est métier devrait se trouver au niveau des sessions. Malheureusement, les sessions prennent vie uniquement quand un client est présent (et en plus, chaque client a sa propre session...). En pour ce qui est des entités, ces dernières prennent vie sur accès aux données (et donc ne convient pas pour réaliser un noyau)...

Je demande donc votre aide pour m'éclairer sur la méthode à adopter (si elle existe chose que je commence à remettre en question )

Je sens qu'il y a encore une confusion des concepts de session bean, entiy ...
Le mot "session" dans session bean ne correspond pas nécessairement à "session utilisateur" (HttpSession, GUI). On peut avoir un ou plusieurs session beans (stateless, stateful, singleton) dans une application, utilisés pour servir plusieurs utilisateurs, donc plusieurs "sessions utilisateur", et même plusieurs requêtes d'un même utilisateur... Il n'y aurait pas duplication de ton "noyau" pour chaque client.

Evidemment il y a cette notion de stateful session bean qui peut sembler ambigüe, car il y a une instance de bean par utilisateur, mais là encore, cette instance peut juste avoir la durée de vie d'une conversation (un cas d'utilisation par ex.), ou elle peut durer pendant toute la session utilisateur (si tu veux y conserver des informations de login par exemple ou autre), tout dépend des besoins de ton application.

Voilà, je pense que tu devrais peut-être d'abord faire quelques exemples de plus, sans penser à l'application que tu veux créer, histoire de mieux appréhender les différents concepts JEE; puis seulement après de voir comment adapter tout cela à ton besoin particulier. Le tutorial de Sun que tu as cité est très bien, surtout le dernier sur jee6, je l'ai trouvé pas mal.

[butane]

Je sens qu'il y a encore une confusion des concepts de session bean, entiy ...

non, je crois que c'est bon, ce qui est pas claire c'est ce que je peux faire avec... Dans mon esprit, une session sert à faire des adaptions (essentiellement de communication) entre un client et un serveur mais dans le vocabulaire JEE c'est apparemment pas trop le cas...

Moi je vois la chose comme ça :

• Des sessions stateless / statefull (encore à déterminer ) pour tout se qui est des adaptations sessions utilisateurs (GUI java, WEB, ...)
• Une session singleton pour mon noyau.

Je sais pas si c'était très clair mais je dois avoir une seule et même instance du noyau pour toutes mes sessions utilisateurs et donc je pense bien que mon noyau est une session singleton... sinon c'est la qu'il y a un truc magique qui m'a échappé...

[manblaizo]

non, je crois que c'est bon, ce qui est pas claire c'est ce que je peux faire avec... Dans mon esprit, une session sert à faire des adaptions (essentiellement de communication) entre un client et un serveur mais dans le vocabulaire JEE c'est apparemment pas trop le cas...

OK, tant mieux si les choses sont claires. Désolé, je me suis relu et je pense que j'aurais pu formuler ma phrase un peu autrement.

Moi je vois la chose comme ça :

• Des sessions stateless / statefull (encore à déterminer ) pour tout se qui est des adaptations sessions utilisateurs (GUI java, WEB, ...)
• Une session singleton pour mon noyau.

Les beans session stateless/stateful ça sert à représenter un cas d'utilisation, c'est pour cela qu'on peut en avoir plusieurs dans une même application, et le client en appellerait plus d'un au cours de sa "session utilisateur".
Les singleton session beans ont fait leur entrée seulement en ejb3.1, et même sans ça, tu aurais pu développer ton application avec les versions précédentes de ejb.

Je sais pas si c'était très clair mais je dois avoir une seule et même instance du noyau pour toutes mes sessions utilisateurs et donc je pense bien que mon noyau est une session singleton... sinon c'est la qu'il y a un truc magique qui m'a échappé...

Je ne sais pas si tu as vraiment besoin d'un singleton, mais bon, peut-être que tu devrais nous en dire un peu plus sur la fonctionnalité de ce noyau, ça nous aiderait à mieux comprendre ton besoin.

[butane]

Les singleton session beans ont fait leur entrée seulement en ejb3.1, et même sans ça, tu aurais pu développer ton application avec les versions précédentes de ejb.

Si t'as de la doc, un tuto ou autre sur le sujet je suis preneur. C'est en fait un peu pour ça que j'ai lancé ce post

Je ne sais pas si tu as vraiment besoin d'un singleton, mais bon, peut-être que tu devrais nous en dire un peu plus sur la fonctionnalité de ce noyau, ça nous aiderait à mieux comprendre ton besoin.

Le noyau en question devrait avoir les fonctionnalités suivantes :

1. Plusieurs clients (de type différent : WEB, GUI Java, ...) doivent pouvoir se connecter et se déconnecter du noyau n'importe quand.
2. Quand ces derniers sont connectés, ils peuvent passer des commandes se qui a pour conséquence (en fonction du déroulement de ces commandes) de notifier tous les clients connectés au noyau.
3. Même sans client, le noyau doit pouvoir continuer a exécuter des commandes.

C'est surtout ce dernier point qui me fait dire que j'ai besoins d'un singleton (en plus dans la version actuelle de l'application c'est exactement se que j'ai ).