Nesse caso eu não poderia substituir o EJB por FTP

REST ?

Veja a implementação em java do RESTfulie

FTP, para o seu caso, é a pior alternativa possível, pois existem vários pontos de falha. Exemplo: você pode se conectar, enviar um arquivo, mas durante o envio a conexão cair. Consequência: o diretório destino possui um aquivo incompleto, que pode ser processado tranquilamente por sua thread.

EJB é uma solução old, mas não tem nada de gold. O problema do EJB na sua parte remota está no simples fato de ser RPC, que gera alto acoplamento entre cliente e servidor. Sem falar que não possui versionamento. Sai fora desse barco furado.

Com conexão remota, procure sempre uma solução via HTTP, pela sua ubiquidade. Exemplo: dificilmente, o cara com notebook conectado ao WiFi de uma cafeteria vai ter acesso à porta 1099 do EJB, mas pra se conectar à Web, vai estar tudo bem. Outro: se alguém falar: “quero uma aplicação cliente no iPhone”, você não vai conseguir se conectar a uma tecnologia Java, apenas protocolos Web.

Valeu pelas respostas…

Leonardo3001 Suas observações me ajudaram muito… mas como eu faria então qual a sua sugestão, transferencia de XML pelo HTTP? Um problema que eu tenho que já iria ser dificil de resolver com o FTP (por isso eu pensei no EJB) é que algumas atualizações precisam ser sincronas, o cliente executa a atualizaçao se alguma coisa falhar aparece uma mensagem de erro no cliente.

Pensei também em WEB-Services (estilo NFE) alguns serviços assincronos e outros sincronos. Seria uma boa solução?

REST te dá praticamente tudo isto.

peczenyj, valeu cara, eu até hoje só tinha ouvido falar em REST, mas estou estudando melhor agora pra ver se encaixa…

O protocolo HTTP possui códigos de retorno. Utilize-os para tratar erros no lado do cliente.

peczenyj, deu uma lida sobre REST e pensei em resolver meu problema da seguinte forma (posso estar falando muita merd*, por favor me corrija).

Primeiro problema eu preciso enviar informações do cliente para o servidor, e podem ser muitas essas informacões.
Para isso eu utilizaria XStream para parsear os objetos java.
Enviaria o XML resultante através de uma requisição HTTP feita pelo cliente Swing. (com commons HTTP-CLiente ou qq outra coisa)

No servidor eu criaria uma Servlet (se existir alguma outra coisa pra facilitar por favor me avise)
Usaria de novo o XStream, processaria tudo o que veio do cliente.
Parseava de novo o resultado do processamento para XML e enviava pro cliente.

Com isso se um dia eu precisar implementar o cliente IPhone como o Leonardo3001 bem lembrou eu consigo.

É isso? Quais ferramentas vc aconselha pra eu não reiventar a roda no cliente JAVA e no Servidor.

Muito obrigado pela força…

Leonardo3001:

FTP, para o seu caso, é a pior alternativa possível, pois existem vários pontos de falha. Exemplo: você pode se conectar, enviar um arquivo, mas durante o envio a conexão cair. Consequência: o diretório destino possui um aquivo incompleto, que pode ser processado tranquilamente por sua thread.

Péssimo argumento. Uma queda de conexao pode ocorrer em qualquer protocolo, inclusive o HTTP. Além disso é um problema facilmente contornavel confrontando o checksums dos arquivos ou uma forma mais simples de garantir essa integridade seria pelo tamanho do arquivo. Cada caractere corresponde a um byte se o numero não bate houve alguma falha na transmissão.

Eu considero a opção de enviar arquivos textos a opção mas prática. O arquivo texto pode ser enviado através do protocolo HTTP também. A única dificuldade é voce documentar um Layout (estrutura) para o arquivo. Ele deve possuir cabecalho, rodapé e segmentos. Há centenas de padrões no mercado dos quais voce pode se basear entre eles o CNAB 240 utilizado pelo setor bancário no Brasil mantido pela FEBRABAN. XML com Schema ou DTD definidos também é uma opção inteligente, mas o importante é que essa troca eletronica de dados seja feita por upload de arquivos.

duplicated post

FrancoC:

Leonardo3001:

FTP, para o seu caso, é a pior alternativa possível, pois existem vários pontos de falha. Exemplo: você pode se conectar, enviar um arquivo, mas durante o envio a conexão cair. Consequência: o diretório destino possui um aquivo incompleto, que pode ser processado tranquilamente por sua thread.

Péssimo argumento. Uma queda de conexao pode ocorrer em qualquer protocolo, inclusive o HTTP. Além disso é um problema facilmente contornavel confrontando o checksums dos arquivos ou uma forma mais simples de garantir essa integridade seria pelo tamanho do arquivo. Cada caractere corresponde a um byte se o numero não bate houve alguma falha na transmissão.

Eu considero a opção de enviar arquivos textos a opção mas prática. O arquivo texto pode ser enviado através do protocolo HTTP também. A única dificuldade é voce documentar um Layout (estrutura) para o arquivo. Ele deve possuir cabecalho, rodapé e segmentos. Há centenas de padrões no mercado dos quais voce pode se basear entre eles o CNAB 240 utilizado pelo setor bancário no Brasil mantido pela FEBRABAN. XML com Schema ou DTD definidos também é uma opção inteligente, mas o importante é que essa troca eletronica de dados seja feita por upload de arquivos.

Você entendeu algo que eu não disse! Em nenhum momento aparece escrito: “O protocolo FTP é o único da face da Terra que tem falha de conexão.”. O problema do FTP é que a queda de conexão é indetectável. Como é que o lado servidor sabe, estritamente pelo protocolo, que o documento é inválido? Não sabe, só vai saber que deu problema olhando checksums de arquivo. Só que isso é trabalhoso de se programar e sujeito e erros de codificação.

Usar HTTP é, pra mim, uma solução melhor e mais robusta, principalmente pela maior variedade de frameworks e bibliotecas.

Galera obrigado pela ajuda eu implementei um teste aqui com HTTP, vou colocar aqui como eu fiz (caso interesse pra alguem)…

Cliente Swing usando Common HttpClient

HttpClient httpclient = null;

		try {
			httpclient = new DefaultHttpClient();
			HttpPost httpPost = new HttpPost("http://localhost:8080/Teste/principal?action=armazenar");

			List<NameValuePair> nvps = new ArrayList<NameValuePair>();
			nvps.add(new BasicNameValuePair("arquivo", stringDoXml));//Classes java transformada em XML via XStream
			httpPost.setEntity(new UrlEncodedFormEntity(nvps, HTTP.UTF_8));

			ResponseHandler<String> responseHandler = new BasicResponseHandler();
			String retorno = httpclient.execute(httpPost, responseHandler);

                        //TODO processar o retorno
		}finally {
			try {httpclient.getConnectionManager().shutdown();} catch (Exception e) {}
		}

No servidor, criei uma Servlet simples:

private void execute(HttpServletRequest request, HttpServletResponse response) {
		String action = request.getParameter("action");
		if(action != null && action.equals("armazenar")) {
			String textoXML = request.getParameter("arquivo");

			Armazenagem armazenagem = new Armazenagem();
			armazenagem.armazenarDados(textoXML );
		}
		
		ServletOutputStream os = null;
		try {
			os = response.getOutputStream();
			os.print("ok");
			os.flush();
		}catch (Exception e) {
			e.printStackTrace();//TODO
		}finally {
			try {os.close();} catch (Exception err) {}	
		}
	}

Ta funcionando legal…Valeu…

Agora tenho outra duvida (não entendo nada de segurança na WEB)…

Desse jeito ficou aberto qq um pode fazer a requisição para o servidor e passar os parâmetros que ele vai aceitar… Como eu faço para permitir que somente os MEUS clientes que eu desenvolvi em Swing acessem o servidor?

Existe alguma maneira (sem ter que reinventar a roda) de criptografas os dados que eu passo via os parametros da requisição Post, para que não corra risco caso a requisição seja interceptada no meio do caminho?

Obrigado…

Usando REST vc pode se beneficiar de muitas tecnologias que vc tem para a web.

Vc pode usar uma combinação de OpenID + SSL ou OAuth + SSL (via http://hueniverse.com/oauth/ ) por exemplo, ou usar apenas Basic Authentication se quiser uma segurança ligeiramente acima do 0.

Voce pode utilizar uma API da Sun chamada Java Cryptography Architecture(JCA) que inclui a Java Cryptographic Extension (JCE)

É uma API extremamente complexa, mas acho que vale a pena voce estuda-la se quiser implementar algo profissional.

http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html

http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html

http://www.java2s.com/Code/Java/Security/EncryptingandDecryptingwiththeJCE.htm

Mas ainda acho mais fácil e interessante aprender a usar essa API de criptografia do que aprender esse tal de REST.

peczenyj, eu li pela internet os conceitos de REST, realmente achei interessante, mas me diz uma coisa (duvida de noob mesmo) do que eu fiz ai em cima o que falta para ser REST… ou o que eu fiz não tem nada a ver e eu entendi tudo errado?

valeu…