クイックバージョン：
制御するパブリックホスト（データベースホストである可能性がありますが、必ずしもそうとは限りません）で実行されているWebサービス中間層を使用します。パブリックWebサービスのメソッドを公開して、許可したい限られた作業だけを実行します。
関連する質問：
実装オプション
個人的には、 ApacheTomcat
のようなJavaアプリケーションサーバーを使用します。 または
-
HTTPリクエストを使用してJSONまたはXML応答を生成するRESTのようなAPI（JavaのJAX-RSはJerseyとRESTEasy、その他のさまざまなlangsツールを実装します）。
-
古典的な「Webサービス」レイヤーであるWSDLを使用したSOAP。 Javaでは、他のオプションの中でも特にJAX-WSを使用します。ほとんどの言語にはSOAP+WSDL用のツールがありますが、特にモバイルなどの断続的に接続されたデバイスで作業するのはちょっと厄介です。
-
痛みが好きならXML-RPC
いくつかのJAX-RS
重要な考慮事項
可能であればHTTPを使用し、アクセスを公開しない場合は、HTTPを介したHTTP基本認証などの適切なHTTP認証スキームを使用します。適切なWebサービスの実装は、認証オプションを提供するか、それが実行されるプラットフォームの認証オプションをサポートします。 Webサービスレイヤーで独自の認証とユーザー管理を実装したいという誘惑を避けてください。 それを台無しにします。すでに作成およびテストされているHTTPレイヤーで認証を使用します。これには、Apacheのmod_auth_pgsqlのようなものの使用が必要になる場合があります 、JBoss AS 7のJDBCセキュリティレルムなど。適切なユーザーごとのHTTP認証を行わないと考える唯一のケースは、セキュリティ上の理由でユーザーを分離する必要がない場合です。サーバーにアクセスするのは自分のアプリだけです。つまり、セキュリティ要件が非常に弱い場合です。この場合、アプリ全体に固定のユーザー名/パスワードを使用し、Androidでサポートされている場合はX.509クライアント証明書を使用する可能性があります。
どのようにセキュリティを保護しても、すべての資格情報はユーザーに知られているか、.apkから簡単に抽出できるため、アプリだけでなく、誰でもWebサービスメソッドにアクセスできると想定する必要があります。それに応じて書いてください。
しない アプリからWebサービス呼び出しを介してサーバーにSQLを送信し、結果をJSONとして返すだけです。これは恐ろしく不安定であり、醜くて不格好です。アプリで実行できるようにする個々のタスクごとにWebサービスメソッドを記述し、SQLをサーバーに保持します。パラメータ化されたクエリを使用し、他のSQLインジェクションのリスクに注意することを忘れないでください。これらのWebサービスメソッドは、1つ以上のクエリを使用して単一の応答を生成する場合があります。たとえば、「Customer」レコードと関連するすべての「Address」および「Contact」レコードを収集し、Androidデバイスの素敵なJSONオブジェクトで結果を返す場合があります。消費する可能性があり、低速で信頼性の低い多数のネットワークラウンドトリップを節約できます。
何を使用する場合でも、ユーザーインターフェイスをブロックしないように、必ずバックグラウンドワーカースレッドでWebサービス呼び出しを行ってください。タイムアウトとエラー、および再試行の必要性に備えてください。断続的な接続損失、高遅延、高率のパケット損失をシミュレートしてアプリをテストし、引き続き使用できることを確認します。