Note de lecture : Spring Microservices in Action, par John Carnell

Note : 7 ; Il reprend là où « Spring Boot in Action » s’arrête…

Effectivement, « Spring Boot in Action » m’avait laissé sur ma faim. C’est essentiellement parce qu’il se focalisait sur la construction d’une application MVC, nous laissant un peu démuni sur la construction d’un serveur Rest, qui constitue pourtant l’un des cas d’usage nominaux. C’est bien sur ce cas d’usage et pas un autre que se focalise ce volume. Mais il va plus loin en couvrant l’intégralité de l’architecture microservices grâce à la stack Neflix et à son intégration dans Spring.

Je commence à froncer les sourcils à partir de 300 pages, mais les 350 de celui-ci se digèrent assez bien, malgré des chapitres aussi en moyenne plus volumineux que ce que j’apprécie généralement : ce volume en compte 10. Les 35 pages de l’introduction s’avalent très bien, on y a droit à une vue générale de l’architecture des applications microservices avec Spring Boot. C’est à la fois plus concret que ce que l’on croise généralement et aussi fort bien illustré, une constante du livre. Certes on n’a pas produit de code (mais l’auteur nous en dispense des fragments) mais on a un plan précis de ce qui nous attends.

La trentaine de pages du chapitre 2 nous amène vers le « hello world » du microservice et même un peu plus loin avec un certain nombre de considérations liées au déploiement. Tout cela s’avale très bien et on peut déjà se salir les mains avec succès. Cela dit, moi j’aurais fait deux chapitres… C’est également une trentaine de pages qui nous attends avec le chapitre 3, où l’on prend de plein fouet la stack Netflix, plus exactement, Eureka, à partir duquel l’auteur nous amène à construire un serveur de configuration. L’architecture de déploiement prends soudain beaucoup plus de complexité, mais c’est somme toute le destin des architectures microservices.

Lire la suite

Publicités

Note de lecture : Spring Boot in Action, par Craig Walls

Note : 6 ; Craig Walls (heureusement) toujours égal à lui-même !

J’avais hâte d’aborder ce volume, car on m’avai dit grand bien de Spring Boot. Craig Walls balaye consciencieusement tous les aspects de cette famille de frameworks depuis plusieurs années, avec une plume qui rend tout cela agréable : bon point. Atre bon point, le volume réduit du livre qui est de seulement 180 pages. Hélas cela a conduit à certains choix de contenus que je trouve malheureux ou qui au moins m’ont frustré. Mais j’y reviendrais.

Pour l’instant, voyons le contenu, qui compte 8 chapitres. Le premier « bootstrapping Spring Boot » ne compte que 22 pages, juste de quoi faire le tour du propriétaire et voir les différentes manières d’installer Spring Boot et d’initialiser un projet. C’est aussi l’occasion de voir que le reste du livre va faire l’impasse sur pas moins de 4 sur 5 types de projets que permet Spring Boot (page 13). C’est fâcheux et c’est le principal reproche que j’ai à faire au texte. Cela lui coute 2 points sur ma note de lecture !

Le second chapitre est consacré au « hello world » (d’est du MVC, bien sûr…). Autant dire que ses 25 pages sont précieuses. C’est un plaisir à lire et l’auteur couvre bien les aspects lié au build, à la structure du « starter » et à la gestion commune des dépendances. L’auteur montre une préférence marquée pour Gradle pour le build, mais Maven n’est pas mis à l’écart.

Lire la suite

Neo4J et Spring Data, avec Florent Biville

Ce premier Octobre, Zenika accueillait de nouveau le groupe Meetup dédié à Neo4J. L’occasion de faire connaissance avec Spring Data grâce à Florent Biville.

Echauffement

Débuter un Meetup par l’interlude commercial, ce n’est pas nécessairement le meilleurs départ. Mais Cédric Fauvet connait au moins le public auquel il a à faire et il fut lui-même développeur. En fait, il a même évoqué deux ou 3 choses qui ont piqué ma curiosité !

Meetup Neo4J Octobre 2013

La première réelle application de la théorie des graphes semble être celle des 7 ponts de Königsberg. Le seigneur du coin voulait savoir s’il était possible de faire un trajet dans la ville en passant une fois et une seule par chaque pont. Ce n’est pas possible et l’on peut s’en rendre compte de manière empirique, mais c’est Leonhard Euler qui le démontra mathématiquement.

Les 7 ponts de Königsberg

Il n’y avait pas Neo4J à l’époque, mais aujourd’hui on en dispose et on résoud avec d’autres problèmes ayant trait à la théorie des graphes:

  • Bien sûr il y a déjà le cas classique des réseaux sociaux, comme les suggestions de contacts utilisés par Viadeo.
  • Les analyses d’impact sur les réseaux, mis en oeuvre chez SFR.
  • Les calculs de primes de commerciaux, chez Sisco (!) Il ne faut pas moins de 2 clusters pou gérer cela.
  • Le routage des colis chez un grand opérateur en Allemagne.

Aujourd’hui la communauté Française semble se porter plutôt bien, elle compte 362 personnes inscrites sur le Meetup et un nouveau Meetup va démarrer sur Lyon.
Du point de vue de l’actualité, c’est la version 2.0 qui occupe le terrain et doit être le sujet principal de Graph Connect.

Après le pizza-break, place au sujet principale de la soirée.

Spring Data

Nous sommes face à un dilemme aujourd’hui : le monde devient de plus en plus dynamique, ce qui fait la part belle à des bases de données orientées graphe telle que Neo4J. Et pas seulement cette dernière d’ailleurs, mais aussi des solution empruntant le même paradigme:

  • Flock DB, une solution construite par Twitter.
  • Titan, une base de données orientée graphes distribuée.
  • Blueprint, qui est plutôt une abstraction au-dessus des bases de données graphe, mais aussi une stock logicielle offrant des fonctionnalités de plus haut niveau.
  • RDF, l’ancêtre de ces bases de données, qui est une normalisation par le W3C des représentations de données sous forme de triplets.
  • Orient DB qui mixte des fonctionnalités d’une base orientée documents avec une base orientée graphes.
  • InfiniteGraph

Un dilemme disais-je, car si ces solutions adaptées aux problèmes actuels se développent, l’entreprise reste, elle, conservatrice. Elle continue de s’appuyer majoritairement sur les bases de données relationnelles et donc sur les ORM pour assurer la jonction avec le code applicatif.

Meetup Neo4J Octobre 2013

Ces solutions ORM, tel que le standard JPA ne semblent pas poser de problème dans la plupart des cas, pourtant on fait rapidement face à “l’abstraction leak”, à savoir que les paradigmes fondamentaux des SGBDR et des applications sont différents et les ORM tentent de le masquer.

Les bases de données graphe offrent un mapping plus simple et plus naturel. Elles permettent en outre de satisfaire d’autres besoins :

  • L’hétérogénéité des propriétés associées aux noeuds.
  • L’absence de schéma prédéfini. Sur le papier, c’est un problème car il permet une discordance des donnés par rapport à l’intention de structuration. Mais avec Neo4J 2.0 le schéma existe de manière optionnelle.

Il y a-t-il un intérêt à proposer un mapping objet des bases orientées graphe ? Oui, si il offre une réelle simplification et des fonctionnalités intéressantes.

Hibernate OGM, une première approche

Hibernate OGM offre une approche inspirée de l’ORM qui ne convainc pas Florent. D’une part, à l’instant de JPA elle offre le plus petit dénominateur commun des bases orientées graphes, et l’idée de faire entrer toutes les bases de données NoSQL (pas seulement les bases orientées graphes) dans un même moule semble pour le moins un gros challenge…

Tinkerpop Frames

Cette solution se focalise également sur la construction d’une abstraction des bases orientées graphes (et seulement celles-ci). Elle propose son propre langage de requête, Gremlin. Las aujourd’hui le langage de requête de Neo4J, Cypher est l’un des atouts important du produit et de gros efforts sont consentis pour en améliorer les fonctionnalités. On se retrouve donc dans une course à la fonctionnalité… que Gremlin peut difficilement gagner.

Spring Data

Suivant l’idée d’origine de Spring, il s’agit d’une brique très légère. En fait, à l’origine même de ce sous-projet, il y a la rencontre entre Emil Eifrem et Rod Johnson, à savoir respectivement les créateurs de Neo4J et de Spring !

Un atout important de Spring Data est aussi son concept de “multi-store”. Nous avons évoqué la frilosité des entreprises par rapport aux nouveau paradigmes de bases de données. Spring Data adresse cela en permettant des ponts entre différents paradigmes (par exemple relationnel vers graphe) permettant des transitions douces vers ces nouveaux mondes !
D’un point de vue pratique, pour un repository standard, tout ce que l’on a à faire, c’est d’hériter de l’interface GraphRepository<> … et Spring Data s’occupe du reste ! Derrière le rideau, cette interface hérite de quelques autres (je ne vais pas les lister, elles sont sur le slide 31). Derrière le second rideau, au niveau de l’implémentation générée, cela va bien entendu être la “foire aux proxys” ! Bon, comme on dit : on ne peut pas tout avoir !
Spring Data offre d’importantes facilités pour écrire, ou plutôt ne pas écrire, des méthodes de recherches :

  • Des “find”, où la simple convention de hommage va permettre de connaitre les critères de recherche en les mappant sur les paramètres.
  • Des recherches plus complexes s’appuyant sur des clauses Cypher figurant en annotation @Query de la méthode.

En annotant des classes @NodeEntity, on peut spécifier ce qui est persisté et ce qui ne l’est pas, ce qui constitue des arcs, et bien d’autres choses encore !
Les templates Neo4J, à la façon de ce qui existe pour d’autres modules Spring, permettent d’opérer des requêtes de projection en éliminant la plomberie inhérente à l’utilisation brute de la base.

Spring Data offre de nombreuses fonctionnalités supplémentaires, comprenant bien entendu les famaux “cross store storage” que nous avons évoqué au début.

Pour conclure
Une soirée instructive sur les possibilités de Spring Data, bien que j’ai regretté que cela aille un peu vite sur les NodeEntity et que l’on ne s’arrête guère sur les stores multiples, car cela me parait un point clé pour Neo4J en entreprise, bien plus que l’économie de code que permet le framework !
Par ailleurs Florent a initié une série d’articles très bien écrits pour s’initier à Neo4J : le premier de la série est ici.

Note de lecture : Spring Batch in Action, par A. Cogoluègnes, T. Templier, G. Gregory & O. Bazoud

Note : 7 ; Une qualité de prose qui fait honneur à la « in action » series, mais une lecture un peu lourde au total.

Mon premier contact avec ce livre a été teinté d’appréhension : il compte pas moins de 440 pages hors annexes, ce qui me semble beaucoup, je le dis sans ambage ! Puisque l’on en est aux présentations : le volume est découpé en 14 chapitres, eux mêmes regroupés en 3 parties. Il faut en plus compter une vingtaine de pages d’annexes. Cela nous donne une moyenne d’une trentaine de pages par chapitre. C’est beaucoup à mon gré, mais consistent avec le standard de la « in action » series. A propos de cette série, Manning fait beaucoup d’effort pour maintenir une ligne éditoriale de bonne qualité qui permet d’être rarement déçu avec chacun des opus. Nous verrons que ce volume fait honneur à la série.

La première partie s’intitule « background » et regroupe les deux premiers chapitres pour un total de 50 pages. Le premier d’entre eux nous fait faire le tour du propriétaire. Non seulement on y comprends l’architecture logique (finalement, Spring Batch c’est un framework-ETL Java) mais on va jusqu’à faire une mini-application de traitement (lecture, traitement et écriture) avec la configuration Spring correspondante. Impressionnant pour un premier chapitre !

Le second chapitre rentre plus avant dans les concepts sous-jacents du framework : job, métadonnées du job, step, etc… Le but de ce chapitre est de nous donner les clés pour décomposer une spécification de traitement en étapes décomposées. Bon boulot, à nouveau.

La seconde partie « core spring batch » est de loin la plus imposante du livre. Elle compte 7 chapitres et 225 pages. C’est donc un mini-livre à elle toute seule. C’est d’ailleurs à mon avis le problème le plus important du livre, mais je reviendrais là-dessus plus tard ! Le chapitre 3 qui débute cette seconde partie nous immerge dans la configuration des batches. Plus clairement : comment s’articule la configuration Spring d’une application Spring Batch. Il y a 5 niveaux d’entités hiérarchiquement emboitées à configurer (sans compter le repository de jobs) et le chapitre passe par le menu la manière de configurer tout cela avec les attributs qui vont bien. C’est un poil lourd, mais bien écrit.

Le chapitre 5 explore en profondeur la manière de lancer (et arrêter) les jobs : en ligne de commande ou en planifiant de différentes manières. Le tout est bien illustré par des diagrammes de séquence, entre autre chose.

Avec le chapitre 5, on attaque réellement le développement de traitements Spring Batch, en débutant par les composants de lecture. Le sujet est largement balayé en largeur sur 40 pages, que ce soit sur des fichiers plat, du JSON, du XML ou de l’accès aux bases de données. Rien à dire sur la manière dont le sujet est abordé, mais c’est quand même un peu long quand ce que l’on souhaiterait, c’est arriver au bout du chemin pour voir ce que cela donne !

Le chapitre 6 aborde fort logiquement le composant d’écriture. Si les aspects de base (field extraction, formatage) sont fort logiquement abordés, là aussi le sujet est abordé en largeur, avec non seulement l’écriture sur fichier, mais la production de XML, de file sets et l’écriture en base de données. Mais on aborde aussi l’écriture en flux JMS et l’envoi de mails. Là aussi je trouve que cela fait beaucoup pour une première passe, et paradoxalement, certains de ces sous-sujets sont traités un peu rapidement !

Toujours dans la même veine, le chapitre 7  nous présente les composants de traitement. Les items processors de Spring Batch recèlent nombre de richesses et il me semble difficile de faire des impasses par rapport à ce qui figure dans le texte. La lecture du chapitre me laisse cependant un léger sentiment de confusion, mais rien de bien grave. Les excellentes illustrations graphiques ou en code permettent de toute façon de se raccrocher aux branches.

Le chapitre 8 compte à peine 30 pages, mais elles recèlent une expertise qu’il serait dommage de rater. Il s’agit de la conception des reprises sur erreur avec Spring Batch. Excellent !

Cette seconde partie s’achève avec le chapitre 9 qui couvre l’aspect transactionnel des batches. Le sujet est traité de manière solide et claire en 25 pages, que ce soit sur les erreurs à ne pas commettre, sur la portée des transactions et les différents niveaux de transaction disponible (job, chunk,…). Rien à redire.

La 3ème partie du livre est consacré aux « sujets avancés » et le premier chapitre de cette partie, le chapitre 10, dédie 25 pages au contrôle d’exécution. Partage de contexte, flux alternatifs et même externalisation des définitions de job sont parmi les sujets traités.

Avec le chapitre 11, on commence à toucher du lourd, à savoir l’intégration d’entreprise. Les auteurs évoquent d’abord les styles d’intégration d’un point de vue architecture logique. Il n’est pas étonnant qu’ils fassent référence aux Enterprise Integration Patterns de Gregor Hope ! D’un point de vue pratique, la quarantaine de pages de ce chapitre s’appuie sur 2 fondations : Spring Integration d’une part et Spring MVC pour illustrer une intégration http/ReST. Il est juste dommage que les 2 approches ne soient pas mieux abordées en séquence afin de rendre la prose plus claire.

Ce livre ne rate pas le, oh combien important, sujet du monitoring. Le chapitre 12 fait du bon boulot là-dessus, que ce soit pour décrire la structure BDD supportant cela, pour décrire l’intégration JMX ou même pour éclairer l’usage de l’outillage prêt à l’emploi de Spring batch à savoir Spring Batch Admin ou JConsole.

Le chapitre 13 est vraiment un sujet avancé car il traite de scaling. Un chapitre sur lequel il est possible de faire l’impasse en première lecture.

Ce n’est pas le cas du dernier chapitre qui aborde la problématique des tests. Il le fait à 3 niveaux : tests unitaires, tests d’intégration et tests fonctionnels. Ces 3 niveau s’appuient sur JUnit est sur des helpers fournis par Spring batch. Je ne suis pas convaincu par ce qui est proposé du côté tests fonctionnels, mais les 2 autres niveaux sont OK.

Spring Batch in action est une bonne surprise. Les auteurs ont fait globalement un très bon travail à rendre le propos clair et l’apprentissage progressif. L bouquin reste hélas un gros pavé. Mais le framework est aussi beaucoup plus riche que je ne l’avais pensé au début. Pour en rendre l’abord plus digeste, je pense que les auteurs auraient dû découper la seconde partie en 2 : en traitant d’abord d’un cas d’utilisation simple n’utilisant qu’un sous-ensemble de chacun des 3 types de composants, puis une seconde itération pour les autres cas de figure. Au final, le volume du livre aurait un peu augmenté mais cela aurait permis au lecteur de faire l’impasse sur une centaine de page en première lecture !

Ce livre s’adosse à la version 2.1 de Spring batch, il est donc toujours parfaitement d’actualité, mais une révision sera certainement nécessaire quand la version 3.0 sera en GA.

Spring Batch in Action

Référence complète : Spring Batch in Action – Arnaud Cogoluègnes, Thierry Templier, Gary Gregory & Olivier Bazoud – Manning 2012 – ISBN : 978 1 935182 95 5

Spring Batch in Action


http://www.goodreads.com/book/add_to_books_widget_frame/1935182951?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Spring in Action 3rd édition, par Craig Walls

Note : 6 ; A la fois plus et moins complet que l’édition précédente.

Spring devient de plus en plus important … de plus en plus gros, même s’il se modularise. Je me demandais bien à quelle sauce on allait être mangé cette fois-ci ! L’édition précédente faisait 700 pages, celle-ci en fait … 380 ! En fait, non seulement cette édition se recentre sur les aspects essentiels du frameworks (certains thèmes ne sont donc plus traités), mais les aspects qui le sont toujours ont été revus et en fait la table des matière a changé de manière non anecdotique. Mon conseil : si vous avez la seconde édition, conservez-là !

Dans la première partie, les déclarations XML sont traitées plus légèrement à la faveur des annotations plus largement décrites, ainsi que du langage d’expression. De même la déclaration d’aspects est traité sur plus d’espace.

Ce qui était dans la précédente édition la seconde partie se retrouve désormais sur deux parties (la 2 et la 3). La plus importante différence réside sans doute dans le « client side Spring » qui a complètement disparu.

La première partie « Core Spring » regroupe 4 chapitre et compte 110 pages. Elle reprend les aspects qui ont fait le succès des éditions précédentes : une bonne introduction à ce qu’est Sprint (en y intégrant dès le début les annotation et les aspects) et un chapitre très solide sur le wiring qui inclut les namespaces de Spring et le langage d’expression SpEL. A cela s’ajoute un chapitre tout nouveau sur la prise en charge de l’injection de dépendances par annotations qui complète celui consacré aux aspects. Tout cela est très didactique et très bien épaulé par des exemples assez courts pour être parlants et de bons schémas.

La seconde partie « Spring Application Essentials » est longue de 140 pages en 5 chapitres. C’est le liens aux couches applicatives qui sont traitées ici. D’abord l’accès aux bases de données. Ce chapitre s’enrichit d’une partie consacrée à JPA, mais hélas les autres frameworks (à l’exception d’Hibernate) sont abandonnés ! Regrettable, spécialement pour iBatis / MyBatis. Une lacune que l’on va retrouver dans le chapitre suivant consacré aux transactions qui fait même l’impasse sur les transactions XA ! Les chapitres dédiés à Spring MVC et Spring Webflow sont repris de l’édition précédente et actualisés. Mais ne cherchez pas l’intégration avec JSP, JSF ou Struts : cela a complètement disparu. Il en va de même pour l’intégration EJB (bon, pour EJB2, j’aurais tendance à comprendre…). Enfin le chapitre consacré à la sécurité est toujours là, ni mieux ni moins bien que dans l’édition précédente.

La dernière partie est consacrée à l’intégration. Les exporters qui sont là depuis la version 1.0 peuvent passer pour de vieux trucs, mais ils sont bien pratiques et ils figurent toujours au menu de cette édition sans en réduire la voilure. Ouf ! Ne pas évoquer le support REST eut été une grosse lacune aujourd’hui : un chapitre complet lui est consacré. On retrouve aussi le support JMS, qui traite aussi de l’intégration ActiveMQ et Lingo. Le chapitre consacré à JMX est très court mais fait le boulot. Et finalement, le dernier chapitre regroupe l’intégration des trucs qui ne vont pas ailleurs. : l’externalisation de la configuration (cela aurait eu plus de sens dans la première partie), le wiring via JNDI, EJB (tiens si, finalement on en parle…), l’envoi d’emails et la planification de tâches. Sur ce dernier aspect on ne parle que du Scheduling natif Spring, mais pas de l’intégration Quartz qui est pourtant plus puissant ! Là encore, ne jetez pas votre édition précédente.

C’est vrai, Spring devient de plus en plus volumineux, mais il devient aussi modulaire car tout le monde n’a pas besoin de tout tout le temps. La ligne éditoriale du livre suit ce principe et un ouvrage de près de 700 pages qui aurait été en route pour en faire 900 se trouve réduit à en faire 380. La qualité de la rédaction est toujours là et les adaptations à Spring 3.0 sont réelles sans que cela soit pour autant des changements en profondeur à bien des égards. Le livre a été profondément restructuré au passage, et cela me paraît plus logique et mieux fait ainsi. Il faudra donc aussi compter désormais avec d’autres volumes pour compléter celui-ci : Spring batch in Action, Spring Integration in Action, etc…

Bref, ne vus dépêchez pas de jeter la seconde édition…

spring-inaction-3edt-manning

Référence complète : Spring in Action, 3rd édition – Craig Walls – Manning 2011 – ISBN : 978-1-935182-35-1

Spring in Action

http://www.goodreads.com/book/add_to_books_widget_frame/1935182358?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Modular java, par Craig Walls

Note: 8 ; Vraiment un excellent tutorial, sur OSGi d’abord, puis sur Spring DM ! Bravo !

Craig Walls est déjà l’auteur de l’excellent « Spring in Action ». Je connaissais donc déjà ses talents d’auteur. Il n’a pas failli à sa réputation ici. En fait, je pense qu’il a fait encore mieux ! Le challenge de réussir ce tutorial en 200 pages, se partageant entre OSGi « brut » d’abord, puis ensuite sur Spring DM y est aussi pour beaucoup.

Dès le premier chapitre, on est séduit par la limpidité de la présentation d’OSGi et de l’intérêt d’un approche « composant runtime ». On n’en a que d’avantage l’eau à la bouche pour attaquer la première partie, celle qui présentera le développement OSGi sans Spring, soit 90 pages sur 4 chapitres.

Très intelligemment, le chapitre 2 présente la construction d’un bundle OSGi minimaliste, mais où l’on construit toute la plomberie à la main ! C’est bel et bien la meilleure façon de comprendre cette plomberie. Jouer avec la console OSGi (un outil dont la compréhension est indispensable), est le complément naturel de cette approche. C’est l’occasion d’aborder les différentes implémentations d’OSGi et principalement les deux implémentations open source : Equinox et Apache Felix. L’auteur penche pour Equinox, c’est visible.

Le troisième chapitre peut paraître curieux, car on y découvre peu de choses sur OSGi ! L’auteur nous y présente l’architecture de l’application que nous allons construire, mais surtout il introduit les outils PAX construct, une boit à outil qui va vite s’avérer indispensable pour construire et tester les bundles OSGi.

Les chapitres 4 et 5 abordent enfin la création de différents types de bundles et le développement de services. Au bout du 5ème chapitre, nous sommes devenus opérationnels pour construire des bundles OSGi qui coopèrent ensemble. Toute cette première partie constitue un tutorial remarquable.

La seconde partie va aborder l’utilisation de Spring DM afin de faciliter le développement de bundles OSGi en en masquant la complexité. 3 chapitres et 65 pages suffisent à la tâche. Le chapitre le plus important est d’ailleurs le premier de cette partie (le chapitre 6) car il explique comment la plomberie du bundle est prise en charge par le contexte Spring et l’injection de dépendances inter bundles !

C’est aux « web bundles » que ce se consacre le chapitre 7. Je l’ai trouvé personnellement assez complexe, car il a trait à beaucoup de problématiques de configuration, pour déployer des bundles sur Tomcat et sur Jetty et pour régler des problématiques de listener http et autres… Disons que c’est un mal nécessaire (ou incontournable).

Le chapitre 8 revient au développement et nous présente la création de fragments. Je pense que cela aurait pu être présenté en première partie, mais ça marche aussi ici ! Petit détail, cela ne profitera qu’à ceux qui développent avec Equinox. Dommage pour ceux qui ont choisi Apache Felix !

La dernière partie, constituée de deux chapitres, adresse le passage en production : déploiement, administration, configuration et suivi d’exploitation. Tout cela est remarquablement expliqué en peu de pages.

Ce livre ne vous donnera peut-être pas des informations complètes sur tout ce que vous pourriez savoir sur OSGi et Spring DM, ce n’est pas une bible ! Mais je pense que c’est sa qualité première, il se débarrasse du superflu pour se concentrer sur l’indispensable et nous mettre le pied à l’étrier du développement avec Spring DM. Un tutorial, un vrai. La mission est remplie à 100% ! Je conseille sans réserve ce livre qui fut une bonne surprise.

modular-java-pragprog

Référence complète : Modular java, creating flexible applications with OSGi and Spring – Craig Walls – The Pragmatic Bookshelf 2009 – ISBN: 1-934356-40-9 ; EAN: 978 1934356 40 1

Modular Java: Creating Flexible Applications with Osgi and Spring


http://www.goodreads.com/book/add_to_books_widget_frame/1934356409?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on