Utilisant WebObjects depuis maintenant 6 mois dans le cadre de mon stage ingénieur sur Sophia (voir mon CV), j’aimerais revenir sur cette expérience et donner mon avis sur cette technologie assez peu connue. Pour ceux qui ne connaitraient que de nom ce framework, en voici une petite description.

WebObjects est un framework initialement développé en Objective C par la société NeXT de Steve Jobs qui sera ensuite rachetée par Apple. Il est constitué d’une couche basse d’abstraction de la base de donnée appelée EOModel, d’une architecture de gestion de cache et de persistance et d’un moteur de template. WebObjects passera progressivement d’Objective C à Java vers l’an 2000. Bien que différents par de nombreux points, il est comparable aux technologies J2EE.

Je tiens à signaler que mes commentaires sont faits sur la version 5.3 de WebObjects et je ne sais pas si certaines choses n’ont pas été corrigées en version 5.4.

Coût de formation et cadre de développement

Soyons assez clair, le coup d’entrée de WebObjects est assez élevé. Le framework a été pensé pour réaliser des projets d’entreprise et vous ne pourrez pas sortir une page de démonstration en moins d’une heure comme le proposent des plateformes de développement comme Google App Engine. En revanche, une fois formé à l’architecture logiciel vous disposerez d’un cadre de programmation assez stricte dans la forme, mais souple dans les possibilités. Comprenez que vous pourrez faire à peu près n’importe quoi, mais pas n’importe comment. À mon sens, c’est un avantage puisque vous êtes à peu près certain que les personnes utilisant WebObjects vont travailler relativement proprement, contrairement à d’autres technologies où il est possible de faire tout et n’importe quoi, surtout n’importe quoi.

Tenue de charge et modularité

WebObjects est designé pour être capable de gérer de grandes charges, aussi les données sont toujours chargées progressivement au moment où elles sont réellement nécessaires. Au niveau du fonctionnement lui-même, le framework est construit autour de dictionnaires de données. Par exemple pour les attributs d’un objet, les getters vont simplement chercher la valeur dans un dictionnaire à partir du nom de l’attribut. C’est de ce mécanisme que vient toute la souplesse de WebObjects puisqu’il est possible de faire évoluer dynamiquement le modèle pendant l’exécution. Même si les occasions d’utiliser une telle possibilité sont assez rares, elles sont quasiment impossible à réaliser autrement.

Mélange d’API

Comme je l’ai dis dans mon introduction, WebObjects reposait initialement sur le langage Objective C, mais a été migré vers le langage Java depuis plusieurs années maintenant. Cependant les choix qui ont été faits me laissent quelque peu sceptiques. En effet afin que les personnes ayant travaillé avec l’Objective C ne perdent pas leurs connaissances acquises, les classes de  base de NeXT ont été portées en Java. Un ingénieur d’expérience sur l’API Java sera donc un peu perdu face aux NSArray, NSMutableArray et autres NSDictionnary. Pire encore, ces classes implémentent des interfaces de l’API Java, mais n’implémentent pas les méthodes qu’elles apportent, se contentant de propager une exception ! Assez perturbant donc et pouvant se révéler source de surprises.

[MISE A JOUR]
On me signale que le problème des exceptions sur les méthodes ont été corrigé en version 5.4 sauf dans les cas où il y avait une raison. Je m’explique, en WebObjects il éxiste deux types de tableaux, les NSArray en lecture seul et les NSMutableArray en lecture écriture. Bien évidemment la méthode ADD n’a aucun sens dans un NSArray qui ne supporte que des GET. En revanche la méthode ADD ne NSMutableArray ne demande plus d’utiliser à la place la méthode addObject.
Il reste toutefois que quelqu’un ayant utilisé un certain temps les classes de la JRE de base, ArrayList et autres, aura besoin d’un petit temps d’adaptation.

Trouver des personnes

Abordons finalement un point assez critique: les ressources. Il sera difficile à la plupart des personnes ayant des années d’expérience sur des plateformes J2EE de se former à WebObjects en raison des différences conceptuelles et à l’API s’écartant de celle de Java. Le coup de formation est assez élevé et l’intégration à des processus d’entreprises comme Maven, bien qu’existant, peut s’avérer coûteuse en temps.
En comparaison d’autres framework, WebObjects souffre d’une très faible documentation. Le site d’Apple propose une documentation technique, mais très peu d’autres sites proposent des exemples ou des explications différentes de la version officielle. On se retrouve donc facilement le bec dans l’eau devant un problème dont la solution n’est pas documentée sur le site d’Apple. Une solution existe: la mailing list qui est fréquentée par des experts de la technologie, mais on ne peut évidemment pas abuser et questionner ces personnes en permanence.
Il est très profitable d’avoir au sein de son entreprise une personne expérimentée en WebObjects donc, cependant il s’agit d’une ressource rare. Lors d’un recensement récent, 800 développeurs ont été dénombrés dans le Monde, dont 40 en France. Autant dire qu’il est difficile de se procurer un « expert » dans le domaine, sachant que connaissant la technologie, je ne me considère pas du tout comme un expert, mais un simple utilisateur.

En conclusion, voici un petit récapitulatif de ce billet en avantages/inconvénients.

Avantages

• Framework avec architecture
• Développement propre
• Flexible
• Pensé pour tenir la charge

Inconvénients

• Peu de ressources et très peu d’experts
• Mélange d’API Java/Objective C
• Manque de documentation tierce

cv, ingénieur, java, Programmation, webobjects