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] -------------------------------------------------------------------------