6

私の会社は、SOA (Service Oriented Ambiguity を引用しないでください) 環境の Enterprise Service Bus (ESB) として BizTalk (私たちは Microsoft ショップです) を提案した新しいアーキテクチャを実装しようとしています。

私たちのビジネスは、顧客データベース、製品カタログ、注文システム、およびそれぞれが WCF サービスとして公開されるその他の補助システムに接続する必要がある新しい注文キャプチャ GUI を介して注文を受け取ることです。注文は注文管理などに渡されます。フルフィルメントのための下流システム、そして最終的に請求のための請求システムへ。現在、各システムには独自の GUI があり、それらを接続するために ESB を導入するという自然な考えを自動化および統合するために手動プロセスを使用してそれらの間で情報を渡しています。

私の ESB の理論的根拠の一部は、バスがシステムの接続方法 (各システムは不可知論的であり、他のシステムについては何も知らない) と、情報のフォーマット/変換方法を心配することです。将来、既存のシステムの一部が新しいシステムまたは当社のファミリー企業内のシステムに交換される可能性が非常に高くなります。

これは私には理にかなっているように思えますが、ポイント ツー ポイント ソリューションで十分な場合になぜそれを導入するのかについて、いくつかの抵抗に直面しています。

残念ながら、会社の歴史 (私が任命される前) では、BizTalk を導入する最初の試みは失敗しましたが、BizTalk には場所があり、提供できると確信しています。

私の質問はおそらく BizTalk に関するものではありませんが、説明したシナリオで ESB が良いアイデアであるかどうか、いつ ESB を導入するのが理にかなっていますか?

4

6 に答える 6

6

わかった。規範的アーキテクチャ グループによる Biztalk に関する ESB ガイダンス - http://msdn.microsoft.com/en-us/library/cc487894.aspx

私が働いている場所では、BizTalk を使用して多くのことを行っています。彼はいくつかの単純な点積分を持っています。高度にカスタマイズされたアダプターとパイプラインを使用した、より複雑なポイント統合がいくつかあります。私たちは、顧客マスター、製品情報、価格、見積もりを注文するための部門別エンタープライズシステム統合を行っています。これらはすべて個別の BizTalk アプリケーションです。かなり小さいものもあれば、かなり大きいものもあります。主に BizTalk を使用して、ESB パターンを使用せずにポイント ツー ポイント/多ポイント ソリューションを実行しました。ESB の実装は、バス自体のガバナンス レベルと、バス上で許可されるエンタープライズ メッセージ標準を意味します。多数の異なるフォーマットを持つ多数のシステムとインターフェースする場合、ESB は非常に理にかなっています。達成したい統合が野心的でない場合、ESB はやり過ぎかもしれません。そうは言っても、これはクリーンで拡張可能なアーキテクチャです。コスト値の決定を行う必要があります。

BizTalk も複雑な獣ですが、すべての可動部分により、素晴らしいレベルの柔軟性がもたらされます。ただし、学習曲線やコンサルタント費用に備える必要があります。

于 2008-12-05T03:31:56.613 に答える
4

同僚から同じ質問をされたばかりで、彼にこう言いました。

ほとんどの統合シナリオでは、BizTalk のようなものを使用する前に、かなり先に進むことができます。BizTalk を使用する前に、これ以上簡単に統合できないことを確認します。

統合ソリューションが低レイテンシーで大量にスケーリングする必要があり (素晴らしい非同期パブリッシュ/サブスクライブ メカニズムを備えている)、フォールト トレランス (冗長性、スケーリング、およびメッセージ再試行機能を備えている) とソリューションのガバナンスが必要であると思われる場合のみ。 (Business Activity Monitoring があります) BizTalk の使用を検討すべき強力な議論はありますか? また、今後必要となる複数の統合があることがわかっている場合は、BizTalk を使用することが非常に魅力的になります。

一方で、それを操作するためのスキルが利用可能であることを確認する必要があります。システムの開発者にとって、学習とパラダイムシフトにはしばらく時間がかかります。ただし、.NET と SQL Server でゼロから構築されているため、ツールと概念には非常に精通しています。

重要なことは、パフォーマンス、可用性、拡張性、回復力、堅牢性、スケーラビリティなどの機能以外の要件を考慮して、ソリューションの概念アーキテクチャを正しく理解し、それらが技術設計によって適切に対処されていることを確認することだと思います。これらすべての NFR 用に開発するよりも、BizTalk がすぐに提供するものに対して CPU ライセンスあたり 35,000 ドルを支払う方が安価であることに気付くかもしれません。

また、最近クライアントに新しい ESB Toolkit 2.0 を実装しましたが、非常に満足しています。Itinerary (Routing Slip パターンhttp://www.enterpriseintegrationpatterns.com/RoutingTable.htmlを参照) 処理機能により、Web サービスの作成が簡単、柔軟かつ高速になります。

于 2009-06-24T13:13:12.620 に答える
2

私は ESB という言葉を避ける傾向があります。結局のところ、私が聞いたさまざまな説明のすべてにおいて、これは単なるパターンに過ぎず、かつて BizTalk が非常にうまくサポートしていました。

では、BizTalk はあなたのやりたいことに合っていると思いますか? 断固としてはい。ポイントツーポイント接続を避けるのは正しいと思いますか? はい、そうですが、SOA イニシアチブを含む再利用のためのリファクタリングの演習と同様に、どれだけの変更とどのくらいの再利用が期待されるかを検討する必要があります。あなたは「デカップリング」運動をしています。

于 2008-12-05T10:25:16.483 に答える
2

あなたが説明した要件に基づいてデータ ブローカーを使用することは理にかなっていると思いますが、個人的には、あなたの状況では BizTalk が最良の選択になるとは思いません。あなたが説明した統合のタイプについては、ハードウェア データ ブローカー アプライアンスを検討します。私が見た中でうまくいくのは、IBM DataPower、Vordel のアプライアンス、Layer7 のアプライアンスです。これを使用する通話の種類については、アプライアンスが理想的です。ルーティング、変換、変換を提供するだけでなく、スキーマ ポイズニングなどから保護します。また、ユーザーストアにリンクすることで、承認、認証、および監査も処理します (説明した環境に基づいて Active Directory ユーザーストアがあると思いますが、LDAP でも機能します)。

アプライアンスは、所有コスト (サポート コストなし) の点で BizTalk またはその他のソフトウェア ソリューションであり、アプライアンスのパフォーマンスは BizTalk を桁違いに上回る可能性があります。

于 2008-12-04T18:04:08.023 に答える
1

レイテンシーとスループットについて話す必要があります。他のすべてはただの何とかです。

于 2009-03-11T17:20:29.227 に答える
0

それは非常に明確なパターンです。通常、システムAからシステムBにメッセージを送信する場合は、システムAの形式からシステムBが必要とする形式に直接変換します。ESBがある場合は、システムAのメッセージをESB形式（つまり、一般的なPO、注文など）に変換してから、システムBに必要な形式に変換します。これは1に対して2つの変換であり、バスパターンには次のものが必要です。すべてのメッセージには動詞があります（つまり、追加、削除、更新など）。これは本当に重要な違いであり、ESBが多くの参加システムとの統合に非常に役立つ理由です。

于 2008-12-07T05:18:44.350 に答える