Archives de catégorie : Ecrit en français

Comprendre REST

Pour répondre à une question posée sur ce carnet, voici ma collection de liens vers les ressources que j’ai trouvées les plus abordables pour comprendre ce qu’est le modèle architectural REST (REpresentational State Transfer) (par ordre décroissant de digestibilité) :

Test: WordPress peut écrire en différé

Je suis en train de tester une fonctionnalité de mon logiciel de blogs: WordPress. Cette fonctionnalité consiste à publier un message anti-daté. Par exemple, je publie ce message aujourd’hui (début janvier 2007) mais je l’anti-date à début janvier 2004. La question que je me pose est la suivante: est-ce pour autant que mon message va apparaître en dernier dans un flux RSS, va-t-il y être visible ou non? J’espère que non. Vérifions.

Semantic Wiki

This is an attempt to translate this other post into English
Charles Nepote, as he notified me, builta prototype of a wiki engine based on some of the semantic web technologies and providing some somewhat “semantic” features. I appreciated this prototype a lot. It lets me imagine how the wiki of the future would look like. Here are some pieces of a dream on this topic. The wikis of tomorrow would…

  • …provide the semantic features of Charles Nepote’s prototype : complying to the REST style, one URL for every page, publishing both HTML and RDF representations of this page (it would be better to provide RDF within XHTML rather than beside, would’n it ?)
  • … be Blikis (also known as Wikilogs) with pingback and/or trackback and so on
  • …implement syndication of recent changes ; therefore they should produce distinct URLs for every update (every “diff” : as an example with URL like http://www.monsite.toto/2004/01/01/12/WikiPage for the 12th modification of the WikiPage, on 1st January 2004, whereas the URL of the WikiPage still remains http://www.monsite.toto/WikiPage).
  • …“wikify” remote semantic data ; thus the page http://www.monsite.toto/DcTitle would contain a RDF statement (an OWL one ?) that would mean that this URL is the equivalent to the dc:title property of the Dublin Core
  • …allow users to easily produce metadata with the help of an extension of the Wiki syntax ; as an example, when a WikiPage contains the statement “DcKeywords::MyKeyword”, the wiki engine automatically adds the RDF triplet with subject being the page itself (its URL), predicate being the URL of the “keywords” property as defined by the Dublin Core and object being the URL http://www.monsite.toto/MyKeyword.
  • …have search engine allowing users to explore the Wiki with a navigation mode similar to sourceforge’s Trove Map based on the semantic data published by the Wiki ; as an example, the user will be able to display all the pages that are related to MyKeyword and are written in French (because they contain the RDF statements equivalent to the following explicit statement made by users within the page : DcKeyword::MyKeyword and IsWritten::InFrench)
  • …have search engines allowing users to save their queries and explorations as agents (with their own WikiNames) so that other users can browse the same path of exploration as the user who defined the agent

I implemented these two last features as a draft of micro-application pompously called RDFNavigator for Zope, and base don the RDFGrabber product. It is very drafty so it is very incomplete, not documented, instable (because RDFGrabber is not particularly stable itself in my environement), so it may be difficult to make it run. Nevertheless, if someone dares trying it, I am eager to hear comments and critics ! :) By the way, I hope some day to make a more honorable product based on the integration of rdflib into Zope, i.e. based on Rope unless the Ticle project quickly provides a similar result within Plone.

“Open sourcer” des développements spécifiques

Redistribuer des développements spécifiques sous licence “open source” (“open sourcer” des développements spécifiques) peut constituer une brique importante d’une stratégie informatique visant à se doter d’une architecture durable. Un témoignage sur Slashdot présente les arguments utiles pour convaincre une direction informatique du bien-fondé d’une telle démarche :

L’argument le plus simple pour la plupart des managers est du type : “vous bénéficiez du travail de N programmeurs mais vous ne payez le salaire que de M d’entre eux.” Et vous obtenez du test gratuit de certaines parties de votre produit. Vous pouvez également renforcer le soutien de la direction en mentionnant occasiollement : “Eh, je viens de resynchroniser nos modifications du package TRUCMUCHE, and j’ai vu que quelqu’un vient d’y ajouter le module TRUCBIDULE que nous justement l’intention de développer.” Cela donne à votre direction la douce et agréable sensation d’obtenir quelque chose à partir de rien.

Plus loin, il est ajouté, sur le même ton quelque peu cynique :

Dans de nombreux cas, bien sûr, contribuer au code open source ne faisait pas partie des intentions premières. L’idée d’origine était seulement d’utiliser un module pioché dans une archive quelconque. Mais parfois on découvre que le module ne fait pas exactement ce que l’on attendait de lui. Avec les logiciels libres, on peut résoudre ce problème. Et on donne ses modifications en retour, bien sûr. Ensuite, on en parle à la direction, qui hausse systématiquement les épaules et va s’occuper de quelque chose de plus intéressant. Si il y a débat, celui-ci peut être abrégé en rappelant quelque chose du genre : “Ce module nous a permis d’économiser plusieurs mois de développement ; passer un jour à résoudre un problème et à publier nos modifications est un petit prix à payer pour un tel bénéfice.”

Jon Udell complète ce témoignage par une analyse plus circonspecte de la situation :

Même lorsque les développeurs maison sont prêts à contribuer en retour, leur code (à juste titre) n’est pas toujours le bienvenu. ‘Le propriétaire d’un projet open-source froncerait les sourcils devant des modifications proposées par des personnes qui n’ont pas encore montré patte blanche […] Mais le développeur maison n’a ni le temps ni la disponibilité suffisante pour montrer patte blanche. Résultats : de multiples duplications maison (des “forks”) et la perte de ressources qui en résulte.”

Jon Udell rapporte également le terme de “releasability remediation” qui semble désigner l’activité consistant à rendre un code redistribuable au regard de la bureaucratie ambiante (restriction aux exportations, mesures de sécurité de l’entreprise, etc.).
Son article évoque ensuite diverses formes de contribution des entreprises aux projets open source dont elles bénéficient : publicité (via un bel enrobage dans des carnets Web, des discussions et des messages dans Usenet) et subventionnement de recherches académiques. La question qui reste ouverte est celle de la meilleure forme de contribution par l’entreprise à ces projets. Dans leurs commandes à leurs prestataires informatiques, les entreprises devraient-elles faire l’effort financier nécessaire à la redistribution de leurs développements spécifiques à base de logiciels open source ? Comment valoriser cet effort auprès de l’actionnaire et donc de la direction générale ?

Développement d’une architecture informatique durable

Les grandes entreprises ont besoin de stratégies informatiques, en particulier en matière d’architecture applicative. Voici donc une esquisse de stratégie architecturale.

  1. Objectifs stratégiques
    • sécuriser l’environnement informatique : maintenir la sécurité de fonctionnement du système d’information, faire cesser la prolifération désordonnée des technologie, maîtriser l’incendie du e-business
    • optimiser les économies : réduire les coûts sur le long terme, gagner en productivité
    • bâtir un ordre social pour la communauté informatique : ordonner les investissements informatiques, se doter d’une politique, de règles d’architecture, de processus de contrôle, construire une communauté interne pour soutenir et faire appliquer cette politique
    • => “triple bottom line” => comment assurer développement durable d’une architecture informatique ? une architecture “future-proof” ?
  2. Objectifs tactiques : construire une architecture applicative durable …
    • … du point de vue économique : à moindre TCO = “scalable” (évolutivité, capacité à supporter des développements futurs à moindre coût), exploitable et maintenable (minimiser les coûts récurrents), à moindre investissement (licences logiciells, …)
    • … du point de vue écologique : sûre et robuste quelles que soient les évolutions du reste de l’environnement informatique (sécurité, interopérabilité, portabilité, évolutivité), sobre en ressources (en ressources réseaux, en infrastructure), assurant une autonomie vis-à-vis de son environnement (indépendance vis-à-vis des politiques commerciales des fournisseurs, indépendante de l’évolution des métiers de l’entreprise, indépendante des évolutions de l’organisation de l’entreprise à moyen terme y compris acquisitions et cessions),
    • … du point de vue social : appuyée sur un modèle de gouvernance durable, qui implique toutes les parties prenantes de la gestion des systèmes d’information (y compris les fournisseurs et éditeurs, les services utilisateurs, les équipes informatiques, la direction générale), offrant des ancrages de l’organisation dans des communautés locales et des réseaux de partenariat étendus (avec d’autres entreprises partenaires, avec les futurs gestionnaires de cette architecture, …)
    • donc appuyée sur les principes architecturaux suivants :
      • couplage faible et couplage tardif : les composants mis en oeuvre doivent offrir une modularité extrême, pouvoir évoluer indépendamment les uns des autres, être “agnostiques” sur l’usage qui sera fait des données qu’ils traitent ou produisent (de manière à en maximiser les opportunités de réutilisation), faire les hypothèses les plus réduites possibles sur les évolutions à venir du S.I., ne pas requérir de vision globale (ni d’étude globale) préalable à leur mise en oeuvre, supporter une dynamique d’évolution “en bazar” plutôt qu’ “en cathédrale”, s’assembler selon le modèle REST (REpresentational State Transfer) plutôt que selon le modèle RPC (Remote Procedure Call)
      • l’architecture applicative est isolée des métiers : de même que la fonction financière de l’entreprise peut être rendue indépendante des spécificités de ses métiers, l’architecture applicative, pour être durable, doit être considérée comme indépendante des métiers d’entreprise ; sa portée est universelle dans l’entreprise ; son universalité offre des opportunités de benchmarking et de partenariat étendues avec les acteurs externes
      • respect absolu des standards les plus ouverts possibles : qu’il s’agisse d’un standard de facto (informatique “legacy”, monopole commercial, …) ou de jure (spécifié par un organisme de normalisation), un standard est ouvert si :
        • il “vient de l’Internet”, i.e. on peut observer un grand nombres de ses implémentations sur l’Internet, ses spécifications détaillées sont publiées sur l’Internet, la communauté qui l’a élaborée privilégie l’Internet comme mode de collaboration,
        • il dispose d’implémentations nombreuses et diverses et l’une de ses implémentations est distribuée sous une licence de type “open source”,
        • ses spécifications sont élaborées par une communauté ouverte : regroupant des acteurs d’origine et de taille diverses, avec une barrière à l’entrée très basse, et sachant tirer partie des contributions qui lui sont adressées sur la base de l’intérêt objectif de celles-ci et non de l’identité du contributeur
  3. Objectifs opérationnels
    • contrôler l’architecture par le biais des relations fournisseurs : favoriser systématiquement la mise en concurrence des fournisseurs informatiques, n’acquérir une technologie que lorsqu’elle s’accompagne d’une offre de services supportée par une communauté de prestataires à la fois diversifiée (plusieurs sociétés de services) et dynamique (nombreuses références, nombreuses contributions), ne placer des fournisseurs en situation de monopole (contrats cadres) qu’à condition de préparer le changement futur de fournisseur (si les conditions contractuelles ne sont pas respectées ou bien, tout simplement, à l’issue du contrat), rester systématiquement dans une position de fermier (“je cultive ma terre”) plutôt que de métayer (“je cultive la terre du propriétaire”, en l’occurence celle de mon fournisseur), piloter les choix logiciels par les principes architecturaux (couplage faible et tardif, respect des standards)
    • open sourcer l’architecture : c’est-à-dire externaliser les coûts de développement auprès de tiers par le biais d’une redistribution sous lience “open source” des adaptations spécifiques et développements maison, de manière à annuler les coûts d’investissements (pas de coûts de licences à l’achat) et de manière à mutualiser les coûts de développement et de maintenance avec des tiers (autres entreprises utilisatrices, sociétés de services informatiques, informaticiens indépendants) ; pour cela, redistribuer systématiquement les développements maison non stratégiques (non liés à un avantage concurrentiel certain) sous licence “open source”
    • préférer les choix “juste-assez” aux choix “idéaux” (“le mieux est l’ennemi du bien”) : pour évaluer la disponibilité en compétences informatiques nécessaires à l’exploitation et la maintenance de la technologie nouvellement acquise, ne pas confondre la disponibilité suffisante de compétences et la disponibilité maximale de compétences ; appuyer le choix de nouvelles technologies à acquérir non pas sur leur degré absolu de sophistication (ce qui se paie en compétences d’exploitation) et de popularité médiatique (ce qui se paie en coût de licences et de support) mais sur l’adéquation entre celle-ci et le besoin qu’on en a ; si votre système d’information est urbanisé, préférer l’approche “citadine” à l’approche “4×4”

Le secteur sans but lucratif

Edith Archambault a effectué un travail d’étude qui est devenu une référence pour décrire l’organisation du “secteur sans but lucratif en France et dans le monde”. Voici, ci-après, quelques informations de synthèse glanées dans cette étude.
De plus en plus d’associations loi 1901 se créent en France, notamment pour incarner des solidarités spécialisées (soutien aux victimes d’une même maladie rare, d’un attentat, etc.). Le “tiers secteur” représente 5% des emplois salariés en France (soit environ 1 million de salariés), ce qui est équivalent au volume de l’emploi dans l’agriculture, par exemple. L’emploi salarié dans les associations croît en moyenne de 3,4% chaque année. Toutefois, il inclut un grand nombre d’emplois temporaires ou atypiques (emplois jeunes…). Le budget du tiers secteur est d’environ 45 milliards d’euros, soit l’équivalent du chiffre d’affaire de l’ensemble des services d’eau, gaz et électricité ou encore l’équivalent de la construction mécanique. Il faudrait ajouter à cela l’estimation monétaire du travail bénévole. Le poids du secteur associatif attendrait alors 75 milliards d’euros. Les principaux secteurs d’activité des associations sont les suivants :

  • la culture et les loisirs : 42% du nombre d’associations, 47% du bénévolat, dédiés à l’entraînement sportif, aux mouvements de jeunesse et aux clubs du troisième âge ainsi qu’aux associations culturelles
  • les services sociaux : 33% des dépenses courantes du secteur, 40% de l’emploi du secteur associatif, 21% du nombre d’associations, 16% du bénévolat avec les hôpitaux privés non lucratifs (qui assurent 16% des activités sanitaires en France, loin derrière le secteur public, mais avec une plus grande spécialisation sur le traitement du cancer, de la toxicomanie et la rééducation), les maisons de retraite, et les services sociaux vers les pauvres et les populations en difficulté (handicapés), ainsi qu’avec les services de procimité et de maintien à domicile ; les associations emploient environ 60% des travailleurs sociaux
  • l’éducation et la recherche : 25% des dépenses courants, 21% de l’emploi, avec notamment l’enseignement privé dont 95% d’écoles privées catholiques ainsi que la plupart des écoles de commerce et les associations de parents d’élèves
  • Il est intéressant de noter que les activités d’aide internationale (humanitaire), les fondations et la défense de l’environnement ont un poids économique extrêmement faible malgré une visibilité médiatique et politique élevée.

60% des ressources du secteur associatif proviennent de financements publics dont le premier pourvoyeur est la sécurité sociale, devant les caisses de l’Etat (surtout pour l’enseignement privé) et les communes (pour l’entraînement sportif et les activités culturelles). L’idée que l’Etat délègue aux associations certains services publics est courante. Les dons individuels aux associations sont peu répandus en France (par rapport aux pratiques des autres pays européens par exemple) car la majorité des français a tendance à considérer que ce mode de financement fait double emploi avec l’impôt. Les recettes privées des associations assurent cependant un tiers de leurs revenus, principalement sous la forme des cotisations de leurs membres. Actuellement, ces financements évoluent vers une privatisations des ressources : moins de soutien public, plus de ressources propres. Le bénévolat progresse également de manière considérable.

This is a test about WordPress

This is a test related to my post on WordPress support forum (see below). You can ignore this message or read the comments in order to follow the results of this test.

Ampersands escaped in URLs within comments

On my blog (http://sig.levillage.org/) equipped with WordPress 0.72, when someone posts a comment containing an HTML link with an URL containing an ampersand, this URL gets mangled… Some characters (like the &) seem to be systematically escaped. IMO, this is a bug (not a feature). The escaping function should not escape ampersands in URL when the URL is a value of a tag attribute. What do you think ? Did I miss something ? Is there currently a workaroung ?

— Sig
http://sig.levillage.org

Zope and Plone learning roadmap

It is sometimes said that the art of mastering Zope and Plone is difficult. It has also been said that learning Zope Zen involves a steep learning curve. I have also read many newbies (like me) asking for information about the first steps to go through in order to smoothly get into Zope development. “Don’t start learning Zope before you know Python !”, “No need for mastering in TAL, TALES and METAL for building Plone user interfaces, you’d rather learn advanced CSS techniques”, or the like… So I wonder : what is the recommended roadmap for learning Zope and Plone ? how to make the global learning curve smoother or just a little bit more visible and manageable ? So the diagram below is my guess on the ideal learning roadmap for a would-be master in Zope+Plone :
The ideal roadmap for learning Zope and Plone.

Innovation technologique au service du développement durable (suite)

J’avais signalé ici ce rapport sur la place de l’innovation technologique dans les politiques de développement durable des entreprises. J’en retiens également les quelques points particuliers suivants :

  • La gestion de l’environnement est un argument en faveur des stratégies d’entreprises visant à développer des offres de services autour d’offres de produits existantes.
  • La communication des entreprises en matière de développement durable relève soit d’une activité de marketing innovante lorsqu’elle est proactive soit plutôt d’une activité de lobbying lorsqu’il s’agit de défendre certains intérêts économiques de l’entreprise.
  • Pour une entreprise, parmi les motivations à innover, le développement durable ne figure pas parmi les priorités.
  • Les dirigeants d’entreprise peuvent difficilement convaincre les actionnaires de la rentabilité d’une stratégie de développement durable sans une intervention publique qui aille explicitement dans ce sens.
  • Les stratégies d’innovation observées diffèrent selon la taille de l’entreprise : “une grande entreprise pourra définir une stratégie à long terme, mobiliser ses ressources en R&D, améliorer sa communication interne et externe et pratiquer le lobbying tandis qu’une petite enteprise préfèrera investir dans des innovations plus pointues ou des niches de marché et mobiliser la créativité de l’ensemble du personnel”.
  • une technologie au service du développement durable doit à la fois être propre (ne pas porter atteinte à l’environnement) et sobre (consommer peu de ressources).

rdflib and ROPE

I just blog this Bob DuCharme article so that I can remember where practical information about rdflib can be read.
By the way, I have tested the very pre-pre-release of Reinout’s ROPE (see ROPE = Rdflib + zOPE). And I could install it on a Zope 2.7.0b3 fresh install. It was quite easy to install it. But, as Reinout said, it is still a very early release and, as you can see on the attached screenshot, there is much work to be done before it is really usable. This screenshot is just a hint for Reinout : if you add several namespaces into a rdfstore (shouldn’t you name it a “rope” ?), they end up displayed one next to another instead of being options of the same HTML select widget. Anyway, I am looking forward further releases of Rope.

L’avenir de l’énergie

Dans la sérieuse revue Scientific American a été présenté un ouvrage faisant le point sur l’avenir énergétique de la planète. Selon l’auteur de ce livre, la question essentielle est de savoir comment mettre l’énergie à la portée des bourses des milliards de personnes pauvres sur la planète sans pour autant endommager de manière irrémédiable l’environnement mondial (et donc celui des pays riches notamment). L’ouvrage défend les thèses suivantes :

  • Nos civilisations ne seront pas de sitôt à cours d’énergie ; par contre elles sont presque déjà “à cours d’environnement”.
  • Il n’est pas prudent d’attendre des preuves supplémentaires de l’impact climatique des activités humaines ; cet impact est suffisamment probable pour devoir influencer nos politiques énergétiques dès à présent.
  • Il faut interrompre le subventionnement du marché de l’énergie, “internaliser” dans ce marché le coût induit par les changements climatiques liés à la production de gaz à effets de serre (“polleur payeur”), et fournir aux pays pauvres les technologies environnementales modernes qui leur éviteront de passer par les étapes les plus polluantes du développement industriel.

Economie sociale et ISR

Les acteurs de l’ économie sociale (coopératives, mutuelles et associations) seraient des champions de l’Investissement Socialement Responsable. Autre idée : la principale faiblesse de l’économie sociale est la difficulté à prendre des risques car les investisseurs ne sont pas rémunérés pour leur prise de risque ; d’où le besoin de sociétés de capital risque spécialisées dans les entreprises de l’économie sociale.

Innovation technologique au service du développement durable

Une technologie innovante n’est pas en soi favorable ou défavorable au développement durable. Par contre, le processus d’innovation peut l’être davantage. La plupart des technologies qui sont adoptées pour renforcer une démarche de développement durable dans l’entreprise sont des technologies dites “additives” : elles s’ajoutent à un procédé existant pour en limiter les effets néfastes sur l’environnement ou d’économiser la consommation de ressources (eau, énergie, …) par exemple. Cependant, les entreprises communiquant le plus sur le développement durable privilégient la promotion des technologies intégrées au cycle de vie de leurs procédés, i.e. intervenant dès l’amont, lors de la conception d’un produit.

Prestations de services pour les associations

Une petite exploration des prestataires de services ayant une offre spécifiquement dédiée au marché associatif :

Structuration du secteur associatif

Le Crédit Coopératif présente sa segmentation du marché associatif. Tout d’abord, figure le secteur sanitaire et social, organisé en unions ou fédérations (UNIOPSS, FEHAP, UNAPEI, APAJH, FNARS, CCOMCEN, UNASSAD, …) pour lesquelles le Crédit Coopératif offre un fonds de garantie mutuelle, des services télématiques et de télétransmission pour gérants de tutelle professionnels. Ensuite vient le secteur de l’enseignement privé (90% d’établissements catholiques) et de la formation (OPCA), pour lequel le Crédit Coopératif propose des services de facilitation du cycle de gestion et des financements d’investissements avec garanties, ainsi que des services de gestion de fonds et de trésorerie. Puis on trouve les organisme confessionnels (congrégations et leurs oeuvres par exemple) auxquels le Crédit Coopératif propose des placements solidaires ou éthiques. Viennent ensuite les clubs, ligues, comités et fédérations du sport pour lesquels il est nécessaire de financer certains équipements spécifiques. Les associations de solidarité internationale ont, quant à elles, des besoins de transferts de fonds internationaux. Les organismes de défense de l’environnement peuvent trouver un complément de financement par le biais de placements solidaires gérés par le Crédit Coopératif. Enfin, le secteur des loisirs et du tourisme associatif fait l’objet de prestations de financement de travaux (création d’établissements hôteliers).

Logiciel pour le financement associatif

Le financement des organismes sans buts lucratif a ses spécificités et constitue un segment particulier pour les offres logicielles, au moins en Grande-Bretagne. Là-bas, le produit largement leader sur le marché s’appelle “Raiser’s Edge” de la société Blackbaud, avec une base installée de plus de 1000 clients. Ce type de logiciels permet d’accepter les dons en ligne avec une intégration complète dans le système de comptabilité de l’association. Un challenger est Visual Alms de Westwood Forster. Les autres grandes fonctionnalités des logiciels de ce type concernent la gestion des membres et des cotisations ainsi que des fonctionnalités plus “classiques” telles que la gestion de la paye, la gestion financière, budgétaire, etc.
D’après la base de connaissances de lasa.org.uk, une association qui a des besoins simples et cherche un système mono-utilisateur pourrait trouver son bonheur pour environ 500 euros ; pour 2 à 5 utilisateurs, les logiciels un peu plus pointus et basés sur un outil bureautique tel que Microsoft Access coûteraient de l’ordre de 10 000 euros et autant en coût d’implémentation et de formation ; pour des systèmes conçus pour 5 à 25 utilisateurs et s’appuyant sur un serveur de base de données, forcément, ça coûte plus cher…

EJB : ce qu’il ne faut pas faire avec

A l’occasion de la sortie du livre “Bitter EJB”, Slashdot fait le point sur ce qu’il ne faut pas faire avec les EJB. Il est rappelé que “bien qu’outils incroyablement puissants entre les mains d’architectes expérimentés, les EJBs sont le sujet d’un grand nombre de mauvais emploi par les développeurs novices qui en font un usage inapproprié”. C’est souvent la complexité des EJB qui tourne les entreprises vers d’autres plate-formes applicatives. Encore une fois, il est rappelé qu’un fusil à éléphant n’est pas forcément l’armement adéquat pour se débarrasser d’une souris domestique.
Mais les remarques les plus intéressantes viennent, comme souvent, des lecteurs/commentateurs de Slashdot. Ceux-ci, dans leur majorité, sont perplexes devant les EJBs. Ainsi, l’un d’entre eux affirme : “La grande majorité des gens avec qui j’ai parlé semble montrer qu’ils n’ont jamais rencontré de projet de développement pour lesquels l’utilisation d’EJB n’aurait pas été totalement superflue et pour lesquels des solutions plus simples, plus faciles à maintenir et moins coûteuses n’a pas été finalement retenue.” Encore un développeur amer au sujet des EJB : “[Avec les EJBs,] il vous faut construire 10 systèmes qui ne marchent pas avant de pouvoir deviner comment en faire un qui fonctionne. Franchement, les EJBs ne m’ont pas l’air de valoir la peine qu’il faut pour les apprendre.” Un peu plus loin : “Si il y a bien une technologie qui est en risque d’extinction dans le monde Java, c’est bien les EJBs. Pratiquement tous les nouveaux projets J2EE dont j’entend parler se tiennent bien à l’écart des EJBs et adoptent des solutions plus simples du type servlet/JSP avec JDO pour la persistence. Ensuite vous distribuez le système horizontalement avec mod_jk ou un équilibreur de charge matériel… Vue leur complexité et la nature restrictive de leur API, je n’ai vraiment pas besoin de cette technologie.” Un autre s’interroge : “Les EJBs… semblent causer plus de problèmes qu’elles n’en résolvent… Pour quel type d’usage sont-elles réellement appropriées ? Je n’ai pas été capable de le deviner la dernière fois que j’ai travaillé en environnement J2EE.”.
Heureusement, au moins un développeur Java cite un cas d’utilisation appropriée pour cette technologie : “Je suis un architecte qui travaille sur une application d’entreprise de plusieurs millions de dollars et notre expérience avec les EJB a été jusqu’ici extrêmement positive. Nous nous sommes bien gardés d’adopter les ‘entity beans’ en nous contentant d’une couche JDO… Avec du matériel modeste, nous remplaçons de manière assez rentable l’application mainframe que nous réécrivons ainsi.” Et un autre de conclure : “Si vous n’avez pas besoin d’une isolation transactionnelle dans le cadre d’un système distribué, les EJBs sont superflues.”