I.T. aware

Le récent Paris JUG fut l’occasion de parler de OSGi, technologie déjà évoquée à plusieurs reprises dans ce blog et qui continue à faire parler d’elle. Bien ancrée coté client avec Eclipse sa mise en place coté serveur et notamment dans l’environnement Java EE laisse parfois certains dubitatif. Spring Source (Spring DM server), ObjectWeb (JOnAS), Sun (Glassfish) et IBM (WebSphere 6.1) ont pourtant clairement fait le choix. Quels en sont les réels avantages pour nos applications coté serveur ?
Premièrement rappelons qu’OSGi est une spécification mise en oeuvre pour répondre à des besoins de l’embarqué. Ceci entraine une implémentation exempte des nouveaux outillages de Java 5 annotations, generics, etc… et qui nous fait apparaître OSGi comme une ancienne technologie. Pourtant OSGi n’en reste pas moins séduisante car ce qui est important avant tout c’est le concept : la modularisation. Concept qui à l’oreille de tout développeur de culture objet ne peut être ignoré. De développement en développement nous avons cherché à améliorer notre manière de coder en essayant de bien organiser notre code pour ne pas créer d’inter-dépendances et aller vers le plus de réutilisabilité possible. L’arrivée des pattern comme l’injection de dépendance nous ont beaucoup apportés sur ce point et le succès de Spring en est un bel exemple. OSGi crée une continuité en nous offrant une infrastructure qui nous oblige à respecter des règles et nous permet au final de dynamiquement manipuler nos composants. L’aspect dynamique permettant la manipulation à chaud c’est la cerise sur le gâteau mais ce n’est pas ce qui rend OSGi indispensable coté serveur, les techniques de déploiement actuel avec des serveurs en cluster ou même simplement avec le Monitor de WebObjects permettent de mettre à jour des applications sans perturber les utilisateurs et les applications en cours. Ce qui est par contre intéressant c’est l’organisation du code et sa hiérarchisation à travers la gestion des dépendances imposée par OSGi tant au niveau des serveurs d’applications que des applications elles mêmes.
Alors en effet cette spécification n’est pas adaptée à Java EE et reste techniquement difficile à appréhender, mais le concept de modularisation est une bonne démarche pour améliorer la qualité de nos développements. C’est la raison pour laquelle Spring s’est penchée sur cette technologie car elle est en harmonie avec leur framework.
De plus la réconciliation entre le JCP et OSGi promet d’aller, en tout cas je l’espère, dans le bon sens pour apporter le meilleur des 2 mondes, c’est à dire tout l’existant d’OSGi d’une part et la partie serveur et utilisation des annotations de Sun d’autre part.
Il ne faut cependant pas négliger l’aspect dynamique car bien que les utilisateurs ne soient pas aussi exigents au point de vouloir voir apparaître un nouveau bouton dynamiquement suite à une demande d’évolution, le fait est qu’avec OSGi ce sera techniquement possible. Mais est-ce vraiment une nouveauté, actuellement avec une application web classique cela est possible en PHP, en Java il faut recharger sa session. Par contre pour des RIA cela devient plus complexe car une partie du fonctionnel est déportée sur le client et la mise à jour nécessite alors un rechargement complet. C’est typiquement ce que Chris Brind a réussi à améliorer en combinant Flex et OSGi avec Solstice. Ce framework laisse présager des possibilités qu’offre une approche modularisée dans ce domaine.
Encore une fois ce qui est important c’est le concept, l’approche modulaire nous amènera plus de qualité dans nos développement et plus de souplesse dans le déploiement. A la communauté de choisir la meilleure technologie pour le faire …

The recent Paris JUG was an opportunity to talk about OSGi technology, already mentioned several times in this blog, and continues to hear about it. Although OSGi is present on the client side with Eclipse, the development of the server side and especially in Java EE environment sometimes leaves developers not convinced. Spring Source (Spring DM server), ObjectWeb (JOnAS), Sun (Glassfish) and IBM (WebSphere 6.1) have clearly made the choice. What are the real benefits for our applications on server side?
First don’t forget OSGi is a specification designed for the embedded domain. This make an implementation without the new Java 5 features : annotations, generics, etc … and that makes us appear OSGi like an old technology. But OSGi stay attractive because what is important above all is the concept: modularization. Concept that on each ear of OOP developer can not be ignored. By development on development we have tried to improve the way we write code, trying to organize it to not create inter-dependencies and go over possible reusability. The arrival of the DI pattern help us to do that and the success of Spring is a good example. OSGi creates a continuity in offering us an infrastructure that obliges us to respect the rules and allows us to dynamically manipulate our components. The dynamic aspect and hot deployment is the icing on the cake but this is not what makes OSGi essential on server side, the current deployment technics with clustered servers, or even with the simple WebObjects Monitor tool, help us to update applications gracefully. What is interesting it’s how the code is organized and the hierarchy throw the management of dependency imposed by OSGi, in application servers and applications themselves.
So in fact this specification is not suited to Java EE and remains technically difficult to understand, but the concept of modularization is a good approach to improve the quality of our developments. That is why Spring focused on because it fits with their framework.
Moreover reconciliation between JCP and OSGi promises well, I hope in the right direction, to make the best of 2 worlds, i.e. all existing OSGi in one hand and the server aspect and Java 5 new features for Sun on the other.
However, we must not forget the dynamic aspect because although users are not insist to see a new button dynamically appear at each time thez need a new functionnality, the fact is with OSGi it is technically possible. But is it really an improvement, actually with a web application it is also possible in PHP, in Java (must reload session). For RIA this becomes more complicated because part of the functional is deported on the client side and update requires complete reloading. This is typically what Chris Brind has managed to improve by combining Flex and OSGi with Solstice. This framework show the potential of modular approach in this domain.
Again what is important is the concept, the modular approach will bring us more quality in our development and greater flexibility in deployment. Let the community choose the best technology to do it…

A short post to report the victory of Benjamin MESTRALLET at the “Young dirgeant technology price”. Exo Platform is a great and quite promising company managed by quality persons ;). Long life to you …

Un bref billet pour saluer la victoire de Benjamin MESTRALLET au “Prix du jeune dirigeant de la technologie”. Exo Platform est une société qui a de l’avenir et menée par des personnes de talents ;). Longue vie à vous et à bientôt sur le chemin de la réussite.

It was a pleasure to show Terracota presentation by its creator Ari Zilka, organized by the very innovative company Zenika.
Terracota is a JVM cluster, it allows to synchronize JVM, based on the principle of NAS but for memory: NAM for Network Attached Memory. Lire la suite »

J’ai eu le plaisir d’assister à une présentation de Terracota par son créateur Ari Zilka, organisée par la société Zenika, que je salue au passage pour son approche novatrice et cette initiative réussie.
Terracota est un cluster de JVM, il permet de synchroniser des JVM entre elles en se basant sur le principe du NAS mais au niveau de la mémoire : NAM pour Network Attached Memory. Lire la suite »

On a project using BIRT I was confronted with this problem. I generate complex reports using components and datasets defined in a library. I wish to show a component only if the bound dataset contains data.
The operation is simple but I looked for the most generic solution. Indeed the component will be used in some reports and the update operations have to be the simplest as possible.
Lire la suite »

Sur un projet intégrant BIRT j’ai été confronté à ce problème. Je génère des rapports complexes utilisant des composants et des datasets (jeu de données) définis dans une librairie. Je désire afficher un composant uniquement si le dataset lié contient des données. L’opération en soit est simple mais dans la mesure où le composant est défini dans une librairie qui en contient plusieurs, je cherchais la solution la plus générique possible. En effet le composant sera utilisé dans plusieurs rapports et il pourra évoluer. Il faudra que les opérations de mise à jour soient le plus simple possible.
Lire la suite »