プロセス設計は本当に宣言型プログラミングですか？

Question

私は誰かが、ビジネスプロセス自動化ツール（Weblogic Integrationなど）をプログラミング言語（ある種の馬鹿げたもののように聞こえます）として使用して、物事を宣言的にしていると聞きました。次に、すべてのロジックをプロセス内に配置します。すべての if および while です。

しかし、プロセスは目標に到達するための段階的なエンティティの方法ではありませんか？

私にとっては、プロセスが完全に必須になります。どう思いますか？

Answer 1

間違いなく、宣言型プログラミングについて話すとき、人々が通常意味するものではありません何らかの意味を宣言と呼ぶことができます。

Answer 2

オーケストレーション言語は、実際には、条件、ループ、およびその他の伝統的に命令型の構成を持つ命令型スクリプト言語です。 、通常はフローチャートベースのユーザーインターフェースで表されます。彼らは確かに（私の経験では）末尾再帰関数プログラミング、バックワードチェーン、または一般に受け入れられている意味で宣言的と合理的に説明されるその他のパラダイムを実装していません。

MS Workflow Foundationはルールエンジンを備えていると宣伝されていますが、これはかなり単純化されており、多少のラウンドアバウト方法を除き、実際にはフォワードチェーンを行いません。 ILOGは、実際にルールエンジン用のアダプターを作成して、MSワークフローの基盤にドロップします。

他のワークフローツールには、より優れたルールエンジンと、宣言型と見なすことができる適切なフォワードチェーンシステムがあります。ただし、ループと条件付きブランチを使用してワークフロー自体に入ると、命令型プログラミングの領域にいることは間違いありません。

ただし、一部のシステムでは、ワークフロー用にペトリネットまたは状態変更ベースのマークアップシステムも実装しています。これは、宣言型として合理的に説明できますが、基礎となるシステムとの対話の命令モードがまだあります。それらはまだ変数を更新し、副作用があります。

1つまたは2つのアプリケーションを見ました（たとえば、データ分析のTOAD ）実際にスクリプト言語としてMS Workflow Foundationを使用します。そのため、（少なくともマーケティング目的のために）プログラミングスキルを使用する必要のないスクリプト機能をアプリケーションに追加できます。

実際には、「非プログラマ」向けのスクリプトフレームワークを備えたSQLクエリを作成、編集、および実行するために設計されたツールは、どのオーディエンスを本当に対象としているのか不思議に思います。スクリプト言語として、ワークフローモデリングツールはかなり不器用で、抽象化の機会が非常に限られています。実際には、IronPythonやBooなどの.Netベースのスクリプト言語は、特に適切なテンプレートメカニズムと組み合わせて、このようなツールに非常に強力な追加機能となります。

この種のグラフィカル言語についての1つのポイントは、複雑になってもうまく拡張できないことです。同様の問題がETLツールにも当てはまります。 Crossworlds（現在はWebsphere Integratorとして知られている）で（皮肉にも）行われたプロビジョニングアプリケーション（以下を参照）を見てきました。アプリケーションを開始してから1か月以内に、グラフィカルワークフロー言語がアプリケーションの複雑さに合わせて拡張されず、Javaで記述されたカスタムルールエンジンとかなり大量の特注に基づいて再構築されたことが明らかになりましたJavaコード。

このタイプの問題は、EAIおよびOrchestrationシステムでは珍しくなく、である理由の1つです。 SOA は実際には実装が困難です。あなたがしているのは、実際にビジネスロジックを非常に不器用なプログラミング環境に押し込むことです。これは単純なケースでは機能しますが、複雑なシステムで動作させるのは困難です-これはSOAサークルでの有罪の秘密です。

コーダ： プロビジョニングアプリケーションは、電気通信サービス契約（この場合は携帯電話ネットワーク）のプランを取り、構成情報をプッシュするシステムです。 さまざまなスイッチ、課金アプリケーション、その他のアプリケーションに対するルールに基づいています。それらはかなり複雑になる傾向があります。毎分非常に多くのテキストと非常に多くのテキストを含む携帯電話プランを購入すると、プロビジョニングアプリケーションは、アクセスおよび課金ルールに関する構成情報をシステムの残りの部分にプッシュします。