Sommaire

Introduction  Urbanisation : les fondamentaux  Cartographier son SI  SOA : Modéliser l'entreprise, pour qui, pourquoi, comment ?  BEA Aqualogic  Sun Java Integration Suite  Oracle Fusion Middleware

Dossier Urbanisation

Cette tribune est le cinquième volet d'une série proposée par la SSII Dreamsoft (groupe SoluCom) autour des architectures orientée services (SOA).

Nos tous premiers articles expliquaient que la SOA était la solution de conception du SI, qui va permettre "d'aligner le SI sur la stratégie de l'entreprise".

Aligner le SI à la stratégie de l'entreprise, dans le passé, a souvent été réalisé par l'introduction de progiciels (ERP, CRM, SCM …) implémentant les fonctions métier de l'entreprise auxquels nous venions rajouter les éléments manquants par des développements spécifiques fortement couplés ou par ajout d'un module complémentaire de l'éditeur de la solution globale, qui se traduit par une adhérence forte entre les modules ou les structures de données manipulées.

Aujourd'hui, dans le contexte d'une SOA, ces solutions logicielles doivent y être intégrées. Les éditeurs nous proposent donc des solutions "SOA-isées" de leurs progiciels.

Parmi tous ces éditeurs "progiciels", celui qui nous semble intéressant est Oracle. Pourquoi ? Tout simplement parce que, par rapport à ses concurrents, il est atypique. En effet, Oracle, éditeur de bases de données relationnelles, s'est lancé dans la fourniture d'infrastructure logicielle J2EE avec son serveur d'application et ce, tout en développant des "APPS" (terminologie de l'éditeur pour ses solutions logicielles).

Être le troisième fournisseur d'infrastructures logicielles ne permet pas à un éditeur d'avoir des parts de marché qui le rendent incontournable - surtout lorsque les deux majeurs ont plus de 75% de parts de marché du domaine commercial et que l'Open Source vient prendre le reste.

Par contre, il est important, dans une approche "APPS", de ne pas être dépendant de solutions d'infrastructure et donc de construire des systèmes applicatifs reposant sur des standards interopérables et d'avoir une infrastructure applicative modulaire, c'est-à-dire avoir la capacité de fournir des briques logicielles indépendantes les unes des autres.

Deux axes se présentent alors : réaliser soi-même la brique logicielle (et/ou applicative), acquérir le spécialiste sur le domaine.

L'approche d'Oracle, en la matière, a été d'acquérir les leaders sur leur marché. Cela s'est traduit par les rachats de Collaxa, Oblix (entre autres dans le monde des infrastructures logicielles) mais également Siebel / PeopleSoft dans le domaine des progiciels.

Par ces acquisitions, aujourd'hui, Oracle a la capacité de fournir des solutions métier verticales qui s'intègrent pleinement dans le SI, car l'infrastructure logicielle sous-jacente répond aux concepts d'implémentation d'une SOA.

Deux ombres à ce tableau idyllique :
  Il n'existe pas de solution, dans l'offre logicielle (décrite ci-dessous) qui permet la modélisation et la simulation de processus métier (lire article sur la modélisation des processus).
  Pour garantir sa SOA, il est nécessaire de mettre en place "un annuaire" permettant l'identification des services, la définition des échanges, la localisation des services, la définition des contrats de services etc… et dans un contexte progicialisé, ouvert et interopérable, cela doit être porté par la solution.

A ce jour, ces ombres s'estompent :
  Oracle et IDS Sheer viennent d'annoncer (en août dernier) un partenariat sur l'intégration de leurs offres, permettant à Oracle de couvrir un pan manquant dans son offre (voir le détail).
  De plus, il est question (dans une version 11.x ou plus de la solution) de mettre en place un "Meta Data Repository" qui couvrira les fonctionnalités d'annuaire en conception et en déploiement. Evolution logique et normale de leur offre.

Par contre, ce qui est l'élément marquant de cette offre, qui de plus devrait rassurer les clients ayant investi massivement sur les APPS Oracle, c'est que les nouvelles versions des APPS seront construites sur l'offre "Fusion Middleware", qui n'est autre que le socle technique et logiciel d'implémentation d'une architecture SOA.

Comme décrit dans la suite, les différentes briques logicielles composant l'offre Fusion Middleware sont issues de rachats, mais possèdent toutes des références opérationnelles en production indépendamment les unes des autres. Reste maintenant à Oracle de démontrer leur intégration, avec toute la flexibilité annoncée, au sein de son offre "Fusion".

Pour comprendre l'offre et bien comprendre son positionnement, il faut la replacer dans le contexte de l'époque : Oracle n'est pas perçu comme le leader sur les serveurs d'application J2EE, et il lui faut démontrer qu'il est malgré tout incontournable. Ce qu'il fait par la fourniture de briques logicielles applicatives ou d'infrastructures viables car construites sur des standards (J2EE, XML, BPEL webService…) et pouvant fonctionner sur n'importe quel serveur d'application.

Le schéma ci-dessous positionne l'offre "Fusion Middleware"


Ce schéma n'est pas très différent de ce déjà vus précédemment. Sa particularité réside dans le fait que le serveur d'applications, bien qu'obligatoire, n'est pas forcément celui de l'éditeur, mais bien toute solution certifiée par ses soins.

  L'Entreprise Service Bus : c'est le petit dernier de l'offre. Il offre toutes les fonctionnalités d'un ESB. Il s'appuie sur les éléments de connectiques existantes dans l'offre aujourd'hui intégrée à BPEL Process Manager. Ce module a vocation à supporter tous les échanges et plus particulièrement les règles de routage définies dans BPEL Process Manager.

Il s'appuiera, à terme, sur un "Service Registry" et un "MetaData Repository" fournis par Oracle. Actuellement il est interopérable avec les annuaires UDDI connus à ce jour.

  Le WebService Manager (issu du rachat de OBLIX) : indépendamment des autres modules de l'offre, il a pour vocation de déterminer et de configurer des opérations sur des services donnés. Ces opérations peuvent être des opérations de sécurité, de monitoring ou de tout autre type, à condition d'agir sur des flux XML.

  Le BPEL Process Manager (issu du rachat de Collaxa) : il a été très longtemps le fer de lance de l'offre Oracle. Moteur d'exécution BPEL, il avait pour vocation la réalisation des processus "métier" en intégration les dimensions humaines et l'intégration de moteur de règles.

Il assurait également les aspects de connectique, de routage et de transformation des messages. Avec l'arrivée de l'ESB, toutes ces fonctionnalités seront transposées dans l'ESB, puisque les modules en charge de ces traitements dans l'ESB sont issus (en partie) du BPEL ProcessManager.

  "Les studios" : chacune des solutions possède sa propre interface de configuration et de développement. Elles doivent toutes s'harmoniser et être intégrées dans JDevelopper, outil mythique de l'offre Oracle.

Les plus et les moins
Points fort	Offre modulaire, conforme aux concepts portés par la SOA.   Elle est la base de la composition de l'offre APPS d'Oracle, donc garantie de pérennité et d'interopérabilité de la part d'Oracle.   Ces offres possèdent individuellement des références opérationnelles.
Point faible	L'intégration de tous les produits n'est pas complète et certaines fonctionnalités sont dédoublées entre les différents produits   Manque d'harmonisation (à court terme) dans les outils de développement et de supervision.
Source :Dreamsoft, 2006

Mariano Boni