OpenESB/Sun Java CAPS 6, quel avenir?

le 25/06/2009 par Karim Ben Othman
Tags: Évènements

La version 6 de la solution ESB de Sun Microsystems, Java CAPS (Composite Application Platform Suite), historiquement connue sous le nom Seebeyond (en référence à la société Seebeyond qui commercialisait cette solution jusqu’en 2005), a fait un bond technologique conséquent par rapport à la version 5.1.3. Même si cette nouvelle version préserve une comptabilité ascendante avec la version 5.1.3 (elle intègre 2 solutions en une : la solution open source OpenESB et Java CAPS 5.1.3) elle marque une rupture technologique par rapport à la précédente version. La principale nouveauté: s’appuyer sur des solutions open source qui ont fait leurs preuves:

  • Glassfish pour le runtime

  • Netbeans comme environnement de développement

  • Derby comme base de données intégrée

  • Java MQ comme solution de messaging JMS

  • Intégration native avec CVS et Subversion

En ce qui concerne les principales spécificités de cette solution:

  • Solution full JEE (Message Driven Beans, Adaptateurs JCA, JAXB, JMS, etc.)

  • Implémentation de la spécification JBI 1.0:

    - Service Engines (SE): BPEL 2.0, XSLT, Intelligent Event Processing, ETL, Scheduler,.)

    - Normalized Message Routers (NMR)

    - Binding Components (BCs) : fichier, JDBC, JMS, Oracle, LDAP, email, HTTP, SOAP, etc.

  • Génération automatique des tests unitaires

  • Différents éditeurs proposés: WSDL, XSD, etc.

Avec le rachat de Sun par Oracle, cette solution, qui jouissait, depuis sa sortie il y a presque un an, d'un avenir certain, risque de subir de plein fouet les conséquences de ce rachat. Oracle ne manque pas de solutions similaires dans son offre actuelle (Oracle Fusion middleware, Oracle Service Bus, Oracle Weblogic Integration, Oracle BPEL Process Manager, etc.) et nul ne sait quelle stratégie pourrait entreprendre Oracle par rapport aux solutions de Sun.

En cette phase transitoire, nous préconisons à tous ceux qui ont entamé des travaux sur cette solution de:

  • Se focaliser plutôt sur les problématiques d’architecture d’intégration que sur l'outil.

  • S’appuyer au maximum sur les standards (runtime, environnement de développement, connectivité, composants de transformation, etc.)

  • Eviter les projets critiques

  • Procéder par itération pour la mise en œuvre.

Cela dit, en dépit de ces incertitudes, je reste confiant par rapport à la survie de cette solution. C'est l'occasion ou jamais pour qu’Oracle tend la main au monde de l’open source. La question qui subsiste malgré tout, comment sera positionnée cette solution dans la jungle logicielle d’Oracle?