Mardi 12 décembre 2017
NASDAQ : 0.0 0   nasdaq0 %
RECHERCHE
OK
 
NEWSLETTER
newsletter
Abonnez-vous gratuitement
à notre newsletter
hebdomadaire - Cliquez ICI
Indexel
  • DOSSIERS
  • PRATIQUE
pub Publicité
 

INFRASTRUCTURE

Réussir son projet SOA en trois étapes

Imprimer Envoyer à un ami Contacter la rédaction
Par Marie Varandat le 31/05/2005 - indexel.net
 

Réponse aux besoins métiers des entreprises, garantie d'évolutivité, de réactivité et de réduction des coûts : les architectures "orientées services" (SOA) nécessitent aussi un minimum de précautions. Explications.

 

Si le concept d'architecture SOA (Service Oriented Architecture) n'est pas fondamentalement nouveau, il s'appuie aujourd'hui sur des technologies standard, plus ouvertes et faciles à mettre en oeuvre que Corba ou DCOM, premières architectures informatiques à préconiser le principe de séparation des couches et de réutilisation des développements. Il serait donc dommage de ne pas faire évoluer son existant pour profiter de ces nouvelles technologies et construire une informatique plus en adéquation avec les besoins métiers de l'entreprise. Dans ce cadre, Unilog, société de conseil et d'ingénierie en nouvelles technologies a édité en février dernier un livre blanc intitulé "SOA et urbanisme - Le rôle des Architectures orientées Services dans l'alignement métier des Systèmes d'Information" sur lequel nous nous sommes appuyés pour vous fournir les préalables indispensables au succès de votre projet.

 

1. Analyser et cartographier l'existant

 

"SOA ne veut pas dire big bang, il faut adapter l'existant", estime François Rivard, Manager EAI chez Unilog Management, rédacteur du livre blanc. En découpant les applications monolithiques des mainframes ou des modèles client/serveur en services, les entreprises ont la possibilité "d'exposer" des fonctions existantes sous forme de services afin de les réutiliser dans de nouvelles applications. Cette opération implique une analyse du code existant qui peut être facilitée par des outils proposés par la plupart des éditeurs impliqués dans la mise en oeuvre de SOA. Dans certains cas, l'existant ne répond toutefois pas aux principes de séparation des couches de SOA : logique métier, présentation et services techniques sont imbriqués. Plutôt que de revoir le code, opération complexe et parfois risquée, il est alors possible de faire appel à des solutions proposées notamment par IBM ou Seagul. Similaires aux mécanismes du Web to Host, elles encapsulent les écrans des mainframes, par exemple, en composants (COM, EJB ou Web Service) qui peuvent ensuite être exposés.

 

2. Définir la granularité et l'architecture, arrêter un périmètre

 

"On est dans un projet global de migration du système d'information vers le métier de l'entreprise, explique François Rivard (photo). Il faut donc penser autrement et porter une véritable réflexion métier pour arriver à déterminer comment découper une application en services que l'on va pouvoir mutualiser. Cette opération va forcément de pair avec une réflexion sur l'architecture en termes de transversalité des services et des processus à mettre en place". Voir grand et réaliser petit constitue également un point clef de la réussite : la réflexion doit porter sur l'architecture cible à laquelle on souhaite parvenir mais la mise en oeuvre doit être progressive afin d'évite les projets trop longs qui, quand ils aboutissent enfin, ne sont même plus en adéquation avec les nouveaux besoins.

 

"Il faut procéder par périmètres, à l'occasion d'une nouvelle application, sans perdre de vue l'objectif final", estime François Rivard. Enfin, avant même d'attaquer le projet, il faut envisager la mise en oeuvre d'un référentiel ou annuaire de services afin d'assurer la maintenance et l'évolutivité de son architecture. Cet annuaire est d'autant plus critique qu'avec SOA on n'a plus quelques applications à gérer mais une multitude croissante de services utilisés par plusieurs applications, des processus complexes orchestrés à différents niveaux, etc.

 

3. Prévoir le monitoring de ces architectures complexes

 

La supervision et le management de la nouvelle architecture constitue une étape également clef. Avec SOA sont apparu des outils de monitoring orientés métier, (BAM pour Business activity monitoring). Très proches des outils décisionnels, ils mesurent la performance de l'entreprise. Mais ces outils ne couvraient pas la dimension technique : si on était capable de voir qu'un processus bloquait à cause d'un individu qui ne faisait pas son travail, on était en revanche incapable de voir que la cause provenait d'une panne matérielle ou logicielle.

 

On assiste aujourd'hui à une convergence des outils de BAM avec les solutions de monitoring classiques : HP Open View, Unicenter de Computer Associates, Patrol de BMC, MOM de Microsoft, etc. Convergence indispensable pour maîtriser les architectures SOA que des sociétés comme  Amberpoint, WebMethods et Tibco proposent déjà et sans laquelle on peut difficilement mettre en place des solutions offrant la qualité de service nécessaire au fonctionnement de l'entreprise.

 

Enfin, "si l'on veut profiter pleinement de ces outils, il faut concevoir des services qui incluent dans leur code une sémantique métier. Exploitée par les outils de monitoring, elle permettra à l'entreprise d'être encore plus efficace dans sa supervision et le pilotage de son système d'information", conclut François Rivard.

 

 
Partager :
 
pub Publicité

CloudStack by IkoulaCloudStack by Ikoula

Cloud Computing : Atouts et freins, acteurs du marché, conseils et témoignages