オーケストレーションはESBの責任ですか？

Question

エンタープライズサービスバスです（メディエーター、メッセージブローカー、サービスイネーブラー、スキーマ変換エンハンサー、トランスペアレントロケーションプロバイダー、サービスアグリゲーター、ロードバランサー、モニター、およびすべてとして機能するツールそのようなもの）サービスをオーケストレーションする責任がある？

エンタープライズサービスバス内に、1000を超えるステップと数十のサービス呼び出しを含む自動化されたビジネスビジネスプロセスを配置するのはどうですか？

それを行いますか、またはBPELエンジンなどのオーケストレーションのスペシャリストを使用しますか？

ご意見をお聞かせください。

Answer 1

はい、いいえ。オーケストレーションとアグリゲーション/サービスの増強の間には、細くて区別できない線があります。

一般的に、長期または複雑なビジネスプロセス（プロセスはキーワードですが、定義は避けます）がある場合は、BPELに最適です。

3つのサービスコールの結果を集約するなどの単純なタスクは、ESBレイヤーで実行できる場合が多くあります。

ただし、あまりにも多くの睡眠を失う価値はありませんが、

免責事項：私はIBM ESBコンサルタントですが、公式の立場でこれを書いているわけではありません。

Answer 2

いいえ、ESBの責任はサービスのオーケストレーションではありません（それ自体）。 ESBは、<！> quot;ソフトウェアインフラストラクチャレベル<！> quot;で抽象化のレイヤーを提供します。

これは、ESBが<！> quot;接続のための単一の論理抽象ポート<！> quot;であることを意味します。バスで公開されているすべてのサービスで。

ESBは抽象的であり、バス上のサービスの消費者は<！> quot;知る必要はありません<！> quot;サービスの展開の詳細、および<！> quot;内部に面したサービス<！> quot;を公開することができます。単一のドキュメントモデル。 ESBは低レベルのサービス（プロトコル変換やメッセージ変換など）を提供するため、内部サービスは簡単に通信できます。

これは、何らかのオーケストレーションを意味します：ESBは、前述の低レベルサービスのオーケストレーションを提供します（IIOPを介してサービスXが呼び出される場合、これをAttachmentsを使用してSOAPに変換します。

ESBで通常回避するオーケストレーションは次のとおりです。この（保険）販売を処理するには、まず購入者から提供された情報を検証し、次に保険のリスクを引き受け、最後に計算する必要があります。保険の支払いが必要な保険料。その後、<！>＃8230;など。

上記の手順は明らかにビジネスプロセスです（中断される可能性さえあります<！>＃8230。たとえば、自動引受が不可能な場合、人間の引受人はリスクをさらに評価する必要があります）。

通常オーケストレーションと呼ばれるビジネスプロセス（保険販売など）を構成するビジネスサービス（検証、保険引受、保険料計算）は、ビジネスプロセスエンジンでの実行に最適であり、正式化されたビジネスプロセスモデリング言語（BPELなど）。

また、プロセスの多くのステップについて推測する：上記の例では、Validationは（コースグレイン）サービスです。検証ルール自体はそのサービスの内部にあります。複雑なビジネスルール（ビジネスプロセスではない）の場合、ビジネスルールエンジンの使用が必要になる場合があります。

Answer 3

私の短い簡単な答えはNOであり、その責任ではありません。

私はそれをBPELまたはBPMスイートに任せたいと思います。

Mhh私は他に何を追加するのか分からない:) ...頑張って？

Answer 4

今、私自身のビジョン。

ESBが行わなければならないすべての作業に関して、SOAの主要なインフラストラクチャ要素内にサービスオーケストレーションを配置することは良い考えではありません。

集計、OK！しかし、ビジネスロジックを使用してコミュニケーションチャネルをビジー状態にすると、他の機能を提供する能力に大きな影響を与えることになります。

結局、BEA Aqualogic ServiceなどのほとんどのESB は、ステートフルの欠如機能、およびwait（タイマー）またはpick（プロセスで入力が移動するのを待つ）、split / join機能（ALSB 3.0に既に追加されている）など。

まさか。 BPELエンジンのようなツールまたはWeblogic Integrationのようなツールを使用するだけです。

ありがとう。

Answer 5

相互作用する2つ以上のサービスがある場合は常に、サービスオーケストレーターを使用します。つまり、構成およびプロセス制御サービスに使用します。 esbがある場合は、esbでこの構成サービスを公開します。この構成サービスを含む新しいサービスを構成する必要がある場合は、オーケストレーターを使用して、esbで再度公開する必要があります。 サービス配信メカニズムとWebサービスブローカーおよびプロキシとしてesbを使用します。サービスオーケストレーターの作成では、esbを使用して対話型サービスに到達します。これらの相互作用サービスが互換性のないxmlスキーマを使用する場合、esbは実行時にそれらを共通スキーマに変換/マッピングし、コンテンツに基づいてサービスリクエストをルーティングできます。名前空間。

Answer 6

はい、オーケストレーションは、ほとんどの場合、ESBの責任です。または、ESBインフラストラクチャとオーケストレーションインフラストラクチャの間に線を引く場合、責任の論理的帰属ではなく、パフォーマンス上の理由で物理レベルで線を引きます。

2つの選択肢があります-たとえば、HRシステムが新しい従業員を受け取った場合-<！> quot;というビジネスロジックをどこに配置しますか？ OK、HR部門は雇用を確定する必要があります。その後、経理部門は新しいエントリが必要になり、給与計算システムを更新する必要があります。それが失敗した場合は、HR <！> quot ;?すべてのビジネスプロセスが開始部門/アプリケーションによって「所有」されていると見なされると、エンタープライズであるシステム全体が複雑になり、オーケストレーションシステムが異なります。

2番目の選択肢は、オーケストレーションを集中化することであり、オーケストレーションを本質的にメッセージングプラットフォームの論理パートナーにします。これらを別々のアーティファクトとして見ることを選択した場合、それはあなた次第ですが、ESBとして両方を説明することは等しく有効です。

Answer 7

Enterprise Service Busは、サービスのオーケストレーションに責任を負うべきではありません。

オーケストレーションは、最低<！> quot; smarts <！> quot ;、具体的には失敗したトランザクションを補正する機能を意味します。サービスバスツールは、多くの場合、<！> quot; try-catch <！> quot;またはそのようなものですが、スコープ付きコンポジションを実行する能力は、適切なオーケストレーションツールのマークです。さらに、待機したり、自身の状態を把握したり、物事を中断状態にしたりする能力は、バスではなくオーケストレーターを扱っていることを示すもう1つの指標です。

1000以上のステップに加えて数十のサービスについて話す場合、if-thenのプロセスを検討してください。 1000ステップのすべてのif-thenステートメントが、ペイロードを変更せずにルーティングのみを話す場合は、<！> quot; routing <！> quot;のままです。したがって、まだESBにあります。しかし、if-thenが1つでもネストされている場合は、さまざまなツールを探し始めます。余談ですが、ルーティングのように見えるif-thenは、ビジネスロジックに非常に迅速に影響を与える可能性があります。ビジネスロジックが表示され始めたら、BPELやBPMNなどの優れた言語が優れています。

オーケストラの指揮者の例は、オーケストレーションがどのように機能するかを説明するためによく与えられます。オーケストラは、スコアに従ってミュージシャンを指揮する中心人物です。多くの場合、省略されるのは、指揮者が指揮するだけでなく、聞くことでもあるという考えです。何か問題が発生した場合、信頼性の高い再現可能な方法で補償できます。

たとえば、最初の指揮者がチューバ奏者を連れてきたが、チューバ奏者が他のことをすることにしたと想像してください。シンプルなピンボールスタイルの<！> quot; orchestrator <！> quot;チューバのセクションに来て、そこにないことを十分に知ってから、観客が後で文句を言うのを待ちます。本当に精通した指揮者はチューバが消えてしまい、すぐにそれを補うためにより深いバリトンの角を持ち上げます。