Architecture

Oracle SOA Suite – Vision terrain, Modèle de Maturité SOA et outillage

Publié le : Auteur: Emmanuel Lesne Laisser un commentaire
SOA MM n4

Cet article est le 2nd de la série sur SOA Suite. Après avoir présenté les principes de l’architecture Oracle, je vous propose de confronter la réalité du terrain avec la théorie du modèle de maturité SOA et des techniques spécialisées dans les architectures SOA.

Premièrement, les applications SOA ont la nécessité de respecter les standards d’interconnexion regroupés principalement dans WS-*. Bien que les services REST se répandent progressivement, je n’aborderai pas cette variante. Il suffit de regrouper quelques retours d’expériences pour se rendre à l’évidence: seuls les standards basiques de WS-* sont mis en œuvre. Malheureusement, les choix d’implémentation sont autant dictés par la complexité fonctionnelle que par la non maitrise des outils et des plateformes par les architectes logiciels et les développeurs.

Dans les faits, on retrouve une complexité de mise en œuvre calqué sur le niveau de maturité de maîtrise de l’architecture SOA. Ce qui peut sembler étonnant car peu de personnes s’y réfère. La pyramide du MM vision AmberPoint et Systinet est une vision simple que j’apprécie:

Je vous propose donc de parcourir ces différents niveaux en faisant un petit parallèle avec la réalité du terrain et ce que propose un outil spécialisé comme SOA Suite.

Au niveau 1, on retrouve dans la pratique les standards suivants :

  • la description WSDL des opérations
  • le protocole SOAP
  • le respect de l’interopérabilité (WS-I)

L’implémentation des services de ce niveau est une extension de plateformes logicielles existantes. Il s’agit en fait de proposer une interface (liste d’opérations) à distance. Pour répondre à cela, les techniques Java couramment utilisées sont:

  • Les annotations WebServices sur EJB
  • L’utilisation de frameworks spécialisés comme Axis
  • L’ajout de module Spring

La majorité des traitements applicatifs sont développés avec ces techniques.

Quand à Oracle, il propose 2 produits pour ce niveau: WebLogic et JDeveloper.

 

 

Au niveau 2, on parle d’ « architecture ». Mais il s’agit encore trop souvent d’une architecture logicielle et spécifique à un projet ou une application. Il est rare de rencontrer une architecture de Système d’Information comme référencée dans le MM.

Les implémentations sont à ce niveau plus délicate. Il ne s’agit plus de proposer des services mais de les consommer, les coordonner, les agréger ensemble. Les sources d’informations (fichiers, bases de données, etc.) et les protocoles augmentent (JDBC, SOAP, REST, JMS, etc). Pour faciliter l’intégration, un ESB « opportuniste » est souvent utilisé. Les produits fuseESB et muleESB sont idéaux pour cela. Par contre la coordination et l’agrégation mais surtout les processus applicatifs sont codées en Java ou dans l’ESB. Enfin la gestion des versions des services est balbutiante et finalement souvent repoussée puis abandonnée.

En fait, sans une vraie vision d’urbanisme, cette architecture ne porte pas d’objectif de niveau Entreprise et n’arrive pas à atteindre un niveau satisfaisant.

Pou cela, les standards suivant doivent être mis en oeuvre:

  • la gestion de la sécurité (WS-Security et SAML)
  • l’asynchronisme des appels (WS-Addressing et WS-ReliableMessaging)
  • la manipulation des messages (XQuery et XPath)
  • les envois de contenus joints (MTOM)

Dans la définition du SOA Maturity model, la mise en œuvre de WS-BPEL est identifié dans la niveau 3 mais je me rapproche de la vision de Franck dans son article sur BPEL et BPMN. Je le paraphraserai donc en reprenant sa définition sur BPEL: « BPEL est un langage d’exécution destiné à automatiser et implémenter des processus applicatifs. ». L’outillage BPEL est pour moi nécessaire dès le niveau 2. La coordination de services est une nécessité technique qui arrive tôt dans les implémentations alors que les processus métier sont tout une autre problématique.

Si l’on croise les techniques et les solutions Oracle, le schéma ci-dessous identifie donc BPEL Process Manager et ses connecteurs (Adapters). Ce moteur est en plus combiné à un moteur de règles et un moteur de workflow. Il possède donc toutes les fonctionnalités pour proposer un socle applicatif SOA complet.

 

 

Au niveau 3, l’objectif 1er est un retour sur investissement au niveau Système d’Information du point de vue fonctionnel. La vision des urbanistes rentre pleinement en compte. Ils permettent d’aboutir à une qualité importante des services grâce à :

  1. la définition d’une organisation fonctionnelle cohérente
  2. la définition des processus et des services sous-jacents
  3. l’identification des services à fortes valeurs ajoutées.

Ici peu de place à la technique pour garantir que la cible est atteinte. Une fois que le cadre fonctionnel est posé, les outils SOA entrent en jeu, permettent d’accélérer puis de faciliter leur développement et leur gestion. Par expérience, seuls ces pré-requis de leadership identifiés dans la conduite de la vision fonctionnelle de l’architecture SOA permettent de rentrer dans ce niveau 3.

Le 1er facteur de réussite dans la gestion des services est de les virtualiser grâce à un ESB de niveau entreprise (partagé entre plusieurs applications). Ce facilitateur permet aux applications existantes de s’interconnecter facilement et sans modification au travers de ces fonctionnalités majeures:

  1. la médiation protocolaire
  2. la capacité à gérer un modèle métier pivot
  3. l’adaptation des messages via de la transformation entre les producteurs et consommateurs
  4. le couplage faible (conséquences de l’application de patterns)

Il est courant de rencontrer des clients ayant installé un ESB pour faire uniquement de la médiation protocolaire et manquer tous les autres avantages.

Le 2nd facteur de réussite est la facilité d’implémentation des techniques asynchrones (WS-AtomicTransaction ou WS-BusinessActivity) et des services avec états. Le nombre d’interlocuteurs et des techniques d’échanges de flux croit avec la complexité des cas d’usages fonctionnels. Là encore le moteur BPEL est notre couteau suisse, car elles sont couvertes nativement. Malheureusement, encore trop de clients dépensent de l’énergie inutilement et réécrivent des solutions complexes pour répondre à ces problématiques. Dans les futures articles, je vous proposerai quelques exemples concrets avec Oracle BPEL Process Manager.

Le niveau 3 du SOA MM couvre principalement 2 types de services fonctionnels: les services métiers dont je viens de parler et les services collaboratifs. Les services collaboratifs portent tout autant des interactions avec des partenaires que entre les organisations et services d’une même entreprise. Il est évidemment difficile de différencier au sein d’une entreprise qui est un partenaire externe ou interne. Toutefois, de nombreux échanges se déroulent en mode fichiers avec les partenaires. Oracle B2B est le support à ces échanges fichiers (XML, HL7, ebXML, etc) sur des protocoles adaptés (FTP, JMS, SMTP, etc).

Pour couvrir les problématiques de sécurité, l’ESB est le point de contrôle privilégié pour la partie technique des flux. Dans l’architecture Oracle, l’ESB Oracle Service Bus est épaulé pour la gestion de la sécurité par un outil spécialisé, Oracle WebServices Manager.

Enfin, on retrouve à ce niveau de maturité le besoin de maîtriser les processus d’organisation et d’entreprise. Il est couvert par la suite complémentaire, Oracle BPM Suite. Il est important de noter que SOA Suite ne contient pas la licence du moteur BPMN.

Finalement, la stack Oracle correspond alors à cette vision:

 

Au niveau 4, l’objectif est de mesurer la qualité de services, de s’assurer des engagements pris vis-à-vis des partenaires internes ou externes, de facturer les services en fonction de leurs usages, etc. bref de maîtriser les services mis en place.

Il y a en fait 3 axes d’action pour y arriver:

  1. la supervision des SLA
  2. l’analyse via les données métier à postériri ou en temps réel
  3. la gestion de l’évolution des services

La supervision des SLA est codée traditionnellement par des indicateurs enregistrés en base de données puis avec lesquelles des rapports sont produits. Chaque application enregistre ses propres indicateurs suivant des durées différentes. L’uniformisation et la centralisation des mesures et du reporting est une évidence. Oracle Entreprise Manager couvre cette partie supervision.

L’analyse en temps réel n’est pas encore très répandue. Grâce aux outils Business Activity Monitoring (BAM), un tableau de bord similaire au BI est mis à disposition des analystes fonctionnels. L’intérêt de cet outillage est de proposer quasi instantanément une vision agrégée des flux et des données de production. Bref, si vous ne pouvez attendre les rapports extraits de votre outils de BI, le BAM est fait pour vous.

Oracle propose pour cela Oracle BAM qui est un serveur dédié à la gestion de l’activité métier.

Par ailleurs, je ne parlerai pas de Oracle Complex Event Processing pour lequel je n’ai pas de retour d’expérience significatif.

Enfin, la gouvernance est la dernière brique de ce niveau de maturité. Après avoir installé un ou plusieurs ESB dans le SI, la gestion du changement est un sujet consommateur d’énergie. La propagation de Services dans le SI facilite leur réutilisation mais réduit le grain applicatif à gérer. Pour une « ancienne » application, il y a maintenant N applications SCA. Pour ne pas tomber dans une lourdeur de gestion du changement, 2 outils sont nécessaires:

  • un annuaire de référencement des services (annuaire UDDI)
  • un outil de gouvernance.

L’annuaire UDDI offre la capacité de découverte dynamique. Chaque application est déployée à un endroit unique sur 1 ou plusieurs serveurs. L’annuaire couplé à l’ESB, permet à ce dernier de découvrir dynamiquement la localisation du service. Par exemple, il est ainsi possible de monter une VM supplémentaire utilisable dynamiquement via ce mécanisme. L’annuaire UDDI est un outil de production et n’a pas d’utilité lors du développement.

Enfin l’outil de gouvernance, encore trop peu répandu, offre une gestion complète des services de l’entreprise en proposant:

  • l’expression des besoins
  • la définition des contrats
  • l’évolution des versions
  • les dépendances entre services
  • la traçabilité des impacts
  • etc.

Une bonne pratique est de disposer très tôt de cet outil de gouvernance. Il offre un support de conception mature lors de la transformation du SI vers une architecture SOA.

Côté produit, Oracle propose un outil pour chaque besoin:

  • Oracle Service Registry comme annuaire UDDI
  • Oracle Entreprise Registry comme solution de gouvernance SOA.

Ce niveau complète la stack Oracle de la manière suivante:

 

Les 4 outils de ce niveau (OEM, BAM, CEP, OSR et OER) sont des compléments ou annexes aux moteurs d’exécution des traitements. Ils se greffent tous à une plateforme existante.

En conclusion, cet article démontre que l’utilisation d’une plateforme telle que Oracle SOA Suite permet d’attendre un niveau de maturité SOA important. Cet exercice aurait pu être fait avec d’autres éditeurs. Ces outils sont des facilitateurs pour permettre la maitrise de l’ « architecture SOA » sur des perspectives complémentaires: le développement, l’exécution, la supervision, l’analyse et le suivi. Sur le terrain, le constat est souvent résumé à cela: la construction itérative et opportuniste d’une architecture SOA apporte un nombre important de difficultés techniques dont le principal est le manque de cohérence. Les équipes projets sont remises à elles-mêmes et leur choix non discutés. Comme je le présentais en introduction de mon article précédent, l’intégration des outils et leurs fonctionnalités facilitent la mise en œuvre du SOA, mais il n’est pas possible d’arriver à bon port sans un pilotage humain de qualité. L’outillage n’est qu’un des facteurs de réussite… mais un facteur de poids.