Inscrivez-vous gratuitement à la Newsletter BFM Business
Les services peuvent être assemblés côté serveur via un outil de BPM, ou directement sur le poste de travail de l'utilisateur, au sein d'un client riche de dernière génération.
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.
Le bureau métier se démocratise
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.
Votre opinion