15

質問があります-BizTalkまたはWF？そして、最初の3つのアーティファクトの背後にある類似のテクノロジーを認識し、それらを構築できることを明確にしておきますが、それらがWFに組み込まれていることがわからないため、なぜ1つを使用するのかを理解しようとしています。他の技術よりも。

  1. 変換
  2. バインディング
  3. ポート/アダプター
  4. BizTalk Future

変換

BizTalkがネイティブにサポートされており、起動する設計者が強化されており、スキーマとマップを作成する機能がサポートされているのは非常に便利です。さらに、ワークフロー内の統合ポイントについて心配する必要がないため、すべてが変換されるという事実が気に入っています。これは、統合が変化するときにリスクを軽減する一貫した形式であるためです。スキーマとマップをリファクタリングするだけで済みます。 。

対照的に、WFの場合、その豪華さは組み込まれていないので、何かが足りないのでしょうか、それともBizTalkに+1がありますか？

バインディング

バインディングは、BizTalkのもう1つの完全にカプセル化された機能です。前述のアーティファクトにより、ワークフローを文字通り任意のバインディングに設定できます。つまり、テスト中にファイルシステムにバインドでき、本番環境中にサービスにバインドできます。

対照的に、WFでは、そのような贅沢な機能が組み込まれていないので、何かが足りないのでしょうか、それともBizTalkに+2があるのでしょうか。

ポート/アダプター

これは、BizTalkに存在する最大のアーティファクトである可能性があります-IMHO。物理的な接続を多数の具体的な実装に抽象化するために必要な労力。特に、これらの具体的なものの一部が基本的なファイルシステムとSOAP / RESTを超えて、IBMメインフレームやMSMQなどに到達する非常に大規模な組織ではそうです。ワークフローにメッセージを送信する前に、変換を通じて生データを自動的に実行するBizTalkの物理ポートアダプターは、非常にシンプルで洗練されています。

対照的に、WFでは、そのような贅沢な機能が組み込まれていないので、何かが足りないのでしょうか、それともBizTalkに+3があるのでしょうか。

BizTalk Future

最後に、私の調査から、BizTalkを構築したのと同じチームがWFを構築していることを述べておきます。これは素晴らしいことです。さらに、Microsoftの長期的なビジョンは、この新しい流行語「統合サーバー」であり、事実上、BizTalkが今日行うことを提供する緩く結合されたフレームワークの大規模な配列です。そして、Azureの取り組みのおかげで、その取り組みは私にとって非常に理にかなっています。これが貢献していると確信しています。ただし、15年後に機能するソリューションを今日実装する必要がありますが、BizTalkよりもWFを活用する場合、ソリューションをまとめるためにどの部分を使用する必要があるかも理解する必要があります。あなたの経験を教えてください。

4

2 に答える 2

14

(免責事項 - 私の WF の経験は WF3.0 に限定されているため、最近の WF の開発に遅れをとっている可能性があります)

BizTalk は、システム間、部門間、および企業間の統合 + ビジネス プロセス ワークフロー (BPEL)、つまりエンタープライズの問題に最も適しています。IMO WF はこれまで、内部システムまたはアプリケーションの問題に重点を置いてきました。しかし、どちらも Azure + Appfabric に向かって収束しているように見えるため、ますます灰色の領域が増えていることは間違いありません。

統合のためにWFを見ているようですか？

変換- 間違いなく BizTalk の利点 - XSLT で視覚的または直接的にマッピングできるため、ポートまたはオーケストレーションでメッセージ形式をすばやく変換でき、物理テクノロジを後付けとして使用できます。つまり、設計をすぐに実装できます。論理レベルであり、特定のテクノロジ (MQ、WCF、SQL、FTP など) で「行き詰まる」ことはありません。

1 つの注意点 - スキーマの管理は非常に面倒になる可能性があります。すべてのメッセージにはスキーマがあり、BizTalk のすべてのアプリで一意の XMLNS#Root が必要です。また、「不可知論者」になって、内部フローに正規のスキーマを使用することもできます。そのため、適切な命名、構成、および管理の規律が必要です。BizTalk を多くの WCF / WebService サービスに結合している場合、スキーマ管理は特に面倒です。消費されるサービスごとに要求および応答スキーマが存在します (MessageContract を使用すると、共通のスキーマを共有できます)。

バインディング- ほとんどのことは理解できました。さらに、ダイレクト (メッセージ ボックス) バインディングを使用する場合は、適切なフィルターを使用して新しいポートを追加するだけで、複数の着信受信場所または送信先を選択できます。この pub-sub 機能は、Bizalk の ESB ツールキットの基礎を形成します。さまざまな環境 (Dev、UAT、Prod など) のバインドも適切に管理されます。

アダプター- 同意 - ファイルから MQ シリーズへの切り替えは、ポート構成を変更するのと同じくらい簡単です。BizTalk は、MSMQ および IBM MQ と非常にうまく連携します。

さらに、EAI / BP ソリューションを管理および維持するための労力を過小評価しないでください。通常、統合は企業にとってミッション クリティカルであり、エラーの追跡とダウンタイムの回避が不可欠です。BizTalk には、次の操作上の利点があります。

  • 運用管理 - 追跡/トレース、中断メッセージの管理、SCOM 統合パックなど
  • スケーラビリティ / クラスタリング / フェイルオーバー機能、アダプターの再試行、自動スロットリングなど
  • ビジネス監視とイベント - BAM

IMO BizTalk の大きな「欠点」は次のとおりです。

  • 料金
  • 開発に熟練するための準備時間 (BTS には、ゾンビや、XLS および XML ファイルでの BAM 定義の定義などの癖があります)
  • ネットワーク/管理者の専門家が運用管理のスキルを習得するための時間を増やす

結論 : 少数の重要でないメッセージを含む 2 つまたは 3 つのアプリ間の統合を行っている場合は、専用または WF ルートに進みますが、企業全体のソリューションを検討している場合は、BizTalk のような EAI / BPEL エンジンが適しています。前方。

于 2012-03-08T11:28:43.523 に答える