![]() |
Emploi
|
![]() |
Start-up
|
![]() |
Evénements 01 | ![]() |
Avis d'expert | ![]() |
Vidéos | ![]() |
Indicateurs
|
![]() |
Distribution
|
![]() |
Telecharger Pro
|
![]() |
Livres blancs | |||||||||||||||||||||












Jusqu'ici, les entreprises couvraient chaque domaine fonctionnel avec un seul logiciel. Les architectures orientées service décloisonnent peu à peu ces silos applicatifs sous la forme de processus et de données métier au périmètre plus réduit, que l'on peut agréger à loisir comme des pièces de Lego. Il devient ainsi possible de s'adapter en permanence aux évolutions du métier de l'entreprise.
“ Il existe deux catégories principales de logiciels consommateurs de services : ceux qui possèdent une interface graphique, et ceux qui en sont dépourvus ”, constate Matthieu Guillemette, architecte dans la SSII Sfeir.
Ces derniers sont souvent des applications métier qui accèdent à des services internes ou de partenaires. “ Les services ont alors une grosse granularité. C'est la cible privilégiée des architectures orientées service ”, explique Matthieu Guillemette.
Ceux dotés d'une interface graphique sont des logiciels proposés aux utilisateurs. Ces interfaces graphiques appellent des services distants, à la granularité et la provenance très divers. On peut imaginer une interface utilisateur de prise de commandes basée sur un service client hébergé chez Salesforce.com, un service produit fourni par le PGI, et un service livraison hébergé chez Fedex.
Trois architectures autorisent l'agrégation de services : une suite BPM (Business Process Management) ou un portail côté serveur, ou encore un socle de client riche. “ Dans ce dernier cas, les applications composites imposent de repenser le poste de travail. Et notamment d'introduire un bureau métier capable d'accueillir de nouveaux processus au fur et à mesure des besoins de l'utilisateur , estime Didier Girard, directeur technique de Sfeir.
D'Adobe (Apollo) à Microsoft (.Net 3.0 et Office 2007) en passant par la communauté Java (Eclipse et Netbeans RCP), tous les éditeurs fournissent aujourd'hui les technologies nécessaires à la création d'un bureau métier. Microsoft va jusqu'à intégrer un moteur de workflow dans .Net, déployé par défaut avec Windows Vista.
Vista est ainsi capable d'agréger des services hétérogènes, comme le ferait un moteur de BPM côté serveur. Ajax donne aussi la possibilité d'appeler simultanément différents services au sein d'une application Web. En revanche, les clients riches Internet (RIA) bâtis sur cette architecture n'ont pas la capacité d'orchestrer les appels.
Outre leur intérêt technique, ces applications composites renforcent l'autonomie des directions fonctionnelles. En effet, une fois les données et processus exposés sous la forme de services par la direction informatique, leur assemblage par une direction fonctionnelle est non intrusif. Il devient enfin possible de s'appuyer réellement sur la logique royaume-émissaire, et de dissocier clairement les responsabilités et domaines de compétence de chacun. On peut donc présager que, à terme, chaque direction fonctionnelle disposera de son propre serveur de BPM et construira ses propres applications composites.
En l'état actuel des technologies et des mentalités, les architectes considèrent cependant qu'il reste préférable de concentrer la logique métier côté serveur pour favoriser sa réutilisation et bien séparer la couche de présentation des traitements métier. Ils craignent, en effet, que les entreprises n'aient pas encore tiré la leçon des désastres de l'ère client-serveur. L'agrégation des services s'opère donc encore principalement côté serveur, domaine de responsabilité du fournisseur de services.
“ C'est d'autant plus vrai si le processus met en jeu des transactions métier ”, note Matthieu Guillemette. Si bien que construire une interface graphique utilisateur revient, pour l'instant, à habiller un service Web de grosse granularité, fournissant en un seul échange client-serveur l'ensemble des informations affichées à l'écran.
Tout l'intérêt des architectures orientées services réside dans la facilité de composer des outils à partir de services – processus et données – existants, exposés par la DSI. Les nouvelles technologies de clients riches – RIA et RDA – facilitent cette agrégation au niveau du poste de l'utilisateur ou d'un serveur BPM départemental, piloté par une direction fonctionnelle.
















