Le socle technique des architectures orientées services est désormais clairement défini. Les descriptions des fonctions proposées par chaque service Web sont publiées au sein de documents XML (norme WSDL) et sont référencées au sein d’annuaires de composants : DSML (Directory Services Markup Language), UDDI, LDAP… Les échanges entre composants sont assurés par le protocole Soap sur HTTP. Une application distribuée est alors créée par assemblage statique ou dynamique de services distants, selon un scénario qui dépend à la fois des logiques fonctionnelles spécifiques, d’événements divers et des interactions avec les utilisateurs finals.Ces assemblages deviennent rapidement complexes lorsqu’il s’agit de bâtir de lourdes applications assujetties aux contraintes opérationnelles et organisationnelles qui pèsent sur l’entreprise (applications de type B-to-B, places de marché…).Une fois les services Web développés, décrits et dûment publiés dans des annuaires spécialisés, il convient de pouvoir décrire de manière non équivoque les scénarios d’enchaînement de composants afin d’orchestrer les différents échanges nécessaires. On parle ainsi de chorégraphie ou encore d’orchestration de services web. La définition d’une nouvelle application (processus fonctionnel) nécessite d’abord de spécifier le rôle de chaque composant impliqué et celui des acteurs concernés, les opérations mises en ?”uvre et la logique générale d’enchaînement des services. Il s’agit d’une description statique, parfaitement déterminée par la logique applicative.La seconde étape consiste à décrire la dynamique de ces assemblages : description des états, conditions de changement d’états, nature des événements à gérer, structure et comportement des transactions…
Plusieurs propositions s’affrontent
Pour décrire précisément la nature des messages (Soap) que vont s’échanger les services web composant un processus, diverses propositions de standards s’affrontent, parmi lesquelles WSFL d’IBM, WSCL de HP et XLANG de Microsoft. Toutes ces propositions reposent sur XML et sont décrites à l’aide de DTD ou de schémas spécifiques. Ceux-ci sont notamment utilisés pour décrire le type des données échangées entre services distants. Les trois propositions permettent de spécifier des logiques d’enchaînement arbitrairement complexes de services Web, assemblés de manière statique, à l’instar des processus caractéristiques de l’univers du workflow.Des structures de contrôle (boucles, blocs conditionnels, sauts, alternatives…), inspirées des langages traditionnels de programmation structurée, enrichissent ces propositions et permettent de décrire des assemblages conditionnels pilotés par des événements ou dépendant de l’état général du processus au moment de son exécution.La dynamique des applications s’intéresse à la synchronisation des échanges (messages, données…) et à la définition de transactions impliquant potentiellement de nombreux services hétérogènes et distribués. Elle fait l’objet de descriptions spécifiques. Les architectures à base de services web s’appuient sur un environnement technique d’exécution n’intégrant aucun dispositif simple de gestion des états transactionnels : à titre d’exemple, HTTP est un protocole sans état. Pourtant, les applications à mettre en place sont, par essence, de nature transactionnelle. Les propositions WSCL, XLANG et WSFL permettent de décrire sommairement ces structures dynamiques et de définir des transactions distribuées.BPML (Business Process Modeling Language) est la proposition à la fois la plus avancée et la plus générale en matière de description de processus métier. Publiée par le consortium BPMI (Business Process Modeling Initiative), qui regroupe notamment Sun, HP,Intel, Nortel et SAP, cette spécification décrit des processus de manièreabstraite, indépendante de toute application caractéristique d’un environnement spécifique d’exécution.
BPML sépare le code de l’application
Une description BPML doit être associée au moment de l’exécution à une configuration de production composée d’un ensemble de services Web. BPML décrit la dynamique de processus sophistiqués pouvant impliquer plusieurs entreprises. La proposition sépare clairement le code de l’application de la gestion des processus fonctionnels : description de l’enchaînement des composants, règles de gestion, transactions distribuées… Le BPMI travaille également sur un langage de requête baptisé BPQL, qui permet d’interroger le référentiel constitué par l’ensemble des documents au format BPML et offre la possibilité de découvrir à distance la structure des processus modélisés.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
