Devo usar JBoss?

Programação Java
#1

Olá,

Estou desenvolvendo uma aplicação cliente-servidor. No servidor está o banco de dados, e as máquinas clientes acessam esse banco de dados através de uma aplicação Swing.

Estou usando JDBC para a aplicação no cliente conectar ao banco de dados no servidor.

O problema é que para isso funcionar eu tenho que habilitar o banco de dados a aceitar conexões remotas TCP/IP. Acho que isso não é muito seguro, porque permite que qualquer computador conecte ao banco de dados, desde que tenha o login e senha do banco. Basta alguma pessoa descompilar os .class em alguma máquina cliente, e ela poderá achar as strings de conexão com as senhas e tudo…

O ideal seria que essas strings de conexão, etc… estivessem no servidor, e não nos clientes. Daí mesmo que alguem pegue esses .class e descompile, não adiantaria nada, porque meu banco só vai permitir conexões locais.

Daí qual seria a solução para essa questão? Devo usar RMI? Resolveria esse problema? Ou usar JBoss?

Obrigado.

#2

Olá

Retire todo e qualquer código de acesso à base de dados da sua aplicação cliente Swing. Crie um pequeno servlet que receba as solicitações do cliente swing para acesso à base de dados e que responda com o resultado do comando SQL. Para troca de mensagens entre o swing e o servlet use URLConnection (ou HttpClient). O servlezinho que acessa à base de dados no servidor por ser instalado no tomcat ou no jetty. Não precisa do JBoss só para isto.

[]s
Luca

#3

Algumas dicas para complementar o post anterior:

. Para a comunicação entre o cliente SWING e o servlet, use um protocolo padrão. Existem vários: SOAP, XML-RPC, JSON, etc. Só não invente mais um !

. No processo de migração, o mais provável é que vc. acabe construindo façades com os métodos de negócio utilizados pelo cliente. Dependendo de como eles existem hoje, pode ser interessante utilizar Statefull Session Beans para a implementação destas façades.

. De modo geral, eu prefiro usar o JBoss como plataforma de produção em vez do Tomcat stand-alone, mesmo quando não existem EJBs nem nada do gênero. Considero que ele agrega facilidades de integração e monitoração que evitam a proliferação de “puxadinhos” na forma de scripts de crontab, servlets “autoexec” e assemelhados, sem, no entanto, exigir demais em termos de treinamento e manutenção como um WebSphere ou BEA.

#4

Olá

Desculpe-me por discordar.

Minha sugestão era para comunicar Java no cliente com Java no servlet. A regra básica para construir as mensagens POST com HttpClient em sistemas com desempenho aceitável é KISS. Portanto jamais use SOAP ou outro protocolo qualquer desenvolvido para interoperabilidade para comunicar 2 lados iguais. Principalmente para fazer uma camada de apresentação de um sisteminha CRUD.

E sobre SFSB eu não sou contra seu uso desde que realmente seja necessário manter o estado (session) em ambientes distribuídos pois pior do que SFSB é SLSB + singletons. Mas não consigo imaginar como refatorar um sistema que usava JDBC na camada de apresentação para ir direto para um ambiente distribuído que só tem serventia em pouquíssimos casos.

[]s
Luca

#5

Não tem do que se desculpar. Eu tb vou discordar e não vou pedir desculpas por isso ;^)

Sem dúvida SOAP é overkill, mas atende ao KISS no quesito “fácil de implementar com as ferramentas existentes”. Montar os dados do POST é tb. é simples, mas vc. tem que implementar classes para serializar/desserializar os dados de um lado e de outro. Pesando estes fatores, ainda mantenho minha posição de usar um protocolo padrão. Minha preferência, neste caso, seria pelo XML-RPC, muito menos “verbose” que o SOAP e com mapeamento automático no lado servidor para métodos de uma classe java convencional - e vc. ainda ganha visibilidade dos dados que passam “no fio” usando qualquer Ethereal da vida.

Um dos pouquissimos casos em que faz algum sentido usar SFSB é justamente quando o front-end é um cliente SWING. Por exemplo, se a interface usa tabelas (típico de CRUDs), a implementação do TableModel correspondente fica mais simples se for utilizado este recurso, com a vantagem de se poder utilizar cursores no lado do servidor para avançar/retroceder no resultset. Como benefício grátis, esta abordagem permite uma implementação da comunicação usando RMI sobre HTTP(S) (ao menos no JBoss), tornando irrelevante a discussão sobre o protocolo.

#6

Olá

Faltou você acrescentar “caso os requisitos do SLA permitam”

Minha experiência com isto é que o throughput fica sofrível. Como já trabalhei com sistemas obrigados por contrato a responder mais transações do que a realidade permitia, continuo achando que as mensagens devem ser as mais simples possíveis. Nem sempre vale economizar tempo de desenvolvimeento achando que colocando mais hardware o sistema acabará sendo usável. Já vi coisas feitas com boa intenção indo para o lixo por falta de desempenho aceitável. E uma das vezes foi justamente quando se enviava classes serializadas nas mensagens ao invés de apenas os campos.

[]s
Luca

#7

Mandar or campos e tratar a resposta correspondem à serialização/desserialização a que me refiro, e que é inevitável. Usei o termo no sentido amplo e não querendo significar “serialização de objetos usando a api do java”.

Quanto a ficar sofrível, cada caso é um caso, e é por isto que existem vários padrões de mensageria. Um dos mais compactos que conheço é o ISO-8583, que, inclusive, possui uma versão XML, mas eu não o utilizaria antes de passar por uma rodada de otimizações em outros pontos do código - mas acho que já estou divagando do tópico.

#8

Olá

Agora entendi e você tem razão.

Sobre serialização Java há casos recomendáveis: é quando o sistema é todo baseado em tabelas, isto é, se a maioria do tráfego de mensagens é composto de ArrayLists para preencher tabelas. Mas eu não imaginei um sistema assim.

Sobre os padrões de mensagens que é um dos meus interesses. Um dos grandes problemas destes padrões é que justamente seu uso não é padronizado. Assim há o EDIFACT de fulano, o ISO-8583 de Redecard e assim por diante. Esta confusão é um dos motivos de se buscar soluções com SOA/EDA.

Uma pergunta: você tem experiência com o JPOS?

O que usou para converter o ISO para XML? Desenvolveu na raça? Usou um produto comercial?

[]s
Luca

#9

Os quais, IMHO, so aumentam a confusão, ainda mais pela visão que se tenta passar de que sistemas díspares vão cooperar apenas por usarem SOA, mas este é assunto para outro thread…

Já usei bastante, mas só a parte de empacotamento/desempacotamento. Existem bancos no Brasil em que toda a mensageria da camada web para o host utiliza este pacote.

O JPoss possui o conceito de Packagers, que fazem a etapa final de conversão dos “bits” em uma mensagem pronta para ser transmitida. Existe um packager que suporta XML, mas não cheguei a utilizá-lo.

O cenário em que usei XML + ISO foi um pouco diferente. Utilizei o XML-RPC (não confundir com o SOAP XML-RPC, veja em http://www.xmlrpc.com !) para fazer uma transação com o host já mandando a mensagem ISO formatada a partir do cliente. A mensagem ISO era um dos argumentos da chamada e usei o JPos do lado do servidor para tratamento dos bits. O lado cliente usava C/C++ e usei um dos bindings disponíveis para esta linguagem

#10

Legal…

Não sabia que dava para usar Servlets com Swing. Sempre pensei que Servlets eram apenas para aplicações web…

Ainda estou meio confuso sobre o que usar… Acho que vou tentar usar servlets, porque parece mais fácil. Vocês falaram umas coisas aí que eu nem sei direito o que é hehehe…

Valeu.

#11

Java Player,

outra solução mais simples é vc definir seus usuários no BD. A senha para acesso ao sistema é a mesma utilizada na conexão com o banco, de maneira que ela não fica gravada em qualquer .class. Obviamente, o acesso precisa ser configurado caso-a-caso de maneira que o banco só permita que o usuário realize as funções de sua alçada.

#12

Dei uma pesquisada a respeito de XML-RPC e SOAP, mas fiquei em dúvida se é mesmo a melhor solução para meu caso.

Posso dizer que meu sistema é em parte um CRUD, usando JTable no cliente para popular dados que ele vai requisitar através do servlet.

Para a comunicação entre o cliente Swing e o servlet no servidor, eu pensei em usar XML usando uma API XML como o XStream.

O servlet no servidor faz uma busca no banco de dados, e gera um ArrayList com esses dados. Depois ele pega esse ArrayList, e faz a serialização usando a API XML XStream. Em seguida envia esse arquivo XML para o cliente, como resposta à requisição.

Esse arquivo XML seria algo do tipo:

<List>

   <Cliente>
      <nome>João da Silva</nome>
      <email>joao_da_silva@yahoo.com.br</email>
      <foneComercial class="Telefone">
         <ddd>55</ddd>
         <numero>5555 5555</numero>
      </foneComercial>
   </Cliente>

   <Cliente>
      <nome>Manuel Fernandes</nome>
      <email>manuel@yahoo.com.br</email>
      <foneComercial class="Telefone">
         <ddd>55</ddd>
         <numero>3333 3333</numero>
      </foneComercial>
   </Cliente>

</List>

Daí o cliente Swing vai pegar esse XML e desserializar, gerando um ArrayList de volta.

No meu código no servidor eu tenho vários metodos do tipo:

public List<Cliente> getClientes();

public List<Produto> getProdutos();

public List<Produto> getProdutosCategoria(int categoria);

Daí eu pensei em criar uma servlet para cada um desses métodos.

Tipo, eu iria criar as classes: ServletGetClientes, ServletGetProdutos, ServletGetProdutosCategoria, etc…

Essa é a solução mais simples que eu consegui enxergar para o meu caso.

O que vocês acham? Gostaria da opinião de você que já mexeram com essas coisas.

Obrigado.

#13