Published by Publicis Sapient Engineering
Il y a 15 ans -
Temps de lecture 1 minute
OSGi au Paris JUG – Slides de la présentation
Cyrille Le Clerc et Nicolas Griso, Xebia, ont présenté OSGi, prêt pour Java EE ? au Paris JUG d’Octobre.
Nous tenons à remercier les participants d’avoir fait le déplacement, les organisateurs Antonio Goncalves, David Dewalle et Zouheir Cadi pour leur accueil toujours aussi chaleureux et tous les bloggers qui ont relayé cette soirée.
Nous souhaitons à Didier Girard et Jérôme Louvel une assistance aussi nombreuse pour la soirée GWT du Paris JUG de Novembre .
La blogosphère en parle
- Le Touilleur Express : Présentation d’OSGI au Paris JUG : naphtaline et peinture fraîche
- Eric Le Merdy (Valtech Blog) : Back from OSGi at ParisJUG
- Tom’s quest : OSGi : oui mais non
- Ruchika Goyal (Xebia Hollande) qui relate lui aussi son expérience OSGi dans Experimenting with OSGi on Server Side
La présentation
Télécharger en PDF
Le plan
- Pourquoi la modularité ?
- La modularité en Java
- L’existant
- Les jars
- Les classloaders hiérarchiques
- Maven 2
-
Le futur
- Java Module System
- OSGi / JSR 291 : Dynamic Component Support for Java SE
- L’existant
- OSGi Alliance
- L’histoire
- Le fonctionnement
- OSGi Alliance et le JCP
-
La plateforme OSGI
- Les bundles
- Le réseau de classloader
- Le conteneur
- Le cycle de vie des bundles
- Le Service Registry
- L’assemblage des services
- BundleActivator et ServiceTracker
- Declarative Service
- RFC 124 – A Component Model for OSGi (aka Spring DM)
- Les services standards
- Import d’un service
- Exposition d’une servlet : le HttpService
- Upgrade à chaud d’un bundle
- Log4j !
- Client side
- Server Side
Rendez-vous le mois prochain au Paris JUG !
Commentaire
6 réponses pour " OSGi au Paris JUG – Slides de la présentation "
Published by Eric Le Merdy , Il y a 15 ans
Dans la série « La blogosphère en parle », j’ajoute:
http://blog.ippon.fr/2008/10/06/osgi-la-norme-de-gestion-de-modules-dynamiques-java-au-jug
Published by Clement , Il y a 15 ans
Bonjour,
Interessante cette présentation. Cependant, la description d’Apache Felix iPOJO aurait été également utile (http://ipojo.org). Ca aurait d’ailleurs répondu à une question : qu’utilise le serveur JEE Jonas pour gérer la complexité d’OSGi…
De plus, ce projet est loin d’être « mort » vu qu’il rassemble de plus en plus d’utilisateurs et que la pérénité du support et du développement est aujourd’hui assuré.
Clement
Published by Cyrille Le Clerc , Il y a 15 ans
Bonjour Clément,
Si nous ne nous sommes pas attardés sur Apache Felix iPOJO, nous n’avons en aucun cas voulu donner l’impression que ce projet était « mort ».
Nous avions initialement prévu de placer iPOJO aux côtés de Spring DM comme successeur potentiel du très récent Declarative Service (2005) qui lui même devait proposer un modèle de programmation plus simple que le couple ServiceTracker/BundleActivator.
Cependant, nous avons eu l’impression que le modèle de Spring DM faisait l’unanimité au sein de l’OSGi Alliance avec notamment l’éloge qu’en a fait Peter Krien, Director of technology de l’OSGi Alliance, dans Spring and OSGi: Jumping Beans (01/2007) puis l’annonce d’Eric Newcomer, co-chair de l’OSGi Enterprise Expert Group, dans Early Draft OSGi V4.2 Docs Available : la V4.2 introduirait avec la RFC 124 un nouveau modèle de composants inspiré par Spring DM [1].
La culture de débats ouverts du Java Community Process ne nous avait pas habitué à ce qu’une spécification semble exclusivement inspirée par un produit déjà sur étagère sans que les autres acteurs de l’expert group apportent leur contribution mais c’est bien la tournure que semble prendre « RFC 124 – A Component Model for OSGi ».
La seule tentative de débat public que nous ayons trouvée sur ce point, Gunnar Wagenknecht’s weblog – OSGi RFC 124, a malheureusement tourné court avec la réponse cinglante d’un membre de l’OSGi Enterprise Expert Group, Hal Hildebrand – Oracle, qui a avancé des arguments aussi constructifs que « Dude, since I haven’t seen you operating in the EEG committee » … quand on se souvient que l’OSGi Alliance demande 20 000 $ pour participer à ces comités, on regrette le JCP qui lui accueille gratuitement les membres individuels et a des débats de plus en plus souvent publics.
Pour revenir à la RFC 124, auriez-vous des informations sur les débats internes de l’Enterprise Expert Group qui ont mené à une RFC dans laquelle on ne retrouve pas d’inspiration de Declarative Service ou de Felix iPOJO ?
Cyrille (Xebia)
[1] « The big new areas of course are the distributed OSGi and the « Spring-inspired » component model ». Plus de détails dans OSGi 4.2 Early Draft / RFC 124 – A Component Model for OSGi
Published by Nicolas Griso , Il y a 15 ans
Dans la série “La blogosphère en parle”, j’ajoute:
http://www.itaware.eu/2008/10/19/osgi-cote-serveur-est-ce-vraiment-utile/
Published by Etienne VRIGNAUD , Il y a 15 ans
Bonjour,
Je pense qu’iPojo et Spring DM sont très différents. Avec les deux on peut utiliser des descripteurs XML. Sur ce point ils sont « comparable ».
Mais iPojo peut aussi fonctionner à l’aide d’annotation (http://felix.apache.org/site/how-to-use-ipojo-annotations.html). Cette fonctionnalité est très pratique et correspond bien à la tendance actuelle. C’est ce mode que j’utilise.
En fait le fonctionnement d’iPojo par annotation n’est pas très facile à appréhender car il n’est pas mis en avant sur le site d’iPojo. Il est regrettable qu’il n’y ait pas de tutorial sur l’utilisation d’iPojo avec les annotations. Quand on utilise les annotations, le descripteur XML reste utile uniquement pour déclarer les instances qu’iPojo doit fabriquer.
Etienne
Published by Clement , Il y a 15 ans
Bonjour,
« Pour revenir à la RFC 124, auriez-vous des informations sur les débats internes de l’Enterprise Expert Group qui ont mené à une RFC dans laquelle on ne retrouve pas d’inspiration de Declarative Service ou de Felix iPOJO ? »
La RFC est directement tiré de Spring-DM et comme vous l’avez remarquer ne s’inspire pas vraiment des autres modèles à composants sur OSGi( Service Binder, SCR, Dependency Manager, iPOJO et bien d’autres). Cette RFC est plutot destiné au développeurs utilisant « Spring » (c’est à dire un développement type JEE). Cependant, cette RFC ne garde pas vraiment la philosophie d’OSGi (small, ‘simple’, dynamic).
C’est là, la plus grosse différence, iPOJO a été bati pour OSGi sur OSGi. Spring-DM est une migration de Spring sur OSGi. D’ailleurs, Spring-DM profite de touts les services techniques de Spring. Ceux-ci sont très utiles mais gardent une connotation JEE. Cependant, faire tourner une application Spring-DM sur J2ME me semble complexe, alors qu’il existe des applications iPOJO tournant sur Android, NSLU (JamVM), voir des périphériques encore plus petits (JVM Mika) …
Concernant les discussions de l’EEG, Richard Hall (Apache Felix leader et l’un des ‘défendeurs » d’iPOJO) fait parti de l’EEG et discute régulièrement avec les autres participants (dont Hal Hildebrand et Adrian Coyler).
PS pour Etienne: l’équipe d’iPOJO va bientôt fournir un tutorial complet concernant les annotations.
Clement