Certified Spring Enterprise Integration Specialist Study Notes

En l’espace de 8 mois, me voici doté d’une deuxième certification Spring. Après la certification Spring Core dont je vous ai fait écho dans mon tout premier billet, j’ai eu l’opportunité de préparer la certification Spring Integration Specialist.

Comme à l’accoutumée avec les certifications Spring, la formation officielle Spring Enterprise Integration est pré-requise. Elaborée par SpringSource et dispensée par Zenika, cette formation couvre de nombreux sujets basés sur Spring Framework 3 et différents projets du Portfolio Spring :

  • Multi-Threading et Scheduling
  • Spring Remoting
  • Spring Web Service 2.0 (Security en annexe)
  • REST avec Spring MVC
  • Spring JMS
  • Transactions locales et distribuées (JTA et XA)
  • Spring Batch 2.1
  • Spring Integration 2.0

A la fin de ces 4 jours, je suis reparti avec le livre Spring Batch in Action (généreusement offert par notre formateur Arnaud, co-auteur du livre) et quelques devoirs.

Pour me préparer, à l’instar du Jeanne Boyarsky’s Spring 3.X Certification Study Notes, j’ai rédigé quelques fiches de révisions, bien plus pratiques à transporter que le livret reçu en formation. Aujourd’hui, je vous propose de vous en faire profiter.

Présentation des fiches de révision

Ces fiches reprennent une à une toutes les questions abordées dans l’Enterprise Integration with Spring 1.x Certification Study Guide  mis à disposition par SpringSource.  J’ai essayé d’y répondre en m’appuyant sur le support de formation, les différents manuels de référence et le code source.

Au regard de la formation, lorsqu’il m’a semblé que des points importants n’avaient pas été abordés, j’ai ajouté des questions/réponses repérables par leur police en italique.
Vous trouverez ces fiches sous 2 formes :

Remoting

Généralités

Les concepts proposés par Spring Remoting, côté serveur comme client 

 

Remoting => appel synchrone de méthodes distantes 

Côté serveur : concept d’Exporter permettant d’exposer à distance un bean Spring (POJO).

Côté client : un ProxyFactoryBean chargé de créer dynamiquement un proxy masquant les appels distants et gérant la plomberie technique (connexion, exceptions …)

Les bénéfices de Spring Remoting par rapport aux techniques traditionnelles d’appel de méthodes distantes
  1. Faible couplage avec la technologie d’accès à distance : les exceptions vérifiées sont encapsulées par Spring,
  2. Il n’est plus nécessaire d’étendre d’interfaces techniques (ex : Remote),
  3. Les services métiers peuvent directement être exposés sans modification du code,
  4. Spring s’occupe de l’enregistrement dans le registre (RMI) ou l’exposition du service en tant qu’endpoint (http).
  5. Aucun couplage avec la technologie de remoting utilisée.
  6. Changement de protocole possible par simple changement de configuration
 Les protocoles de Remoting supportés par Spring
  • RMI(-IIOP)
  • HTTPInvoker : protocole d’échange propriétaire à Spring permettant de sérialiser des objets java sur HTTP
  • Hessian : protocole binaire basé sur HTTP conçu par Caucho
  • Burlap : alternative XML à Hessian)
  • JAX-RPC : remplacé par JAX-RS depuis Java EE 5 / Java 6
  • EJB sans état

RMI-based Spring Remoting

En quoi le remoting RMI avec Spring est moins invasif que le RMI natif ? Côté serveur : 

  • Exposition de services POJO (RmiServiceExporter)
  • Les interfaces des services exposés n’ont plus à étendre java.rmi.Remote
  • le binding dans le registre RMI est effectué automatiquement par Spring

Côté client :

  • Spring convertit les exceptions vérifiées java.rmi.RemoteException en exceptions non vérifiées (runtime) de type RemoteAccessException
  • Plus besoin de stub RMI : Spring génère dynamiquement le proxy (RmiProxyFactoryBean).

Attention : les classes échangées doivent toujours implémenter l’interface Serializable

Spring HTTP Invoker

Comment le client et le serveur interagisse l’un avec l’autre ? Protocole propriétaire utilisant la sérialisation Java pour les paramètres en entrée et en sortie. 

L’invocation de méthodes est réalisée à l’aide d’un POST HTTP.

Utilisation au choix de l’API du JDK ou d’Apache Commons HttpClient.

Comment exposer un service en HTTP ?
  1. Déclarer le bean spring du service à exposer
  2. Exporter le bean en utilisant le HttpInvokerServiceExporter
    <bean name="/monservice" class="o.s.r.h. HttpInvokerServiceExporter …/>
  3. Utiliser la DispatcherServlet de Spring MVC ou déclarer dans le web.x