Языки оркестровки - это фактически imperative scripting languages с условностями, циклическими и другими традиционно императивными конструкциями, обычно выражаемыми через пользовательский интерфейс на основе последовательности операций. Конечно, они (по моему опыту) не реализуют хвостовое рекурсивное функциональное программирование, обратную цепочку или любую другую парадигму, которая может быть разумно описана как декларативная в общепринятом смысле.
MS Workflow Foundation рекламируется как имеющий механизм правил, но это довольно упрощенно и на самом деле не преследует цепочку, за исключением нескольких обходных путей. ILOG фактически делает адаптер для своего механизма правил специально, чтобы отбросить его в основу рабочего процесса MS.
Другие инструменты документооборота имеют лучшие двигатели правил и правильную систему цепной передачи, которая может рассматриваться как декларативная. Однако, как только вы попадаете в рабочие процессы с помощью циклов и условных ветвей, вы определенно находитесь на территории императивного программирования.
Однако некоторые системы также используют систему разметки, основанная на изменениях в петричной сети или состоянии для рабочего процесса, которая может быть разумно описана как декларативная, но по-прежнему имеет императивный режим взаимодействия с базовой системой. Они по-прежнему обновляют переменные и имеют побочные эффекты.
Я видел одно или два приложения (например, TOAD for data anlaysis), фактически используя MS Workflow Foundation в качестве языка сценариев. Таким образом, это позволяет добавить в приложение средство сценариев, которое (по крайней мере, в маркетинговых целях) не требует использования навыков программирования.
На практике инструмент, предназначенный для написания, редактирования и запуска SQL-запросов, оснащенных структурой сценариев для «не-программистов», заставляет задуматься о том, на какую аудиторию он действительно нацелен. В качестве языка сценариев инструменты моделирования рабочего процесса довольно неуклюжи и предлагают очень ограниченные возможности для абстракции; на практике язык сценариев на основе .NET, такой как IronPython или Boo, особенно в сочетании с достойным механизмом шаблонов, будет очень мощным дополнением к такому инструменту.
Одним из таких графических языков является то, что они не масштабируются со сложностью. Аналогичная проблема относится и к инструментам ETL. Я видел приложение обеспечения (см. Ниже), которое было сделано (по иронии судьбы) с помощью Crossworlds (теперь известного как Websphere Integrator). В течение месяца после запуска приложения стало очевидно, что графический язык рабочего процесса не будет масштабироваться со сложностью приложения и он был перестроен на основе механизма пользовательских правил, написанного на Java, и довольно большого количества заказных java-код.
Этот тип проблемы нередко встречается с системами EAI и Orchestration и является одной из причин, по которым SOA трудно реализовать на практике. То, что вы делаете, фактически подталкивает бизнес-логику к очень неуклюжей среде программирования, которая официально не признается таковой. Это будет работать в простом случае, но трудно работать над сложной системой - это своего рода секрет, скрытый в кругах SOA.
Coda: приложение инициализации представляет собой систему, которая принимает планы по контрактам телекоммуникационных услуг (в данном случае для сети мобильной связи) и передает информацию о конфигурации на основе правил из различных переключателей, биллинг приложений и других приложений , Они, как правило, довольно сложны. Когда вы покупаете план мобильного телефона с таким количеством минут и так много текстов в месяц, приложение обеспечения выдает конфигурационную информацию остальной системе о ваших правилах доступа и биллинга.