Le point sur la politique de workflow de Microsoft

Pourquoi un workflow sur la plate-forme applicative de Microsoft ?

Notre workflow est un composant indispensable introduit avec .NET 3.0. Avant, des solutions basées sur BizTalk étaient très axées sur le transactionnel et l’interopérabilité. Avec la plate-forme .NET 3.0, le workflow est devenu une brique fondamentale, des petites applications à la refonte totale des environnements informatiques, qui apporte la capacité de modéliser et d’automatiser les processus.

Les architectures de services (SOA) sont à la fois une mode mais surtout une tendance pour construire et rénover. Nous assistons à une réorganisation de l’entreprise par pôle, et un portage des services et des desktops sur le workflow.

Qu’est qui vous a poussé à développer Windows Workflow Foundation ?

Avant, nous trouvions des solutions spécifiques et spécialisées plutôt orientées métiers que technologies. D’où notre idée d’instancier un composant technique, ce qui a abouti au développement de Windows Workflow Foundation, notre moteur de workflows intégré à la plate-forme Windows.

Il y a plusieurs scénarios à l’usage d’un workflow. Si la cinématique est tournée vers une application complexe, on peut la définir via le moteur de workflow. Ou encore, on peut imaginer un workflow instancié sur un serveur, avec un composant de stockage sous SQL Server, un workflow qui gère avec persistance les applications. Windows Workflow Foundation est la brique complète qui fournit cet ensemble.

Le workflow permet d’échanger entre métiers, entre actions entre métiers, entre des applications à développer ou existantes, et de construire son propre modèle applicatif. C’est l’exemple de SharePoint, notre workflow développé sous .NET et implémenté sur notre plate-forme Office Server 2007.

Quelle stratégie adopter alors en matière d’interopérabilité ?

L’interopérabilité est gérée via la plate-forme .NET, mais en réalité il y a deux plates-formes. Si la brique workflow du framework .NET suffit, alors on l’utilise telle quelle. S’il faut intégrer de multiples sources, du transfert de données, de la maintenance et du monitoring, des connexions SOA, des manipulations XML ou sur d’autres protocoles, c’est BizTalk 2006 qui s’impose.

BizTalk ne repose pas sur Windows Workflow Foundation, il a été conçu avant celui-ci. En revanche, il partage les mêmes composants. On peut également déployer un middleware d’intégration à .NET. C’est le cas des API en direction de SAP.

Comment intégrez-vous cette approche avec votre politique de distribution indirecte ?

Notre volonté n’est pas d’adresser toutes les plates-formes et métiers, mais de proposer des solutions accessibles en environnement Windows. Par exemple, plusieurs partenaires éditeurs de logiciels nous ont accompagnés lors du lancement de Vista.

Windows Workflow Foundation est intégré au framework de .NET, qui est lui-même intégré à Vista. On peut l’exploiter via Visual Studio. C’est tout bénéfice pour les gens formés à .NET qui profitent de la logique d’une plate-forme intégrée.

De plus, le framework .NET 3.0 est compatible avec Windows XP et Windows Server. Ainsi on n’impose pas de faire évoluer le parc vers Vista. C’est un facteur d’intégration et d’adoption de nouvelles briques technologiques.