White Paper Workflow et Service Oriented Architecture (SOA) Présentation Cet article offre une approche pragmatique de la SOA et du workflow à travers des problématiques d'entreprises, une méthodologie de mise en oeuvre et une analyse des technologies et des standards disponibles aujourd'hui. Membre de la Workflow Management Coalition (WfMC), ADVANTYS participe activement à la définition des standards de workflow. Son logiciel de workflow WorkflowGen a été réalisé sur la base des derniers standards et offre une solution parfaitement cohérente avec une SOA. SOMMAIRE Encore 3 lettres pour une nouvelle technologie? Présentation de la SOA Est-ce que le SOA ré-invente le Workflow? Faut-il mettre en place une SOA avant d utiliser une solution de Workflow? Gérer son projet workflow en pensant SOA Standards SOA ou Standards de Workflow : que choisir? Les challenges techniques de la SOA Conclusion
Encore 3 lettres pour une nouvelle technologie? L informatique est plus que jamais une science, les nouvelles architectures pour concevoir des systèmes d information font appel à de vraies formules mathématiques difficilement compréhensibles par un néophite : SOA = (EDI + EAI + XML + BPM) x WEB Pourtant l expression de besoin des organisations est simple : Comment automatiser et optimiser mes processus métiers? Il y a encore quelques années la réponse était simple : Workflow. Aujourd hui, de nombreuses réponses sont disponibles pour cette question ; - Standardiser les échanges d informations entre les différents systèmes d informations avec de l EDI (Electronic Data Interchange), des documents XML et en s appuyant sur des solutions d EAI (Enterprise Application Integration) - Automatiser la circulation des informations et optimiser les traitements avec un outil de BPM (Business Process Management) - Réaliser cette intégration en s appuyant sur les standards du Web comme le protocole HTTP et les Web Services Et comme si cela ne suffisait pas, il est maintenant fortement recommandé de repenser l architecture de son système d information sous forme de «services». De plus pour faciliter cette tâche plus d une vingtaine de «standards» plus ou moins concurrents sont disponibles... Après 10 ans de migration laborieuse vers les applications orientées objets et les architectures 3 tiers les entreprises doivent elles recommencer à zero? Le SOA et le Workflow sont ils synonymes, complémentaires ou concurrents? Comment répondre immédiatement aux besoins d optimisation des processus tout en intégrant les dernières technologies? Présentation de la SOA Simplement, la Service-Oriented Architecture est une approche d implémentation d applications basée sur l utilisation de «services». Le «service» étant un composant ré-utilisable disponible sur le réseau interne de l entreprise ou externe. Ce composant prend la forme d un Web Service, permettant à l ensemble de l architecture d être très modulaire, indépendante de la plateforme hébergeant le service et de reposer sur des standards comme HTTP, XML et SOAP. Le fournisseur de Web Services peut ainsi facilement offrir à des applications «consommatrices» internes ou externes à l entreprise des fonctionnalités facilement intégrables par des applications quelque soit leur support : Client Riche (Windows), Client légér (Web) ou Client mobile (PDA). L application consommatrice de web services peut se «servir» auprès de fournisseurs de fonctionnalités indépendamment de leurs emplacements sur le réseau, des technologies utilisées et des bases de données interrogées. La mise à disposition d un annuaire de web services permet de trouver facilement le service le plus adapté à son besoin. Le concept n est pas nouveau, les «object brokers» de DCOM et de CORBA fournissent déjà ce type de services. La SOA se concrétise par l adoption massive par les solutions logicielles des standards comme XML et les Web Services, rendant ainsi réalisable la création d applications complètes en utilisant ces technologies. L objectif du SOA est donc de systèmatiser la création et la consommation de web services dans l architecture informatique de l entreprise.
Il est recommandé qu un service réalise un traitement unitaire afin d améliorer sa ré-utilisabilité dans différents traitements métiers plus complexes, appelés aussi business process. Il est donc rapidement indispensable de disposer d outils et de standards afin de modéliser et d orchestrer l exécution des différents services. Nous arrivons donc au coeur du problème : Est-ce que le SOA ré-invente le Workflow? D un point de vue marketing : «orchestrer» des web services est un peu trop abstrait pour les entreprises, optimiser des business process est beaucoup plus explicite. Les éditeurs de logiciels d EAI orientés XML et Web services se sont naturellement dirigés vers le SOA en apportant une réponse claire à un besoin client. Cependant la plupart de ces logiciels restent spécialisés dans les workflow de traitements automatiques : des process complètements automatisés synchrones ou asynchrones. On reste donc dans l univers de l EAI. D un point de vue technique : le SOA est une formidable plate-forme pour les logiciels de Workflow. En effet, la plupart des solutions de BPM peuvent «consommer» des web services pour exécuter des traitements automatiques. Réciproquement, un processus géré par un moteur de workflow peut être vu comme un web service asynchrone par une autre application. Ces fonctionnalités sont notamment possibles en utilisant les standards du WFMC et d OASIS comme ASAP et WF-XML 2.0. Ainsi une organisation mettant en place une Service-Oriented Architecture optimisera considérablement ses processus gérés par sa solution de Workflow. Faut-il mettre en place une SOA avant d utiliser une solution de Workflow? Cela n est pas nécessaire, voir non recommandé. En effet, le projet Workflow permettra de modéliser précisément les processus de l entreprise et de mettre en valeur les traitements automatiques qui seront les futurs Web Services de votre SOA. La mise en oeuvre d un logiciel de workflow est la démarche naturelle pour faire évoluer votre système d information vers une SOA. De plus, d un point de vue utilisateur final, un web service reste encore quelque chose de difficile à matérialiser. Chronologiquement vous pouvez ainsi répondre aux besoins immédiats d optimisation de vos process avec un moteur de workflow puis optimiser vos traitements automatiques en batissant une SOA.
Gérer son projet workflow en pensant SOA Il est encore prématuré d imaginer la mise en place de processus métiers dont toutes les actions sont entièrement automatisées. Au contraire, le management collaboratif des projets et l outsourcing génèrent un nombre important d actions (d approbation notamment) humaines. Dans la plupart des processus administratifs, les actions automatisables sous forme de web services sont encore minoritaires. Cependant, les gains de productivité les plus spectaculaires seront générées sur ce type d actions. Par exemple, la mise en œuvre d un workflow pour un process de validation de demande d achat apporte des gains de productivité considérables. Automatiser, à l aide d un web service par exemple, l action d enregistrement de la demande d achat validée dans l ERP va encore plus loin en faisant gagner un temps précieux et en éliminant le risque d erreur de saisie. Enfin, la réactivité est un élément clés, il faut donc pouvoir adapter les process en fonction des changements internes ou externes à l organisation. Il est donc particulièrement important d intégrer ces paramètres dans la méthodologie de mise en oeuvre de vos workflows tout en bâtissant votre architecture SOA. Voici quelques étapes importantes pour réussir ce type de projet : Réaliser l inventaire de vos process La plupart du temps, votre projet workflow se limite à la mise en place d un process. Il est cependant très intéressant de prendre un peu de recul sur l ensemble de vos process (par département, domaines, etc.). Cette étape vous permettera d identifier les traitements automatiques communs à différents process. Ainsi lors de la réalisation de ces «services» vont pourrez anticiper leurs ré-utilisabilités, en évitant par exemple de les spécialiser trop fortement par rapport au process consommateur. Travailler par version de process Dans certains cas la réalisation d un web service peut devenir un sous-projet substantiel dans la mise en oeuvre de votre workflow. Cela peut retarder sensiblement la réalisation du workflow en raison par exemple d un problème de ressource pour analyser et développer le web service. Automatiser un process avec un moteur de workflow est déjà un gain très important de productivité et de qualité de service. Quand cela est possible, Il est donc pertinent de lancer une version 1 (dans le cadre d un projet pilote par exemple) avec des web services simples. La mise en production de la version 1 mettra en valeur éventuellement des améliorations ou des changements par rapport à ce qui avait été prévu initialement pour le web service. Désigner un SOA Manager Rapidement le nombre de web services va augmenter et les consomateurs aussi. Comme pour une base de données, il est important d organiser l administration de votre «bibliothèque» de web services. La première étape est de désigner un responsable qui assurera la mise à jour du référentiel des web services disponibles (description, version, sécurité,etc.) et de leur usage interne et éventuellement externe à l entreprise. C est aussi la possibilité d assurer un suivi qualité notamment sur l homogénéisation des paramétres, les performances, la disponibilité et la sécurité. En résumé, une approche pragmatique de ces nouvelles technologies vous permettera de réaliser vos objectifs de workflow tout en évoluant vers le SOA. La mise en place efficace d une SOA nécessite une certaine maturité de l entreprise vis à vis de l automatisation de ses process, essayer de tout faire avec un seul outil, au même moment et cela par les mêmes profils de concepteurs semble particulièrement difficile en l état actuel.
Standards SOA ou Standards de Workflow : que choisir? Comme indiqué précédemment, la Service-Oriented Architecture constitue une plate-forme particulièrement puissante pour accéler et optimiser la gestion des workflows. On est donc sur des niveaux de modélisation et d exécution différents. Mais les points de liaisons, voir de recoupement, entre BPM/Workflow et SOA sont nombreux. Le problème aujourd hui est surtout sur la relative compétition des organismes de standardisation. En effet, les standards autour des web services, de l XML, de l EAI et de l EDI convergent vers le BPM et le workflow en particulier. Historiquement, le WFMC est le précurseur dans ce domaine notamment avec l XPDL pour la définition de processus et WF-XML pour les échanges inter-applications. L association avec OASIS pour la réaliser du protocole ASAP constitue un point de jonction avec les autres standards de type Web services. Dans le domaine du BPM le «standard stack» devient particulièrement complexe à comprendre. On peut citer notamment le positionnement de BPEL par rapport à XPDL et BPML. Cette multiplication des standards (BP.., WS..) à la fois présentés comme standard SOA, BPM ou Workflow, pose un réél problème sur le choix d un standard ou plutôt d une combinaison de standards pour batir la solution technique pour gérer ses process. A terme, l arrivée d acteurs majeurs sur ce secteur résoudra de facto ces problèmes. En attendant il faut répondre aux besoins de plus en plus importants d automatisation des process, une position conservatrice est d avancer sur les «bases» du Workflow et du SOA à savoir le modèle du Workflow défini par le WFMC et les Web Services au travers de SOAP. Plus concrêtement SOAP pour la communication inter-applications, XPDL pour la définition du process, BPEL pour l orchestration des web services et ASAP pour la gestion des web services asynchrones sont des standards facilitant la mise en place de workflows intégrés dans une architecture SOA. Les challenges techniques de la SOA Le problème majeur de l architecture SOA est le niveau de services offerts par les web services. SOAP est à la fois trop simple et trop compliqué. Trop simple pour traiter les problèmes de sécurité, d adressage et de disponibilité. Trop compliqué pour une mise en oeuvre très rapide. On observe donc deux tendances : d un coté un foisonnement de nouvelles spécifications et standards (WS...) pour apporter les éléments fonctionnels manquants à SOAP et de l autre coté des alternatives plus simples comme REST. Peut-on conclure à un manque de maturité de cette architecture? Conceptuellement non, car la réalisation d applications collaboratives et réparties répond aux réalités des systèmes d information aujourd hui. L exploitation des technologies et des standards issus du Web est incontournable. D un point de vue technique, il est clair que les solutions packagées commencent a être proposée sur des standards en cours d élaboration. Le meilleur moyen d éviter des problèmes de choix éventuels est de recadrer votre projet SOA dans une perspective fonctionnelle, à savoir l optimisation des process métiers, donc le projet Workflow. Les solutions de workflow aujourd hui intégrent de manière packagée et stable de nombreuses fonctionnalités pour automatiser vos process. Elle vous permettent d utiliser dès à présent les web services pour effectuer les traitements automatiques sans avoir d outils supplémentaires.
Conclusion La Service-Oriented Architecture est vraisemblablement la solution d organisation des systèmes d informations répondant aux nouveaux défis de développements et de communications des applications. Le travail de migration et le choix du moment pour effectuer cette migration sont les principaux obstacles à sa mise en oeuvre rapide dans les entreprises. Restreindre la mise en place d une SOA à un projet de migration technique seul peut à la fois bloquer son acceptabilité pour des problèmes budgétaires et générer un risque certain dans les choix des solutions encore très jeunes. Par contre, intégrer dans son projet Workflow l intégration de Web services pour la réalisation des traitements automatiques est la solution la plus pragmatique pour mettre en place progressivement et efficacement en terme de ROI une architecture SOA. Dans ce domaine, l expertise et les travaux du WFMC apportent une contribution significative. La collaboration avec d autres organisations de standardisation permet d intégrer l ensemble de la problèmatique fonctionnelle et technique. Cependant il ne faut pas qu une certaine forme de compétition démultiplie les standards similaires en rendant ceux-ci sans intérêt. Workflow, BPM et SOA ne sont donc pas concurrents mais l effervescence marketing et technique autour de l automatisation des process est telle que la lisibilité des solutions est particulièrement difficile du point de vue des entreprises clientes. Dans ce contexte particulier, les solutions présentant des outils dont la mise en oeuvre et l utilisation sont simples auront très certainement le plus de succès. Découvrez comment WorkflowGen peut vous aider à construire votre SOA. Cet article écrit par Arnaud Bezancon, Directeur Technique et co-fondateur d'advantys éditeur de WorkflowGen, est un extrait de "Workflow Handbook 2005", reproduit avec l'accord de Future Strategies inc.