Olha, Halex, vou tentar dar uma ideia para vc. Como os conceitos q vc
pediu sao bem amplos, vou tentar nao me aprofundar e ser imparcial.
Pelo que eu entendi, vc quer que a aplicacao acesse, via Socket, via
RMI, ou, talvez CORBA uma base remota, certo?
Vamos lah. Por acaso este servidor seu (onde estarh a base de dados)
possui um endereco fixo? Seja um IP fixo ou um nome url?
Caso possua, vc nao precisarah utilizar Socket, RMI, CORBA, etc.
Basta vc fazer com que a propria aplicacao possua uma conexao diretamente
para a base de dados remota. De uma olhada sobre o JDBC do banco de dados
que vc estah usando. Jah fiz isso com MySQL, PostgreeSQL, ORACLE e SYBASE.
Nao tem segredo nao!
Exemplo para o MySQL (qq google acha ele!)
...
import java.sql.*;
...
public class SuaClasse {
private Connection con;
...
try {
Class.forName("org.gjt.mm.mysql.Driver");
} catch (...){ ... }
String url =
"jdbc:mysql://seu_servidor.seu_dominio.sua_regiao:3306/NOME_DA_SUA_BASE_DE_DADOS";
con = DriverManager.getConnection( url, "SEU_LOGIN", "SUA_SENHA" );
...
Pronto! Vc estah conectado aa sua base remota! Ah! Nao se esquecer de
colocar o arquivo .jar do JDBC (fornecido por cada fabricante dos bancos)
no seu CLASSPATH!
Detalhes:
1) Para cada banco, a linha "Class.forName(...)" vai receber parametros diferentes.
2) Na String url, usei 3306 como a porta default onde meu MySQL escuta. Isso muda
para cada banco.
Dica:
google search: java+JDBC+SEU_BANCO
(java+JDBC+MySQL)
isso vai te dar varios exemplos de codigos e possivelmente dicas de
sites para downloads de JDBC, bem como FAQs, etc.
Bem, isso pode ser que vc jah sabia e, por algum motivo NAO quer fazer
assim. Bem, vamos ver como seria para as solucoes que vc mencionou:
Sockets
-------
Penso que uma maneira facil de se fazer a conexao utilizando Sockets
seria colocar um servidor(claro q em algum IP conhecido!) escutando uma
determinada porta. Esse servidor possuiria uma conexao (da mesma forma
como eu mostrei acima) para a maquina desejada.
Sua aplicacao deveria possuir um Socket que se conectaria no seu
ServerSocket (lembre-se q o IP deveria ser conhecido) e todas as consultas
SQL da aplicacao deveriam ser passadas para seu servidor (quem realmente
executaria os SQLs) por meio deste Socket. Esta comunicacao pode ser feita
via stream de bytes (que vc trataria da forma como lhe agradasse mais),
via envio de Objetos serializados, XML ou qualquer outra forma que lhe
agradasse.
O problema desta solucao eh quando vc nao conhece o IP do local onde vc
colocaria o servidor no ar ou, entao, mesmo este sendo conhecido, o
servidor nao saiba o IP da maquina onde vai estar o banco. Caso tudo seja
conhecido, facilite seu trabalho! Use a conexao diretamente da aplicacao.
RMI / CORBA
-----------
Juntei ambos, pois para esse caso, podemos resolver isso da mesma
maneira com qualquer um deles.
Em primeiro lugar, vamos definir uma arquitetura para a sua aplicacao
neste momento. Esta arquitetura pode variar de implementador para
implementador. Aqui, vou mostrar como eu montaria:
(tomara q vc use currier para ler isso!)
--------------------- ---------------------
| Aplicacao Cliente | <-==========-> | Objeto Remoto (*) |
--------------------- (internet) ---------------------
^
|
S Q L
|
---|-------
/ v /|
/ / |
----------- |
| SUA | /
| BASE DE | /
| DADOS |/ (**)
-----------
(*) Pode ser um objeto RMI ou um CORBA.
(**) Era para ser um cilindro!
Nesta arquitetura, sua aplicacao deve possuir uma referencia para o
objeto. O objeto nao precisa se preocupar em conhecer onde estah a base,
pois este pode ser executado na propria maquina onde estah a base de
dados.
Nao sei se vc conhece RMI/CORBA (tomara que sim!), temos o servico de
localizacao (RMIREGISTRY/ORB, respectivamente). Esse localizador serve
como uma "lista telefonica", quando vc precisa saber qual o numero do
telefone (referencia para o objeto que deseja). Para procurar na lista, vc
tem o nome da pessoa que deseja (a aplicacao deve saber o nome que ela
deve fornecer para o localizador, conhecido como broker, para conseguir a
referencia para o objeto que vc quer).
Pensando no problema, seu servidor (o objeto "remoto" que acessa
diretamente o banco de dados) registrar-se-ia no broker e ficaria
aguardando por requisicoes (invocacoes de seus metodos). A aplicacao
apenas precisaria fazer uma consulta ao broker para conseguir uma
referencia para o objeto remoto.
Problemas:
1) O Broker! Ele precisa estar em um local (IP) conhecido!
2) Programar com RMI/CORBA retornando objetos serializados que possuem
resultados de consultas SQL (por exemplo tuplas de tabelas), quando estes
possuem campos null, geram exceptions. O programador deve cuidar disso
(nem um pouco dificil, porem chato de fazer!).
Por fim, solucoes hibridas!
--------------------------
1) Por que nao fazer uma solucao RMI/CORBA que te retorne, em vez da
execucao do SQL, apenas a conexao com o banco. Assim a aplicacao poderia
fazer diretamente seus SQLs sem ter que passar por toda a "burocracia" de
RMI/CORBA.
Nesse caso, vc teria seu servidor de conexao sendo um objeto remoto
(RMI/CORBA) que possuiria apenas um objeto Connextion. Ele registrar-se-ia
no broker e, quando a aplicacao necessitasse acessar o banco, pediria para
o broker pelo objeto servidor de conexao. Com a referencia para o objeto
servidor de conexao, vc pediria por um metodo getConnection(), por
exemplo, que retornaria o objeto Connection (jah conectado aa base - isso
eh utilizado para que todas as conexoes sejam realizadas com o mesmo
usuario, senha e bd; tambem eh possivel que este objeto execute um
escalonador de conexoes e possa realizar balanceamento de carga, caso
exista mais de um banco de dados). A aplicacao, agora com uma conexao para
o banco de dados remoto, pode realizar seus SQLs normalmente.
2) Solucao 1), porem, no lugar de retornar o objeto Connection, retornar
o endereco URL de onde se encontra o banco de dados. Repare que NAO perde
a possibilidade de se implementar o balanceamento de carga! Basta o objeto
remoto escalonar uma entre as varias URLs onde a aplicacao pode encontrar
o banco de dados.
3) Nao usar RMI/CORBA, porem fazer algo parecido. Caso vc tenha acesso a
algum servidor DNS, pode-se adicionar uma entrada neste servidor e fazer
com que a aplicacao faca um lookup nesde DNS e conseguir o endereco onde
se encontra a base de dados.
4) Solucao 3), porem trocando o DNS por HTTP! Sim! Por que nao montar um
servlet em algum lugar conhecido (tb pode ser php, ou qq outro meio - html
estatico tb funciona!) onde a aplicacao possa se conectar e "ler" o
conteudo do html para conseguir a URL onde ela encontra a base de dados?
Funciona!
5) Solucao 3), com FTP! Basta pegar um arquivo (de texto, por exemplo)
que contem a URL!
Bem, acho que vc jah viu que dah pra fazer isso de varias formas. Acho
mais interessante vc analisar em qual dos casos acima sua aplicacao se
encontra, para depois poder decidir o que vai utilizar como solucao.
Para qualquer uma delas que vc escolher, pode contar com a ajuda minha (e
acho que de toda a lista).
Tentei NAO ser parcial. Jah implementei aplicacoes com um pouco de tudo o
que estah acima. Cada uma delas vai ter seus proprios problemas e
limitacoies. Podemos analisar isso depois.
Fui!
Bruno do Amaral
Ragnar Solutions
www.ragnar.com.br
On Wed, 11 Jun 2003, Halex Maciel wrote:
> Caro(a)s colegas, estou querendo desenvolver uma aplicação que faça acesso
> remoto ao banco de dados, este banco de dados estará em um servidor
> remoto e a minha aplicação estará na máquina do cliente, ´mas a
> aplicação do cliente não terá nada a não ser a própria aplicação. Eu
> gostaria de saber como faço ou onde acho conceitos de acesso remoto de
> banco de dados. (Socket, RMI, Etc...) Alguém sabe? Valeu
>
> Halex Maciel
>
------------------------------ LISTA SOUJAVA ----------------------------
http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP
dúvidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
historico: http://www.mail-archive.com/java-list%40soujava.org.br
para sair da lista: envie email para [EMAIL PROTECTED]
-------------------------------------------------------------------------
