Webサービスを使用するデスクトップベースのクライアントのオフラインフェールオーバーを実行する最良の方法は何ですか?


13

共通の問題を共有する次の3つのプロジェクトがあります。

Webシステム上にロジックが必要であり、RESTful Webサービスを介してそのようなシステムと通信するローカルアプリケーション(POSなど)が必要です。

私のソリューション

私が思いついたソリューションは、デスクトップアプリケーションにメッセージキューを実装して、サービスがオフラインである間、より正確には非同期メッセージキューを操作を保存することです。しかし、それは簡単な部分です(もしそれが最良の解決策であるなら)。また、データの同期と競合の解決にも関心があります。

利害関係者によるレポートと監視にはWebアプリが必要であり、Webサービスは複数の施設の要求を処理するため、メインシステムはWebベースである必要があります。

デスクトップクライアント(できればシン)はJava(より具体的にはNetbeans)で実装され、WebシステムはSymfony2で実装されます。2つのプロジェクトにはクライアントのハードウェア統合が必要であるため、Webテクノロジー(Appcelerator Titaniumなど)を使用してデスクトップアプリケーションを作成することは大きな苦痛になる可能性があります。

私の質問

  1. 最小の労力で最大の効率を意味する、拡張可能な優れたソリューションとは何ですか(ローカル操作用にバックアップサーバーを購入するなどの追加コストは不要)。

  2. 他に誰がこれに対処しましたか?どのようにして問題を解決しましたか?どんな教訓を共有できますか?

  3. 同期はどのように対処しましたか?

編集:ポイント#3で私の質問に不足している部分を追加しました

回答:


3

あなたの質問はjavaですが、本当に好きです 、このタイプのメッセージバススタイルのアーキテクチャはています。

基本的に、メッセージが送信されると、潜在的に2つの応答を受け取ります。1つ目はローカルキャッシュからのもので、2つ目はサーバーが接続されるとサーバーからのものです。

このアーキテクチャ(rhinoバスとnhib)を自分のアーキテクチャ(MQとhib)に簡単に適応できると確信しています。


うん、私はまさにそのようなメッセージ指向のアーキテクチャを探していました。リンクのキャッシュ引数と最後の文は私を納得させました。
dukeofgaming

10

ローカルですべてを実行し、定期的に同期します。

私があなただったら私がすることはここにあります(私は.NETにあるようなJavaの同期フレームワークを知りません)。

最後に正常に接続した時刻を保持するローカルアプリケーションのタイムスタンプを維持します。

再接続する時間に関係なく、そのタイムスタンプは新しいデータを引き出し、ローカルで生成された新しい注文を送信するために使用されます。

その後、2つのタイムスタンプを維持します。1つはオーダーが作成されたとき(ローカルまたはオンライン)を定義し、もう1つはサーバーによって記録されたときに定義します。

そのためにメッセージキューはお勧めしません。Navisionに接続する必要があったeコマースWebサイトに、過去にMQを使用しました。Navision内ですべてが運用され、注文ステータスや製品の説明、価格設定などを含むすべての変更がMQ経由でeコマースWebサイトに送信されました。新しい注文もMQ経由でNavisionに送信されました。


うーん、私はプッシュモデルのアイデアが好きですが、コンピューターの時間が変更されるとデータが失われる可能性があるという問題があります。ところで、私はデータベース設計ですべてのレコードにタイムスタンプを付けるという慣習があります。なぜMQを推奨しないのですか?
dukeofgaming

そうです、時間同期されたPCとUTCを使用する必要がありますが、現在はかなり標準です(少なくともWindowsでは)。MQは時々必要ですが、開発している種類のアプリケーションには多すぎると思います。

わかりました。したがって、信頼性を優先するために、デスクトップアプリは切断され、デスクトップアプリをファーストクラスの市民として扱う方が良いと考えた方がよいのですが、MQはまだローカルデータベースの実装を簡単に置き換えることができます。また、サーバーですべてのCRUD操作を暗黙的に行うと、セキュリティが向上すると思います。これら2つの点についてどう思いますか?
dukeofgaming

@dukeofgaming:私の場合、注文はWebを含むPOS(注文処理システムではなく、注文処理システムとしても使用できます)から取得できます。すべてが全国に配布されました。切断された場合、すべてのデスクトップが自律的であることが絶対に必要でした。MQはそのシナリオでも機能するので、私はそれに反対しません。マスターサーバーとクライアント間で強力なデータ同期を実装する方が簡単だと感じています。したがって、マスターサーバーでのCRUD操作はオプションではありませんでした。

2
+1-これは私が過去に行った方法です。また、uniqueidentifier(Guids)を主キーとして使用すると、物事が非常に簡単になると思います。それを行うことは、同期が必要な場合に、今後あなたの人生を本当に楽にするものの1つです。
スコットホイットロック

1

または、リモートクライアントをサーバーに同期させるという面倒な作業を行う、時々接続されるシステムデータベースの実装を確認する必要があります。(SQL ServerはこれをSQL CEである程度備えていますが、Outlookはこれを行います)。

このようにして、小さなフットプリントデータベースですべての変更をローカルで実行できます(PCのクロックなどを心配する必要がないように、バージョン管理/論理タイムスタンプなどを維持します)。サーバ。

システムがほとんどの時間オンラインになれないとき、私はRESTソリューションに行きません。


分散データベースについて説明していますか?それについて詳しく説明できますか?
-dukeofgaming

いいえ-これは、現実世界の意味での分散データベースではありません。分散データベースは通常、ほぼすべてがオンラインであることも期待しますが、ダウンしたピア間のレプリケーションのロジックはここでも適用されます。レプリケーション作業を実行する機能を備えたデスクトップ/デバイスデータベースがいくつかあります(blogs.msdn.com/b/stevelasker/archive/2007/03/18/…)-このデバイスdbをセットアップするだけで、ここで変更をログに記録し、コンピューターネットワークに接続したら、syncを呼び出します。これにより、メインサーバーへのデータ転送が行われます。
スブサンカラスブラマニアン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.