Javaが単純なRPCサービスにサーブレットコンテナを必要とするのはなぜですか？
私はJavaで書かれた大きなデータベースコントローラーを持っています。コントローラはデータベースから情報を読み取り、CLIに表示されるデータ構造に解釈します。
Javaを選択した理由は、コードをすばやく簡単に作成できるためです。次に、コントローラの上にRPCサーバー（将来のXML-RPCまたはJSON-RPC AJAX呼び出し））を作成したいのですが、RPCサービス用のサーブレットコンテナが必要なようです。昨年Pythonで別のプロジェクトにこの種の機能が必要になったときに、 SimpleXMLRPCServer を使用して同じ機能を作成するのに5分もかからなかったので、混乱しています。
私が思い出す限り、同じ作成の容易さはC＃にも当てはまります。
しかし、Javaの話は異なります。今はサーブレットが必要なので、サーブレットコンテナ（つまり、Tomcat、Jetty）が必要です。つまり、Webサーバーをインストールして維持する必要があります。 JSON-RPCが機能するには、Springフレームワークが必要です。
コードを1行も書かずに、Tomcatがどのように機能するかを、設計とソートの学習に2時間ほど費やしてきました。
私はWebを検索して、スタンドアロンオプションがあることを発見しました： this library を使用できますが、維持されていないようで、多少複雑でもあります（デコレーター/アノテーションで何かを探しています） ）。
私が見つけたもう1つのオプションは、いわゆる「組み込み」桟橋を使用してから、それを設定してコードで構成しようとすることですが、これも面倒な作業のようです。
このような一般的なインターフェースにstandaloneメカニズムがないのはなぜですか？私はここで何かを逃していますか？
誤った仮定
サーブレットとサーバーが必要であるというあなたの仮定は、誤って導かれ、正しくありません 。たくさんあります Javaの組み込み可能なHTTPサーバー 、いくつかは単一のクラスで、フル機能のサーバーではありませんが、HTTPサーバーは単なるTCP/IPソケットベースのプロトコルです。サーブレットAPIは、詳細から離れた素晴らしい抽象概念です。
RPCを実行したくない、RESTを実行したい
RESTEasyのような開発を加速するものを使用するには、最小限のサーブレットコンテナーが必要です。
Javaのエンタープライズ機能（JEEと同様）はOracle/Sunによって実装されておらず、代わりにJava Enterprise Edition仕様に含まれています。
結果として、Tomcat、Jetty、WebSphereなど、アプリケーションサーバーの多数の実装があり、それらはすべてJEE仕様のさまざまな部分を実装しています。
エンタープライズJava機能を使用しているため、現在の状況であるアプリケーションサーバーが必要です。
Jettyは非常に軽量なサーバーであり、Tomcatで問題が発生した場合、運がいいかもしれません。
.NETでこのようなことを行うのは簡単です。Javaに到達するにはもう少し作業が必要ですが、最終的には同じ結果になります。
Web.xmlファイルやあらゆる種類のサーブレット構成なしで、コードからJettyインスタンスを単に開始することが可能です。
これは、カスタムハンドラーを実装してサーバーインスタンスに渡し、サーブレットAPIを完全にバイパスすることで可能になります。
HttpServletRequestとHttpServletResponseはまだ使用されているので、python ^^
欠点は、これを行うことはあまり一般的ではないため、グーグルが完全に役に立たない可能性があることです。
一方、サーブレットAPIを使用する場合との違いは非常に小さいため、何かが深刻な問題が発生した場合、非常によく似た例外メッセージとスタックトレースが発生する可能性が高いため、万が一、完全に独力でいる必要はありません。ある日、下り坂を少し横道に行くことにしました^^