5

システムAとシステムBの2つ(ただし、将来的にはさらに増える予定)の完全に分離されたシステムとしましょう。

各システムのすべての情報にinformationIDがあるとしましょう。informationIDが異なるシステムで同じになるのを止めるものは何もありません。すべてのシステムで情報を一義的に識別するのは、Source-informationIDのペアです。

システムAからシステムBに情報をエクスポートする必要があるとします。次に、同じ情報をシステムBからエクスポートして、システムAに再インポートし、それが同じものであることを認識できるようにする必要があります。情報の。

人々の経験でこれを行うための最良の方法は何ですか?

これは私がやろうと思っていることです:

  1. メッセージキューを備えたシステム間にメッセージバスを設定します。
  2. 変更を監視し、キューに送られるメッセージにラップされたコマンドを生成する各システムのエンドポイントを設定します(たとえば、情報の一部が作成/削除/更新された場合)。
  3. システム名に依存せず、一般的な階層のみに依存するように、作成/削除/更新コマンドに関連するエンドポイントにランクを割り当てます。これにより、各システムが他のシステムについて知る必要がなくなります。
  4. 各エンドポイントに更新/削除/作成コマンドのしきい値を割り当てて、しきい値の要件を満たしていないコマンドが除外され、処理されないようにします。

ただし、これでは、originalSource+originalSourceIDを持ち歩く必要があるという事実は解決されません。

助けていただければ幸いです。

4

5 に答える 5

4

誰かがすでに書いているように、これは典型的な EAI の問題のように思えます。EAI ツールは以前は高価でしたが、現在では無料のオープンソース ツールの幅広い選択肢があります。私が最も好きなもののリストの下に

  1. OpenESB
  2. ラバ
  3. アパッチ サービスミックス
  4. アパッチキャメル

私のお気に入りは OpenESB です。私が最もよく知っているのは、完全な IDE (Netbeans)、大手ベンダーによるオプションのサポート、および膨大な量の追加コンポーネントを備えていることです。そのシンプルさと有効性から、私は Apache Camel を気に入っていますが、それらのいくつかを試してみて、どちらが自分に適しているかを判断してください。その後、これらすべてのサポート サービスを購入することもできます。

于 2009-01-31T02:38:04.070 に答える
2

私たちは、あなたが説明した A -> B -> A のようなことをほぼ正確に行っています。最初は、A、B、C などすべてをピアにすることを検討しましたが、それは難しすぎたので、現在は 1 つをプライマリとして指定し、他をレプリカに指定しています。あるレプリカから別のレプリカにデータを取得するのは簡単ですが、プライマリ経由です。

これはすべて Web サービスを介して行われます。データセットはレプリカからプライマリに、またはその逆に移動し、レプリカはそれ自体でエクスポートを実行し、プライマリでインポートを呼び出します。次に、プライマリにエクスポートを行うように指示し、それ自体でインポートを実行します。

したがって、コードは各システムで同一です。ホームと呼ぶのはレプリカだけです。

エクスポートおよびインポート プロセスは、関連するビジネス オブジェクトにすべての一覧表示と保存を行うように指示します。これらのビジネス オブジェクトは、DataRows から自身をインスタンス化して永続化する方法を既に知っているからです。

これは、毎秒数十トランザクションのアーキテクチャではありませんが、機能し、ほぼリアルタイムの同期を実現できます。

ちなみに、Source/Id の一意性は改善されていません :)

于 2008-12-15T21:00:34.807 に答える
2

この問題は、TibcowebMethodsなどの EAI (Enterprise Application Integration) ベンダーによって対処されています。(現在は Software AG の一部)。これまで Tibco を使用したことはありませんが、webMethods を使用してこの種の問題を解決したことがあるので、Webmethods に焦点を当てます。たとえば、企業では、従業員に関するデータを Active Directory と PeopleSoft の両方に置くことができます。webMethods を使用すると、1 つのシステム (アプリケーション) での変更、追加、削除がリアルタイムで別のシステムに反映されるようにすることができます。他の組織では、従業員に関するデータも Oracle または SQL Server データベースにある場合があります。繰り返しますが、問題ありません。これらの webMethods などの EAI ツールは、さまざまなバックエンドと通信できます。webMethods は 1 つのソースと 1 つのターゲットに限定されませんが、パブリッシュ/サブスクライブ アーキテクチャを備えているため、1 つのソースからのデータが、特定の情報をサブスクライブする複数の関心のあるターゲットに流れることができます。これらの製品には、配送の保証とその他の機能が含まれている場合があります。従業員の例に戻ると、最終的には適切に処理すれば、企業内のすべてのシステムとアプリケーションに、従業員に関する同じ情報を矛盾なく含めることができます。

したがって、C# や Java でプログラミングを行う代わりに、4GL 言語に非常によく似た webMethods プログラミングを行うことになります。ロジック、ループ、if then else、ブランチ、変数、パッケージなどがまだ含まれているため、プログラミングと呼んでいますが、非常に手続き指向です。つまり、OOP の概念はまったくありません。

これらの EAI ツールは、限られた目的を念頭に置いて構築されており、その目的の 1 つは、企業内の異種システム間でデータを簡単に同期することです。そして、彼らは自分の仕事をとてもうまくやっています。

欠点は、これらのツールには多額の費用がかかることです。多くの場合、企業はこれらのツールに投資する前に長期的な戦略を立てています。

于 2008-12-15T20:42:13.707 に答える
2

各情報に GUID を割り当てると、これが大幅に簡素化されます。ソース ID やその他の ID を追跡する必要がある場合は問題ありませんが、情報は常に割り当てられた GUID と共に移動する必要があります。

マシンがその情報を再度確認すると、GUID が表示され、それが既存のデータに関連付けられます。その後、ユーザーは何をすべきかを決定できます。しかし、あなたはそれが同じデータであることをすでに知っています。

GUID は、各マシンが独自に作成し、別のマシンまたは同じマシンで別の時点で作成された GUID と (すべての実用的な意図と目的のために) 競合しないように作成されることに注意してください。

これは、GUID が作成された大きな理由の 1 つです。

-アダム

于 2009-01-31T02:50:47.553 に答える
1

システム設計にこれを妨げる特定の制限がない限り、共有/共有可能な情報を別の DB に分割し、他の 2 つがローカルで参照または複製できるようにすることをお勧めします。そうすれば、二重要素キーも精巧なESBの仕掛けも必要ありません...

于 2008-12-15T20:15:38.487 に答える