2

BizTalk を Service Bus として組織に導入しました。これにより、新しい Web GUI が多数の既存のバックエンド システムにリンクされます。既存のシステムをサービス (WCF) としてラップし、BUS に接続しました。

また、レガシー システム GUI の一部を新しい Web GUI に置き換えています (既存の機能を確実に複製します) が、すべてのレガシー サービス/API を BUS 経由で公開するか、それらに直接接続するか、別の方法で構成し、バスを介してそれらを公開します。たとえば、顧客管理システムに、検索、追加、取得、更新、請求詳細の設定という 5 つの既存のサービス/API があるとします。

これらの各サービスを BUS を介して公開することは理にかなっていますか (レイテンシが追加されると主張する人もいます)。それとも、BUS は検索、追加、取得、更新などの粗粒度のサービスのみを公開し、細粒度のサービスは公開しないでください。GUI はきめ細かいサービスに直接接続する必要がありますか?

理想的な SOA/ESB では、Update と Set Billing Details の両方を 1 つの粗粒度サービスに構成するという印象を受けましたが、これは正しいですか?

私は SOA/ESB パラダイムに忠実であり続けたいと思っています。誰か教えてください。

4

2 に答える 2

4

ESBは、「複合」アプリケーションの構築に最適です。

まず、多くの個別のアプリケーションから多くのきめ細かいサービスを公開する必要があります。

これにより、複合アプリケーションを構築するための準備が整います。

重要なのは、単一のアプリケーションには存在しない複合サービスを作成することです。これらのサービスはESBにのみ存在します。それらはきめ細かいサービスから構築されています。

コンポジットは、どちらもESBに存在するきめ細かいサービスに依存しているため、きめ細かいサービスの検索と実行に伴うオーバーヘッドが削減されることに注意してください。ただし、実際の作業は外部アプリケーションによって行われるため、オーバーヘッドが発生します。

パフォーマンスESBベースのアプリケーションは、他の対話方法を完全に打ち負かすため、「待ち時間」に手を絞ると、即時の直接統合による大きな勝利を逃すことに注意してください。

于 2009-02-22T13:17:28.767 に答える
0

よくあることですが、これにはさまざまな見方があります。単純にバスの観点から見ている場合 (私はあまり好きではありません)、非集約/複合サービスに BizTalk を使用する価値はほとんどありません。 (そして、あなたが述べたように) 遅延などを追加しています。もちろん、この場合でも、監視、管理、スケーラビリティなど、BizTalk が提供するすべてのサービスについて議論することはできますが、これらがどの程度かを判断するのは困難です。完全なシナリオを知らなくても関連します。

ただし、BizTalk は統合エンジンでもあり (主にそう主張する人もいます)、多くの場合、サービスの実装からコンシューマをマスクするために使用されます。

考えられるシナリオは次のとおりです (ここでも、それがあなたのケースに当てはまるかどうか、またどの程度当てはまるかはわかりません) - SOA を有効にするためにサービスにラップしているレガシーアプリがあります。今から 18 か月後に代替サービスの実装を完了しますが、それには別のインターフェイスがあります (より多くの機能があるため)。中間に BizTalk がある場合、呼び出し元によって提供された古い形式を潜在的にマップできるレイヤーがあります。サービスに必要な新しい形式と、その逆の応答。これは、すべてのクライアント アプリを (一度に) 変更する必要がないことを意味します。

だから - 答えは、私が推測する - それは場合によります。

于 2009-02-23T14:20:54.393 に答える