0

私は、レコードセットの継続的に書き込まれたファイル（1か月あたり800.000.000レコード）を読み取り、ファイルからデータを一括読み取り、Webサービスを呼び出してデータも読み取るJavaアプリケーションを開発しています。これらのデータはデータベース（巨大なデータベース）に保存する必要があります。次に追加する機能はWebサービスです。これは、他のアプリケーションから呼び出して、レコードを追加または受信できます（事前定義されたクエリ[メソッド/クエリの実行時間は約1分または2分]）。Webサービスに加えて、c＃、c ++などで記述された他のアプリケーションが接続できるようにしたいです（プロトコルバッファーまたはApache Thriftについて考えました）。そして、少なくともそれはアプリケーションを管理する方法を提供する必要があります（私はWebサイトについてですが）

私の意見では、それはサーバーアプリケーションでなければなりません。しかし、自分でサーバー（ソケットを開くなど）、Java EEを開発する必要がありますか、それとも他の「サーバーフレームワーク」（桟橋、ソケットなどの組み合わせ）がありますか？

4

2 に答える 2

2

分割統治法：1つの解決策はTomcatを使用することです：

関数1）ファイルを読み取るスレッドを作成します。次に、web.xml内でコンテキストリスナーを定義できます

関数2）java.util.Timerを確認するか、より堅牢な機能については、Quartzなどのサードパーティ製品を確認してください。

機能3a）利用可能なWSフレームワークはたくさんあります。チュートリアルを見つけるためにグーグルを使用してください

機能3b）Google for AsynchronousWebServiceまたはサーブレットでの非同期サポート

関数4）AFAIKThriftには組み込みのTServletがあります。TomcatとGoogleProtokollBuffersも可能だと思います

機能5）Webサイトの提供はtomcatsの主な機能の1つです

于 2012-07-19T14:17:14.747 に答える
1

ユーザーがデプロイできるもの（クライアントが購入する製品、またはダウンロードするためのオープンソースツール）になる場合は、コンテナーに依存しない方法で開発するのが最善の方法であることをお勧めします。可能な限り。

つまり、アプリケーションの機能に焦点を当て、サービスの起動や接続などを抽象化します。そうすれば、コンテナ固有の要素を記述して、ユーザーがアプリケーションを、たとえば、選択したアプリサーバーにデプロイしたり、スタンドアロンアプリケーションとしてデプロイしたりできるようにすることができます。

一方、アプリケーションの使用方法のすべての側面を完全に制御する社内プロジェクトの場合は、上記の一部またはすべてを回避できます。ただし、いずれにせよ、そのような抽象化を使用する方がよいでしょう。

確かに、Eric Leschinskiは、TomcatやIISのようなものを開発したくないという点で正しいです。

于 2012-07-19T13:23:25.787 に答える