Una progettazione di processo è davvero una programmazione dichiarativa?

Question

Ho sentito da qualcuno che stanno usando uno strumento di automazione dei processi aziendali (come l'integrazione di Weblogic) come linguaggio di programmazione (che sembra qualcosa di stupido) per rendere le cose dichiarative. Quindi hanno inserito tutta la logica all'interno di un processo, ogni singolo if e while .

Ma, non è un processo un modo per passo passo entità per raggiungere un obiettivo?

Per me rende un processo completamente imperativo. Cosa ne pensi?

Answer 1

Non è sicuramente ciò che la gente di solito intende quando parlano di programmazione dichiarativa , anche se in qualche modo può essere chiamato dichiarativo.

Answer 2

I linguaggi di orchestrazione sono in effetti linguaggi di script imperativi con condizionali, loop e altri costrutti tradizionalmente imperativi , generalmente espresso tramite un'interfaccia utente basata su diagramma di flusso. Certamente non (nella mia esperienza) implementano la programmazione funzionale ricorsiva della coda, il concatenamento a ritroso o qualsiasi altro paradigma che potrebbe ragionevolmente essere descritto come dichiarativo in senso generalmente accettato.

MS Workflow Foundation è pubblicizzato come un motore di regole, ma questo è abbastanza semplicistico e non fa realmente concatenamento, tranne che in modo un po 'circolare. ILOG in realtà crea un adattatore per il loro motore di regole specificamente per inserirlo nella base del flusso di lavoro di MS.

Altri strumenti per il flusso di lavoro hanno motori di regole migliori e un sistema di concatenamento corretto che può essere considerato dichiarativo. Tuttavia, una volta che entri nei flussi di lavoro stessi con i cicli ciclici e condizionali, sei sicuramente nel territorio della programmazione imperativa.

Tuttavia, alcuni sistemi implementano anche un sistema di markup basato sul cambiamento di rete o sul cambiamento di stato per il flusso di lavoro, che potrebbe ragionevolmente essere descritto come dichiarativo, ma hanno ancora una modalità imperativa di interazione con il sistema sottostante. Aggiornano ancora le variabili e hanno effetti collaterali.

Ho visto una o due applicazioni (ad esempio TOAD per anlaysis di dati ) utilizza effettivamente MS Workflow Foundation come linguaggio di scripting. Come tale ti consente di aggiungere una funzione di scripting all'applicazione che (almeno per scopi di marketing) non richiede abilità di programmazione da usare.

In pratica, uno strumento progettato per scrivere, modificare ed eseguire query SQL, dotato di un framework di scripting per "non programmatori", ci si chiede a quale pubblico sia realmente rivolto. Come linguaggio di scripting, gli strumenti di modellizzazione del flusso di lavoro sono abbastanza goffi e offrono opportunità di astrazione molto limitate; in pratica un linguaggio di scripting basato su .Net come IronPython o Boo, in particolare in combinazione con un meccanismo di modellamento decente, sarebbe un'aggiunta molto potente a tale strumento.

Un punto sui linguaggi grafici di questo tipo è che non si adattano bene alla complessità. Un problema simile si applica anche agli strumenti ETL. Ho visto un'applicazione di provisioning (vedi sotto) che è stata fatta (ironicamente) con Crossworlds (ora noto come Websphere Integrator). Entro un mese dall'avvio dell'applicazione è diventato evidente che il linguaggio del flusso di lavoro grafico non si sarebbe ridimensionato con la complessità dell'applicazione ed è stato ricostruito, basato su un motore di regole personalizzato scritto in Java e un corpus abbastanza grande di su misura codice java.

Questo tipo di problema non è inusuale con i sistemi EAI e Orchestration ed è una delle ragioni per cui La SOA è difficile da attuare nella pratica. Quello che stai facendo è in realtà spingere la logica di business in un ambiente di programmazione molto goffo che non viene ufficialmente riconosciuto come tale. Funzionerà in un caso semplice ma è difficile far funzionare un sistema complesso: questo è una specie di segreto colpevole nei circoli SOA.

Coda: Un'applicazione di provisioning è un sistema che prende piani per i contratti di servizi di telecomunicazione (in questo caso per una rete di telefonia mobile) e invia le informazioni di configurazione sulla base di regole per vari switch, applicazioni di fatturazione e altre applicazioni. Tendono ad essere abbastanza complessi. Quando acquisti un piano di telefonia mobile con così tanti minuti e così tanti messaggi al mese, un'applicazione di provisioning invia le informazioni di configurazione al resto del sistema in merito alle tue regole di accesso e fatturazione.