Une conception de processus est-elle vraiment une programmation déclarative?

Question

J'ai entendu dire par quelqu'un qu'ils utilisaient un outil d'automatisation des processus métier (comme Weblogic Integration) comme langage de programmation (ce qui paraissait plutôt stupide) pour rendre les choses déclaratives. Ensuite, ils insèrent toute la logique dans un processus, chaque if et tant que .

Mais, n’est-ce pas un processus qui explique comment une entité étape par étape pour atteindre une cible?

Pour moi, un processus est absolument impératif. Qu'en penses-tu?

Answer 1

Ce n'est certainement pas ce que les gens veulent dire quand ils parlent de la programmation déclarative , même si un sens peut être appelé déclaratif.

Answer 2

Les langages d'orchestration sont en fait des langages de script impératifs avec des conditionnels, des boucles et autres constructions traditionnellement impératives , généralement exprimée via une interface utilisateur basée sur un organigramme. Selon mon expérience, ils n’implémentent certainement pas une programmation fonctionnelle récursive, un chaînage en amont ou tout autre paradigme pouvant être raisonnablement décrit comme déclaratif au sens généralement accepté.

Il est annoncé que MS Workflow Foundation dispose d’un moteur de règles, mais il est assez simpliste et ne permet pas réellement d’enchaîner, sauf de façon quelque peu détournée. ILOG crée en fait un adaptateur pour leur moteur de règles, spécialement pour l'insérer dans la base de flux de travail MS.

D'autres outils de flux de travail ont de meilleurs moteurs de règles et un système de chaînage en aval approprié pouvant ê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 très certainement sur le territoire de la programmation impérative.

Cependant, certains systèmes implémentent également un système de marquage basé sur le réseau de Petri ou un changement d'état, que l'on peut raisonnablement qualifier de déclaratif, mais qui ont toujours un mode d'interaction impératif avec le système sous-jacent. Ils mettent toujours à jour les variables et ont des effets secondaires.

J'ai vu une ou deux applications (par exemple, TOAD pour l'analyse des données ) utilisant réellement MS Workflow Foundation comme langage de script. En tant que tel, il vous permet d’ajouter à l’application une fonction de script qui (du moins à des fins de marketing) ne nécessite pas de compétences en programmation.

En pratique, un outil conçu pour l'écriture, l'édition et l'exécution de requêtes SQL, doté d'un cadre de script pour les «non-programmeurs», permet de se demander à quel public il s'adresse réellement. En tant que langage de script, les outils de modélisation de flux de travail sont assez maladroits et offrent des possibilités d'abstraction très limitées. dans la pratique, un langage de script basé sur Net, tel que IronPython ou Boo, en particulier associé à un mécanisme de modélisation décent, constituerait un ajout très puissant à un tel outil.

Un aspect des langages graphiques de ce type 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 provisioning (voir ci-dessous) qui a été réalisée (ironiquement) avec Crossworlds (maintenant connu sous le nom de Websphere Integrator). Un mois après le démarrage de l'application, il est devenu évident que le langage de flux de travail graphique n'allait pas avec la complexité de l'application et il a été reconstruit, sur la base d'un moteur de règles personnalisé écrit en Java et d'un assez grand nombre d'applications personnalisées. 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 La SOA est difficile à mettre en œuvre dans la pratique. Ce que vous faites, en réalité, consiste à introduire 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 en quelque sorte un secret coupable dans les milieux SOA.

Coda: Une application de provisioning est un système qui prend en charge des projets de contrats de services de télécommunication (dans ce cas pour un réseau de téléphonie mobile) et transmet des informations de configuration. basé sur des règles pour divers commutateurs, applications de facturation et autres applications. Ils ont tendance à être assez complexe. Lorsque vous achetez un forfait de téléphonie mobile avec tant de minutes et autant de SMS par mois, une application de provisioning transmet des informations de configuration au reste du système concernant vos règles d'accès et de facturation.