Comment choisir un Enterprise Service Bus (ESB) ?

3 mai 2008 par admin

Catégorie: java, soa

Traduction de servicemix faq Servicemix est un projet Apache proposant un ESB (Enterprise Service Bus),un SCA (Service Component Application) et un JBI (Java Business Integration).

Devant les besoins d’intégration d’un middleware , il est logique de considérer l’adoption d’un ESB. En faisant les évaluations des logiciels, il est important d’approcher le choses de manière à ce que vos exigences soient l’instrument central du processus. Il y a habituellement deux niveaux d’évaluation qui doivent être considérés lors de l’adoption de n’importe quel software : vos besoins métiers et les fonctionnalités du logiciel (Ici de l’ESB). Il y a de nombreux points dans ces 2 niveaux, et nous allons les passer en revue.

Votre objectif métier

Ne dites pas que votre objectif métier c’est le SOA. C’est le comment, pas le pourquoi. SOA n’est qu’une façon de penser l’architecture logicielle. Votre objectif métier c’est le but que vous essayez d’atteindre dans votre activité à travers l’usage du logiciel que vous êtes en train de mettre en place. Voilà un exemple:

Notre objectif métier est de combiner des données météo avec des cartes pour fournir aux clients des prévisions météo immédiates pour leurs destinations quand ils font des réservations de voyage sur notre portail.
Cela facilite non seulement les projets de voyage, mais aussi permet à notre système d’annonces publicitaire de mieux cibler les clients . Cela apportera un plus à nos clients, mais permettra de mieux cibler les publicités pour tenter d’augmenter le taux de conversions (clics sur annonces).

Remarquez que l’objectif métier est concentré sur le but du logiciel du point de vue métier. Le but est de:

Améliorer l’expérience des clients grâce à l’usage de cartes et de météo
Augmenter le taux de conversion des annonces publicitaires

Comprendre vos objectifs métiers vous met en meilleure position pour définir des exigences fonctionnelles pour atteindre cet objectif.

Vos exigences fonctionnelles

Une fois compris les objectifs métiers du projet, passons aux exigences fonctionnelles. Ci dessous sont listés quelques exemples d’exigences fonctionnelles pour notre objectif métier:

Fournir un accès aux données météo
- Cela demande l’intégration d’un socket pour récupérer les données
- Il faudra parser les données
Fournir un accès aux données géographiques, aux cartes
- Google offre une API (Google Map API ) pour accéder à ces données
Créer un “overlay” permettant d’intégrer les cartes et la météo sur les destinations des clients
En combinant les prévisions et les destinations , donner des règles au système fournissant les publicités pour adapter les annonces aux destinations et aux prévisions météo
Si le client clicke sur une annonce, sauvegarder cette information en base de donnée et la lier au profil du client. Cela améliorera nos prédictions lorsque le client reviendra une autre fois.

Ces exigences fonctionnelles augmentent dramatiquement lorsque l’objectif métier est identifié et clairement communiqué à toutes les personnes concernées dans le projet. De telles exigences vont amener les choix d’architecture du système et du logiciel.

Vos choix d’architecture

Avant de commencer à contacter des fournisseurs, il est important d’établir quelques choix d’architecture. Ces choix ne sont pas gravés dans le marbre. Cela peut inclure de concevoir le système d’une façon “Orientée Service”, d’utiliser certains packages, et peut être le hardware et les softs de test. Vous avez peut être fait ces choix de façon implicite à travers vos expériences précédentes. Si il en est ainsi, il est important d’identifier et de communiquer ces décisions explicitement aux différentes parties-prenantes pour qu’il y ait un certain niveau de clarté dans le groupe.

En travaillant à travers ces exercices, vous devriez avoir non seulement un ensemble de solutions à partager, mais vous aurez aussi vos critères d’évaluation d’un ESB.

Vos critère pour évaluer un ESB

N’importe quelle évaluation de software demande la connaissance des sujets discutés plus haut. Sans une bonne maîtrise de ces sujets, il est difficile d’évaluer la capacité d’un logiciel d’atteindre des buts spécifiques.

Il est important aussi de ne pas comparer les solutions logicielles fonction par fonction. Cette méthode d’évaluation ne donne une image quand au but attendu du logiciel.

Par exemple:

Quelle importance si un logiciel A affirme fournir des accès sécurisés vers des ressources X, mais que son API est vraiment compliqué à utiliser ?

Quelle importance si un logiciel B annonce fonctions 1, 2 et 3 mais que ses performances sont déplorables ?

Une expérience personnelle avec un logiciel donné dans votre environnement est une priorité. Quand on parle d’ESB, c’est encore plus critique parce que l’ESB contrôle l’intégration du système et que deux scénarios d’intégration ne sont jamais identiques. Déployer un ESB dans votre environnement pour résoudre un ou deux de vos problèmes par une validation de conception vous donnera bien plus d’informations et de conclusions que n’importe quelles comparaisons sur papier.

Promouvoir cet article : Ces icônes sont des liens vers des sites de partage de signet sociaux où les lecteurs peuvent partager et découvrir de nouveaux liens.