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