insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 2 mai 2010

Spring Batch au Spring User Group

Mercredi dernier s’est tenue la deuxième réunion du Spring User Group France. A cette occasion, Julien JAKUBOWSKI et Olivier BAZOUD nous ont présenté Spring Batch.

Les slides de cette très bonne introduction sont disponibles ici.

Pour ma part, voici ce que je retiens de cette présentation :

Qu’entend t-on lorsque l’on parle de batch ?


On parle ici de “Batch processing”, dont la traduction française est “Traitement par lot”.
Il s’agit d’un enchaînement automatique de commandes ne nécessitant pas l’intervention d’un opérateur. Ces traitements peuvent réaliser des opérations métier sur de gros volumes de données.
Un exemple courant de batch est l’import d’un référentiel de données XML dans une base de données relationnelle.

L’accent a été porté par les intervenants sur le fait qu’il ne faut pas confondre batch avec scheduler. En effet, un scheduler (Cron, Quartz) n’est qu’un outil permettant de lancer un batch.

Les frameworks disponibles pour la réalisation de batchs ?

La réalisation d’applications WEB ou encore la gestion de la persistance en Java sont des tâches couvertes par de nombreux frameworks.
Par contre, lorsque l’on s’attaque à la réalisation d’un batch, on peut parfois se sentir démuni de tout outil, pourtant Spring Batch est là.
Bien entendu, il ne répond pas forcément à tous les cas d’utilisation mais en faire un petit tour d’horizon peut aider à prendre une décision la prochaine fois que la réalisation d’un batch s’impose.

A quoi ressemble un batch classique ?

Les batchs réalisés sans outils spécifiques présentent habituellement un certain nombre de problèmes.
Ils consistent souvent en un bloc monolithique de code, ils sont de ce fait difficilement maintenables.
La réutilisation de code d’un batch à l’autre n’est pas une tâche aisée et l’on est souvent amené à réinventer la roue pour réaliser des fonctionnalités très semblables (lecture d’un fichier XML, écriture dans une base de données, ...).
Il est nécessaire de connaître la volumétrie avant le développement, de manière à découper en lots appropriés les traitements.
Il est difficile de faire évoluer un batch qui était initialement prévu pour traiter un fichier de 10ko pour qu’il traite à l’avenir des fichiers de 100mo.
La gestion des transactions et des rejets est laissée à la charge du développeur.

Quelle est la réponse de Spring Batch ?

Spring Batch répond de manière plutôt efficace à ces différentes problématiques, il propose un cadre de développement et de conception.
Il instaure un vocabulaire commun d’un batch à l’autre.
Il permet de répartir les traitements par lots et cela sur de gros volumes sans que les développements spécifiques ne soient impactés.
Ce framework intègre la gestion des transactions et un processus de commit régulier.
Bien entendu, l’intégration de Spring dans le batch est native. Au-delà de ces différents aspects de base, Spring Batch propose des fonctionnalités “avancées” permettant de répondre à des besoins plus spécifiques parmi lesquels :
  • Le partitionnement
  • Le parallélisme
  • La reprise sur erreur

Comment s’organise un batch Spring Batch ?

Dans la terminologie Spring Batch, un batch est un Job, ce dernier peut être constitué de plusieurs étapes : Step.

Une étape met en oeuvre un ItemReader, un ItemWriter et peut également faire appel à un ItemProcessor.
Ces trois éléments sont des interfaces, voici la vocation de chacune : 

ItemReader : Comme son nom l’indique, cette interface est chargée de lire un item à traiter dans une étape. Il en existe un bon nombre d’implémentations, telles que la lecture de fichier plat, la lecture en base via JDBC, Hibernate, ... 

ItemProcessor : Il peut être utilisé pour réaliser des transformations, validations ou encore filtrages sur les éléments traités dans l’étape. Il transforme un élément et en retourne un autre, c’est le bon endroit pour indiquer des règles métier. 

ItemWriter : Encore une fois, il porte plutôt bien son nom, l’ItemWriter va se charger d’écrire les éléments de sortie. Comme pour l’ItemReader, diverses implémentations sont fournies. 

Le traitement des données dans une Step s’effectue par lots (Chunk) successifs. La gestion d’un lot s’effectue de la manière suivante : n items d’entrée sont lus successivement puis transformés en vue d’être écrits. 

La taille des lots est définie par le commit-interval. Lorsque le nombre d’items lus atteint cette limite, les items sont écrits par l’ItemWritter et la transaction est “commitée”. 


Dans la documentation Spring Batch, le schéma ci-dessus est représenté de la manière suivante en code :


List items = new Arraylist();
for(int i = 0; i < commitInterval; i++){
items.add(itemReader.read());
}
itemWriter.write(items);
Pour une Step donnée, il est possible de définir des listeners à l’écoute des différents évènements de celle-ci. Ainsi, combiné à un writer, un listener peut permettre de renseigner un fichier de rejet. 

Il est possible d’éxécuter un batch en ligne de commande et de lui passer ses paramètres en utilisant le CommandLineJobRunner.


Les tests :

Du fait du cadre proposé par Spring Batch, l’écriture de tests unitaires est relativement aisée. Il est ainsi possible de tester unitairement les différents composants de votre réalisation intervenant dans l'exécution du batch (itemReaders, itemProcessors, ...).

De même, il est tout à fait possible d’écrire des tests d’intégration.

Retour d’expérience des intervenants :

Olivier Bazoud nous a présenté son constat vis à vis de l’utilisation de Spring Batch en entreprise.
Il a mis l’accent sur le fait qu’il y avait moins de code à écrire, cet élément couplé au fait que les batch réalisés avec Spring Batch sont fortement testables, les erreurs possibles sont moindres.
Un point important est le fait qu’il est plus facile à deux développeurs de batchs de communiquer grâce au vocabulaire porté par Spring Batch.
La délégation de la gestion des transactions à Spring Batch est un point appréciable.
Sur le plan concret les chiffres suivants ont été évoqués :
  • 15% à 50% de gain sur le temps de développement
  • 15% à 50% de gain sur le temps d'exécution des batchs

Conclusion :

Spring Batch est un outil fiable et qui présente de bon patterns, il présente l’avantage de faciliter la testabilité et la maintenabilité des batchs réalisés ce qui n’est pas toujours une tâche évidente lorsque l’on réalise un batch sans outil spécifique.
De nombreuses fonctionnalités avancées sont intégrées à l’outil et peuvent être mises en place à moindre coût.
Bien que la productivité soit meilleure à termes, il faut toutefois être conscient que le coût initial est important.

Les intervenants ont évoqué la possibilité d’intervenir une prochaine fois sur les notions plus avancées de Spring Batch telles que le partitionning, le parallélisme, le remoting, la reprise sur erreur ou encore Spring Batch Admin

Liens :
La présentation
Le code qui a servi de support à la présentation
Documentation officielle Spring Batch
Le Spring User Group

La prochaine session du Spring User Group est prévue le 10 juin sur les styles d’injections de dépendances de Spring. Cette session sera animée par Chris Beams (ingénieur Spring Source).

lundi 9 novembre 2009

Les rencontres spring 2009, Spring 3 par Arjen Poutsma

Signes distinctifs

Java 5

La première information qui saute aux yeux c'est que Spring 3 est complétement écrit en Java 5, ce qui d'emblée signifie qu'un projet utilisant Spring 3 est nécessairement compatible Java 5. ça peut paraitre brutal mais il faut savoir que depuis le 30 Octobre dernier, Java 5 n'est plus supporté par sun lire ceci.
pour illustrer ce changement voici un exemple qui met l'accent sur l'utilisation massive de Java 5 :

T getBean(String name, Class<T> requiredType)
la BeanFactory, et qui représente de loin une brique assez importante dans Spring, est elle même -Généric complient-

plus besoin d'XML, ou presque

l'autre nouveauté apportée par Spring 3, c'est la possibilité de configurer la bean factory sans le moindre XML ! cependant, Spring 3 reste totalement rétro compatible avec les version précédentes.

Utilisation de l'annotation @Configuration :
Configuration
public class ApplicationConfig {
}

la classe ApplicationConfig sera donc responsable de l'instanciation des Beans, pour déclarer un Bean, rien de plus simple :
@Configuration
public class AppConfig {
@Bean
public TransferService transferService() {
return new TransferServiceImpl();
}
}

Cette approche permet d'une part de donner au développeur le moyen de contrôler du code spécifique avant de rendre le Bean, d'autre part ça permet au code de l'application d rester totalement indépendant de la plateforme. L'autre façon est par l'utilisation des Meta Annotation

Restructuration du repository du code

l'organisation des modules de Spring 3 a été complétement revue, désormais le code source de chaque module est maintenu séparément.
Plus d'information sur le site de Spring. <<LINK>>

Spring Expression Language

Spring EL et qui s'apparente à Unified EL, propose des possibilités de simplification très puissantes et notamment lors de la définition des Beans dans une XML ou par annotations.
voici un exemple illustrant les possibilités qu'offre Spring EL :
<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName" value="#{systemProperties.databaseName}"/>
    <property name="keyGenerator" value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

dans cet exemple, l'attribut databaseName et keyGenerator font référence à deux Beans précédemment initialisés dans le contexte.
le même comportement est facilement reproductible par l'utilisation des annotations selon l'exemple suivant :

@Repository
public class RewardsTestDatabase {
@Value("#{systemProperties.databaseName}")
public void setDatabaseName(String dbName) {
}
@Value("#{strategyBean.databaseKeyGenerator}")
public voidsetKeyGenerator(KeyGenerator kg) {
}
}
La résolution des @Value se fait automatiquement et dynamiquement par Spring au Runtime, ce qui offre une nouvelle possibilité pour les développeurs qui la prise en compte à chaud par Spring 3 d'un changement effectué dans les fichiers de configurations .properties.

Web

Spring MVC

Pas de nouveauté concernant le volé Spring MVC depuis la version 2.5 de Spring, qui a introduit l'utilisation des Annotations pour construire des Contrôleurs MVC dans une applicaiton, ce que Spring 3 ajoute -ou supprime- c'est la déprécation de "SimpleFormController" dans le but de faire orienté les nouveaux développements vers l'utilisation "systématique" des annotations pour les contrôleurs Spring.

Amélioration du support REST

Le support de REST a été amélioré dans cette version de Spring 3. REST est devenu en quelques années le standard de facto pour quiconque souhaite mettre en place une architecture orientée service par l'utilisation de Web Service, cependant REST est beacoup plus que ça. Le modèle de développement REST est assez simple et passe par l'utilisation intensive des Annotations. Un aspect non négligeable que REST permet d'atteindre est la normalisation des URI, je m'explique, pour faire passer des valeurs à travers une URL standard en GET le moyen le plus simple est de faire comme ci-dessous :
http://www.application.com?VARIABLE=VALUE,....
le problème qui se pose est qu'un certain nombre de proxy refuserons ce genre d'URL. le format des URI REST sont de pure URL qui respecte le standard HTTP.
pour pouvoir utiliser REST avec Spring 3, rien de plus simple :

URI Templates
@RequestMapping("/hotels/{hotelId}")
public String getHotel(@PathVariable String hotelId, Model model)
List hotels = hotelService.getHotels();
model.addAttribute("hotels", hotels);
return "hotels";
}
Quand une requête arrive à "/hotels/1", le serveur repondera par le renvoi de la chaine "hotels", noté cependant que {hotelId} dans "@RequestMapping" au début de la classe est repris dans la déclaration de la méthode "getHotel" par l'utilisation de l'annotation "@PathVariable".

D'autres possibilités sont offertes et notamment avoir plusieurs variables sur le même path ce qui permet de faire des filtres assez affinés :

@RequestMapping(value="/hotels/{hotel}/bookings/{booking}", method=RequestMethod.GET)
public String getBooking(@PathVariable("hotel") long hotelId, @PathVariable("booking") long bookingId, Model model) {
Hotel hotel = hotelService.getHotel(hotelId);
Booking booking = hotel.getBooking(bookingId);
model.addAttribute("booking", booking);
return "booking";
}
Je vous conseil vivement d'aller sur le blog de Arjen Poutsma qui vous donnera de plus amples informations.

View

Spring-MVC permet au @Controller de décider quelle vue rendre pour une requête donnée, via ViewResolver. Dans un scénario RESTful, c'est le client qui décide du rôle de la représentation acceptable (XML, HTML, JSON), en passant par l'en-tête HTTP-Accept. Le serveur répond avec la représentation livrés via l'entête Content-Type. Ce processus est connu comme la négociation de contenu.

Spring Integration

Spring Integration est un framework léger d'intégration à l'image de Apache Camel ou Mule, il permet par exemple l'échange de données entre applications Spring se trouvant dans plusieurs instances JVM à travers un canal de communication. Pas de bouleversement concernant Spring Integration pour la version 3 de Spring à part le fait d'une meilleure prise charge ,un modèle simplifié d'utilisation et un découplage Framework-application amélioré.

Support de JEE 6

Une prise en compte du support de la très prochaine version JEE 6 annoncée pour la mi Décembre 2009 existe déjà dans Spring 3 et notamment le support de la JSR 330. La version Spring 3.1 aura pour mission la prise en compte totale de JEE 6.

Depricated & Pruned

Plusieurs packages et Classes font désormais partie du grand nettoyage du printemps engagé par les équipes de Spring et cela dans le but d'avoir du code encore plus facilement "maintenable", évolutif et moins complexe. Je vous invite vivement de jeté un coup d'œil dans la documentation de Spring pour prendre en compte les changements dans vos projets respectifs.

Téléchargements

Voici comment vous devez faire si vous voulez utiliser Spring 3 RC1. Je pars de l'hypothèse que vous utilisez maven pour le build de vos projets.
Pour commencer ajouter les URL des différents repository des Bundles dans votre settings.xml :

  <repository>
<id>com.springsource.repository.bundles.snapshot</id>
<name> SpringSource Enterprise Bundle Repository – SpringSource Bundle Snapshots </name>
<url>http://repository.springsource.com/maven/bundles/snapshot </url>
</repository>
<repository>
<id>com.springsource.repository.bundles.milestone </id>
<name> SpringSource Enterprise Bundle Repository – SpringSource Bundle Milestones </name>
<url> http://repository.springsource.com/maven/bundles/milestone </url>
</repository>
<repository>
<id>com.springsource.repository.bundles.release </id>
<name> SpringSource Enterprise Bundle Repository – SpringSource Bundle Releases </name>
<url> http://repository.springsource.com/maven/bundles/release </url>
</repository>
<repository>
<id>com.springsource.repository.bundles.external </id>
<name> SpringSource Enterprise Bundle Repository – External Bundle Releases </name>
<url> http://repository.springsource.com/maven/bundles/external </url>
</repository>
et puis ajouter les dépendances des modules que vous voulez utilisé, il faudra prendre en compte le changement des noms des différents ArtifacId qui désormais suivent tous le format suivant :

<dependency>   <groupId>org.springframework</groupId>   <artifactId>org.springframework.core</artifactId>   <version>3.0.0.BUILD-SNAPSHOT</version></dependency>

la version actuelle est 3.0.0.BUILD-SNAPSHOT.

Veuillez noté que l'artifact spring tout court n'existe plus.

Ressources

Arjen poutsma REST in Spring 3 post
Arjen Poutsma Blog
Juregen Hoeller Annotated Web MVC in Spring 2.5 post
Juergen Hoeller Blog
Spring Integration
Slim Tebourbi sur insideit.fr autour de Spring Expression Language
Spring JavaConfig Reference Guide
Rod Johnson lors de la SpringOne/2GX 2009
Les rencontres Spring 2009, ROO par Bruno Guedes
Les rencontres Spring 2009, Keynote par Adrian Colyer

mercredi 4 novembre 2009

Spring Expression Language, a simple use case.

Waiting for the release of Spring3, I have taken a look at the source code. There was an eternity that I didn’t that. My first insights where focused on the Expression Language (SpEL). When I discovered the @Value(“systemProperties[‘myProperty’]”) feature, I didn’t understand why it wasn’t more generally implemented to cover all spring managed properties, those for which we used the PropertyPlaceHolderConfigurer. So I decided to make it.

It is a BeanFactoryPostProcessor that extends the PropertiesLoaderSupport, the same base class as the PropertyPlaceHolderConfigurer utility class. This post processor registers a bean that merges the declared properties and is exposed to the context of the SpEL which is simply the running container.

Given that properties can be accessed simply like this:

@Value("#{properties['property']")
private String property;

where “properties” is simply the name of the registered bean and “property” is the name of the desired property. Note that the setter can be omitted in order to make the property immutable.

Besides, this gives me the possibility to use the EL feature to declare the locations of the properties files, to have another solution to resolve the “Complexity at the structural and dynamic level” (see this post : http://blog.springsource.com/2007/06/25/code-samples-from-springone-beyond-the-obvious-talk/).

For example I can define my files locations like this :

<bean id="spelPropertiesExposer" class="example.spring3.spel.PropertiesSpelExposer">
    <property name="locationPatterns" value="configuration/%{#environment ?:'dev'}/env.properties"/>
</bean>

Where “environment” is a system property which represents the application’s environment such as dev, staging or prod. In the example, if the property is undefined, the default value ‘dev’ is used.

You can find the entire source code here on gitHub. And if you want to simply see the BeanPostProcessor go directly here.

mardi 7 avril 2009

Spring javaConfig, spring en 100% @Orienté Objet

Né des critiques à propos des problèmes liés aux fichiers de configuration XML définissant les contextes du conteneur, Spring Java Configuration ou JavaConfig était destiné à être une alternative qui permettrait de s’en affranchir en présentant  une solution basée sur les annotations dont le succès n’a cessé de percer depuis leur apparition dans la version 5 de Java.

Ainsi, avec JavaConfig les contextes Spring ne sont autres que des classes java (qui toutefois, ne sont pas de simples Pojos) ; ce qui devrait naturellement pallier à certaines contraintes classiquement associées à l’ancien modèle de configuration telles la verbosité, le typage faible ou le refactoring, et qui ont été, d’ailleurs, en grande partie résolus par Spring IDE ; mais surtout, à mon avis, de changer la manière avec laquelle on perçoit cette notion de configuration et sa gestion. C’est que l’intérêt du passage de XML à java est beaucoup plus important si on considère le passage au monde de l’orienté object, qui est de nos jours le paradigme le plus évolué et le plus mature.

En effet, cela permet de bénéficier de la puissance des concepts de l’orienté objet (abstraction, encapsulation, polymorphisme, découplage) et incitera à appliquer les principes de conception qui font leur succès tels que la SOC (separation of concerns), la hiérarchisation ou encore la « ré-utilisabilité », et qui, même s'ils étaient en partie d’actualité avec les fameux fichiers XML, n’étaient pas toujours évidents à mettre an place.

De ce fait, l’avènement de JavaConfig fera naître des patterns de configuration évolués, chose qui n’a pu être vraiment établi en quelques années de configuration XML. C’est que les possibilités offertes donnent beaucoup de flexibilité et de choix pour résoudre cette problématique de configuration.

Outre les possibilités offertes par la configuration XML et reprises par JavaConfig tel que l’aggrégation simple de contextes :

 

@Configuration

@Import({ContextA.class,ContextB.class})

public class AggregatedApplicationContexts {

 

    //...

}

 

 Qui peut même inclure des fichiers configurations xml :

 

@Configuration

@Import({ContextA.class,ContextB.class})

@ImportXml(locations="context.xml")

public class MixedApplicationContexts {

 

    //...

}

 

Et là, il faut noter que les configurations faites avec Javaconfig sont entièrement compatibles avec celles en XML et que l’association donc la ré-utilisabilité des anciens contextes est garantie; ce qui permet d’une part, l’intégration de JavaConfig dans des applications utilisant déjà la configuration XML ; et d’autre part, de fournir une solution de plus, qui coexiste avec les précédentes et donc de donner à l’utilisateur la liberté de choisir la possibilité la plus adéquate selon le besoin et les contraintes imposées par le contexte.

 

On pourrait aussi, faire hériter des contextes comme de simples classes.

 

@Configuration

public class ContextB extends ContextA{

 

    @Override

    protected @Bean Component bean() {

        //...

      bean = super.bean();

      bean.setXXX(XXX);

      //...    

    }

}

 

Et là, ce qui diffère par rapport à la configuration XML, c’est qu’on bénéficie de mécanismes de surcharge plus évolués que ceux proposés par cette dernière et qui permettent d’une part d’étendre cette action sur des beans invisibles depuis des contextes extérieurs (protected ou package) ; et d’autre part de réutiliser en partie la définition à surcharger. Ce qui amène aussi à noter un autre point fort de cette méthode de configuration : la définition dynamique des beans, un peu comme avec les langages de scripts dynamiques tel que Beanshell ou Groovy (<lang /> dans xml) mais sans être obligé d’ajouter de telles librairies.  

 

Une autre fonctionnalité, qui pourrait être très utile, est la capacité de gérer les contextes Spring comme étant eux-mêmes des beans ordinaires. Ainsi ils bénéficient de toutes les facilités du conteneur dont l’injection, soit pour recevoir des dépendances depuis d’autres contextes :

 

@Configuration

@AnnotationDrivenConfig

public class Context{

    @Autowired

    private ComponentA componentA;

    @Bean

    public ComponentB component(){

          ComponentB component = new ComponentB();

          component.setComponentA(componentA);

          return component;

    }

    public void setComponentA(ComponentA componentA) {

          this.componentA = componentA;

    }    

}

 

 

soit pour être eux-mêmes injectés comme tels.

 

@Configuration

@AnnotationDrivenConfig

public class Context{

    @Autowired

    private ComponentsContextA componentsContextA;

   

    @Bean

    public ComponentB component(){

          ComponentB component = new ComponentB();

          component.setComponentA(componentsContextA.componentA());

          return component;

    }

    public void setComponentsContextA(ComponentsContextA componentsContextA) {

          this.componentsContextA = componentsContextA;

    }    

}

 

Enfin, et pour s’en tenir qu’à cela, je dirais que même si cela a pris longtemps pour sortir de l’ombre et bénéficier d’un peu plus d’attention en étant intégré dans l’arborescence principale de la nouvelle release de Spring (la version 3), JavaConfig aura un impact réel et important dans l’univers de Spring et sûrement changera la manière d’utiliser ce framework.

samedi 22 novembre 2008

Changement dans le marché des serveurs d'application par Peter Cooper-Ellis

Plus tôt dans le mois eurent lieu les Rencontres Spring. Durant cet événement, Peter Cooper-Ellis, qui pour rappel est VP de SpringSource depuis juin 2008 après 10 ans chez BEA, nous a fait le plaisir de partager sa vision de l'état du marché des serveurs d'application. En résumé, la demande est à la simplicité et à la flexibilité, d'où l'offre SpringSource dm Server.
Dans l'article "Changes in the Application Server Market" qu'il vient de publier sur JavaLobby et que je vous recommande vivement, il précise la raison d'être de ce nouveau produit SpringSource en retracant l'historique des serveurs d'application.

Bonne lecture et bon weekend.

jeudi 13 novembre 2008

les Rencontres Spring 2008

Aujourd'hui, salle comble pour la première édition des Rencontres Spring. Cet événement co-organisé par SpringSource France et Sfeir marque le partenariat entre les deux entreprises. Pour rappel, Sfeir est un "System Integrator Partner" de SpringSource.

Durant cet événement, des acteurs majeurs de la communauté Spring :

  • Peter Cooper-Ellis, VP de SpringSource depuis juin 2008 après 10 ans chez BEA ;
  • Juergen Hoeller, co-fondateur du framework Spring (avec Rod Johnson) et aujourd'hui principal développeur du framework ;
  • Mark Thomas, principal contributeur au projet Apache Tomcat ;
  • Guillaume Laforge, co-fondateur du défunt G2One et désormais lead des développements Groovy et Grails chez SpringSource ;
  • Julien Dubois, directeur régional France de SpringSource ;
  • Didier Girard, directeur de l'innovation de Sfeir.

et des utilisateurs de la technologie :

  • Voyages SNCF Technologies ;
  • HSBC ;
  • SG CIB ;
  • Improve ;
  • Grails.

ont respectivement annoncé les nouveautés que nous réserve SpringSource pour l'année à venir et témoigné de la puissance de l'offre de SpringSource.

Des témoignages, je retiens que les technologies Spring respectent leurs engagements. Elles simplifient le développement, réduisent les coûts et assurent de bonnes performances :

  • le site www.voyages-sncf.com supporte très bien la charge avec une infrastructure minime ;
  • réduction de 60% du code écrit chez HSBC grâce à un framework "maison" reposant sur Spring ;
  • temps de réponse de l'ordre des millisecondes garantis chez la SG CIB.

Beaucoup de nouveautés nous attendent, entre-autres :

  • évolution de SpringSource dm Server ;
  • Spring 3.0 ;
  • intégration de Flex dans Spring Web ;
  • intégration de Groovy et Grails dans la stack Spring ?

Voici les nouveautés marquantes de la version 3.0 du framework Spring :

  • évolution du modèle de description par annotation ;
  • support de Spring Expression Language pour la configuration des beans ;
  • le support de REST dans Spring MVC ;
  • ajout d'un modèle de validation basé sur les annotations (respectant la JSR 303 et le modèle de validation d'Hibernate).

Concernant les aides au déploiement, SpringSource mise sur son dm Server. Ce serveur d'application Java est basé sur OSGi et a été pensé pour offrir une grande modularité. Cette modularité permet une meilleur gestion des ressources. Cela résulte en un serveur avec une trace légère donc au démarrage rapide, ce qui est très apprécié par les développeurs. Grâce à l'approche OSGi, SpringSource dm Server offre également la flexibilité pour la gestion des applications en permettant le chargement à chaud et le multi-versioning.
Peter Cooper-Ellis, fort d'une longue expérience dans le développement de BEA WebLogic, annonce une évolution sur le marché des serveurs d'applications. La demande est à l'agilité.

Photos de l'événement sur flickr.
Bientôt : Les slides et les vidéos de l'événement.