Versão rápida:
Use uma camada intermediária de serviço da Web em execução em um host público que você controla (possivelmente, mas não necessariamente, o host do banco de dados). Exponha métodos de serviço da Web públicos para fazer o trabalho limitado que você deseja permitir e nada mais.
Perguntas relacionadas:
Opções de implementação
Pessoalmente, eu usaria um servidor de aplicativos Java como Apache Tomcat ou JBoss AS 7 e eu escreveria meus métodos de serviço da web usando JAX-RS para produzir uma boa API no estilo REST para meu aplicativo usar. É com isso que estou familiarizado e funciona bem, mas você tem muitas opções, incluindo implementações de:
-
APIs do tipo REST (Java's JAX-RS impls Jersey e RESTEasy, várias outras ferramentas langs) que usam solicitações HTTP e produzem respostas JSON ou XML.
-
SOAP com WSDL, a camada clássica de "serviço web". Em Java feito com JAX-WS entre outras opções. A maioria das linguagens tem ferramentas para SOAP+WSDL, mas é meio ruim trabalhar com isso, especialmente em dispositivos conectados de forma intermitente, como celulares.
-
XML-RPC se você gosta de dor
Existem alguns JAX-RS inícios rápidos nos inícios rápidos do JBoss AS 7 Lista; basta procurar por "JAX-RS". O "pia da cozinha " quickstart é útil, embora talvez não seja ideal se você não estiver familiarizado com os fundamentos do JBoss AS 7 e Jave EE 6. Para as especificidades do JAX-RS, é melhor usar um tutorial Jersey ou RESTEasy como isto ou este .
Considerações importantes
Use HTTPs, se possível, e se o acesso não for público, use um esquema de autenticação HTTP adequado, como autenticação HTTP Basic sobre HTTPs. Qualquer implementação de serviços da Web decente oferecerá opções de autenticação ou oferecerá suporte às da plataforma em que é executada. Evite a tentação de implementar sua própria autenticação e gerenciamento de usuários na camada de serviços da Web, você vai estragar tudo; use a autenticação na camada HTTP que já foi escrita e testada. Isso pode exigir o uso de algo como o
mod_auth_pgsql do Apache , reinos de segurança JDBC do JBoss AS 7, etc. O único caso que eu consideraria não fazer uma autenticação HTTP adequada por usuário é quando não preciso separar meus usuários por motivos de segurança, só me importo que seja meu aplicativo acessando o servidor , ou seja, se meus requisitos de segurança são muito fracos. Nesse caso, eu usaria um nome de usuário/senha fixos para todo o aplicativo e possivelmente um certificado de cliente X.509 se o Android os suportar. Lembre-se de que não importa como você proteja as coisas, todas as credenciais são conhecidas pelo usuário ou podem ser extraídas trivialmente de um .apk, então você ainda tem que assumir que qualquer pessoa pode acessar seus métodos de serviço da Web, não apenas seu aplicativo. Escreva-os de acordo.
não basta enviar o SQL do seu aplicativo por meio de uma chamada de serviço da Web para o servidor e retornar os resultados como JSON. Isso é terrivelmente inseguro, além de feio e desajeitado. Escreva um método de serviço da Web para cada tarefa individual que você deseja que o aplicativo possa executar e mantenha o SQL no servidor. Lembre-se de usar consultas parametrizadas e tenha cuidado com outros riscos de injeção de SQL. Esses métodos de serviço da Web podem usar uma ou mais consultas para produzir uma única resposta - por exemplo, você pode coletar um registro "Cliente" e todos os registros "Endereço" e "Contato" associados e retornar o resultado em um bom objeto JSON no dispositivo Android pode consumir, economizando inúmeras viagens de ida e volta de rede lentas e não confiáveis.
Não importa o que você usa, certifique-se de fazer suas chamadas de serviço da web em um thread de trabalho em segundo plano e não bloquear a interface do usuário. Esteja preparado para tempos limite e erros e para a necessidade de novas tentativas. Teste seu aplicativo simulando perda de conexão intermitente, alta latência e altas taxas de perda de pacotes e certifique-se de que ele permaneça utilizável.
