Enterprise Service Bus (メディエーター、メッセージ ブローカー、サービス イネーブラー、スキーマ変換エンハンサー、透過的なロケーション プロバイダー、サービス アグリゲーター、ロード バランサー、モニターなどとして機能するツール) は、サービスのオーケストレーションを担当していますか?
エンタープライズ サービス バス内に、1000 以上のステップと数十のサービス呼び出しを含む自動化されたビジネス ビジネス プロセスを配置するのはどうでしょうか?
それを行いますか、それとも BPEL エンジンなどのオーケストレーションのスペシャリストを使用しますか?
ご意見をお聞かせください。
はいといいえ。オーケストレーションとアグリゲーション/サービス拡張の間には、細く、時には区別がつかない境界線があります。
一般に、長期にわたる、または複雑なビジネス プロセス (プロセスはキーワードですが、定義は避けます) がある場合は、BPEL が最適です。
3 つのサービス呼び出しの結果を集約するなどの単純なタスクは、ESB レイヤーで実行できますし、多くの場合、実行する必要があります。
とはいえ、あまりにも多くの睡眠を失う価値はありません
免責事項: 私は IBM ESB コンサルタントですが、これは公式の資格で書いているわけではありません。
いいえ、ESB の責任は、サービスのオーケストレーション (それ自体) ではありません。ESB は、「ソフトウェア インフラストラクチャ レベル」で抽象化のレイヤーを提供します。
これは、ESB が、バス上で公開されている任意のサービスとの「接続のための単一の論理的な抽象呼び出しポート」であることを意味します。
ESB が抽象的であることは、バス上のサービスのコンシューマーがサービスの展開の詳細を「知る必要がない」ことを意味し、単一のドキュメント モデルで「内部向けサービス」を公開することが可能です。ESB は低レベルのサービス (プロトコル変換やメッセージ変換など) を提供するため、内部サービスは簡素化された方法で通信できます。
これは、いくつかのオーケストレーションを意味します。ESB は、前述の低レベル サービスのオーケストレーションを提供します (たとえば、サービス X が IIOP 経由で呼び出された場合、これを添付ファイル付きの SOAP に変換します。次に、シリアル化されたデータからの要求を XML ペイロードに変換します)。
ESB で通常回避するオーケストレーションは次のとおりです。この (保険) 販売を処理するには、まず買い手から提供された情報を検証する必要があり、次に保険のリスクを引き受け、最後に必要な保険料を計算する必要があります。保険料を支払う必要があり、その後…などを行う必要があります。
上記の手順は明らかにビジネス プロセスです (中断される可能性もあります。たとえば、自動引受が不可能な場合は、人間の引受人がリスクをさらに評価する必要があります)。
通常、オーケストレーションと呼ばれるビジネス プロセス (保険販売など) を構成するビジネス サービス (検証、引受、保険料計算など) は、ビジネス プロセス エンジンで実行するのに最適であり、正式なビジネス プロセスを使用して定義されます。モデリング言語 (BPEL など)。
また、プロセスの多くのステップについても推測します。上記の例では、検証は (粗粒度の) サービスです。検証ルール自体は、そのサービスの内部にあります。複雑なビジネス ルール (つまり、ビジネス プロセスではない) の場合、ビジネス ルール エンジンの使用が必要になる場合があります。
私の短い簡単な答えはノーです。それはその責任ではありません。
私はそれを BPEL または BPM スイートに任せたいと思います。
うーん、他に何を追加すればいいのかわからない:) ...頑張ってね？
今、私自身のビジョン。
ESB が行わなければならないすべての作業に関して、サービス オーケストレーションを SOA の主要なインフラストラクチャ要素内に配置することはお勧めできません。
集計、よし！しかし、コミュニケーション チャネルをビジネス ロジックで忙しくしておくと、他の機能を提供する能力に大きな影響を与えることは間違いありません。
結局のところ、BEA Aqualogic Service などのほとんどの ESBでは、オーケストレーションのサポートが制限されており、ステートフル機能の欠如や、待機 (タイマー) やピック (プロセスで何らかの入力が移動するのを待つ)、分割/結合機能 ( ALSB 3.0 ですでに追加されています)、など。
とんでもない。BPEL エンジンや Weblogic Integration などのツールを使用するだけです。
ありがとう。
相互作用する 2 つ以上のサービスがある場合は常に、サービス オーケストレータを使用します。つまり、構成およびプロセス制御サービスに使用します。esb を持っている場合は、esb でこのコンポジション サービスを公開します。この構成サービスを含む新しいサービスを構成する必要がある場合は、オーケストレーターを使用して、esb で再度公開します。esb をサービス配信メカニズムと Web サービス ブローカーおよびプロキシとして使用します。サービス オーケストレーターを作成する際に、esb を使用して相互作用するサービスにアクセスします。これらの相互作用するサービスが互換性のない xml スキーマを使用する場合、esb は実行時に共通のスキーマに変換/マッピングし、名前空間などのコンテンツに基づいてサービス リクエストをルーティングできます。
はい、ほとんどの場合、オーケストレーションは ESB の責任です。あるいは、ESB インフラストラクチャとオーケストレーション インフラストラクチャの間に線を引く場合、責任の論理的な帰属のためではなく、パフォーマンス上の理由から物理レベルで線を引くことになります。
選択肢は 2 つあります。たとえば、HR システムが新しい従業員を受け入れた場合、「コンプライアンス部門が最初に承認およびチェックする必要があり、それでよければ人事部門が必要とする」というビジネス ロジックをどこに配置しますか。採用を確定するには、経理部門が新しいエントリを必要とし、次に給与システムを更新する必要があります。それが失敗した場合は、人事部に電子メールを送信する必要があります。」すべてのビジネス プロセスが開始した部門/アプリケーションによって「所有されている」と見なされる場合、企業であるシステム全体が複雑になり、さまざまなオーケストレーション システムが存在します。
2 番目の選択肢は、オーケストレーションを一元化して、基本的にメッセージング プラットフォームの論理的なパートナーにすることです。これらを別個の成果物として見ることを選択する場合、それはあなた次第ですが、両方を ESB として説明することは等しく有効です。