私たちのビジネスは、約 2000 人ほどのユーザーを含むかなり大規模なビジネス アプリケーションを構築することを計画しています。
システム内の多くのオブジェクトは、やや複雑な一連の承認、通知などを必要とします。
さまざまな理由から、当社は BPMN または BPEL の正式な使用を拒否することにしました。私が探しているのは、これらのオブジェクトの状態を促進、追跡、および管理する手段として、これらのオブジェクトを渡すことができるワークフロー エンジンです。このプロジェクトは、EJB 3.1 と WebSphere AS を使用して実装しています。
ワークフロー エンジンに関する私の理解は正しいですか? すべてが BPMN または BPEL に関連付けられているようです...ほとんどのソリューションが BPMN または BPEL を実装しているように見える理由について、ここで何かが足りないのですか? いくつかのアドバイスは素晴らしいでしょう！
ワークフローエンジンは通常、エンタープライズアーキテクチャで積極的な役割を果たします。それらは宣言型プロセスモデルを実行します。これは基本的に、アクティビティまたはタスクを表すノードと、これらのエッジ間の制御フローを表すエッジで構成される有向グラフです。このようなエッジには、条件付きの分岐/マージを表現できるように条件を付けることができます。YAWL、XPDL、jPDL、BPEL、BPMN 2.0など、いくつかのモデリング言語があります。これらは、これらの抽象的な概念といくつかの構文的、視覚的、機能的な砂糖の上にありますが、公式の業界標準は後者だけです。これは、ベンダーのロックを回避し、モデルを（少なくともある程度は）交換可能にし、専門家やさまざまなツールでサポートできるようにするために重要です。実行時に、プロセスインスタンスは、プロセスモデルに基づいて作成され、モデルによって定義された制御フローに従って実行されます。したがって、エンジンは1つのアクティビティから次のアクティビティにアクティブにナビゲートし、ビジネスロジックを「調整」します。BPMN 2.0とBPELの主な違いは、BPELがWebサービスと緊密に結合されていることです。つまり、アクティビティによって呼び出されるビジネス機能はWebサービスとしてレンダリングされることになっています。したがって、WS- *サービスを調整したい場合でも、BPMN 2.0には具体的なサービス実装への明確に定義され、標準化されたバインディングがないため、これが最良の選択です。いずれにせよ、標準化された言語の1つを使用することを強くお勧めします。これらの言語は業界で広く受け入れられており、さまざまなベンダーやオープンソースコミュニティによって十分にサポートされているからです。したがって、エンジンは1つのアクティビティから次のアクティビティにアクティブにナビゲートし、ビジネスロジックを「調整」します。BPMN 2.0とBPELの主な違いは、BPELがWebサービスと緊密に結合されていることです。つまり、アクティビティによって呼び出されるビジネス機能はWebサービスとしてレンダリングされることになっています。したがって、WS- *サービスを調整したい場合でも、BPMN 2.0には具体的なサービス実装への明確に定義され、標準化されたバインディングがないため、これが最良の選択です。いずれにせよ、標準化された言語の1つを使用することを強くお勧めします。これらの言語は業界で広く受け入れられており、さまざまなベンダーやオープンソースコミュニティによって十分にサポートされているからです。したがって、エンジンは1つのアクティビティから次のアクティビティにアクティブにナビゲートし、ビジネスロジックを「調整」します。BPMN 2.0とBPELの主な違いは、BPELがWebサービスと緊密に結合されていることです。つまり、アクティビティによって呼び出されるビジネス機能はWebサービスとしてレンダリングされることになっています。したがって、WS- *サービスを調整したい場合でも、BPMN 2.0には具体的なサービス実装への明確に定義され、標準化されたバインディングがないため、これが最良の選択です。いずれにせよ、標準化された言語の1つを使用することを強くお勧めします。これらの言語は業界で広く受け入れられており、さまざまなベンダーやオープンソースコミュニティによって十分にサポートされているからです。0およびBPELは、BPELがWebサービスと緊密に結合されていることを意味します。つまり、アクティビティーによって呼び出されるビジネス機能は、Webサービスとしてレンダリングされることになっています。したがって、WS- *サービスを調整したい場合でも、BPMN 2.0には具体的なサービス実装への明確に定義され、標準化されたバインディングがないため、これが最良の選択です。いずれにせよ、標準化された言語の1つを使用することを強くお勧めします。これらの言語は業界で広く受け入れられており、さまざまなベンダーやオープンソースコミュニティによって十分にサポートされているからです。0およびBPELは、BPELがWebサービスと緊密に結合されていることを意味します。つまり、アクティビティーによって呼び出されるビジネス機能は、Webサービスとしてレンダリングされることになっています。したがって、WS- *サービスを調整したい場合でも、BPMN 2.0には具体的なサービス実装への明確に定義され、標準化されたバインディングがないため、これが最良の選択です。いずれにせよ、標準化された言語の1つを使用することを強くお勧めします。これらの言語は業界で広く受け入れられており、さまざまなベンダーやオープンソースコミュニティによって十分にサポートされているからです。
「これらのオブジェクトの状態を促進、追跡、および管理する」とはどういう意味か完全にはわからなかったため、これをより詳細に説明しようとしました。これは、ワークフローエンジンを使用して状態の変化をアクティブに制御するのではなく、オブジェクトの状態の変化をパッシブに監視することに関心があるように聞こえます。この仮定が正しければ、おそらく抽象ステートマシンがあなたのニーズによりよく合うでしょう。
jBPM5 を見てください。これは非常に柔軟なコアを提供し、その上に独自のドメイン固有言語を構築できるようにします。現在提供されている言語は BPMN2 ですが、独自の言語を簡単に追加できます。乾杯
私たちは、BPMN 2.0 への移行パスを持つ製品を構築していますが、内部では BPMN を使用していません。チェックリストは、フローチャートよりもリアルタイム ワークフローで使用する方がはるかに簡単であると考えています。ただし、まだルール/トリガー/条件などがあります-したがって、プロセスを「ステロイドのチェックリスト」として効果的にモデル化するツールです。
http://tallyfy.comでチェックしてください