9

私が働いている場所では、過去数十年にわたってかなりの数のシステムが作成されており、それらを維持しています。

システムは多様であり、複数のオペレーティングシステム(Linux、Solaris、Windows)、複数のデータベース(oracle、sybase、mysqlのいくつかのバージョン)、さらには複数の言語(C、C ++、JSP、PHP、およびその他のホスト)があります。使用済み。

同じデータを複数のシステムに入力するという犠牲を払っても、各システムはかなり自律的です。

経営陣は最近、すべてのシステムが互いに楽しく通信し、データを共有するために何が必要かを調査する必要があると決定しました。

個々のシステムのいずれかにソフトウェアの変更を加えることはできますが、1つ(またはそれ以上)のシステムを完全に書き直すことは、管理者が楽しませる可能性が高いものではないことに注意してください。

ここでの開発者の最初の考えは単純明快でした。システムAがシステムBからのデータを必要とする場合、システムBのデータベースに接続してそれを取得する必要があります。同様に、Bデータを提供する必要がある場合は、Bのデータベースに挿入するだけです。

使用されるデータベース(およびバージョン)の混乱により、他の開発者は、複数の接続を調整する必要がないように、他のすべてのシステムのテーブルを組み合わせて、1つの新しいデータベースを作成する必要があると考えました。これを行うことで、いくつかのテーブルを統合し、冗長なデータエントリを取り除くことができるかもしれないと彼らは望んでいます。

これは、私が全体の混乱についての私の意見のために連れてこられた頃です。

システム通信の手段としてデータベースを使用するという考え全体は、私には面白いにおいがします。ビジネスロジックは複数のシステムに配置する必要があります(システムAがシステムBにデータを追加する場合、挿入を行う前にデータに関するBのルールをよりよく理解します)、いくつかのシステムは、見つけるために何らかの形式のデータベースポーリングを実行する必要があります。データベーススキーマへの変更は現在複数のシステムに伝播するため、データへの変更、継続的なメンテナンスは頭痛の種になります。

私が最初に考えたのは、時間をかけてさまざまなシステム用のAPI /サービスを作成することでした。これを作成すると、データの受け渡しや取得に簡単に使用できるようになります。他の多くの開発者は、データベースを使用するよりも、それが過剰ではるかに多くの作業であると感じています。

では、これらのシステムを相互に通信させるための最善の方法は何でしょうか。

4

6 に答える 6

8

異なるシステムを統合することが私の日常業務です。

もし私があなたなら、システム B 内からシステム A のデータに直接アクセスすることを避けるために多大な努力を払うでしょう。 システム B からシステム A のデータベースを更新することは非常に賢明ではありません。ビジネス ロジックをそれほど拡散させるのは、正に正反対です。あなたはそれを後悔することになります。

中央データベースのアイデアは必ずしも悪いものではありません...しかし、関連する労力は、おそらくシステムをゼロから書き直すのと同じくらいの規模です. 少なくともあなたが説明する形では、それは確かに私が試みるものではありません. 成功する可能性はありますが、ポイントツーポイントの統合アプローチよりもはるかに困難であり、より多くの規律が必要です。データを他のシステムに直接押し込むだけの「カウボーイ」アプローチと同じように提案されているのを聞くのは面白いことです。

全体的にあなたの本能はかなり良いようです。いくつかのアプローチがあります。あなたが言及したのは、サービスの実装です。特にリアルタイムで更新が必要な場合は、これは悪い方法ではありません。もう 1 つは、データのシャッフルを担当する別の統合アプリケーションです。これが私が通常とるアプローチですが、通常は、統合しているシステムを変更して、必要なデータを要求することができないためです。データをプッシュする必要があります。あなたの場合、サービスのアプローチは悪いものではありません。

初めてシステム インテグレーションを行う人にはわかりにくいかもしれませんが、システム内のすべてのデータには、単一の信頼できる真実のポイントが必要です。データが重複している場合 (および重複している場合)、コピーが互いに一致しない場合、そのデータの真の点でのコピーが正しいと見なされる必要があります。システムを統合するには、複雑さを指数関数的に上昇させる以外に方法はありません。スパゲッティ統合はスパゲッティ コードのようなものであり、絶対に避けるべきです。

幸運を。

編集:

ミドルウェアはトランスポートの問題に対処しますが、それは統合における中心的な問題ではありません。あるアプリが別のアプリに直接データを押し込めるほどシステムが接近している場合、あるアプリが提供するサービスを別のアプリから直接呼び出すことができるほど接近している可能性があります。あなたの場合、ミドルウェアはお勧めしません。ある程度のメリットは得られるかもしれませんが、複雑さの増大がそれを上回ります。一度に 1 つの問題を解決する必要があります。

于 2008-09-25T15:39:56.447 に答える
4

Message Queuingmessage-oriented middlewareを調査したいと思われるかもしれません。

MSMQJava Message Serviceが例です。

于 2008-09-25T15:24:27.250 に答える
0

意見を求めているようですので、私の意見を述べさせていただきます。

私は、すべての異なるシステム用の API を作成するのは過剰であるという他の開発者の意見に同意します。単一のデータベースを作成するという別の提案を採用すれば、おそらくそれをより迅速に実行し、より多くの制御を行うことができます。

于 2008-09-25T15:22:45.553 に答える
0

ミドルウェア + 単一中央データベース戦略に進む場合は、複数のフェーズでこれを達成することを検討することをお勧めします。考慮できる論理的な段階的プロセスは次のとおりです。

  1. 各システムの機能を公開するさまざまなシステムのサービス/API の実装
  2. これらの API にアクセスし、他のシステムからデータ/サービスにアクセスするためのインターフェイスをすべてのシステムに提供するミドルウェアの実装 (利用可能な場合は中央ソースからデータにアクセスし、そうでない場合は別のシステムからデータを取得します)
  3. 中央データベースのみの実装、データなし
  4. システムのいずれかからデータがアクセスされるたびに中央データベースにデータを保存/キャッシュできる、ミドルウェア レベルでのキャッシング/データ ストレージ サービスの実装。データ キャッシング サービスは、これらのレコードを中央データベースに保存し、次にこれらのレコードを中央データベースから取得することができます。
  5. データクレンジングは並行して行うことができます
  6. 複数のシステムから中央データベースにデータを毎日 (自動または手動で) プッシュするインポート メカニズムを作成することもできます。

このようにして、作業は複数のマイルストーンに分散され、データは最初にアクセスされたものから順に中央データベースに保存されます。

于 2008-11-04T17:59:01.653 に答える
0

直面する課題の 1 つは、最初に統合できるように、異なるシステムのそれぞれでデータを調整することです。統合する各システムがまったく異なるデータ セットを保持している可能性がありますが、重複しているデータである可能性が高くなります。API:s の記述に飛び込む前に (これは、あなたの説明を考えると私がたどるルートです)、統合する必要があるデータの論理データ モデルを考え出すことをお勧めします。このデータ モデルは、さまざまなシステムにあるデータを活用し、他のデータベースにとってより有用なものにするのに役立ちます。

また、統合への反復的なアプローチを強くお勧めします。レガシー システムでは不確実性が非常に高いため、すべてを一度に設計して実装しようとするのはリスクが高すぎます。小さく始めて、適度に統合されたシステムを目指してください。「完全統合」を目指す価値はほとんどありません。

于 2008-11-03T13:45:28.093 に答える
0

データベースのプッシュ/ポッキングを介して直接インターフェースすると、あるシステムの多くの内部詳細が別のシステムに公開されます。明らかな欠点があります。一方のシステムをアップグレードすると、もう一方のシステムが壊れる可能性があります。さらに、あるシステムが他のシステムのデータベースにアクセスする方法には技術的な制限がある場合があります (Unix 上の C で記述されたアプリケーションが、Windows 2003 Server で実行されている SQL Server 2005 データベースと対話する方法を考えてみてください)。

最初に決定しなければならないことは、「マスター データベース」が存在するプラットフォームであり、必要な接着剤を提供するミドルウェアについても同じです。API レベルのミドルウェア統合 (CORBA など) に向かう代わりに、メッセージ指向ミドルウェアを検討することをお勧めします。MS Biztalk、Sun の eGate、および Oracle の Fusion は、オプションの一部です。

新しいデータベースについてのあなたのアイデアは、正しい方向への一歩です。Enterprise Entity Aggregationパターンについて少し読みたいと思うかもしれません。

「データ統合」とミドルウェアの組み合わせは、進むべき道です。

于 2008-11-03T13:31:25.483 に答える