私は BizTalk の経験が少しあり、BizTalk 2009 ESB Toolkit 2 を使用せずに理解しようとしています。まず、誰かが私のためにいくつかの概念を明確にすることができるかどうか疑問に思っています:
いくつかのより一般的な質問:
洞察をお寄せいただきありがとうございます。
私はあなたの2番目の質問だけに取り組んでいます:
2) なぜ旅程が必要なのですか? ポートとオーケストレーションを使用して同じものを簡単に作成できないのですか? ここで明らかに何かが欠けています。
私が最後に働いていた場所では、約 1 年間 ESB に取り組みました。itenary の考え方は、メッセージが ESB に入ると、魔法のように正しい順序で適切なシステムに送られるべきだというものです。
ビジネス プロセス指向 (BPM) システムでは、通常、オーケストレーションを記述してロジック フローを指示します。つまり、オーケストレーションでメッセージの旅程またはパスをコーディングします。私たちが構築した ESB では、ビジネス ルールによってメッセージの行き先が決まりました。エンドポイントのオーケストレーションはまだありましたが、それらは通常短く、マッピングといくつかの非常に基本的な機能のみを行いました。私が働いたことのある他の場所では、オーケストレーションは非常に大きくなる可能性があります。
したがって、メッセージをどうするかというルールはどこかになければなりません。ESB では、各エンドポイントは完全に不可知であり、他のエンドポイントを認識しない必要があります。ESB 陣営は、ソフトウェア (つまり、オーケストレーション) を再デプロイすることなく、システムをより動的に変更する必要があると想定しています。そのため、ESB を使用すると、ビジネス ルールを変更して再デプロイするだけで済みます。
ESB に関する困難な問題のいくつかは、トランザクションの処理、ロールバック、および通常は一般的なエラー処理プロセスの作成です。
ニール・ウォルターズ http://BizTalk-Training.com
オンランプ
オンランプはWeb サービス ベースの受信ポートですが、一般的な XML メッセージを受け入れるため、少し異なります。ただし、メッセージには、たとえばメッセージの旅程を可能にするために必要なすべてのプロパティを備えた非常に特別な SOAP ヘッダー (場合によっては「エンベロープ」) があります。
旅程
これについてのNealWalterの返信が好きです。ただし、旅程のアプローチにより、多くの時間と開発労力を節約できる可能性があるというメッセージを追加したいと思います。組織の機敏性を高め、プロセスの変更を容易にすることができます。まったく新しいオーケストレーションを開発して展開する必要がなく、一部の構成を変更して既存のビットを使用するだけで、もちろん多くの時間を節約できます。そして、これが ESB とメッセージの旅程の大きな価値だと私は考えています。
メッセージボックス
BizTalk のメッセージは、常にメッセージ ボックスを経由する必要があります。次のバージョンでは、MS は BizTalk の低レイテンシ シナリオについてほのめかしています。その場合、もう少し制御できるようになるかもしれません。
いくつかの追加ビュー -
受信ポート/オンランプ- Riri の回答に完全に同意し、単純に追加します - BizTalk ESB アプリケーションのコンテキストでのオンランプは、受信ポートの特定の実装です。サブセット; 専用ケース。受信ポートを使用して、ESB ワールドからパターンを実装します。そう - それらは本質的に異なっていません。
旅程- 繰り返しますが、ニールとリリの両方に同意し、あなたの質問に答えて追加します。BizTalk ESB はさまざまな方法で旅程を使用できます。あまり手がかりのないクライアントは単純にメッセージを配信でき、ESB インフラストラクチャ (または、その実装) は特定の要求に関連する旅程を解決できます (これは、リゾルバー、すぐに使用できる、または必要な旅程を決定するためにさまざまな方法を使用するカスタム)。理論的には、クライアントが旅程を提供する場合でも、2 つを組み合わせることができますが、ESB オンランプがそれを置き換え/変更します。
一般的な質問ですが、私が覚えている限りでは、はい、すべてのメッセージがメッセージ ボックスを通過します。しかし、私は BizTalk 2006 R2 を使用しています。ここの写真を見てください。
他の2つの質問については、私は自分で完全に理解することはできませんでした. 今は調査する時間がありませんが、誰も教えてくれなければ調査するでしょう :)