BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Pourquoi avons-nous besoin de Distributed-OSGi ?

Pourquoi avons-nous besoin de Distributed-OSGi ?

Favoris

Vu que nous atteignons une étape clé du projet Distributed-OSGI, il semble être temps de passer en revue ce qui a été fait jusqu'à présent, d'identifier les étapes restantes, et d'expliquer pourquoi nous faisons cela en premier lieu.

En novembre, nous avons publié une mise à jour des spécifications en version "early-acces draft" (Requests for Comments ou RFC dans la terminologie OSGi) pour la prochaine version 4.2 de la spécification OSGi. Ce mois-ci nous avons publié dans Apache CXF le code source de l'implémentation de référence pour la mise en oeuvre de l'une des nouvelles et importantes fonctionnalités pour cette version, la RFC 119, Distributed-OSGi.

Le projet Distributed-OSGi a été lancé dans le cadre de la prochaine version de la spécification OSGi, car la version actuelle de celle-ci a réussi dans le monde de l'embarqué, et commence à être adopté dans le monde de l'entreprise. Par exemple, le framework OSGi est derrière les plug-ins Eclipse, tous les serveurs d'application et la plupart des vendeurs ESB l'utilisent aussi.

L'OSGi Alliance a organisé un wokshop public en septembre 2006, pour étudier les besoins pour une possible version "Enterprise" (Peter Kriens a écrit un très bon article de blog à ce sujet). La version actuelle de la spécification OSGi a été inclue dans Java SE, via la JSR 291, et la question pour ceux d'entre nous qui ont participé à l'atelier, était de savoir si la spécification OSGi devrait également devenir une alternative à Java EE, et si oui, quelles sont les conditions qui doivent être satisfaites. L'une des principales exigences était la capacité des services OSGi à appeler des services en cours d'exécution dans d'autres JVMs, et pour appuyer la demande des entreprises sur des topologies de disponibilité, fiabilité et évolutivité. (La spécification OSGi définit le comportement actuel des appels de service dans une seule JVM. Voir résumé de l'atelier de Peter Kriens pour plus de détails)

Le travail a officiellement débuté en janvier 2007, avec la première réunion de l'"Enterprise Expert Group". Distributed-OSGi est resté parmi les premières exigences ratifiées lors de cette session. Au début, nous avons souvent reçu des critiques disant que nous "réinventions la roue", ou «la création d'un autre CORBA", mais ceci est basé sur un malentendu. Le brouillon de conception (RFC 119) et le code dans Apache CXF devraient aider à clarifier le fait que nous ne faisons pas cela. Nous sommes tout simplement en train d'étendre OSGi pour être utilisé dans les systèmes distribués. Nous utilisons le terme "système distribué" ou DSW dans la RFC 119 comme une référence générique à tout type de protocole et de format de données capable d'invocation de service à distance. À distance signifie dans une autre JVM ou espace d'adressage.

Certains ont suggéré que nous choisissions un type particulier de système de distribué et de le standardiser sur ce point. Un avantage serait de pouvoir exploiter les fonctionnalités spécifiques de chaque protocole, telles que la sérialisation du code exécutable, mais ce serait réduire le choix et créer un blocage potentiel. Au lieu de cela, nous avons défini un mécanisme de configuration générale qui pourrait être utilisé avec n'importe quel système distribué. Nous avons également essayé de ne pas empêcher l'utilisation de fonctionnalités telles que la sérialisation du code exécutable - en d'autres termes, vous devriez toujours être en mesure de le faire si vous le voulez, mais ce n'est pas standardisé, car il est spécifique à un seul type de système distribué.

En plus de l'implémentation de référence Apache CXF, les projets Eclipse ECF et Infiniflow de Paremus ont l'intention de mettre en oeuvre le design, et nous avons entendu des gens dire que le projet Eclipse Riena y pense aussi. J'espère donc que nous sommes sur la bonne voie avec Distributed-OSGi. Mais nous sommes toujours très intéressés par des retours, et il est maintenant temps de changer ce qui se passe réellement dans la spécification. Distributed-OSGI comprend également un service de découverte et une extension de métadonnées SCA pour la configuration de plusieurs composants distribués. Aucun de ceux-ci ne sont encore disponibles publiquement, mais cela ne devrait pas tarder.

Pour expliquer où nous en sommes dans le processus, il est utile de donner quelques explications sur la façon dont l'Alliance OSGi fonctionne. Son processus est très similaire au Java Community Process. La spécification OSGi a commencé sa vie en tant JSR8, et représente encore en partie l'évolution de cet effort initial. Le process OSGi commence avec des RFPs (Request for Proposal) qui détaillent les exigences. Une fois que la RFP est approuvée, une ou plusieurs RFC (Request For Comments) sont créés. Une fois la RFC approuvée, les spécifications sont mises à jour pour inclure les nouvelles exigences. Les RFP et RFC sont initiées par les "Expert Groups", bien qu'ils tendent à être dirigés par des individus ou une petite équipe au sein du groupe.

Quand on regarde la partie spécification du processus, cependant, l'Alliance OSGi est unique car elle paie Peter Kriens pour l'écriture. C'est une très bonne chose parce que Peter a été partie prenante d'OSGi depuis le début, et il assure la qualité et la cohérence de la spécification. Mais il élimine aussi un problème politique typique qu'ont d'autres consortiums quand ils "passent la plume" à un ou plusieurs membres (représentant généralement les vendeurs qui sont en concurrence avec un ou plusieurs autres membres).

La version actuelle de l'implémentation de référence a été faite pour prouver le concept décrit dans la RFC 119, et pour permettre à la RFC de passer le vote. Dans la phase de spécification, nous espérons pouvoir discuter sur la conception au fur et à mesure qu'elle est intégrée dans la spécification, ce qui pourrait ensuite entraîner d'autres changements à l'implémentation de référence.

Les groupes d'experts OSGi ont commencé à travailler avec Peter sur la mise à jour de la spécification pour la Release 4.2, qui devrait être publiée sous forme préliminaire en mars ou avril, et en version finale en juin. Beaucoup plus d'informations à propos de la prochaine version ont été annoncées à l'OSGi Dev Con, qui s'est tenue en conjonction avec EclipseCon à Santa Clara les 23 et 26 mars.

Les autres parties importantes de la sortie prochaine incluent diverses extensions du framework de base, le modèle de composants Blueprint dérivé de Spring, pour le développement de services OSGi, et différents morceaux de Java EE intégrés en tant que bundles OSGi (JTA, JDBC, JPA, JNDI, JMX, JAAS et les applications Web). Les fonctionnalités Java EE n'ont pas été aussi poussées que les améliorations apportées au core, Spring/Blueprint, ou le travail sur Distributed-OSGi, mais un aperçu devrait être publié en même temps que la version finale de la 4.2.

Les deux dernières années ont permis l'intégration de la documentation et des spécifications de Distributed-OSGi en version "early release draft" ainsi que l'implémentation de référence d'Apache CXF. C'est l'une des caractéristiques principales de la nouvelle spécification OSGi R4.2 Enterprise à venir, qui devrait sortir à la mi-2009. Avec aussi des extensions du framework de base OSGi, le modèle à composants dérivé de Spring, Blueprint, et l'intégration des technologies clés Java EE, la prochaine version représente un grand pas en avant pour la spécification OSGi et la communauté.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT