Les langages d'orchestration sont en fait imperative scripting languages avec des conditions, des boucles et d'autres constructions traditionnellement impératives, typiquement exprimées par une interface utilisateur basée sur un organigramme. Ils n'ont certainement pas (selon mon expérience) mis en œuvre une programmation fonctionnelle récursive, un chaînage arrière ou tout autre paradigme qui pourrait raisonnablement être qualifié de déclaratif au sens généralement accepté.
MS Workflow Foundation est annoncée comme ayant un moteur de règles, mais cela est assez simpliste et ne fait pas de chaînage direct, sauf de façon un peu détournée. ILOG fait en fait un adaptateur pour leur moteur de règles spécifiquement pour le déposer dans la base de travail MS workflow.
D'autres outils de flux de travail ont de meilleurs moteurs de règles et un système de chaînage avant approprié qui peut être considéré comme déclaratif. Cependant, une fois que vous entrez dans les workflows eux-mêmes avec des branches en boucle et conditionnelles, vous êtes certainement dans le domaine de la programmation impérative. Cependant, certains systèmes implémentent également un système de balisage basé sur les petri-net ou les changements d'état pour le flux de travail, qui peut raisonnablement être décrit comme déclaratif, mais ils ont toujours un mode d'interaction impératif avec le système sous-jacent. Ils mettent à jour les variables et ont des effets secondaires.
J'ai vu une ou deux applications (par exemple TOAD for data anlaysis) utilisant réellement MS Workflow Foundation comme langage de script. En tant que tel, il vous permet d'ajouter une fonctionnalité de script à l'application qui (au moins à des fins de marketing) ne nécessite pas de compétence de programmation à utiliser.
En pratique, un outil conçu pour écrire, éditer et exécuter des requêtes SQL étant équipé d'une structure de script pour les 'non-programmeurs', on peut se demander à quel public il s'adresse vraiment. En tant que langage de script, les outils de modélisation de flux de travail sont assez maladroits et offrent des possibilités très limitées d'abstraction; dans la pratique, un langage de script basé sur .Net tel que IronPython ou Boo, en particulier en conjonction avec un mécanisme de modélisation décent, serait un ajout très puissant à un tel outil. Un point concernant les langages graphiques de ce genre est qu'ils ne s'adaptent pas bien à la complexité. Un problème similaire s'applique également aux outils ETL. J'ai vu une application de provisionnement (voir ci-dessous) qui a été faite (ironiquement) avec Crossworlds (maintenant connu sous le nom de Websphere Integrator). Moins d'un mois après le lancement de l'application, il est devenu évident que le langage de workflow graphique n'allait pas évoluer avec la complexité de l'application et il a été reconstruit, basé sur un moteur de règles personnalisé écrit en Java et un assez grand nombre de sur mesure code Java.
Ce type de problème n'est pas rare avec les systèmes EAI et Orchestration et est l'une des raisons pour lesquelles SOA est difficile à mettre en œuvre dans la pratique. Ce que vous faites, c'est pousser la logique métier dans un environnement de programmation très maladroit qui n'est pas officiellement reconnu comme tel. Cela fonctionnera dans un cas simple, mais il est difficile de travailler sur un système complexe - c'est un peu un secret coupable dans les cercles SOA.
Coda: Une application de provisionnement est un système qui prend des plans pour les contrats de services de télécommunication (dans ce cas pour un réseau de téléphonie mobile) et repousse les informations de configuration en fonction des règles vers différents commutateurs, des applications de facturation et d'autres applications . Ils ont tendance à être assez complexes. Lorsque vous achetez un forfait de téléphone mobile avec autant de minutes et de textes par mois, une application de provisioning envoie des informations de configuration au reste du système sur vos règles d'accès et de facturation.