¿Es un diseño de proceso realmente programación declarativa?

Question

He escuchado de alguien que está usando una herramienta de automatización de procesos de negocio (como Weblogic Integration) como lenguaje de programación (que suena como algo estúpido) para hacer que las cosas sean declarativas. Luego ponen toda la lógica dentro de un proceso, cada if y while .

Pero, ¿no es un proceso una entidad paso a paso para alcanzar un objetivo?

Para mí hace que un proceso sea completamente imperativo. ¿Qué te parece?

Answer 1

Definitivamente no es lo que la gente suele decir cuando habla de programación declarativa , incluso si en cierto sentido se puede llamar declarativo.

Answer 2

Los

lenguajes de orquestación son, de hecho, lenguajes de secuencias de comandos imperativos con condicionales, bucles y otras construcciones tradicionalmente imperativas , normalmente expresado a través de una interfaz de usuario basada en un diagrama de flujo. Ciertamente, (en mi experiencia) no implementan programación funcional recursiva de cola, encadenamiento hacia atrás o cualquier otro paradigma que pueda describirse razonablemente como declarativo en el sentido generalmente aceptado.

MS Workflow Foundation se anuncia como un motor de reglas, pero esto es bastante simplista y realmente no encadena hacia adelante, excepto de una manera indirecta. ILOG realmente hace un adaptador para su motor de reglas específicamente para colocarlo en la base de flujo de trabajo de MS.

Otras herramientas de flujo de trabajo tienen mejores motores de reglas y un sistema de encadenamiento directo adecuado que podría considerarse como declarativo. Sin embargo, una vez que ingresa a los flujos de trabajo con bucles y ramas condicionales, definitivamente se encuentra en el territorio de la programación imperativa.

Sin embargo, algunos sistemas también implementan un sistema de marcado basado en cambio de estado o red de Petri para el flujo de trabajo, que razonablemente podría describirse como declarativo, pero aún tienen un modo imperativo de interacción con el sistema subyacente. Todavía actualizan variables y tienen efectos secundarios.

He visto una o dos aplicaciones (por ejemplo, TOAD para el análisis de datos ) en realidad usa MS Workflow Foundation como lenguaje de script. Como tal, le permite agregar una función de secuencias de comandos a la aplicación que (al menos para fines de marketing) no requiere habilidad de programación para usar.

En la práctica, una herramienta diseñada para escribir, editar y ejecutar consultas SQL con un marco de programación para 'no programadores' hace que uno se pregunte a qué público está realmente dirigido. Como lenguaje de programación, las herramientas de modelado de flujo de trabajo son bastante torpes y ofrecen oportunidades muy limitadas para la abstracción; en la práctica, un lenguaje de scripting basado en .Net como IronPython o Boo, particularmente junto con un mecanismo de plantilla decente, sería una adición muy poderosa a dicha herramienta.

Un punto sobre los lenguajes gráficos de este tipo es que no se adaptan bien a la complejidad. Un problema similar se aplica con las herramientas ETL también. He visto una aplicación de aprovisionamiento (ver más abajo) que se realizó (irónicamente) con Crossworlds (ahora conocido como Websphere Integrator). Un mes después de comenzar con la aplicación, se hizo evidente que el lenguaje de flujo de trabajo gráfico no iba a escalar con la complejidad de la aplicación y se reconstruyó, en base a un motor de reglas personalizado escrito en Java y un cuerpo bastante grande a medida. código java

Este tipo de problema no es infrecuente con los sistemas EAI y de orquestación y es una de las razones por las que SOA es difícil de implementar en la práctica. Lo que está haciendo es empujar la lógica empresarial a un entorno de programación muy torpe que no se reconoce oficialmente como tal. Esto funcionará en un caso simple, pero es difícil hacer que funcione en un sistema complejo; esto es una especie de secreto culpable en los círculos SOA.

Coda: Una aplicación de aprovisionamiento es un sistema que toma planes para contratos de servicios de telecomunicaciones (en este caso para una red de telefonía móvil) y envía información de configuración basado en reglas para varios conmutadores, aplicaciones de facturación y otras aplicaciones. Tienden a ser bastante complejos. Cuando compra un plan de teléfono móvil con tantos minutos y tantos mensajes de texto por mes, una aplicación de aprovisionamiento está enviando información de configuración al resto del sistema sobre sus reglas de acceso y facturación.