Discussion :

[grunt2000]

Bonjour,

Pour proposer à l'occasion l'alternative à JEE par Spring, il faut que j'examine si je peux répondre à toutes les situations d'emploi de services.

1) Stateless
L'habituel : le serveur d'application donne n'importe quelle instance de bean de service, en en créant des supplémentaires si les appelants sont nombreux.
(je mets @1, @2, etc pour symboliser des instances distinctes).

appelant 1 => Staleless@1
appelant 2 => Staleless@1 (exemple de situation : le serveur n'était pas chargé, et appelant 1 a fini son appel depuis longtemps).
appelant 3 => Staleless@2 (exemple de situation : appelant 2 n'a pas encore fini son appel que appelant 3 veut en faire un immédiatement).
appelant 4 => Staleless@1 (exemple de situation : appelant 2 a fini son appel et Statelss@1 est de nouveau disponible).
appelant 1, de nouveau => Staleless@2 (exemple de situation : appelant 4 utilise toujours Stateless@1, donc appelant 1 reçoit cette fois-ci Stateless@2 : la dernière fois, il avait reçu Stateless@1).
appelant 5 => Staleless@1.
etc.

Ça, je pense que c'est le comportement standard de Spring, dès que l'on annote une classe en @Service ?

2) Singleton
Une seule instance pour tout le monde. Partageant ses données avec tout le monde de fait.
appelant 1 => Singleton@1
appelant 2 => Singleton@1
appelant 3 => Singleton@1
appelant 4 => Singleton@1
appelant 1, de nouveau => Singleton@1
appelant 5 => Singleton@1

Je crois qu'il suffit de rajouter une annotation @Singleton quelque-part pour l'avoir ?

3) Stateful
Une instance distincte et réservée à chaque appelant jusqu'à temps qu'il décide de l'abandonner.
appelant 1 => Stateful@1
appelant 2 => Stateful@2
appelant 3 => Stateful@3
appelant 4 => Stateful@4
appelant 1, de nouveau => Stateful@1
appelant 5 => Stateful@5

Comment réalise t-on ceci ? (déclaration, instanciation puis suppression du service stateful lié à l'appelant ?).

4) Asynchronous
C'est une situation indépendante des trois autres, mais à l'occasion j'aimerais profiter de cette capacité qu'offre JEE si elle existe également sous Spring :
ces méthodes que l'on déclare avec des boites à futur :
@Asynchronous public Futur<MonResultat> obtenirResultat(int x, int y);


Pouvez-vous m'éclairer sur les points où il me manque des informations ou me dire si je me trompe en certains endroits ?

En vous remerciant,

Grunt.

[andry.aime]

Bonjour,

Regarde la documentation sur Bean scopes. Pour @Asynchronous, il y a l'annotation @Async.

A+.

[grunt2000]

D'après ce que je lis, le prototype correspondrait bien à ce que je veux côté Stateful.

Par contre côté Stateless, imposer un singleton, je n'aime pas trop. Je réfléchis aux conséquences que ça a. Il faut que les développeurs veillent à ne jamais utiliser de variables membres à aucun titre dans ce cas : au risque de se les voir écraser ou prendre des ConcurrencyCheckException, à l'occasion.

[andry.aime]

Tu peux utiliser des méthodes thread-safe pour les méthodes critiques. Pour l'accès à la base, par exemple pour hibernate, tu peux gérer ça.

A+.

[grunt2000]

Cas d'emploi :

Un Service de contrôle Stateless A,
appelle un autre service de contrôle Stateless B,
puis un autre service de contrôle Stateful C,
et un dernier service de contrôle Stateless, D.

Le service C est stateful parce qu'il peut potentiellement renvoyer une quantité de données si grande qu'il doit être appelé en plusieurs fois.

Quand le service A s'exécute, c'est assez long.
Plusieurs autres appelants (des batchs souvent, de nature diverses) peuvent aussi souhaiter l'appeler.

Je peux me retrouver avec :
A@1 lié à B@17 et C@8, D@2
puis
A@1 lié à B@17 et C@15, D@9
A@1 lié à B@17 et C@21, D@11

tandis qu'il y a à côté :
A@2 lié à B@12 et C@5, D@7
A@3 lié à B@8 et C@3, D@4

C'est ce scénario précis que j'ai à évaluer, qui doit éviter le singleton et les problèmes de concurrence d'accès. Il doit vraiment faire ce que je dis et pas autre chose, sans complexité car sinon : la solution sera refusée (le projet actuel utilise Spring et JEE, et il faut choisir l'un ou l'autre).

En EJB - JEE, il n'y a aucun problème, ça se fait tout seul.
Là, ça me semble en fait pas possible.

[andry.aime]

Plusieurs autres appelants (des batchs souvent, de nature diverses) peuvent aussi souhaiter l'appeler.

Comme je disait, tu ne peux pas utiliser une méthode thread-safe?

A+.