OSGi: Blueprint vs. Spring DM
Je suis un peu confus à propos de Blueprint et Spring DM:
D'après ce que je pense est vrai:
- Spring DM est un framework défini par Spring Source
- Blueprint est un cadre défini par l'OSGi Alliance
- Blueprint a "repris" bon nombre de ses idées de Spring DM
Non?
Peut-on s’attendre à ce que ces deux cadres deviennent un à l’avenir (fusion)? Sinon, lequel sera le plus pérenne?
OSGi 4.2 introduit la spécification du service Blueprint basée sur le projet Spring Dynamic Modules pour lequel Spring DM (2.x) est l'implémentation de référence (RI).
En bref: Blueprint est une spécification, Spring DM est une implémentation de Blueprint API
Blueprint a été développé au sein de l'Alliance OSGi sous la direction de SpringSource/Interface21.
Cependant, si vous cherchez un moyen de tirer parti d'OSGi, utilisez les services déclaratifs (DS) avec des annotations entre bundles (services). D'après mon expérience, vous n'avez pas vraiment besoin du XML de câblage lorsque vous faites de petits faisceaux cohérents. DS est beaucoup mieux pour travailler avec les services que Blueprint/Spring DM car ils ont tendance à vouloir "cacher" la dynamicité tandis que DS le rend simplement trivial à utiliser.
Ma compréhension est que SpringDM est un projet mort . Vérifiez le GA et les dates de sortie. Donc, même si cela a beaucoup contribué au développement de la spécification à la fin, il avait une mauvaise approche des chargeurs de classe. Apache-Aries est un forte implémentation de Blueprint. Notez que l'utilisation de Blueprint n'empêche pas l'utilisation de Spring. Je suggérerais Karaf comme une plate-forme robuste qui peut utiliser Eclipse Equinox ou Apache Felix pour le moteur OSGI. J'aime le plan par rapport à DS si vous développez au niveau de l'application où vos services peuvent être utilisés par d'autres équipes ou organisations au sein de votre entreprise, ou étendus par votre Je pense que le plan est également mieux adapté aux environnements informatiques d'entreprise traditionnels. Mais DS ou Ipojo peut être plus approprié en fonction de votre environnement cible particulier.
En plus de ce que Dmytro Pishchukhin a répondu, il convient de noter que le projet Spring DM est un peu un projet mort, car DM 2 n'a jamais atteint une "version") version.
Au lieu de cela, c'était contribué à la fondation Eclipse où il a muté en projet Gemini Blueprint .
Dans l'introduction de la documentation Gemini Blueprint, ils expliquent clairement la différence: http://www.Eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/index.html
Je reproduis ici:
Chapitre 1. Spring Dynamic Modules devient Eclipse Gemini Blueprint
Fin 2009, en tant que membre de la proposition de projet Gemini, SpringSource a contribué au projet Spring Dynamic Modules (également connu sous le nom de Spring OSGi) à la Fondation Eclipse. Spring DM v2 a été déplacée vers Eclipse.org avec son outil de suivi des problèmes et son forum. Le projet a obtenu une double licence sous licence Apache et EPL.
Bien que le nom ait changé, le code et ses fonctionnalités sont restés les mêmes. Les applications Spring existantes DM peuvent être facilement migrées vers Eclipse Gemini Blueprint comme indiqué dans le guide de migration.