Discussion :

[le y@m's]

Bonjour,

Je viens d'écrire un petit article qui présente l'utilisation des services Java.
http://ydisanto.developpez.com/tutoriels/java/services/

Bonne lecture.

le y@m's

[Aldian]

La complexité (requiert un fichier de config externe) est difficile à justifier. Si mon interface se nomme IAuthenticate, je préfère que le module chargé de l'implémentation possède une factory AuthenticateFactory implémentant l'interface IAuthenticateFactory

Ensuite de quoi dans le code qui fait appel au module, j'ai quelque chose du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
IAuthenticateFactory authFact = (IAuthenticateFactory) Class.forname("mon.package.ma.AuthenticateFactory").newInstance();
IAuthenticate aut = authFact.getAuthenticate();

Je vous fait grâce du traitement des exceptions que peut générer ce code. Ce code impose l'existence d'un factory de nom fixe dans le sous module, mais par contre il permet d'éviter d'avoir recours à un fichier de propriétés. Avec l'expérience, les fichiers de config en java font moins peur, mais pour les gens qui débutent, je me souviens que c'était pas de la tarte.


J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

[Deaf]

J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

D'un point de vue organisation d'un projet, je trouve peu pratique d'imposer un nom de classe et donc de package. Si j'avais envie de sceller mon JAR, je serais alors obligé d'exclure la factory.

Avec la solution de la factory statique, tu es moins souple. Essaie d'imaginer la procédure à suivre pour remplacer ton implémentation par une autre, de préférence sans avoir à recompiler. C'est un point important car quand tu dois faire fonctionner ton logiciel et que tu n'es pas sur ton poste de travail, tu dois faire avec ce que tu as. Cela peut être très pratique de remplacer un module défaillant par un module prévu pour le debuggage.

Mais le point le plus important qui me vient à l'esprit et qui est évoqué dans l'article, c'est le fait de pouvoir avoir plusieurs implémentations de ton service. Pour t'en sortir avec la factory statique, il va falloir jongler avec les classloaders. Ce qui me semble plus difficile que d'utiliser un fichier de configuration.

[bugsan]

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

Quand on utilise les fameux fichier META-INF/services, on ne présage aucune implémentation. C'est l'ajout d'un jar d'implémentation qui active le truc ...
D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

C'est très utilisé par les API XML. C'est relativement rare d'avoir à implémenter ce genre de chose...

[le y@m's]

@Aldian

Comme vous le soulignez il est effectivement préférable d'utiliser une factory, je suis parfaitement d'accord avec vous et c'est d'ailleurs ce qui est dit dans la javadoc du ServiceLoader.
Mais je ne me suis volontairement pas attardé sur le coté "design" car je voulais un tutoriel simple qui se contentait de présenter la technologie.

L'avantage des services Java sur la méthode que vous présentez est tout simplement l'abstraction. Dans votre exemple le nom de l'implémentation (en tout cas de l'implémentation de la factory) est écrit en dur dans le code... votre code fait donc directement référence à l'implémentation, l'abstraction est perdue. Votre code revient à écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IAuthenticateFactory authFact = new AuthenticateFactor();

A la différence qu'il utilise la réflexion inutilement (je ne m'étendrais pas sur la mauvaise utilisation de la réflexion).
Si demain vous voulez changer l'implémentation de la factory vous êtes bon pour changer votre code (certes une seule petite ligne mais ça suffit), recompiler votre application et la réinstaller chez votre client.

C'est là qu'est la "justification" du fichier de déclaration qui sert juste à dire "hey, moi j'implémente telle interface" pour pouvoir être listé par le ServiceLoader. Typiquement vous placerez ce fichier dans un jar contenant votre implémentation et vous ajouterez ce jar au classpath de l'application. Ce qui ressemble assez fortement au concept de module/plugin vous en conviendrez.
Et je ne pense franchement pas que l'écriture de ce simple fichier ajoute une complexité faramineuse, au contraire je trouve ça assez mineur au vu du gain apporté.


[edit] grilled [/edit]

[le y@m's]

D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

Le ServiceLoader utilise exclusivement les répertoires META-INF/services, il n'utilise jamais les System.properties .

[micromy]

Bonjour,

Merci pour cet exemple et cet article, cette fonction est intéressante, même si certains préfèrent les proxys

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

[le y@m's]

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

C'est corrigé de l'avoir signalé.

[Aldian]

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.


Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas .


Merci pour les autres commentaires

[le y@m's]

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.

Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas .

Et comment fais tu pour avoir plusieurs implémentations ? Tu écris X fois une Factory avec le même nom que tu mets dans chacun de tes jars ? Que va te donner un Class.forName() dans ce cas ? Comment vas tu récupérer toutes les implémentations ?
Ce que tu dis est peut être valable dans le cas où tu ne veux qu'une seule implémentation, mais pas si tu veux gérer une collection de plugins/modules (ce pour quoi est conçu le ServiceLoader).

[Aldian]

Non je n'écris qu'un seul factory, mais lors de l'appel de la méthode IAuthenticate aut = authFact.getAuthenticate(); du factory, je passe en paramètre une string qui indique l'implémentation qui m'intéresse. Ce n'est donc pas un problème rédhibitoire non plus, mais je vois bien où tu veux en venir: ça introduit la nécessité de réécrire le factory chaque fois qu'on ajoute une possibilité d'implémentation. Merci de ta patience .

[le y@m's]

Non je n'écris qu'un seul factory, mais lors de l'appel de la méthode IAuthenticate aut = authFact.getAuthenticate(); du factory, je passe en paramètre une string qui indique l'implémentation qui m'intéresse. Ce n'est donc pas un problème rédhibitoire non plus, mais je vois bien où tu veux en venir: ça introduit la nécessité de réécrire le factory chaque fois qu'on ajoute une possibilité d'implémentation. Merci de ta patience .

Donc tu précises l'implémentation (via le String) lors de l'appel, on en revient à la perte d'abstraction non ? Si tu ajoutes une nouvelle implémentation tu dois modifier ton application pour y ajouter le nouveau String correspondant ?
Et pour récupérer l'ensemble des implémentations disponibles (par exemple pour lister les modules dispo pour ton application) comment gères tu le fait d'avoir plusieurs factory du même nom ? Tu jongles avec les classloaders comme l'a suggérer Deaf ?

[Aldian]

Ah oui non en fait laisse tomber ma réponse précédente, j'avais mal compris l'objection.

Dans ma solution, a supposer que j'ai un projet ayant besoin d'une authentification, et de plusieurs modules implémentant cette authentification, je ne peux en plugger qu'un seul à la fois, et il va effectivement me falloir modifier le factory si je veux en changer. Ou alternativement chaque module peut avoir sa propre version du factory, mais dans ce cas de figure, impossible d'en mettre plus d'un à la fois dans le classpath.

Mais si jamais je venais à avoir besoin de services d'authentification de nature différentes à deux endroits distincts de l'application, je serai bloqué. Merci de tes explications, c'est plus clair maintenant .

[le y@m's]

Oui le ServiceLoader est surtout adapté pour la gestion d'une collection de modules avec plusieurs implémentation simultanées et il est vrai que l'on a rarement besoin de plusieurs mécanismes d'authentifications.
Pour un exemple plus parlant voyons celui de la javadoc du ServiceLoader.
Imaginons que l'on développe une application qui utilise des codecs (video ou audio ou autre peu importe).
Soit deux interface Encoder et Decoder représentant les fonctionnalité d'encodage/décodage.
Soit une interface de type factory CodecSet déclarant les méthodes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Encoder getEncoder(String encodingName);
Decoder getDecoder(String encodingName);

Le code utilisant le ServiceLoader pour récupérer un codec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
private static ServiceLoader<CodecSet> codecSetLoader
     = ServiceLoader.load(CodecSet.class);
 
public static Encoder getEncoder(String encodingName) {
     for (CodecSet cp : codecSetLoader) {
         Encoder enc = cp.getEncoder(encodingName);
         if (enc != null)
             return enc;
     }
     return null;
 }
 
public static Decoder getDecoder(String encodingName) {
     for (CodecSet cp : codecSetLoader) {
         Decoder dec = cp.getDecoder(encodingName);
         if (dec != null)
             return dec;
     }
     return null;
 }

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
String codecName = ... // lecture du nom du codec de l'objet à décoder
Decoder decoder = getDecoder(codecName)
if(decoder == null) {
    throw new UnsupportedOperationException("codec non supporté : " + codecName);
}

Maintenant on peut enrichir notre application avec le support de nouveaux codecs en simplement ajoutant des jars dans le classpath, chacun contenant une implementation de CodecSet (déclarée dans META-INF/services) qui fournira ces nouveaux codecs.

Je pense que cet exemple est peut être plus parlant .

[zolive]

Pour ma part je trouve qu'on se rapproche des concepts de service sous Java/OSGi sans pour autant être aussi flexible ni aussi puissant.
OSGi est adopté de plus en plus sur les serveurs d'applications (Jonas, Glassfish,...) et sans doute vous l'utiliser aussi sans le savoir : Eclipse (Equinoxe) est un framework OSGi.

[le y@m's]

Pour ma part je trouve qu'on se rapproche des concepts de service sous Java/OSGi sans pour autant être aussi flexible ni aussi puissant.
OSGi est adopté de plus en plus sur les serveurs d'applications (Jonas, Glassfish,...) et sans doute vous l'utiliser aussi sans le savoir : Eclipse (Equinoxe) est un framework OSGi.

Le ServiceLoader est effectivement orienté service (pas pour rien qu'il s'appelle ServiceLoader ) et on peut le rapprocher des concepts services d'OSGI.
Cependant ce sont deux choses très différentes et pas vraiment comparable.
OSGI est un framework complet qui défini le cycle de vie d'une application, un environnement d'exécution, des modules, une liste de services, etc.
Le ServiceLoader n'est lui qu'une simple classe qui gère le chargement d'implémentations d'une interface donnée avec une approche orientée service.
Alors c'est normal que le ServiceLoader ne soit pas aussi puissant qu'OSGI.

[Aldian]

Oui en fait l'exemple de la javadoc est un peu abrupt:

Suppose we have a service type com.example.CodecSet which is intended to represent sets of encoder/decoder pairs for some protocol

Ce genre de phrase est typique du gars qui fait ça tous les jours et qui n'imagine pas un seul instant que ses lecteurs puissent ne pas avoir l'habitude de ce type de problématique (ou alors c'est des touristes). La plupart des gens savent qu'il existe un concept nommé "codec" et que c'est lui qui est à blamer s'ils ne peuvent pas lire une vidéo. Quant à savoir ce que ça représente vraiement il y a un monde. Et du coup, l'exemple bateau de la doc n'est pas bateau, à part pour les devs habitués de la manipulation audio ou des protocoles.

Mais avec la discussion précédente, on comprend beaucoup mieux, merci

[deltree]

Intéressant, je ne connaissait pas et du coup, j'avais un peu recodé ma propre implem à la manière d'Aldian.

Les avantages que je vois :
-méthode standard intégrée au JDK

les inconvénients:
-une seule méthode de conf basée sur de fichiers, pas d'annotation, pas d'injection par programme, pas de parcours automatique de répertoire, façon plugin eclipse.
-une seule classe d'implementation final, (comme pour le Logger java), ce qui empêche d'utiliser d'autres implementations, notamment des framework guice etc.

En fait c'est le dernier inconvénient qui me ferais hésiter à utiliser cette techno.

[le y@m's]

-une seule méthode de conf basée sur de fichiers, pas d'annotation, pas d'injection par programme, pas de parcours automatique de répertoire, façon plugin eclipse.

Même réponse que pour OSGI, le ServiceLoader est une simple classe et pas un framework complet, ce n'est pas vraiment comparable .

-une seule classe d'implementation final, (comme pour le Logger java), ce qui empêche d'utiliser d'autres implementations, notamment des framework guice etc.

Soit tu n'as pas tout bien lu du tutoriel et des commentaires précédents soit je n'ai pas bien compris ce que tu voulais dire, mais il est tout à fait possible d'avoir et de déclarer plusieurs implémentations.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
ServiceLoader<MyInterface> loader = ServiceLoader.load(MyInterface.class);
List<MyInterface> implementationsList = new ArrayList<MyInterface>();
// on récupère toutes les implémentations déclarées
for(MyInterface impl : loader) {
    implementationsList.add(impl);
}

[deltree]

Même réponse que pour OSGI, le ServiceLoader est une simple classe et pas un framework complet, ce n'est pas vraiment comparable .

-Oui c'est vrai et c'est beaucoup plus léger qu'embarquer un framework , c'est un avantage de plus.

Soit tu n'as pas tout bien lu du tutoriel et des commentaires précédents soit je n'ai pas bien compris ce que tu voulais dire, mais il est tout à fait possible d'avoir et de déclarer plusieurs implémentations.

Je me suis mal exprimé, j'ai voulu faire (trop) court:
c'est la classe "ServiceLoader" qui est une implémentation unique et finale. donc on ne peut pas imaginer qu'un founisseur Tiers puisse l'étendre (String ou hibernate).

Et je comparais aux Log parce que le Logger java souffre du même problème, ce qui fait que les entreprises se tournent plus volontier vers slf4g et log4j.

Pour revenir à la classe ServiceLoader, si Sun avait simplement fourni une interface pour cette classe, on aurait pu imaginer intercaler un proxy, fournir une autre implémentation etc. tout comme slf4j est basé sur une interface, et permet de rebrancher d'autres logger log4j, on même un logger maison.

En fait je me pose cette question pour faire des choix techniques sur des projets d'entreprise: si on choisi ServiceLoader comme technologie de découplage, puis que finalement on décide de changer de technologie (dans quelques années), quel est l'impact sur tous les développement réalisés (est-ce qu'on parle de dette technique dans ce cas?)

Enfin bref, je râle maisc'est un détail, le tuto est très bien et permet de comprendre rapidement l'intérêt du ServiceLoader.
Et merci pour tes réponses